- Which additional control best addresses this objective?
Answer: Require a device-bound certificate and acceptable endpoint posture in addition to the user's authentication.
When a question asks how to block an attacker who has already satisfied user authentication, your signal is that the solution must lie outside the user credential layer entirely. The attack described — stolen password plus MFA fatigue/approval — means the attacker has passed every user-based check. The organization needs a control tied to the device, not the person.
This is where device trust comes in. Answer B requires a device-bound certificate (cryptographically anchored to a specific managed machine and non-exportable) combined with endpoint posture checks (verifying things like OS patch level, antivirus status, or MDM enrollment). An attacker's unmanaged computer cannot present a valid device certificate, so VPN access is denied regardless of how cleanly the user credentials check out. This directly solves the stated problem.
Answer A addresses session confidentiality after a connection is established — it does nothing to prevent the attacker from establishing that connection in the first place. Stronger encryption doesn't gate access; it only protects data in transit.
Answer C shortens the window of exploitation once connected, but it still allows the attacker in. A shorter idle timeout is a containment measure, not a prevention control — it doesn't address the core vulnerability.
Answer D is a network efficiency and traffic-routing feature, not a security access control. Split tunneling has nothing to do with verifying whether the connecting device is trusted or managed.
Study tip: On security exams, when a scenario says user authentication is already compromised, immediately look for controls that operate at a different layer — device identity, network location, or behavioral analytics. Layered security means each control operates independently.
- Which access model best meets the security and accountability requirements?
Answer: Use named identities with multifactor authentication, time-limited approval, and access restricted to the required application.
When a question involves third-party or vendor access to sensitive systems, you should immediately think about three core principles: individual accountability, least privilege, and just-in-time access. These concepts work together — you can't have accountability without named identities, and you limit risk by constraining both scope and duration.
Option C satisfies all three principles simultaneously. Named identities ensure every action is attributable to a specific technician. MFA prevents credential compromise from granting unauthorized access. Time-limited approval means access exists only during sanctioned windows, shrinking your attack surface. Restricting access to only the required application enforces least privilege. This is the textbook implementation of a zero-trust-aligned, privileged access model.
Option A fails on accountability — a shared account means you can log that an action occurred, but not who performed it. Rotating the password is good hygiene, but it doesn't fix the fundamental identity problem. Option B introduces two serious flaws: continuous VPN access gives vendors persistent network presence far beyond what they need, and relying solely on application logs for accountability only works if the application logs are granular enough — which isn't guaranteed. Option D is the weakest control of all. Source-IP restriction alone is easily bypassed through compromised machines or IP spoofing, and omitting individual authentication entirely eliminates any meaningful accountability.
A useful pattern to remember: whenever a scenario mentions accountability and external access, look for the answer that combines named identities + MFA + scoped, time-bounded permissions. Shared accounts and persistent access are almost always distractors on security exams.
- Which change would most directly reduce the compromised laptop's ability to move laterally?
Answer: Enforce internal segmentation and application-specific allow rules for traffic arriving from the remote-access VPN zone.
When a question describes a compromised device that already has valid network access and asks how to limit its damage, you should immediately think about lateral movement and the principle of least privilege. The threat isn't authentication failure — the attacker is already inside. The real problem is that the VPN grants overly broad access to internal subnets, turning one compromised endpoint into a launchpad for scanning file servers and databases.
Option A directly solves this by enforcing internal segmentation and application-specific allow rules scoped to the VPN zone. Even with a valid tunnel, the laptop can only reach explicitly permitted services on permitted ports — a compromised device scanning random subnets and database ports gets blocked at the internal firewall. This is the network-level implementation of least-privilege access and directly constrains lateral movement.
Option B is a red herring. Upgrading the encryption suite hardens the tunnel's confidentiality, but it does nothing about what traffic is allowed once decrypted inside the network. The attacker still has the same internal reach.
Option C addresses authentication frequency, not authorization scope. Reauthenticating more often doesn't change what the session can access — the compromised laptop still reaches the same subnets after it reauthenticates, possibly automatically.
Option D eliminates split tunneling, routing all internet traffic through the concentrator. This improves visibility into outbound internet traffic but has no effect on the laptop's access to internal resources, which is where the lateral movement is happening.
The key study tip here: authentication ≠ authorization. Many distractors on security exams target authentication when the real vulnerability is overly permissive authorization after access is granted.
- Which VPN configuration change would most directly close the identified inspection gap?
Answer: Use full-tunnel routing so both internal and internet-bound traffic traverse the corporate security gateway.
When you see a question about VPN security gaps, your first move should be identifying where traffic flows and where inspection controls live. The core issue here is a mismatch: malware filtering sits at the corporate gateway, but internet-bound traffic never reaches it.
The scenario describes split tunneling — a configuration where only traffic destined for internal resources travels through the VPN, while internet traffic exits directly from the employee's local connection. That's exactly why compromised websites can deliver malware undetected: the infected traffic bypasses the corporate gateway entirely. Answer A closes this gap by switching to full-tunnel routing, forcing all traffic — including internet browsing — through the corporate security gateway where malware filtering and DLP controls can inspect it. This directly solves the identified problem.
Answer B is a red herring. Stronger encryption protects data in transit from eavesdropping, but it does nothing to inspect whether that traffic contains malware. Encryption is about confidentiality, not threat detection. Answer C is similarly off-target — multifactor authentication strengthens identity verification at login time but has no effect on where traffic flows after the session is established. A fully authenticated user can still browse a compromised website through an uninspected local connection. Answer D deepens the problem rather than solving it. Application-based split tunneling still lets browser traffic bypass the gateway, which is precisely the vector being exploited.
A useful rule of thumb: when a security gap is a routing problem, the fix must be a routing solution. Authentication and encryption changes can't compensate for traffic that never reaches your inspection controls.
- Which approach is most likely to provide secure remote connectivity under this constraint?
Answer: Use a TLS-based remote-access VPN configured to operate through the permitted HTTPS-compatible connection.
When a question restricts available ports or protocols, your first move should be to identify which VPN technology can adapt to those constraints — not which one is theoretically more secure in an unconstrained environment.
Here, the network allows outbound TCP 443 (standard HTTPS) but blocks IKE (UDP 500/4500) and ESP (IP protocol 50), which are the foundation of IPsec. The solution that survives this environment must operate entirely within TCP 443, which is exactly what a TLS-based VPN does. Products like SSL/TLS VPNs (OpenVPN in TCP mode, Cisco AnyConnect, etc.) wrap all traffic inside TLS — the same protocol powering HTTPS — making VPN traffic indistinguishable from normal web traffic to the firewall. That makes D correct: it aligns the tunneling protocol with what the network already permits, without requiring any firewall rule changes.
A fails because it ignores the central constraint entirely. IKE and ESP are both blocked, so an IPsec VPN simply cannot establish or maintain a tunnel in this environment, regardless of its encryption quality.
B is dangerous on two levels: an unencrypted proxy provides no confidentiality, and the fact that port 443 is open does not eliminate the need for encryption — it just means the port is accessible.
C has the same fatal flaw as A. A site-to-site IPsec tunnel still requires IKE and ESP, and the problem explicitly states those are blocked and the configuration cannot be changed.
As a study tip: on firewall and VPN questions, always match the protocol to the allowed traffic. TLS-based VPNs exist precisely to traverse restrictive networks — remember "blocked IPsec → go TLS."
- What is the most appropriate security response?
Answer: Require successful gateway certificate and hostname validation, and investigate the cause of the warning before users connect.
When you see a VPN or SSL/TLS question involving certificate warnings, think about what certificates actually do: they authenticate the remote server before any encryption begins. Encryption and authentication are separate guarantees — you can have encrypted traffic sent to the wrong server entirely.
Certificate-name warnings signal that the hostname in the presented certificate doesn't match the server the client is trying to reach. This is a classic indicator of a man-in-the-middle (MITM) attack, where an attacker intercepts the connection and presents a fraudulent or mismatched certificate. The correct response, B, is to halt connections, investigate the root cause (misconfiguration, expired cert, or active MITM), and enforce strict certificate and hostname validation before any user connects. Resolving the warning properly protects users rather than normalizing a dangerous behavior.
A is dangerously wrong because tunnel encryption only protects data in transit — it does nothing if you've already handed that encrypted tunnel to an attacker. You'd be encrypting traffic for the malicious gateway, not against it.
C compounds the problem. Disabling certificate validation entirely removes the only mechanism that verifies server identity. Longer passwords cannot substitute for cryptographic authentication of the gateway — these controls address completely different threats.
D has the risk backwards. Public Wi-Fi is more susceptible to MITM attacks than private corporate networks, so relaxing validation on public networks is precisely the opposite of what sound security policy demands.
The key takeaway: on exam questions involving PKI and TLS, always remember that authentication must succeed before you trust the encryption. If the identity can't be verified, the encryption itself becomes meaningless.
- Which response is most consistent with zero-trust principles?
Answer: Reevaluate the session and terminate or restrict access according to the updated device-risk policy.
When you see a question about zero-trust architecture, anchor yourself to its core principle: trust is never assumed — it is continuously verified. Zero trust treats every session as potentially hostile and makes access decisions dynamically based on real-time signals, not just the initial authentication event.
This is exactly what makes D the right answer. Once the endpoint protection agent stops running, the device no longer meets the compliance baseline the organization established. Under zero trust, that change in device posture immediately triggers a policy reevaluation. The session must be restricted or terminated because the current security context has changed — the original authentication is no longer sufficient evidence that the session remains safe.
The distractors each reflect a "trust once, trust always" mindset that zero trust explicitly rejects. A is the most common trap: it treats strong initial authentication as a permanent hall pass, ignoring that conditions can change mid-session. B introduces a usage-history exception — limiting restrictions to "new" applications — but zero trust doesn't grandfather in access based on past behavior; it evaluates risk right now. C confuses transport-layer encryption (which protects data in transit) with endpoint security; a noncompliant device can still exfiltrate data, run malware, or be compromised even inside an encrypted tunnel.
Study tip: On exam questions about zero trust, watch for answers that rely on historical trust signals (past authentication, prior usage, session start state). Zero trust is fundamentally about continuous verification — if any answer lets a risky condition slide because things were fine earlier, that answer is almost certainly wrong.
- Which conclusion and response are most appropriate?
Answer: The VPN protected data in transit but not the endpoint, so posture checks and endpoint controls should complement access policy.
When analyzing a security incident, your first instinct should be to identify where the control failed — not just which control existed. A layered security model (defense-in-depth) recognizes that no single control protects everything. Here, the VPN and MFA worked exactly as designed: data was encrypted in transit and the user was properly authenticated. The failure occurred after that — on the endpoint itself, where malware intercepted already-decrypted documents.
This makes D the correct conclusion. The VPN's job is to protect data moving across the network, and it did. But endpoint security — malware detection, posture checks, data loss prevention — is responsible for protecting data once it arrives on the device. The appropriate response is to add endpoint controls (like EDR tools and posture assessments before granting access) that address the actual attack surface.
A is backwards logic: MFA strengthens authentication and had nothing to do with the compromise. Removing it would decrease security, not improve it. B misidentifies the problem entirely — encryption key length is irrelevant when the encryption itself was never bypassed. The malware read files after decryption, so a longer key changes nothing. C is a dangerous non-sequitur: bypassing endpoint controls for internal users would make the organization more vulnerable, not less, since the same malware threat exists internally.
A useful study habit: when a question describes a breach where legitimate controls didn't fail, look for the layer that was missing, not the layer that was present. Attackers don't always break through a wall — sometimes they walk around it.
- Which remote-access design best satisfies these requirements?
Answer: Publish the application through a zero-trust access proxy that evaluates identity and device policy per session.
When you see a question restricting a third-party user to only one application — with no internal IP assignment and no lateral reach to other hosts — you're being tested on zero-trust network access (ZTNA) versus traditional VPN architecture. The core distinction is whether connectivity is granted at the network layer or the application layer.
A clientless proxy that sits in front of a single application is the right tool here. The contractor's browser connects to the proxy, which authenticates the session and forwards only that application's traffic. The contractor's device never joins the internal network, never receives an internal IP, and has no path to any other host. This is exactly what answer C describes — a zero-trust access proxy that enforces identity and device posture per session, granting application-layer access without network-layer exposure.
A fails because a full-tunnel VPN assigns an internal IP address and routes all traffic through the corporate network. Relying on host firewalls to compensate adds complexity and leaves room for misconfiguration — this is a compensating control, not a clean architecture.
B is closer but still wrong. A split-tunnel VPN, even with narrow routes, still assigns the device an internal IP and grants network-layer connectivity to at least one internal subnet. That violates the requirement that the device not receive an internal address or reach any internal host directly.
D introduces a shared administrative workstation, which creates credential-sharing risks, persistent access concerns, and gives the contractor implicit access to whatever that desktop can reach internally.
Your study tip: when requirements mention "no internal IP" and "single application only," zero-trust proxy is almost always the answer — VPNs operate at Layer 3 and can't satisfy application-only isolation by design.
- Which configuration best aligns with the stated requirement?
Answer: Use a fail-closed kill switch with narrowly controlled exceptions for VPN establishment and captive-portal onboarding.
When a question describes an "always-on VPN" with strict requirements about traffic not bypassing the tunnel, you should immediately think about fail behavior — what happens when the VPN connection drops. This is the core concept being tested here.
The requirement is clear: after onboarding, no traffic may leave outside the tunnel, except the narrow carve-out needed for captive-portal sign-in. That description maps directly to a fail-closed kill switch — a mechanism that blocks all internet traffic the moment the VPN tunnel goes down, rather than allowing traffic to flow freely. The captive-portal exception is handled by permitting only the specific low-privilege traffic needed to authenticate with hotel portals (typically HTTP to a gateway IP), keeping everything else locked. This is exactly what C describes, making it the correct answer.
A is wrong because "fail-open" is the precise opposite of what the company needs. Letting users retain full internet access when the VPN drops is the vulnerability the scenario explicitly identifies — the test already showed this is happening and it's the problem to fix.
B introduces split tunneling, which deliberately sends web traffic outside the VPN tunnel. This directly violates the requirement that no general internet traffic bypasses the tunnel. Split tunneling is a convenience feature, not a security control.
D is a distractor that sounds security-conscious because it mentions stronger encryption, but encryption strength is irrelevant if traffic is escaping the tunnel entirely. Hardening the tunnel does nothing when the tunnel isn't being used.
A useful pattern to remember: on security exams, "always-on VPN" questions almost always hinge on fail-closed vs. fail-open behavior — know that fail-closed = block traffic, fail-open = allow traffic.
