Free Certificate of Competence in Zero Trust (CCZT) practice test: 30 questions with answers

Zero trust removes implicit trust based on network location, so every request must be authenticated and authorized wherever it originates. Encryption at rest, patching, and separation of duties are sound controls, but the flaw in this scenario is that the LAN itself is treated as trusted.

Assuming breach means designing as if an attacker may already be present, so segmentation, least privilege, and monitoring limit damage and expose misuse. The other options either drop preventive controls or assume systems stay secure without verification, which contradicts zero trust.

NIST SP 800-207 states that network location does not imply trust and that access to resources is granted per session according to dynamic policy. The other statements describe static trust, perimeter-only encryption, and one-time posture checks, all of which zero trust rejects.

Least privilege with just-in-time elevation gives the contractor only the rights needed, only when they are needed, which removes standing admin exposure. Subnet-wide firewall rules and shared keys grant broad, long-lived access, and single sign-on improves convenience without limiting privilege.

Zero trust replaces network-wide reachability with access to individual applications, so each user reaches only the services their role requires. A second concentrator improves availability, a longer password interval changes nothing about what users can reach, and skipping MFA removes verification entirely.

The Policy Engine is the decision component in NIST SP 800-207, using policy and trust signals to grant or deny access. The Policy Enforcement Point carries out decisions on the data path, the Policy Administrator establishes or ends the session, and an identity provider is a supporting source of identity data rather than one of the three logical components.

The Policy Enforcement Point enables, monitors, and terminates connections between a subject and a resource based on decisions from the Policy Engine. The Policy Engine makes the decision rather than carrying it out, and the catalog and dashboard are supporting functions outside the core logical components.

The Policy Engine and Policy Administrator form the control plane in NIST SP 800-207, where decisions and session setup occur. The Policy Enforcement Point, the subject, and the resource all belong to the data plane, so every other pairing includes a data plane element.

Routing every request through a gateway that checks identity and device posture is policy enforcement at a point in front of the resource, which is the core zero trust pattern. VLAN segmentation, log aggregation, and OS hardening are useful controls, but none of them checks each request before forwarding it.

Enclave-based deployment places gateway components in front of a group of resources, mediating access to the whole enclave. Sandboxing isolates applications on endpoints, perimeter-only designs rely on the firewall alone, and an agent-only model removes the gateway that the deployment depends on.

In SDP the controller authenticates initiating and accepting hosts and tells each accepting host which clients are allowed to connect, while application data flows directly between the two hosts. The controller does not relay payloads, store passwords, or remove the need for endpoint security.

Single Packet Authorization keeps the accepting host silent until a valid authorized packet arrives, which hides the service from scanners. Logging only records attempts after exposure, IP allowlisting still trusts network location rather than verified identity, and a wider port range increases exposure.

In SDP the initiating host sends a single packet authorization to the accepting host, and the controller authenticates the client before the accepting host admits it. Accepting hosts do not publish their ports, the controller does not relay application traffic, and identity is never verified only after access is granted.

Under default deny, services stay dark and no connection is admitted until the client's identity and authorization are verified for that session. The other options describe allow-first policies, implicit internal trust, or certificate checks alone, none of which match default deny.

Aligning zero trust with business goals, starting from the most critical data and services, and securing executive sponsorship gives the program direction and funding. Replacing firewalls, buying a single product, or buying tooling before knowing the assets all skip the planning the strategy depends on.

The protect surface is the set of data, applications, assets, and services that matter most, so focusing controls there reduces risk fastest and produces early results. The other options invent legal limits or size requirements, or falsely claim that zero trust removes monitoring.

A strategy sets a phased roadmap with measurable milestones and names accountable owners for each control domain. A strategy should stay vendor-neutral because product selection belongs in implementation planning, and unrealistic retirement deadlines or a vendor configuration guide are not strategy elements.

Presenting zero trust as risk reduction, with outcome metrics that matter to each business owner, builds the support and funding the program needs. Forcing agents without explanation, hiding the budget, and delaying communication all undermine that buy-in.

Zero trust policies depend on knowing what a resource is, who is accountable for it, and how sensitive its data is, so ownership and classification come first. Unrestricted access, a migration, or permanent removal from scope either skip these steps or create new risk.

Transaction flow mapping shows which users, devices, and services actually communicate with which resources, so teams can design policies and segment boundaries from real traffic. Bandwidth planning, personal data cataloging, and marketing schedules are unrelated to that purpose.

A pilot should have a bounded scope with measurable success criteria, plus a monitoring baseline and rollback steps defined before enforcement begins. Covering every unit at once, enforcing everywhere immediately, or disabling audit logs removes the controlled learning a pilot exists to provide.

A small, well-understood application with a named owner lets the team learn and tune policies on a bounded scope, and its sensitive data makes the result meaningful. Enforcing everywhere at once, or starting with systems that have no owner or unmapped dependencies, creates avoidable outage and blind-spot risk.

Staged enforcement lets the team identify non-compliant devices, route them to remediation, and then block access with less disruption. Disabling checks, granting full access to non-compliant laptops, or waiving checks for personal devices removes the control the design is meant to enforce.

Micro-segmentation confines a compromised workload to the flows it legitimately needs, so lateral movement is limited. Opening extra ports, flattening the network, or removing authentication each widens what an attacker can reach.

Phishing-resistant MFA for privileged accounts, conditional access that weighs device health and sign-in risk, and least-privilege roles mapped to job functions are standard early controls for user access. Shared administrator accounts and disabled audit logs weaken the accountability and visibility that zero trust depends on.

Phased expansion that tunes policies with pilot metrics such as false positives and access failures keeps disruption manageable and improves each wave. Expanding everything at once, stopping monitoring, or copying policies without review each remove the learning or the fit that a sound rollout relies on.

Executive Order 14028, issued in 2021, directs federal agencies to move toward zero trust architecture. The NIST control catalog, the digital identity guidelines, and the CISA vulnerability catalog are valuable references, but none of them is the directive that set the adoption requirement.

The CISA Zero Trust Maturity Model gives agencies maturity stages for measuring progress across its pillars. It does not certify products, replace NIST SP 800-207, or allocate testing budgets.

The Devices pillar of the CISA model covers endpoint health, asset inventory, and device compliance, which is where these gaps sit. Vendor onboarding, facility access, and hardware refresh planning are real operational topics but do not belong to any of the model's five pillars.

Visibility and analytics is a cross-cutting capability in the CISA model that supplies the logging and telemetry needed to confirm whether policies work. Automation and orchestration is also cross-cutting, but it acts on signals rather than producing the visibility the agency lacks, and NAT tuning and budget forecasting are unrelated.