Zero-Trust Architecture Interview Questions

The central principle of zero-trust architecture per NIST SP 800-207 is that no user, device, or network location is implicitly trusted just because it's inside the traditional network perimeter — every access request must be authenticated, authorized, and evaluated based on identity and context, regardless of where it originates. That's a direct rejection of the older castle-and-moat model, where anything already inside the perimeter was implicitly trusted.

It means authentication is not a one-time event at login; instead, the system continuously evaluates identity, device posture, and context (such as location or behavior) on every request, revoking or challenging access if risk changes mid-session.

The foundational slogan of Zero-Trust Architecture is: "never trust, always verify." This means no user, device, or network segment is inherently trusted, even if it resides inside the corporate perimeter.

In a Zero-Trust model, an access decision is based on verifying both the user's identity and the posture of the device they are using — factors such as OS version, encryption status, and patch level collectively referred to as device posture.

BeyondCorp replaces the traditional binary notion of "inside the trusted network" versus "outside" with a model in which every access request is evaluated against the identity of the requesting user and the security state of the requesting device, regardless of network location.

False. Rejecting exactly this assumption is the defining move of zero trust — no asset is granted trust based on physical or network location. A device on the internal network still has to be authenticated and authorized for every access request; being physically or topologically inside the network carries no special weight on its own.

The core tenets from NIST SP 800-207 are that every access request is authenticated and authorized regardless of network location, access is granted per-session with continuous verification, and policy decisions use identity, device posture, and context rather than IP address alone. Zero-Trust rejects the idea that passing a VPN perimeter or trusting the network layer grants implicit trust to internal resources.

We replace the VPN with an identity-centric model built around Okta as our identity provider. Users authenticate to Okta with password + MFA (WebAuthn/TOTP). Okta issues short-lived OIDC access tokens (JWT, 15-minute lifetime) and refresh tokens. All internal dashboards and APIs sit behind an Envoy-based reverse proxy (or API gateway) that acts as the policy enforcement point (PEP). On every request, the PEP extracts the JWT, validates its signature and expiry, and queries an Open Policy Agent (OPA) instance acting as the policy decision point (PDP). OPA evaluates policies such as 'user must belong to group X and request must originate from a managed device' and returns allow/deny. For service-to-service communication, each service obtains a SPIFFE Verifiable Identity Document (SVID) via SPIRE, presenting it as an mTLS client certificate. Services validate each other's SPIFFE IDs and enforce authorization via OPA sidecars. Token lifetimes are 15 minutes; refresh requires an active session with Okta. When a user is revoked (e.g., terminated), Okta invalidates their session and refresh tokens. Because access tokens expire in 15 minutes and the PEP re-evaluates policy on every request, the revoked user loses access within at most 15 minutes. For faster revocation, the PEP can perform token introspection against Okta for sensitive endpoints, cutting access to near-immediate. Legacy services that cannot validate JWTs or mTLS sit behind the PEP, which terminates and strips credentials before forwarding — they never see untrusted traffic directly.

We deploy a device trust client (e.g., Duo Device Health, Jamf Compliance for macOS, or Microsoft Intune compliance for Windows) on all managed laptops. The client continuously collects posture signals — OS version and patch level, FileVault/BitLocker encryption status, EDR agent (e.g., CrowdStrike) running and healthy, and jailbreak/root status — and reports them to a posture evaluation service (integrated with our IdP or a dedicated device trust broker) every 5 minutes via a heartbeat. The posture service maps these signals to a compliance verdict. When a user authenticates to Okta, the access proxy (acting as PEP) queries the posture service for the device's current compliance status and enforces policy: compliant managed laptops get full access to internal apps; non-compliant devices are redirected to a remediation page. Because sessions have a 15-minute TTL and the PEP re-checks posture on token refresh, a device whose EDR agent stops running loses access within 15 minutes. For faster response, the posture service can push a session revocation event to the access proxy via a webhook when it detects degradation. BYOD mobile devices cannot have a full MDM agent enforced, so we apply a reduced posture check (e.g., OS version via the access proxy's device profiling) and restrict BYOD access to browser-isolated, less-sensitive applications — sensitive internal dashboards require a managed device. A user cannot bypass checks by uninstalling the agent: the absence of a heartbeat is itself a non-compliant signal, and the PEP blocks access to any device without a recent (within 10 minutes) posture attestation.

The NIST SP 800-207 access flow proceeds: subject requests resource → PEP intercepts → PE gathers context from PIPs → PE evaluates policy and decides → PA instructs PEP to enforce → PEP grants or blocks. The PEP is the gatekeeper, but the PE makes the decision and the PA communicates it before enforcement occurs.

Micro-segmentation means dividing the network into small, granular zones — down to the level of an individual workload or application — each enforcing its own access policy, so that compromising one segment doesn't automatically grant lateral access to the rest of the network. It shrinks the unit of network trust from a broad zone like a subnet or department VLAN down to something much finer, containing lateral movement if any single workload is compromised.

Google's BeyondCorp implementation bases access decisions on what's known about the device and user rather than which network the request originates from, which lets employees work productively from an untrusted network without a traditional VPN, backed by a managed device inventory whose continuously evaluated certificates and trust signals feed into each access decision. It does not require physical office presence — untethering access from the office network is one of its headline goals — and it does not eliminate authentication; it authenticates more rigorously per request, just without relying on network location to do part of that job.

True. Zero trust treats authentication and authorization as ongoing rather than a single event at login — a Policy Enforcement Point can monitor a session already in progress and terminate it if the risk picture changes, such as a device suddenly failing a posture check or a user's behavior deviating from their baseline. A one-time login check has no mechanism to react to any of that after the session starts.

The perimeter model concentrates defenses at the network edge — firewalls, VPN gateways — and implicitly trusts anything already inside, on the assumption that getting past the perimeter is hard and everything behind it is therefore safe. That assumption breaks down for a few converging reasons: once an attacker breaches the perimeter, whether through phishing, a compromised VPN credential, or a vulnerable internet-facing service, or a request originates from inside via a malicious insider or an already-compromised device, there's little to nothing stopping lateral movement to any other internal resource, since internal traffic is trusted by default. It also stopped matching modern reality — remote work, BYOD, and cloud services mean there often isn't a clean network 'inside' to defend in the first place. Zero trust responds by moving verification to every individual access request instead of to a single network boundary.

A software-defined perimeter dynamically creates a one-to-one network connection between a verified user or device and the specific resource they've been authorized to reach, keeping every other resource invisible and unreachable — often called 'black cloud' infrastructure, since a resource with no authorized connection doesn't even respond to a network probe from an unauthenticated client. It's a common enforcement mechanism for zero trust's 'never trust, always verify' principle: instead of placing a device broadly on a network and using firewall rules to restrict what it can reach afterward, SDP authenticates and authorizes first, then provisions only the narrow, resource-specific path — reducing attack surface by making unauthorized resources undiscoverable, not merely blocked.

A single access request in a NIST SP 800-207 zero-trust architecture moves through a fixed sequence: the subject requests access through the Policy Enforcement Point, the Policy Engine gathers relevant identity, device, and context signals, the Policy Engine evaluates those signals against policy to reach an allow/deny/limit decision, the Policy Administrator translates that decision into establishing or terminating the session, and finally the Policy Enforcement Point enforces the decision on live traffic while continuing to monitor the session for re-evaluation.

False. In Zero-Trust Architecture, authentication at session start does not lock in permissions for the entire session. Access is continuously re-evaluated per-request or at short intervals based on dynamic signals like device posture, user behavior, and resource sensitivity, because the core principle is 'never trust, always verify.'

In NIST SP 800-207, the Policy Engine and Policy Administrator together form the Policy Decision Point (PDP) — the Policy Engine evaluates policy, identity, and risk signals to reach an allow/deny/limit decision, and the Policy Administrator executes that decision by establishing or terminating the session. The Policy Enforcement Point (PEP) is the separate component that sits at the actual resource boundary and enforces the decision on live traffic, and can also monitor and terminate a session already in progress.

Basic tenets of zero trust from NIST SP 800-207 include treating all data sources and computing services as resources needing protection regardless of network location, granting per-session access scoped to least privilege, making access decisions dynamically from real-time signals like identity and device posture, and continuously monitoring asset security posture to keep improving it. Permanently trusting a device after a single initial check is exactly the assumption zero trust rejects — trust status has to be re-assessed on an ongoing basis, not frozen at the moment of enrollment.

Line 2 — granting access purely because the request originates from the internal 10.0.0.0/8 range extends implicit trust based on network location alone, with no identity or device check at all — exactly the perimeter-based assumption zero trust replaces. Anything that reaches that IP range, including a compromised workstation or an attacker who's already pivoted internally, gets in for free

Line 4 combined with line 2 — issuing a device certificate with no_expiry=true, checked only once at enrollment, freezes the device's trust status at that single moment. If the device later falls out of compliance — disk encryption disabled, the EDR agent removed, months of missed patches — nothing re-evaluates it, and it keeps full access indefinitely on a certificate that no longer reflects reality

Per-session, least-privilege access means a grant is scoped narrowly to exactly what's needed for a specific task or session, and expires or is re-evaluated at session boundaries rather than persisting indefinitely — a data analyst querying one dataset gets access to that dataset for that session, not standing access to every dataset in the warehouse for the life of their employment. A broad, long-lived credential undermines zero trust even when the original login was completely legitimate because it decouples the access grant from the ongoing validity of the context that justified it: if the user's account is later compromised, their device becomes non-compliant, or their role changes, a long-lived broad credential keeps working exactly as before, since nothing re-evaluates it. The whole point of scoping tightly and re-issuing per session is that revoking or narrowing access only requires waiting for or forcing the next evaluation, rather than hunting down every place a standing credential might still be valid.

The correct order is: PEP intercepts the request, Policy Engine evaluates trust signals, Policy Administrator issues a directive, PEP enforces the decision, then the session is continuously monitored. This matches the NIST SP 800-207 access-decision pipeline, where enforcement follows evaluation and continuous monitoring begins only after access is granted.

The component is the Policy Enforcement Point (PEP). The PEP sits between the subject and the protected enterprise resource, intercepting every access request and communicating with the Policy Decision Point (PEP) to obtain an allow/deny verdict before brokering the connection. It enforces least-privilege access by evaluating each request individually—checking identity, device posture, contextual signals, and applicable policy—then granting only the minimum required scope and duration. The PEP never implicitly trusts a prior authentication; it terminates and re-establishes sessions on each request, ensuring that access is revoked or narrowed the moment a policy condition changes.

The PDP is the component that evaluates subject identity, device posture, behavioral signals, and policy rules to render a real-time access decision (grant/deny/step-up). The PEP is the component that sits in the data path and enforces that decision — it intercepts the request, forwards context to the PDP, and allows, blocks, or mediates the session accordingly. Logical separation is mandatory because the PDP must remain unreachable from untrusted networks (it is the crown-jewel trust authority) while the PEP must be distributed at every access boundary (micro-segmented workloads, APIs, service meshes). Co-locating them would expose decision logic to the very request flow it is meant to gate, creating a single point of compromise that could forge allow-decisions. The PEP is treated as untrusted by the PDP; every enforcement request carries fresh evidence rather than relying on prior session state.