CompTIA Network+ Part A: 40 PBQs

Sort the layers (from layer 1 to layer 7) to form the OSI Model.

Match the network topology to the description:

Fill in the blank with the network type:

Order these provider links from the slowest transmission speed to the fastest:

Order these cables from the slowest transmission speed to the fastest:

You are tasked with configuring a home office wireless access point following the details below. Additionally, you are requested to assign the first possible IP address to PC_1 and the second possible IP address to PC_2.

WiFi CONFIGURATION DETAILS
Network SSID: LabsDigest
Network ID: 10.0.0.0/16
Host ID: 10.0.0.1

Click on the icons to configure the devices…

PC_1 is unable to access the internet. As a network administrator, you are tasked with troubleshooting the issue.

NETWORK DETAILS.
Network ID: 140.20.40.0/16
Available IPv4 addresses: 140.20.40.10 - 140.20.40.12
Default gateway: 140.20.40.1

Click on the icons to configure the devices…

Match the fiber optic connector to the image:

You are tasked with creating a network with 8 subnets and 30 hosts per subnet. Configure the router following the details below.

ROUTER CONFIGURATION DETAILS
Network ID: 192.168.2.0
Number of Subnets: 8
Number of Hosts/Subnet: 30

Click on the icon to configure the device…

Match the IP address to the default subnet mask:

You’re the network technician for a mid-sized enterprise migrating several services to a new data center. Before going live, your manager asks you to verify that the right physical or virtual appliances are placed at the correct points in the topology to control traffic flow, segment networks, and protect workloads.

You’re assisting with a branch-office rollout that requires internet access control, shared storage for a small team, and reliable Wi-Fi coverage. The design includes front-end web caching, back-end shared file space, and point-to-point connectivity to extend wireless to a detached building.

Your company is launching a public-facing customer portal with knowledge base, web app, and reporting. You must select appropriate service models (SaaS/PaaS/IaaS), establish secure connectivity, and prepare a pilot before go-live while meeting compliance and minimizing operational overhead.

Steps (Shuffled):

1. Establish identity, access, and baseline policies aligned to the shared responsibility model.

2. Collect business, compliance, and latency requirements for the web app, knowledge base, and reporting.

3. Stand up secure connectivity (site-to-site VPN/Direct Connect) and private DNS to the cloud environment.

4. Map each component to a service model (e.g., SaaS for knowledge base, PaaS for web runtime, IaaS for legacy reporting VM).

5. Conduct a pilot in a non-production subscription/account; validate security controls, performance, and costs.

6. Select cloud provider and primary region(s) that meet data residency, availability, and latency targets.

A branch team needs a small analytics stack: dashboards for sales (SaaS BI), a managed database (PaaS), and a legacy ETL tool that only runs on a VM (IaaS). You must prepare the landing zone, enforce access controls, wire up connectivity, and perform acceptance testing before go-live.

Steps (Shuffled):

1. Configure CI/CD or automated deployment for the PaaS database and ETL job artifacts; enable secrets management.

2. Create a cloud landing zone with management groups/projects, standardized networking, logging, and tagging.

3. Provision the PaaS database service and the IaaS VM for the legacy ETL tool; integrate the SaaS BI tenant.

4. Define RBAC/IAM roles, conditional access, and key management policies consistent with shared responsibility.

5. Implement private connectivity and name resolution between on-prem and cloud (VPN/ExpressRoute + private endpoints).

6. Execute end-to-end validation: data ingestion via ETL, PaaS DB performance, SaaS BI dashboards; document DR/backup and obtain sign-off.

You’re finalizing a Layer 2/Layer 3 design for a new campus network. The design review asks you to confirm how specific traffic types will behave across VLANs and subnets so you can place ACLs and optimize switch behavior.

During a hybrid data center migration, you must confirm how discovery, service access, and group streaming traffic will behave. The change board requires precise classification to avoid accidental cross-subnet floods or misrouted service requests.

You’re preparing a new IDF that aggregates building backbones (MPO trunk to core), floor uplinks (duplex LC to SFPs), legacy cross-connects (SC/ST), and user drops (RJ45). You must terminate and test connectors correctly while minimizing contamination risk and ensuring standards compliance.

Steps (Shuffled):

1. Terminate fiber and copper: install MPO trunk, LC duplex to SFP cages, necessary SC/ST jumpers, and crimp RJ45 using the selected TIA-568 variant.

2. Power down/cover optics and place fiber dust caps; implement ESD and eye-safety precautions.

3. Label ports and update the as-built with connector types, patch panel positions, and cable IDs.

4. Clean/inspect fiber endfaces and adapters with approved tools; verify polarity/keying for duplex and MPO.

5. Run certification: OTDR/OLTS for fiber (loss, reflectance) and wiremap/cert for copper; remediate any fails.

6. Map requirements to the panel: define which positions use MPO, LC, SC/ST, and which use RJ45; select TIA-568A or 568B for copper.

A new lab rack shows flapping links and poor video quality on RF runs. You suspect mixed connector types (LC vs SC vs ST), incorrect copper cords (RJ11 in RJ45 jacks), and coax mismatches (BNC vs F-type). Restore reliability without introducing new faults.

Steps (Shuffled):

1. Replace wrong leads/adapters with correct ones: LC↔SC duplex where needed, MPO-to-LC breakout for leaf switches, proper RJ45 patch cords, and correct BNC/F-type jumpers; ensure MPO keying/polarity.

2. Document fixes and update rack elevation and cable schedule; add “do-not-use” tags to removed cords.

3. Clean and re-seat all optical connectors after replacements; verify latch/bayonet engagement and strain relief.

4. Review the path from endpoint to patch panel to device; note symptoms (flaps, errors, loss) and capture interface logs.

5. Visually identify connector types and seating: check LC/SC/ST latching, anycast-style identical addresses not applicable, and confirm BNC (bayonet) vs F-type (threaded) on coax runs.

6. Verify media/grade compatibility: Cat6 for RJ45 (not RJ11), correct RG-type for F-type/BNC, and duplex fiber types (OM3/OM4/OS2) match transceiver specs.

You’re designing a new headquarters network using the three-tier hierarchical model. The team needs to confirm where to locate inter-VLAN routing, default gateway redundancy, policy enforcement, and edge services so that the core stays fast and the access layer stays simple.

You’re migrating a campus from a traditional Layer 2 access model to routed access in selected buildings. The change board wants clarity on where to place STP roots, how uplinks operate, and what the core should do during fast convergence.

You’re bringing a new branch online. The firewall has one public WAN IP, and internal networks must use private addressing with NAT/PAT for internet access. You also need a stable management loopback on the router and must verify app health using localhost without leaking public addresses into the LAN.

Steps (Shuffled):

1. Configure DHCP scopes for user/server VLANs with gateway, DNS, and lease parameters; disable any legacy static ranges that overlap.

2. Select a private RFC1918 block (e.g., 10.10.0.0/20) and create a subnet plan for user, voice, and server VLANs; avoid public ranges entirely.

3. Configure NAT/PAT on the firewall to translate internal RFC1918 addresses to the single public IP; apply egress ACLs and a default route.

4. Test a client: confirm it received a non-APIPA private address, can ping its default gateway, and can resolve/browse to an external site.

5. Create a router/firewall loopback interface using an RFC1918 /32 for management/monitoring; note that 127.0.0.1 is localhost and never routed.

6. For application self-tests on servers, use localhost/127.0.0.1 to verify service binding; then test remote reachability using the host’s assigned private IP.

A new branch receives the block 10.42.16.0/22 for all on-site networks. You must carve subnets for: LAN-A (180 hosts), LAN-B (60 hosts), Voice (30 hosts), Printers (12 hosts), and a /30 point-to-point WAN to HQ. Deliver a documented plan and bring the site online cleanly.

Steps (Shuffled):

1. Allocate subnets from largest to smallest, placing each on a clean binary boundary and recording network/broadcast/usable ranges.

2. Configure SVI/Layer-3 interfaces and the WAN /30 on the branch router; apply DHCP scopes per VLAN.

3. Validate the base assignment and confirm there’s no overlap with other branches: 10.42.16.0/22 is reserved for this site.

4. Order the requirements by host count and select the smallest mask that satisfies each (e.g., /24 for ~180, /26 for ~60, /27 for ~30, /28 for ~12, /30 for WAN).

5. Test end-to-end: clients obtain leases, default gateway pings succeed, and the WAN peer is reachable; correct any mis-sized scopes.

6. Document the final VLSM plan in the IPAM/as-built, including gateway IPs, exclusions, and VLAN IDs.

You’re bringing up new access switches in a wiring closet. Uplinks must trunk to the distribution layer, IP phones will sit in front of users’ PCs, and a few legacy printers require fixed interface settings. Match each interface concept to its correct function so the change window closes cleanly.

Before adding new PoE access points and a redundant uplink, you review existing switch interfaces. You discover trunks with mismatched settings, phones that don’t get a voice VLAN, and a bundle that isn’t hashing traffic. Classify each concept correctly so you can remediate in the right place.

Your company is standardizing on an open IGP across access, distribution, and a small WAN. The network team previously used static routes and some EIGRP at one remote site. You must deploy single-area OSPFv2 for IPv4 in a way that avoids accidental adjacencies on user VLANs and keeps costs consistent on multi-gig uplinks.

Steps (Shuffled):

1. Enable OSPF on the required Layer-3 interfaces/uplinks and set interface costs or update the reference bandwidth for multi-gig links.

2. Inventory routed interfaces and subnets; select OSPF (open standard) instead of EIGRP (proprietary) to satisfy multivendor requirements.

3. Configure a stable router-ID (loopback or highest stable address) and OSPF process; set all user-facing access interfaces to passive.

4. Verify adjacencies and the LSDB; confirm only intended neighbors form, and check best paths in the RIB/FIB.

5. Create and apply interface/VLAN summaries at distribution (where applicable) to keep LSAs small and speed convergence.

6. Document the area design (single area 0), passive-interface list, and final costs in the change record and IPAM.

You’re bringing a new internet edge online. The internal network will run OSPF, and the firewall/router must peer eBGP with the ISP. You must prevent RFC1918 leaks to the ISP, advertise only a single summarized public block, and ensure internal VLANs receive a default route without depending on static routes scattered across devices.

Steps (Shuffled):

1. Configure and verify internal OSPF adjacencies on LAN SVIs/uplinks; set passive on access VLANs and confirm internal reachability.

2. Build the eBGP session to the ISP with correct ASN and neighbor settings; receive a default route and apply a maximum-prefix limit.

3. Create outbound route-filters/prefix-lists and a route-map to advertise only the approved aggregate; prevent RFC1918 and more-specific leaks.

4. Validate end-to-end: internal hosts reach the internet via NAT, traceroute follows the default, and no unintended routes appear in the ISP view.

5. Inject default into OSPF (e.g., “default-information originate” tied to the learned/validated BGP default or tracked static) and confirm propagation.

6. Establish a loopback for stable router-ID and BGP source; set timeouts, MD5/TTL security (if required), and logging/monitoring for the edge peer.

You’re expanding Wi-Fi into a new office wing that needs seamless roaming for employees, a high-reliability backhaul between buildings, and a quick peer-to-peer setup for a lab with no wired drops. Match each network type to the correct description so the build sheet is accurate before procurement.

You’re asked to stand up connectivity for a weekend conference across a main hall, two satellite tents, and a registration booth. Some areas have power but no cabling; the AV team also needs a direct high-bandwidth link between the mixing desk and the stage rack. Choose the appropriate network types for each requirement.

Your org is launching a customer portal with order history, payments, and search. Leadership wants DR metrics locked before production so compliance and SLAs are enforceable. You’ll turn business requirements into specific RPO/RTO targets, then align technology and ops to meet them while instrumenting MTTR/MTBF.

Steps (Shuffled):

1. Map business and regulatory impact: classify data/services and document maximum tolerable data loss and downtime by function.

2. Engineer controls to meet the objectives: set backup/replication cadence, cross-region copies, failover tiers, and runbook checkpoints that achieve the chosen targets.

3. Define service-level RTO per service tier (e.g., payments 30 min, search 2 hrs) and RPO per data class (e.g., orders 5 min, web logs 24 hrs).

4. Baseline reliability tracking: implement incident timestamps, failure categorizations, and telemetry needed to calculate MTTR and MTBF going forward.

5. Validate against design: execute a DR rehearsal to prove RTO/RPO, capture deltas, and update runbooks where recovery exceeded plan.

6. Secure sign-off and publish: record metrics, controls, and evidence in the DR policy and change record for audit.

A storage array failed at 09:42, taking the order database and app tier offline. You must restore service within SLA, minimize data loss, and then update operational metrics (MTTR/MTBF) so leadership sees accurate reliability figures and corrective actions.

Steps (Shuffled):

1. Declare the incident and start clocks: open the major incident, notify stakeholders, and begin timing for MTTR and RTO compliance.

2. Select the recovery point that honors RPO: identify the last validated replica/snapshot and confirm expected data loss window.

3. Restore service to users to meet RTO: fail over compute and database to the chosen replica/region; prioritize critical paths (checkout, auth).

4. Validate data integrity against the chosen point and reconcile deltas (e.g., re-queue messages, replay safe logs) to remain within RPO.

5. Close timing and compute MTTR; update incident record and reliability dashboard, then recalc MTBF using current failure history.

6. Implement corrective actions to reduce future risk: add redundancy/spares, adjust snapshot cadence, automate failover steps, and update the DR runbook.

Your company supports a mixed device fleet (managed laptops, personal tablets, and kiosk machines). You must choose the correct client-to-site access method per use case while preventing data leakage and keeping user experience smooth.

You’re revising your remote-access standard. Some users need full inspection through HQ, others need local internet breakout, and BYOD users must avoid installing a client while still reaching key internal web apps. Match each concept to its description to finalize policy.

Your company is about to accept card payments on a new web portal hosted in a public cloud with a small on-prem data center. Leadership wants a clean PCI DSS assessment this quarter while ensuring cardholder data stays in approved regions. You must order the work so scope is tight, controls are effective, and evidence is audit-ready.

Steps (Shuffled):

1. Implement required controls for the in-scope environment (network segmentation/ACLs, MFA for admins, encrypted storage/transit, centralized logging, change control).

2. Define data locality and cryptographic boundaries for cardholder data (choose cloud regions/availability zones, key custody model, and approved cross-region replication settings).

3. Conduct an internal readiness review: verify control operation, collect sample evidence (configs/logs), and remediate gaps; run ASV scans and an internal penetration test where required.

4. Establish PCI scope by mapping the cardholder data environment (CDE): document data flows, systems that store/process/transmit PAN, and systems that can impact CDE security.

5. Complete the formal assessment (SAQ/ROC with a QSA as applicable), obtain the Attestation of Compliance (AOC), and submit to stakeholders/partners.

6. Create and publish ongoing compliance procedures: evidence retention cadence, change-management checkpoints, quarterly scans, and annual re-assessment calendar.

An EU-based company uses several SaaS apps (some hosted outside the EEA) and maintains a small analytics cluster in the cloud. You must validate GDPR readiness, ensure data stays in approved jurisdictions where required, and prove the organization can meet data subject requests and breach-notification timelines.

Steps (Shuffled):

1. Perform a Data Protection Impact Assessment (DPIA) for high-risk processing; update Records of Processing Activities (ROPA) and risk register with mitigations.

2. Classify personal data and map processing activities and transfers (identify controllers/processors, special categories, and all storage/flow locations).

3. Select and configure data-residency options and transfer mechanisms (EU/EEA regions, SCCs/DPA with vendors, geo-fencing, and encryption/pseudonymization strategy).

4. Define lawful bases, retention schedules, and roles (appoint/confirm DPO if required, identify Supervisory Authority, and align privacy notices).

5. Implement controls and procedures: role-based access, least privilege, audit logging, retention/enforcement jobs, key management, and vendor due-diligence reviews.

6. Test operational readiness: execute a sample DSAR end-to-end, test erasure for a data subject, and rehearse the 72-hour breach-notification workflow.

You’re creating an internet-egress policy for a new site. The network firewall must block risky inbound sources, restrict outbound browsing to approved categories, and prevent users from uploading sensitive files. Match each security concept to the correct definition so the change request can be approved.

A branch office is seeing malware callbacks over random ports and users attempting to upload archives to personal cloud storage. You must tighten controls without breaking business applications that rely on specific SaaS domains and legitimate file transfers.

Monday morning, many users on Floor-2 report “no network” or “limited” connectivity. Facilities confirms the wiring closet was “tidied up” over the weekend. You must identify the problem efficiently without breaking unaffected areas.

Steps (Shuffled):

1. Attempt to duplicate the issue on a controlled test device and jack (e.g., plug in a laptop to an affected port/VLAN and capture DHCP/DNS behavior).

2. Gather initial information from tooling (switch logs, port errors, DHCP scope usage, monitoring alerts) to see the current state and impact radius.

3. Separate and approach multiple problems individually (e.g., treat DHCP failures vs. DNS resolution issues as distinct workstreams).

4. Ask targeted questions to users and the help desk (who/where/when, wired vs. Wi-Fi, specific apps affected, consistent or intermittent).

5. Identify concrete symptoms and scope (which VLANs, which closets, which device types); note whether the issue is Layer 1/2 link vs. Layer 3 addressing vs. name resolution.

6. Determine what changed since it last worked (patch-panel moves, switch renumbering, firmware upgrades, VLAN reassignments, DHCP relay edits).

Remote employees report frequent VPN disconnects and slow performance on a CRM SaaS. The issues started “late last week.” You must identify the problem(s) and avoid conflating unrelated causes (e.g., ISP brownouts vs. a policy push).

Steps (Shuffled):

1. Determine what changed recently (VPN client update, TLS cert renewal, BGP/SD-WAN policy change, ISP maintenance, new split-tunnel routes).

2. Reproduce the problem under control: connect a lab endpoint through a known-good ISP to the same VPN profile and load the same SaaS flows while capturing logs/pcaps.

3. Gather objective information: VPN concentrator logs, tunnel health metrics, SD-WAN stats, SaaS status page, ISP telemetry, incident tickets.

4. Identify and enumerate symptoms distinctly (hard VPN drops vs. throughput/latency degradation; which geos/ISPs; which SaaS paths).

5. Ask users targeted questions (time windows, device/OS, home ISP, Wi-Fi vs. wired, does SaaS still lag when VPN is disconnected if allowed).

6. If both issues exist, approach them individually (stabilize tunnel flaps first; separately analyze SaaS latency—CDN region, DNS, split/full tunnel path).

After a “closet cleanup,” users on VLAN 30 can’t obtain IP leases. You hypothesize the DHCP relay on the SVI was altered. Arrange the correct testing actions by matching the terms to their definitions so you can either fix the issue or pivot cleanly.

Remote users report timeouts to an internal web app over the client VPN, but the same app works off VPN. Your theory is an MTU/fragmentation issue on the VPN path. Match the theory-testing steps to the correct definitions so you can either fix MSS/MTU or pivot responsibly.