- Which explanation and corrective action best address the problem?
Answer: The LAN prefixes overlap; renumber one LAN or apply supported address translation so remote destinations become uniquely routable.
Whenever you see a VPN scenario where the tunnel is up but traffic never crosses it, your first instinct should be to check the routing logic — specifically whether both sides share the same IP address space.
Here, both LANs use 10.20.0.0/24. When a workstation wants to reach 10.20.0.50, it consults its routing table and sees that address falls within its own local subnet. The operating system concludes the destination is on-link and sends an ARP request out the local Ethernet segment — it never even considers sending the packet to the VPN gateway. No amount of VPN configuration fixes this, because the problem is upstream of the tunnel entirely. The solution, as B correctly states, is to renumber one of the LANs (e.g., change one site to 10.20.1.0/24) or use Network Address Translation (NAT) on the VPN gateway so each side sees uniquely routable destinations.
A is a red herring — bandwidth has no bearing on whether a workstation decides a destination is local or remote. That decision is made purely by comparing the destination IP against the local subnet mask, before any packet is even transmitted. C is similarly irrelevant; encryption algorithms affect confidentiality and integrity, not routing decisions. The cipher suite cannot teach a host that a destination is remote. D misunderstands the architecture — site-to-site VPNs don't require per-workstation client software; they handle routing at the gateway level. Installing a client wouldn't resolve an overlapping subnet conflict.
A useful rule of thumb: overlapping subnets always break routing, regardless of how well the VPN tunnel itself is configured.
- Which implementation best satisfies the requirement while preserving the distinction between the branch LAN and the connecting network?
Answer: Create a site-to-site VPN between the branch and headquarters gateways and route the authorized LAN subnets through it.
When a question describes securing traffic between two fixed locations without touching individual end-user devices, you should immediately think site-to-site VPN. The core concept being tested here is the architectural difference between site-to-site and remote-access VPNs, and what it means to preserve network boundaries.
A site-to-site VPN places the encryption responsibility on the gateway devices at each location — typically routers or firewalls. Every branch workstation routes traffic normally through the local gateway, which then encrypts and tunnels it to headquarters. No per-device software is needed, and the branch LAN remains its own distinct subnet, connected securely through the tunnel. This is exactly what option B describes, making it the correct answer.
Option A fails on two counts: it requires installing VPN client software on every branch device (directly violating the stated requirement) and bridging Ethernet interfaces would collapse network boundaries rather than preserve them. Option C makes things worse by extending the headquarters VLAN across the broadband link, merging both sites into a single broadcast domain — this destroys the subnet distinction the question specifically asks you to preserve, and also introduces broadcast traffic across a potentially slow WAN link. Option D is dangerous and wrong: private IP addresses (RFC 1918 space) provide no encryption whatsoever. They simply aren't routable on the public Internet, but any traffic traveling over broadband can still be intercepted and read at the ISP level.
As a study tip, remember that the phrase "without installing software on every device" is almost always a signal pointing toward a gateway-level or infrastructure solution — site-to-site VPN is the classic answer for branch-to-HQ connectivity.
- Which activity is most likely to continue without relying on a backup WAN or VPN path?
Answer: Opening a file from the branch server by its IP address through the operational local Ethernet switching infrastructure.
When a WAN link goes down, the critical question becomes: which traffic path does this activity depend on? Mentally trace each option's network path — if it must cross the dead WAN connection, it fails. If it stays entirely local, it survives.
Local Ethernet switching operates at Layer 2 and requires no routing beyond the subnet. Since the branch switches are operational and both the workstations and file server share the same subnet with valid IP configurations, accessing the file server by IP address never leaves the local network — making C the activity that continues uninterrupted. No router, no WAN, no headquarters involvement needed.
A fails because directory authentication (think Active Directory or LDAP) sends credential requests to a server physically located at headquarters. Those packets must traverse the branch router's WAN interface — which is down — so authentication requests never arrive.
B fails for a similar reason. The workstations are configured to use the headquarters firewall as their outbound gateway. Internet-bound traffic must first travel over the WAN to reach that firewall, then exit to the cloud. A dead WAN link breaks this path entirely, even though the cloud application itself is reachable from headquarters.
D fails because a remote-access VPN concentrator sitting behind the headquarters edge firewall is, by definition, a headquarters-side resource. Establishing a VPN tunnel requires packets to reach the concentrator — again crossing the severed WAN.
Study tip: On network resilience questions, always ask "does this traffic leave the local subnet?" If it does, and the WAN is down, it fails. Local-only traffic is your survivor.
- Which classification is best supported by the information provided?
Answer: The circuit supplies WAN connectivity between the campuses, but no company-managed VPN exists because no tunnel or cryptographic overlay has been configured.
When classifying network connections, always anchor your reasoning in two independent criteria: physical/logical scope (LAN vs. WAN) and security overlay (VPN vs. no VPN). These are separate questions — a link can be a WAN without being a VPN, and vice versa.
The scenario describes two geographically separated campuses linked by a carrier-provided circuit over which routers exchange ordinary IP packets. Geographic separation with routing between sites is the textbook definition of WAN connectivity. Since the company has configured neither tunneling nor encryption, no VPN exists — a VPN requires a deliberate overlay (like IPsec or SSL/TLS) that creates a secure, logical tunnel. C correctly captures both facts simultaneously: WAN yes, company-managed VPN no.
Choice A fails on the LAN classification. A LAN is defined by geographic locality and typically a single administrative broadcast domain — not merely by the transport medium. Carrier-transported Ethernet between distant campuses does not collapse both sites into one LAN, and the absence of VPN client software is irrelevant to that determination.
Choice B confuses privacy with VPN. A private circuit means the carrier reserves bandwidth exclusively for the company, but "private" in the business sense is not the same as cryptographically secured. A VPN requires an intentional tunnel and encryption layer, neither of which is present here.
Choice D introduces a false prerequisite. Network links can absolutely be classified as LANs or WANs based on topology and scope alone — IPsec authentication is not required for classification.
Study tip: On security exams, always distinguish carrier privacy (dedicated circuit) from cryptographic privacy (VPN). Many questions exploit this exact confusion.
- Which pairing most appropriately addresses the two access patterns?
Answer: Use a site-to-site VPN between branch gateways and remote-access VPN clients for individual traveling employees.
When a question presents two distinct access patterns — a fixed location with many devices versus mobile individuals — your job is to match each pattern to the VPN architecture designed for it. These two architectures serve fundamentally different purposes, and mixing them up is the most common trap on exam questions like this.
A site-to-site VPN connects two networks through their gateway devices, creating a persistent, encrypted tunnel between the branch and headquarters. This is ideal for the staffed branch: hundreds of managed devices share one tunnel without any per-device VPN configuration. Individual traveling employees, however, don't have a corporate gateway — they need remote-access VPN clients installed on their personal devices, which authenticate each user and encrypt traffic from wherever they happen to be. Answer A correctly pairs each solution to the access pattern it was designed for, which is exactly why it's correct.
Answer B reverses the logic entirely — deploying remote-access clients on every branch device is operationally wasteful and unnecessary when one site-to-site tunnel handles the whole branch, and no traveler controls their hotel's router to establish a site-to-site VPN from it.
Answer C is a security failure on both fronts: extending a headquarters VLAN over an untrusted WAN introduces serious broadcast and exposure risks, and unencrypted Internet routing for travelers leaves sensitive data completely exposed.
Answer D is neither practical nor secure — dedicated WAN circuits for every individual traveler would be prohibitively expensive, and local Ethernet switching does nothing to securely connect headquarters to the branch across the Internet.
Your study tip: memorize the rule "site-to-site = network-to-network; remote-access = user-to-network." Exam questions will often swap these, so identifying who is connecting (a whole site vs. an individual) should immediately guide your answer.
- Which assessment of the analyst's claim is most accurate?
Answer: The claim is incorrect; multiple routed subnets can remain part of a locally administered LAN environment within the office.
When you see a question mixing networking topology terms like LAN, WAN, and VLAN, anchor yourself to the definitions of those terms rather than assumptions about routing behavior.
A LAN (Local Area Network) is defined by administrative ownership and physical scope — it's a network you manage locally, typically within a single site. A WAN (Wide Area Network) spans geographically separate locations, often across third-party infrastructure. Routing, by itself, does not determine which category a network falls into. VLANs are logical subdivisions of a physical network; a firewall routing traffic between two VLANs in the same office building is simply performing inter-VLAN routing, not connecting geographically or administratively separate networks. Both VLANs remain under the company's local administration, within the same building — that's a LAN environment by definition. Answer A correctly captures this: multiple routed subnets can absolutely coexist within a single, locally administered LAN.
Answer B is the trap the question is designed for. It confuses the act of routing with the definition of a WAN. Routers connect network segments, but crossing a router doesn't teleport you into a WAN — distance, ownership boundaries, and administrative scope are what matter.
Answer C introduces a fictional concept — firewall inspection doesn't reclassify a network segment's geographic or administrative scope. There's no such thing as "firewall inspection converting a VLAN into a WAN."
Answer D incorrectly implies that VPN tunneling is what keeps routed VLANs within a LAN. VPNs extend or secure connections; they don't define LAN vs. WAN boundaries.
Your study tip: always classify LAN vs. WAN by administrative ownership and geographic scope, not by the presence of routers or firewalls.
- Which conclusion best explains both captures?
Answer: The VPN protects traffic between the laptop and VPN gateway, but traffic can be plaintext after tunnel termination.
When you see a question involving VPNs and traffic visibility, focus on where the VPN tunnel begins and ends — because protection only exists inside that tunnel, not beyond it.
A full-tunnel remote-access VPN encapsulates all outgoing traffic from the laptop and encrypts it until it reaches the VPN gateway inside the corporate network. That's why the wireless capture shows nothing readable — the HTTP request is wrapped inside an encrypted tunnel traversing the untrusted Wi-Fi. Once that tunnel terminates at the VPN gateway, the traffic is decapsulated and forwarded in its original form. Since the application uses plain HTTP, the traffic beyond the gateway is completely unencrypted — exactly what the internal corporate capture reveals. Answer D captures this precisely: the VPN protects the laptop-to-gateway segment, but post-termination traffic reflects the underlying protocol with no additional protection.
Answer A is wrong on two counts — the wireless network never joins the corporate LAN (that's the point of a VPN overlay), and access points have no mechanism to silently upgrade HTTP to HTTPS. Answer B incorrectly claims the VPN failed to encrypt, when the wireless capture's unreadability is direct evidence the encryption worked; private addressing alone wouldn't hide payload content from a packet capture. Answer C confuses tunnel encryption with application-layer encryption — a VPN doesn't provide end-to-end encryption at the application layer, and VPN passwords aren't used to decrypt HTTP payloads inside the network.
A useful rule of thumb: VPN protection ends at the gateway. Always ask yourself what happens to the traffic after the tunnel drops — if the application isn't encrypted, that segment is exposed.
- Which explanation best accounts for this behavior?
Answer: Only matching corporate-subnet traffic enters the VPN; other destinations follow the branch router's local Internet default route.
When you see a VPN question describing split behavior — some traffic reaching one destination, other traffic going elsewhere — you should immediately think about traffic selectors (also called interesting traffic or proxy IDs). These define which packets a site-to-site VPN will encapsulate and tunnel. Everything outside those selectors is handled by the router's normal routing table.
In this scenario, the VPN is configured with selectors matching only 10.2.0.0/16 ↔ 10.1.0.0/16. Traffic destined for headquarters flows into the tunnel exactly as intended. However, traffic to the public SaaS provider doesn't match either corporate subnet, so it falls through to the branch router's default route — straight out to the local ISP. That's why the SaaS provider sees the branch's public IP rather than headquarters'. Answer B captures this precisely: split tunneling is in effect, and only corporate-subnet traffic enters the VPN.
A is wrong because public SaaS traffic doesn't stay on the branch LAN — it's routed to the Internet. Layer-2 local switching has nothing to do with VPN behavior or public IP visibility. C invents fictional concepts: VPNs don't convert traffic into LAN broadcasts, and there's no "automatic remote-access encapsulation" for public destinations. D is factually false — site-to-site VPNs absolutely do not require all traffic to traverse headquarters. Many deployments intentionally use split tunneling to reduce headquarters bandwidth load.
Study tip: Whenever a question mentions traffic selectors or a specific subnet range in a VPN config, ask yourself: "What happens to traffic outside those selectors?" That question almost always leads you to the correct answer.
- Which statement most accurately classifies the three networking concepts in this design?
Answer: Each office has a LAN, the carrier connection provides WAN connectivity, and IPsec adds a VPN overlay between the routers.
Networking questions like this one test whether you can correctly classify LAN, WAN, and VPN as distinct, non-overlapping concepts — and recognize that a single network design can contain all three simultaneously.
Each office site has its own Local Area Network (LAN) — a group of devices connected within a limited geographic area, typically using Ethernet switching. The carrier-provided circuit linking the two routers spans a large geographic distance and is managed by an external provider, which is the definition of a Wide Area Network (WAN) connection. When the company enables IPsec between the routers, it creates an encrypted logical tunnel over that WAN link — this is a Virtual Private Network (VPN). The VPN doesn't replace the WAN; it rides on top of it as an overlay. Answer C captures all three layers accurately and is correct.
Answer A fails on two counts: sharing private IP addressing does not merge geographically separate Ethernet segments into one LAN, and IPsec is a cryptographic tunnel, not a switching technology — it cannot convert a carrier circuit into a switched link.
Answer B confuses "dedicated" with "virtual private." A carrier circuit being dedicated makes it a leased-line WAN link, not a VPN. VPNs are defined by logical encryption and tunneling, not physical dedication. Also, a routed office network is still a LAN internally — the router is at its edge, not its definition.
Answer D contains two serious errors: a router's presence does not make a network segment a WAN, and IPsec creates a logical overlay — it cannot merge two sites into one physical LAN.
Your study tip: memorize that LAN, WAN, and VPN describe different dimensions — scope, geography, and security overlay respectively — so they can coexist in the same design.
- Which interpretation best explains the observed traffic paths?
Answer: A split-tunnel remote-access VPN sends corporate routes through the VPN while retaining local Internet access for other destinations.
Whenever you see a question describing traffic that takes different paths depending on the destination, think about VPN tunneling modes — specifically whether the VPN captures all traffic or only selected routes.
A split-tunnel VPN is configured with specific routes pushed to the client. In this scenario, the laptop has a VPN route for 10.40.0.0/16 (the corporate network) but keeps its default route pointed at the home router. This means corporate-bound traffic — like the payroll application reaching the company's public IP — travels through the encrypted VPN tunnel, while all other traffic (the training website) exits directly through the home ISP. That's exactly what D describes, and it perfectly explains why each destination sees a different source IP.
Choice A is wrong because a remote-access VPN does not place the laptop on the corporate LAN at Layer 2 — it operates at Layer 3 (routing), not Layer 2 (switching). HTTPS has no influence on which interface traffic uses; that's determined by the routing table, not the application protocol.
Choice B misidentifies the VPN type. A site-to-site VPN connects two networks (typically two office routers), not an individual remote laptop. The home router here is not acting as a tunnel gateway for the corporate side.
Choice C reflects a common misconception. Split tunneling is a deliberate, functional configuration — not a malfunction. Full-tunnel VPNs route everything through the corporate connection, but split tunneling is a valid and widely used alternative.
Study tip: When a question mentions a default route coexisting with a VPN route, that's your signal to think split tunneling — two routes, two paths, by design.
