GDSA Practice Questions: Zero Trust Architecture and Networking Domain

Correct answer (B): A defensible Zero Trust rollout starts with understanding what must be protected, who needs access, and how applications and services communicate. Without asset, dependency, and trust mapping, enforcement policies are likely to be misaligned, overly broad, or operationally disruptive. This question tests that Zero Trust is an architecture and operating model, not just a tool deployment exercise.

Why the other options are wrong:
- Option A: Immediate segmentation without understanding dependencies risks avoidable outages and exception sprawl. The blueprint emphasizes learning assets and trust relationships before applying enforcement.
- Option C: MFA is valuable, but leaving current access patterns unchanged does not address over-broad trust, undocumented flows, or inconsistent access models.
- Option D: Perimeter upgrades do not solve the core Zero Trust planning problem, especially when the challenge involves internal trust relationships and hybrid access.

Correct answer (A): A consistent Zero Trust model across hybrid environments should apply identity- and context-based policy to the actual applications and administrative workflows, not extend broad routed trust between cloud and on-premises networks. Brokering access to specific resources reduces unnecessary reachability and provides a common access model regardless of hosting location.

Why the other options are wrong:
- Option B: Treating cloud and on-premises as one trusted network increases blast radius and contradicts Zero Trust assumptions.
- Option C: Separate VPN profiles may improve organization, but they still rely on network access after authentication rather than application-specific authorization.
- Option D: A shared management subnet with coarse firewalling is still a network-centric trust model and is too broad for sensitive hybrid administration.

Correct answer (A): Continuous verification means trust decisions are not permanent. If device posture changes or identity telemetry indicates elevated risk, the architecture should re-evaluate the session and respond by reducing access, requiring stronger verification, or terminating the session. That is a core Zero Trust behavior and goes beyond one-time MFA at login.

Why the other options are wrong:
- Option B: Longer session timeouts reduce prompts, but they increase the window of exposure and move away from adaptive control.
- Option C: Stronger passwords at future logins do not address the current problem that risky sessions remain trusted after conditions change.
- Option D: Geographic restriction may add one contextual control, but it still leaves the flawed design of static session trust untouched.

Correct answer (A): Zero Trust applies to workload and automation identities as well as human users. Narrowly scoped identities, short-lived secrets, and monitored authorization for each workflow reduce standing privilege, limit blast radius, and improve accountability. This is a stronger architectural response than simply protecting or relocating broad shared credentials.

Why the other options are wrong:
- Option B: Encrypting storage helps protect credentials at rest, but annual rotation and shared broad access still leave excessive standing privilege in place.
- Option C: A dedicated subnet can isolate hosts somewhat, but it does not address overbroad identity scope or long-lived reused credentials.
- Option D: Reducing human permissions is useful, but preserving broad persistent automation access leaves a major trust and credential risk unaddressed.

Correct answer (B): Zero Trust removes implicit trust based on network location. In this scenario, the problem is not weak initial authentication; it is that VPN users receive broad network reach after login. The best architectural change is to move from network-level connectivity to application-specific, identity-aware access that evaluates user identity, device health, and session context. That supports least privilege and reduces lateral movement because successful authentication no longer grants unnecessary east-west access.

Why the other options are wrong:
- Option A: Password complexity does not address the architectural flaw. Users would still land on broadly trusted internal network segments after connecting.
- Option C: Perimeter firewall tuning may help some north-south exposure, but it does not solve the core issue that authenticated VPN users still gain internal network access they do not need.
- Option D: More frequent MFA strengthens authentication cadence, but it does not by itself enforce least-privilege application access or contain misuse from an already-authenticated endpoint.

Correct answer (A): An identity-aware access broker is the best fit because it mediates access to the specific payroll application instead of extending broad internal network reachability. That reduces exposed attack surface and aligns with Zero Trust by verifying the user and device for an explicit application workflow rather than trusting the contractor after VPN authentication.

Why the other options are wrong:
- Option B: Separating contractors into a subnet is better than full internal access, but it still relies on network reachability after VPN login rather than limiting access to the authorized application.
- Option C: A reverse proxy can help exposure management, but source IP allowlists are a weak trust signal compared with identity, device posture, and explicit per-application authorization.
- Option D: A jump host can narrow paths in some cases, but this design still preserves broad internal routing and does not reduce trust as effectively as brokering access directly to the application.

Correct answer (B): When a legacy application cannot yet support modern identity patterns, a defensible Zero Trust rollout uses compensating controls that reduce exposure and maintain business continuity. Tight segmentation limits where the application can be reached from and where it can communicate. A brokered or monitored access path for vendors constrains access, improves oversight, and reduces direct connectivity into the production environment. This is the best phased design under the stated constraints.

Why the other options are wrong:
- Option A: MFA helps but still leaves the core problem of broad network access for vendors and little containment around a sensitive legacy system.
- Option C: A forced migration does not match the stated operational constraint, and cloud relocation alone does not guarantee a sound Zero Trust design.
- Option D: A vendor VLAN can still become a broad trusted zone if it reaches much of the plant network. That does not adequately limit pivot opportunities.

Correct answer (B): A defensible Zero Trust rollout is usually phased, not enterprise-wide on day one. The strongest starting point is to identify protect surfaces, validate the flows they require, and place policy and telemetry around those high-value assets first. That reduces risk while limiting operational disruption. It also avoids the common failure of deploying segmentation before understanding dependencies.

Why the other options are wrong:
- Option A: Immediate enterprise-wide micro-segmentation without validated dependencies is likely to break business services and create false confidence rather than a defensible rollout.
- Option C: Stronger external filtering does not address the stated internal trust and hybrid dependency issues. The problem is broader than internet-edge exposure.
- Option D: MFA is valuable, but deferring segmentation and telemetry leaves lateral movement and enforcement visibility gaps largely unresolved.

Correct answer (A): Zero Trust enforcement depends on understanding what must communicate, who uses it, and which business processes are critical. In an outage-sensitive environment such as healthcare, mapping assets, identities, dependencies, and traffic flows first is the most defensible choice because it enables precise policy design and reduces the need for emergency exceptions or disruptive blocking.

Why the other options are wrong:
- Option B: A default-deny model may be the long-term goal, but enforcing it before understanding dependencies is likely to cause outages and emergency exceptions.
- Option C: A VLAN change alone is coarse and does not capture identity, application flow, or trust boundary requirements needed for Zero Trust policy.
- Option D: MFA is valuable, but delaying policy and dependency analysis does not solve the immediate architecture problem of designing safe segmentation.

Correct answer (B): MFA materially reduces credential abuse, but it does not fully protect against already-compromised endpoints, token theft, or session misuse. Zero Trust decisions should include verified identity, device state, context, and policy, and should be continuously re-evaluated where feasible. Adding device posture and contextual checks directly addresses the scenario's stated problem.

Why the other options are wrong:
- Option A: Frequent password changes do not address the key risk here: valid access from compromised devices after successful authentication.
- Option C: Subnet placement may separate applications, but allowing any domain-joined laptop still assumes too much trust in endpoint state and does not provide continuous verification.
- Option D: Shorter sessions may have some value, but continuing to trust internal traffic after login does not address compromised endpoints or context-aware enforcement.