CCSP and Zero Trust Cloud Security: What the Exam Tests in 2026

Part of our CCSP Complete Guide series.

Zero trust has moved from industry buzzword to core CCSP exam content. The 2025-2026 CBK update explicitly incorporates zero trust architecture across multiple domains, reflecting the reality that most enterprise cloud security programs now operate under some version of zero trust principles.

Understanding zero trust for the CCSP exam requires more than defining the term. The exam tests your ability to make architectural decisions using zero trust principles — the kind of judgment a senior cloud security professional would exercise when designing or evaluating a cloud security program.

Zero Trust Fundamentals for CCSP

The Core Principle

Zero trust architecture operates on a single foundational assumption: no user, device, or network location should be implicitly trusted. Every access request — whether from inside the corporate network or outside it — must be authenticated, authorized, and continuously validated.

This represents a fundamental shift from perimeter-based security, where users and systems inside the network boundary were implicitly trusted. The CCSP exam tests whether candidates understand why this shift matters for cloud environments specifically.

Why zero trust matters for cloud: Traditional perimeter security assumes a defined inside/outside boundary. Cloud environments dissolve that boundary — workloads run in third-party data centers, users access applications from any location, and data moves between CSPs, partners, and devices without crossing a traditional network perimeter. Zero trust provides the architectural response to this reality.

NIST SP 800-207 Definition

The authoritative reference for zero trust in the CCSP context is NIST SP 800-207 (Zero Trust Architecture). NIST defines seven tenets of zero trust:

1. All data sources and computing services are considered resources
2. All communication is secured regardless of network location
3. Access to individual enterprise resources is granted on a per-session basis
4. Access to resources is determined by dynamic policy
5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets
6. All resource authentication and authorization is dynamic and strictly enforced before access is allowed
7. The enterprise collects as much information as possible about the current state of assets and uses that information to improve its security posture

CCSP questions may reference NIST SP 800-207 directly or test understanding of these principles in scenario form.

Zero Trust Across CCSP Domains

Domain 1: Cloud Architecture and Design

Domain 1 tests zero trust at the architectural design level. Expect questions about:

Reference architectures: Which architectural approach best implements zero trust for a hybrid cloud environment? Questions test knowledge of identity-centric vs. network-centric security design.

Logical segmentation: How should a cloud security architect design access controls when users access workloads across multiple CSPs? Zero trust answers favor identity-based access over network zone-based access.

CSP native zero trust capabilities: AWS IAM, Azure Active Directory Conditional Access, and GCP IAM with VPC Service Controls all implement zero trust principles. Domain 1 questions may test whether a security architect knows which native capabilities to specify for a given architecture requirement.

SASE architecture decisions: When should an organization adopt a SASE architecture? Questions may test the trade-offs between SASE, traditional VPN, and ZTNA-only approaches for cloud access.

Domain 3: Cloud Platform and Infrastructure Security

Domain 3 is where zero trust implementation specifics are most heavily tested. Key topics:

Micro-segmentation: Traditional network segmentation uses VLANs and firewall rules to create zones. Micro-segmentation extends this to the workload level, creating security perimeters around individual VMs, containers, or services. CCSP questions test when micro-segmentation is appropriate and what controls implement it effectively in cloud environments.

Software-Defined Perimeters (SDP): SDP creates dynamically provisioned one-to-one network connections between users and resources. Unlike VPN (which grants broad network access), SDP grants access only to the specific resource the user is authorized for. CCSP questions may compare SDP to traditional VPN in terms of zero trust alignment.

Identity and Access Management integration: Zero trust requires continuous identity verification. Domain 3 questions test how IAM integrates with network access controls to implement zero trust — for example, how service mesh authentication (mTLS) implements zero trust between microservices.

Kubernetes network policies: For container environments, Kubernetes network policies enforce zero trust at the pod communication layer. Domain 3 tests understanding of how these policies implement micro-segmentation and how they should be designed.

CASB (Cloud Access Security Broker): CASB functions as an enforcement point for zero trust policies for SaaS application access. Domain 3 questions test the placement and function of CASB within a zero trust architecture.

Domain 5: Cloud Security Operations

Domain 5 tests zero trust in operational contexts:

Continuous monitoring: Zero trust assumes continuous validation, not one-time authentication. Domain 5 tests how security operations implements continuous monitoring of user behavior, device posture, and access patterns to support zero trust access decisions.

Adaptive authentication: Zero trust enables step-up authentication based on risk signals. Domain 5 questions may test how a security operations team should configure adaptive authentication triggers — for example, requiring MFA step-up when a user accesses sensitive data from an unmanaged device.

Zero trust incident response: How does incident response differ under zero trust? Rather than “detecting the intruder who got past the perimeter,” zero trust operations focus on detecting anomalous access patterns within an already-authenticated session. Domain 5 tests this operational mindset shift.

ZTNA: Zero Trust Network Access

ZTNA replaces or augments VPN for cloud application access. The CCSP exam tests ZTNA in both architectural and operational contexts.

How ZTNA Works

Traditional VPN grants a user access to a network segment, from which they can reach any resource they have network connectivity to. ZTNA grants access to a specific application based on:

1. Identity verification: The user’s identity is verified through an identity provider
2. Device posture assessment: The accessing device is evaluated against security policies (patch level, encryption status, MDM enrollment, etc.)
3. Context evaluation: Time of day, location, behavior patterns, and risk scores are evaluated
4. Application-specific access: Access is granted only to the specified application, not the network

From the user’s perspective, ZTNA may be invisible (agent-based, where a client on the device enforces access policies) or browser-based (agentless, where no client is required).

ZTNA vs. VPN for CCSP Scenarios

CCSP exam questions about ZTNA vs. VPN typically center on the lateral movement risk difference and the appropriate use case for each.

SASE: Secure Access Service Edge

SASE (pronounced “sassy”) converges networking and security functions into a cloud-delivered service. Defined by Gartner in 2019, SASE has become a significant topic in cloud security architecture.

SASE Components

Why SASE for Cloud Environments

Traditional enterprise networks backhauled branch office traffic to a central data center for security inspection before routing to internet or cloud applications. As cloud adoption grew, this created latency and capacity problems.

SASE resolves this by moving security inspection to cloud-based points of presence (PoPs) geographically distributed to minimize latency. Users connect to the nearest SASE PoP, where all security functions are applied, then traffic goes directly to cloud applications.

SASE in CCSP Scenarios

CCSP questions about SASE typically test:

• When SASE is the appropriate architectural choice vs. point solutions
• How SASE components implement zero trust principles
• The trade-offs between single-vendor SASE and best-of-breed integrated stacks
• How SASE handles branch office and remote user security in a consistent way

The CISA Zero Trust Maturity Model

The Cybersecurity and Infrastructure Security Agency (CISA) Zero Trust Maturity Model provides a framework for evaluating and progressing zero trust implementation. It’s referenced in CCSP content particularly for organizations in regulated industries.

CISA Model: Five Pillars

The CISA model organizes zero trust across five pillars:

1. Identity: How users and non-human identities are authenticated and authorized
2. Devices: How device health and compliance are validated before access
3. Networks: How network access is segmented and controlled
4. Applications and Workloads: How application access is managed and secured
5. Data: How data is classified, protected, and access-controlled

CISA Model: Maturity Stages

For each pillar, CISA defines three maturity stages:

CCSP Application

For CCSP scenarios involving regulated organizations (financial services, healthcare, government), the CISA maturity model provides a framework for evaluating where a zero trust program stands and what next steps are appropriate. Questions may ask a security professional to identify which maturity stage a described organization occupies or what controls would advance them to the next stage.

Identity-Centric Access Control

A core principle of zero trust is that identity — not network location — is the primary security control. This has significant implications for cloud security architecture.

Identity as the New Perimeter

In zero trust cloud environments:

• Human identities are verified through strong authentication (MFA, passwordless, phishing-resistant methods like FIDO2/passkeys)
• Non-human identities (service accounts, applications, workloads) are managed through IAM roles, service principals, and workload identity federation rather than shared credentials
• Access decisions are made dynamically based on identity + context, not network segment membership

Privileged Access Management Under Zero Trust

Zero trust changes how privileged access is managed:

• Just-in-time (JIT) access: Privileged access is granted for specific tasks with time limits, rather than assigned permanently
• Just-enough access (JEA): Privilege is scoped to the minimum needed for the specific task
• Session recording and monitoring: All privileged sessions are recorded and behavior-analyzed

CCSP Domain 1 and Domain 3 questions test how identity-centric access control should be designed into cloud architecture. Domain 5 tests how it’s monitored operationally.

Identity Federation Across Cloud Environments

Multi-cloud environments require identity federation — allowing identities managed in one system to be recognized across others. CCSP tests:

• SAML, OAuth 2.0, and OIDC as federation protocols
• Cross-cloud identity federation patterns
• The security implications of federation trust relationships
• How workload identity federation eliminates the need for service account keys

How Zero Trust Questions Are Framed on the CCSP Exam

Understanding the content isn’t enough — you need to understand how zero trust questions are structured on the exam.

Question Pattern: “Which action should be taken FIRST?”

Zero trust questions often test prioritization. For example:

“An organization is migrating to cloud and wants to implement zero trust. Their current environment uses VPN with split tunneling. Which action should the cloud security professional recommend first?”

The answer will involve an assessment or planning step — evaluating current identity infrastructure, assessing application inventory for ZTNA readiness — not jumping to a technical implementation. CCSP rewards the planning/governance response.

Question Pattern: “Which control BEST addresses this requirement?”

“A cloud security architect needs to prevent lateral movement between microservices in a Kubernetes cluster. Which control best addresses this?”

Options might include: network security groups at the cluster level, Kubernetes network policies, service mesh with mTLS, or VPN tunnels between pods. The answer is Kubernetes network policies (or service mesh depending on the exact scenario) — the control that operates at the correct layer for micro-segmentation within a cluster.

Question Pattern: Risk/Governance Decision

“An organization has implemented ZTNA for remote access but still uses traditional VPN for branch office connectivity. The CISO asks about risks. Which risk is MOST significant?”

The answer involves identifying that inconsistent access control models create gaps — branch office traffic doesn’t receive the same zero trust controls as ZTNA traffic, creating a partial trust model that undermines zero trust principles.

Where Design Meets Implementation Friction

The exam presents zero trust as a coherent blueprint, but the first thing that stalls in an actual implementation isn’t a technology choice — it’s the ownership split over who ultimately approves an access request. Organizations built around network perimeters concentrated that decision in one place: firewall rules maintained by a single team. Replace that with dynamic identity-plus-context decisions, and the decision ownership fragments across the network team, the IAM team, and individual application owners, none of whom wants to be the final approver. I’ve watched this gap get filled with exception rules that accumulate quietly during the transition, until the “zero trust” environment is, in practice, an environment full of exceptions wearing a zero trust label.

The other place I see implementations stall is the non-human identity inventory. Human identities get treated as the headline item in any IAM project, but service accounts, CI/CD pipelines, and batch-job credentials routinely get deferred as “we’ll inventory those later.” The result is that organizations declare zero trust migration complete while non-human identities are still running on shared secrets inside the trust boundary. When I assess how far along a zero trust program actually is, checking the ratio of non-human identities still on static credentials tells me more than the human-facing access control metrics do.

Preparing for Zero Trust Content on CCSP

Read the key references:

• NIST SP 800-207 (Zero Trust Architecture) — particularly the tenets and deployment scenarios
• CISA Zero Trust Maturity Model — the five pillars and maturity stages
• CSA Security Guidance (Chapter 8 — Infrastructure Security and related chapters)

Map zero trust to CBK domains rather than studying it as a standalone topic. When you encounter a zero trust concept, ask: Is this an architecture design question (Domain 1)? An implementation question (Domain 3)? An operational monitoring question (Domain 5)?

Practice scenario questions that require choosing between zero trust-aligned and non-zero trust-aligned answers. The exam won’t ask you to define zero trust — it will ask you to apply zero trust principles to a given scenario, often in competition with other plausible approaches.

Understand the why behind zero trust: The exam rewards understanding that zero trust addresses specific weaknesses of perimeter-based security in cloud environments (implicit trust, lateral movement risk, dissolving network boundaries). Knowing the “why” helps you reason through novel scenarios even if you haven’t seen that specific question type before.

Zero Trust for Japan-Based Enterprises

Everything above maps zero trust to the CCSP exam. The same architecture also has to satisfy Japan-specific regulatory and operational expectations once you’re implementing it rather than being tested on it. Three areas come up most often for foreign-affiliated companies operating in Japan.

APPI and access control evidence: The Act on the Protection of Personal Information (APPI), enforced by the Personal Information Protection Commission (PPC), expects organizations to take “necessary and appropriate” measures to prevent unauthorized access to personal data — but it does not mandate a specific architecture. Zero trust’s per-session, identity-centric access decisions produce exactly the kind of access log and authorization evidence that satisfies this expectation in practice, and that a PPC inquiry or breach notification review would ask for. See our APPI compliance guide for foreign companies for the broader obligation set zero trust access logging feeds into.

J-SOX ITGC alignment: For companies subject to Japan’s Financial Instruments and Exchange Act internal control reporting (J-SOX), IT General Controls (ITGC) auditors specifically test access provisioning, access review, and privileged access management. A zero trust deployment with JIT/JEA privileged access and continuous session monitoring (see the identity-centric access control section above) generates the control evidence ITGC testing looks for as a byproduct of normal operation, rather than as a separate compliance exercise. Detail: J-SOX IT General Controls guide.

ISMAP for government-facing cloud: Organizations selling cloud services to Japanese government agencies need ISMAP (Information system Security Management and Assessment Program) registration, which evaluates cloud service security controls against a Japan-specific baseline. Zero trust architecture — particularly the identity federation and continuous monitoring practices covered above — addresses a meaningful share of the access-control and monitoring criteria ISMAP assessors review. See the ISMAP certification guide for the assessment process itself.

Non-human identity is the gap we see most often: Foreign enterprises importing a zero trust design from a US or EU headquarters frequently under-scope non-human identities — service accounts, CI/CD pipelines, and increasingly AI agents that call internal APIs on a schedule or in response to events. The same least-privilege and JIT-access principles that apply to human users apply to these identities, and Japan’s regulatory reviewers are now asking about AI agent access scope specifically. Our AI agent governance and least privilege guide covers this in depth.

None of this changes the CCSP exam content above — NIST SP 800-207 and the CISA Maturity Model are jurisdiction-agnostic. What changes is which evidence you generate along the way, and who ends up asking to see it.

Previous: CCSP Associate Certification Path | CCSP Complete Guide