CCSP Container and Serverless Security: What the Exam Covers in 2026

Part of our CCSP Complete Guide series.

Container and serverless security has expanded significantly in the 2026 CCSP CBK. These technologies have moved from “emerging” to “mainstream infrastructure” in most enterprise cloud environments, and the exam reflects that shift.

This article covers the specific concepts tested and how the CCSP frames container and serverless security questions.

Domain Placement

Container and serverless security content appears primarily in two domains:

• Domain 3 (Cloud Platform and Infrastructure Security) — container runtime security, orchestration (Kubernetes), and infrastructure-level controls
• Domain 4 (Cloud Application Security) — container image security, DevSecOps pipeline integration, Infrastructure as Code (IaC) security

The separation reflects the exam’s architecture: Domain 3 covers the platform that runs containers; Domain 4 covers the application packaging and deployment pipeline.

Container Security

Image Security

Image scanning: Container images are built from base images and layers. Vulnerability scanning examines each layer for known CVEs in installed packages. The CCSP tests:

• When to scan (build time, registry push, deployment)
• What scanners evaluate (OS packages, application dependencies, secrets embedded in layers)
• The governance decision: block deployment on critical vulnerabilities vs. accept risk with compensating controls

Image signing and verification: Supply chain attacks can compromise container images between build and deployment. Image signing (Notary, Cosign, Docker Content Trust) and verification at deployment time ensures images haven’t been tampered with. The CCSP tests this as a supply chain control.

Registry security: Container registries (ECR, GCR, Docker Hub, private registries) store images and are access-controlled systems. Registry security includes access controls, vulnerability scanning integration, content trust, and image retention policies.

Minimal base images: Images built on full OS distributions carry more attack surface than images built on minimal base images (Alpine Linux, distroless images). This is a Design principle question in Domain 3.

Runtime Security

Container isolation: Containers share the host kernel, unlike virtual machines. This affects the isolation model and the attack surface. Hypervisor-level isolation (VMs) vs. kernel-namespace isolation (containers) is foundational content.

Privileged containers: Containers running as root or with elevated capabilities weaken the isolation model. The CCSP tests the principle — avoid privileged containers, use the minimum capabilities required — not specific orchestration configuration.

Runtime protection: Behavioral monitoring tools that detect anomalous container activity at runtime (unusual system calls, unexpected network connections, file system modifications). These are detective controls in the defense-in-depth model.

Kubernetes Security

Kubernetes is the dominant container orchestration platform and has substantial dedicated content in Domain 3:

Default service account permissions: By default, Kubernetes pods are assigned a service account with broader permissions than most workloads require. The CCSP famously uses “disabling default service account permissions” as an exam answer because it directly implements least privilege and removes a common privilege escalation path. This is repeatedly testable.

Network policies: Kubernetes allows unrestricted pod-to-pod communication by default. Network policies enforce isolation rules — which pods can communicate with which other pods on which ports. Network policies are a micro-segmentation control.

Admission controllers: Kubernetes admission controllers intercept API requests before object persistence. They enforce policy: blocking privileged pods, requiring resource limits, enforcing image signing requirements. Admission controllers are a preventive control at the API layer.

RBAC (Role-Based Access Control): Kubernetes RBAC controls who can perform which actions on which resources. The principle — least privilege access to API resources — is the same as RBAC generally. Questions test appropriate role design, not RBAC YAML syntax.

Pod security standards: The current Kubernetes mechanism (replacing deprecated Pod Security Policies) for enforcing security profiles on workloads. Three levels: Privileged, Baseline, and Restricted.

etcd security: Kubernetes stores cluster state in etcd. etcd contains credentials, configuration, and secrets. etcd encryption at rest and access control are testable as data security controls.

Control plane security: The Kubernetes API server is the control plane entry point. Its access controls, TLS configuration, and audit logging are testable in security architecture questions.

Serverless Security

Serverless computing — Functions as a Service (FaaS) like AWS Lambda, Azure Functions, and Google Cloud Functions — changes the shared responsibility model and introduces specific security considerations.

Shared Responsibility Differences

In serverless, the CSP manages the execution environment, OS, runtime, and infrastructure. The customer manages function code, function permissions, and data processed. This is a more constrained security surface but shifts some traditional security controls to the CSP entirely.

Function-Level Access Control

Each function should have only the permissions it needs for its specific task. This is least privilege applied at the function level. CCSP questions test this principle in serverless architecture scenarios.

Event Source Security

Serverless functions are triggered by events (API calls, queue messages, database changes, storage events). The event source is a trust boundary — unauthorized triggering of a function is a threat. Event source validation and authentication is a security control.

Cold Start and Ephemeral Execution

Functions spin up, execute, and terminate. They don’t maintain persistent state in memory. This affects secrets management (no long-lived credential caching), forensics (ephemeral execution makes log capture critical), and monitoring design.

Vendor Lock-in Risk

Serverless functions are often deeply tied to provider-specific event models, IAM integration, and API contracts. The CCSP addresses vendor lock-in in Domain 1 (Cloud Architecture) and Domain 6 (Legal/Risk), including contractual portability requirements.

Infrastructure as Code (IaC) Security

IaC security spans Domains 3 and 4 and covers security for Terraform, CloudFormation, Bicep, and similar tools:

• Static analysis: Scanning IaC templates before deployment for misconfigurations (open security groups, publicly accessible S3 buckets, missing encryption settings)
• Policy as code: Tools like Open Policy Agent (OPA) and HashiCorp Sentinel enforce security policies on IaC changes before they’re applied
• Drift detection: Identifying when deployed infrastructure diverges from IaC templates (which may indicate unauthorized manual changes or attacks)
• Secrets in IaC: IaC templates that contain hardcoded credentials or API keys are a supply chain risk

Exam Question Patterns

CCSP questions on container security typically:

• Present a cloud architecture scenario with containers or Kubernetes
• Identify a security requirement (isolation, access control, supply chain integrity)
• Ask which control best addresses the requirement
• Include plausible-sounding but incorrect answers that address a different concern

The governance-first principle applies: questions asking “which control has the HIGHEST priority” typically have a least-privilege or default-misconfiguration answer, not a complex technical control. The “disable default service account permissions” question pattern (from our practice question article) illustrates this: removing excess permissions is the highest-priority initial hardening step because it prevents privilege escalation at the foundation.

Next: CCSP Salary in 2026 | CCSP AI/ML Security