Zero Trust practice questions

Move the servers into a single larger subnet so internal routing is simplified

Why wrong: Consolidating servers into a single larger subnet does not segment east-west traffic; it actually eliminates any existing Layer 3 boundary, thereby increasing the attack surface for lateral movement rather than reducing it. This approach is tempting because a larger subnet can simplify routing tables and reduce broadcast domain fragmentation, which would be correct if the goal were to improve network performance or reduce administrative overhead, not to contain a breach.

Place the servers behind a network address translation device to hide their IP addresses

Why wrong: NAT can hide addressing details, but it does not provide meaningful internal segmentation or limit east-west access between the workloads. An attacker who compromises one host may still reach the other if no filtering exists.

Rely on password rotation and MFA for administrative logins only

Why wrong: Password rotation and MFA strengthen identity authentication, but they do not restrict network traffic between workloads. Even if an attacker cannot use stolen credentials directly, they could exploit a vulnerability in one server and then move laterally to another through unsegmented east-west paths. Microsegmentation enforces traffic rules independent of authentication state, making it the only option here that actually limits post-compromise movement.

Defense in depth

Why wrong: Defense in depth is a security architecture that layers multiple independent controls—such as network firewalls, IDS/IPS, antivirus, and endpoint protection—so that if one fails, another compensates. While a zero-trust model may include layered defenses, the fundamental premise here is not simply adding more barriers; it is rejecting implicit trust in the network path and continuously evaluating each access request based on identity, device health, and policy. This scenario is about changing the trust model to require verification for every sensitive action, not about layering preventive and detective controls to create redundant lines of defense.

Need-to-know

Why wrong: Need-to-know is an access control principle that restricts access to information or resources to only those users whose job role or mission requires it, often implemented through compartmentalization or formal clearance processes. It defines the static boundaries of what a user may access based on their assigned duties, but it does not address how access decisions are continually validated at the time of each action. The scenario describes a shift where each sensitive operation is rechecked against identity, device posture, and context, which is a dynamic, continuous verification approach—far beyond merely limiting access to information on a need-to-know basis.

Least privilege

Why wrong: Least privilege is a foundational security principle that grants users only the minimum permissions necessary to perform their tasks, reducing the attack surface and limiting potential damage from a compromised account or process. However, it is fundamentally about the initial and ongoing assignment of static access rights, not about requiring explicit validation for every individual access attempt. In this scenario, the team is not simply trimming privileges; they are adopting a model where all access requests—even those from an already authenticated user—are evaluated each time based on identity assurance, device compliance, and contextual risk, which is the defining characteristic of zero trust.

Least privilege, because the user should only have the minimum file permissions needed.

Why wrong: Least privilege is important, but the exhibit shows the bigger issue is trust being granted after one successful login. The user is not receiving excessive file permissions inside the application; instead, the access decision is too permissive over time and location.

Need-to-know, because all finance data should be hidden from anyone outside the department.

Why wrong: Need-to-know limits information to what a person requires for their role, but the exhibit is focused on stale trust decisions after authentication. The problem is not only who can know the data; it is that the session remains trusted without rechecking the user or device.

Defense in depth, because multiple layers are always better than one control.

Why wrong: Defense in depth is a valuable design idea, but this exhibit highlights a trust model problem rather than missing layers. The environment already has a VPN and application controls; the weakness is that one login is being treated as sufficient for continued access.

Defense in depth

Why wrong: Defense in depth is a layered security strategy that combines multiple controls such as firewalls, intrusion prevention, and endpoint protection to create redundancy. However, it does not specifically describe the continuous re-evaluation of device health and session risk that this portal performs. The key differentiator here is the explicit, repeated trust verification before each sensitive action, which is the hallmark of zero trust rather than merely stacking layers.

Least privilege

Why wrong: Least privilege is an access control model that grants users only the minimum permissions required to perform their job functions. While this principle reduces the blast radius of a compromised account, it does not entail real-time device health monitoring or dynamic session re-authentication. The portal's behavior focuses on verifying the trustworthiness of the device and context at every step, which is unrelated to permission level minimization.

Need-to-know

Why wrong: Need-to-know is a data classification principle that restricts access to sensitive information based on whether the user requires it for their specific role or task. It governs what data a user can see, not whether the session or device is currently trustworthy. The portal’s continuous device health validation is a form of dynamic trust assessment, not an information-centric access restriction.

Keep one flat network and increase endpoint antivirus scanning frequency.

Why wrong: Increasing antivirus scanning frequency does not segment the flat network, so an attacker who compromises one user PC can still use ARP spoofing or broadcast-based discovery to reach finance workstations and IP phones directly. This option is tempting because antivirus is a standard defence against malware, and in a scenario where the threat is purely file-based malware propagation rather than network-layer lateral movement, more frequent scanning would reduce infection spread.

Move all printers into the finance VLAN to avoid managing inter-VLAN rules.

Why wrong: Although consolidating printers into the finance VLAN reduces inter-VLAN configuration, it broadens the sensitive subnet's layer 2 attack surface. Printers frequently run outdated firmware and open management ports (SNMP, JetDirect, HTTP) that are prime targets for lateral movement, credential harvesting, or interception of print jobs. Moreover, user workstations still need to print, so you would either need filtering rules from the user VLAN to finance, or you would have to move user devices too — subverting the intended separation. The correct approach is to isolate finance systems and treat printers as untrusted endpoints with dedicated VLANs and strict ACLs.

Disable printing so user workstations cannot communicate with any other device.

Why wrong: Disabling printing eliminates a legitimate business service without achieving any security benefit for the remaining attack paths. User workstations would still share the same flat IPv4 subnet with finance systems and IP phones, so ARP spoofing, broadcast-based discovery, and VLAN hopping remain viable, allowing an attacker to pivot from a compromised PC to sensitive targets. This measure also introduces high operational friction, forcing users to find unsupported alternatives while doing nothing to contain a breach. Proper network segmentation and least-privilege filtering address the root cause without sacrificing required functionality.