Cyber Security Quiz: Secure Remote Access
10 questions · exam conditions
0:00
Secure Remote AccessQuestion 1 of 10

An external support company needs occasional remote access to one production management application. The application is highly sensitive, and the organization must be able to identify which technician performed each action. Support windows are approved in advance.

Which access model best meets the security and accountability requirements?

Issue one shared vendor VPN account protected by multifactor authentication and rotate its password after each support window.
Permit named vendor accounts to use a full network VPN continuously, relying on application logs for accountability.
Use named identities with multifactor authentication, time-limited approval, and access restricted to the required application.
Allow source-IP-restricted access from the vendor's office and omit individual authentication during approved support windows.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Secure Remote Access

Practice Secure Remote Access in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Secure Remote Access, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

An external support company needs occasional remote access to one production management application. The application is highly sensitive, and the organization must be able to identify which technician performed each action. Support windows are approved in advance.

Which access model best meets the security and accountability requirements?

  1. Issue one shared vendor VPN account protected by multifactor authentication and rotate its password after each support window.
  2. Permit named vendor accounts to use a full network VPN continuously, relying on application logs for accountability.
  3. Use named identities with multifactor authentication, time-limited approval, and access restricted to the required application. (correct answer)
  4. Allow source-IP-restricted access from the vendor's office and omit individual authentication during approved support windows.
Explanation: 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.

Question 2

A remote employee uses a properly encrypted VPN and multifactor authentication to reach an internal document system. Malware already present on the employee's laptop reads documents after the authorized user downloads them and then exfiltrates the contents. The VPN logs show no cryptographic or authentication failure.

Which conclusion and response are most appropriate?

  1. The incident shows that multifactor authentication weakened the tunnel, so password-only VPN access should be restored.
  2. The incident primarily indicates insufficient tunnel encryption, so a longer VPN encryption key should prevent recurrence.
  3. The incident resulted from using remote access rather than local access, so internal users should bypass endpoint controls.
  4. The VPN protected data in transit but not the endpoint, so posture checks and endpoint controls should complement access policy. (correct answer)
Explanation: 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.

Question 3

Employees at a customer site must establish remote access through a network that permits outbound web traffic on TCP port 443 but blocks common IPsec negotiation and encapsulation traffic. The company cannot request firewall changes at the customer site.

Which approach is most likely to provide secure remote connectivity under this constraint?

  1. Use an IPsec VPN that depends on IKE and ESP because those protocols are independent of web filtering.
  2. Use an unencrypted proxy on TCP port 443 because the allowed port makes additional tunnel protection unnecessary.
  3. Use a site-to-site IPsec tunnel initiated by the customer firewall without changing its current configuration.
  4. Use a TLS-based remote-access VPN configured to operate through the permitted HTTPS-compatible connection. (correct answer)
Explanation: 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."

Question 4

A company requires managed laptops to use an always-on VPN. Users must be able to complete hotel captive-portal sign-in when necessary, but after onboarding, no business or general internet traffic may bypass the tunnel. Tests show that laptops currently access the internet directly whenever the VPN gateway is unreachable.

Which configuration best aligns with the stated requirement?

  1. Use fail-open behavior so users retain internet access, then reconnect the VPN automatically when the gateway returns.
  2. Use split tunneling for web traffic while sending only corporate application traffic through the always-on VPN.
  3. Use a fail-closed kill switch with narrowly controlled exceptions for VPN establishment and captive-portal onboarding. (correct answer)
  4. Use stronger tunnel encryption while retaining direct internet access whenever VPN establishment is unsuccessful.
Explanation: 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.

Question 5

Attackers steal an employee's password and persuade the employee to approve a fraudulent authentication push. The organization wants VPN access to remain unavailable from an attacker's unmanaged computer, even when the user authentication steps have been satisfied.

Which additional control best addresses this objective?

  1. Increase the VPN's encryption key size so captured sessions are more difficult for the attacker to decrypt.
  2. Require a device-bound certificate and acceptable endpoint posture in addition to the user's authentication. (correct answer)
  3. Shorten VPN idle timeouts so the attacker's authenticated connection disconnects sooner when it becomes inactive.
  4. Use split tunneling so the attacker's public internet traffic does not consume corporate VPN capacity.
Explanation: 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.

Question 6

A contractor needs browser access to one internal project-management application from a personally owned computer. The security team does not want the contractor's device to receive an internal IP address or obtain connectivity to any other internal host.

Which remote-access design best satisfies these requirements?

  1. Provide a full-tunnel VPN account and use host firewalls to prevent access to unrelated internal systems.
  2. Provide a split-tunnel VPN account with routes limited to the subnet containing the project application.
  3. Publish the application through a zero-trust access proxy that evaluates identity and device policy per session. (correct answer)
  4. Provide a remote desktop gateway account that places the contractor on a shared internal administrative workstation.
Explanation: 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.

Question 7

A company routes remote employees' connections to internal applications through a VPN. Internet-bound traffic uses each employee's local connection. The company's malware filtering and data-loss prevention controls operate only at the corporate internet gateway. Security analysts discover that compromised websites are delivering malware to remote laptops without being inspected.

Which VPN configuration change would most directly close the identified inspection gap?

  1. Use full-tunnel routing so both internal and internet-bound traffic traverse the corporate security gateway. (correct answer)
  2. Keep split tunneling but require stronger encryption for traffic sent to internal corporate applications.
  3. Keep split tunneling but require multifactor authentication whenever users establish a new VPN session.
  4. Use application-based split tunneling so approved browsers continue accessing the internet through local gateways.
Explanation: 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.

Question 8

A VPN concentrator authenticates employees securely, but every connected laptop can reach most internal server subnets. A compromised remote laptop uses its valid tunnel to scan file servers and database ports. The company must retain its existing VPN for legacy applications.

Which change would most directly reduce the compromised laptop's ability to move laterally?

  1. Enforce internal segmentation and application-specific allow rules for traffic arriving from the remote-access VPN zone. (correct answer)
  2. Replace the VPN's current encryption suite with a stronger suite while preserving the existing internal routes.
  3. Require users to reauthenticate more frequently while preserving access to the same internal server subnets.
  4. Disable local split tunneling so the compromised laptop sends all public internet traffic through the concentrator.
Explanation: 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.

Question 9

Remote users on public Wi-Fi receive a certificate-name warning when connecting to the corporate VPN gateway. Help-desk staff have been telling users to accept the warning because the VPN traffic will be encrypted after the connection is established.

What is the most appropriate security response?

  1. Continue accepting the warning because tunnel encryption protects traffic even if the gateway's identity cannot be confirmed.
  2. Require successful gateway certificate and hostname validation, and investigate the cause of the warning before users connect. (correct answer)
  3. Disable certificate validation on the client and require longer user passwords to compensate for the unverified gateway identity.
  4. Permit certificate warnings only when connecting from public Wi-Fi because private corporate networks present a greater interception risk.
Explanation: 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.

Question 10

An employee successfully completes multifactor authentication to a zero-trust remote-access service from a compliant managed laptop. During the session, the endpoint protection agent stops running and the device falls out of compliance.

Which response is most consistent with zero-trust principles?

  1. Allow the session until its scheduled expiration because the user was strongly authenticated when it began.
  2. Allow existing application access but deny only requests to applications the user has not previously opened.
  3. Continue the session because transport encryption prevents the noncompliant device from threatening internal resources.
  4. Reevaluate the session and terminate or restrict access according to the updated device-risk policy. (correct answer)
Explanation: 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.