The 4Cs of Cloud Native Security for the KCSA Exam: Cloud, Cluster, Container & Code

The 4Cs of Cloud Native Security is the single most important mental model on the Kubernetes and Cloud Native Security Associate (KCSA) exam. It appears directly in the Overview of Cloud Native Security domain, and it quietly underpins questions in every other domain too. If you understand the 4Cs deeply — not just as a diagram but as a way of reasoning about where a control belongs — you can answer a surprising number of KCSA questions by elimination.

This guide treats the 4Cs the way a security engineer does: what each layer actually protects, which threats live at each layer, the concrete controls you apply, and how the KCSA tends to phrase the scenarios. By the end you should be able to look at any security control and instantly place it in the right ring of the model.

What the 4Cs Model Actually Says

The 4Cs are four nested layers of security, each one wrapping the one inside it:

Cloud (or corporate datacenter / co-located servers) — the outermost ring
Cluster — the Kubernetes control plane and worker nodes
Container — the runtime that wraps your application
Code — your application itself, the innermost ring

The model comes from the official Kubernetes documentation, and the key idea is defense in depth: each layer provides a security boundary, and a weakness in an outer layer undermines everything inside it. You cannot secure the inner layers if the outer ones are compromised. A perfectly written application (Code) running in a hardened container provides no protection if the Cloud account hosting the cluster has wide-open IAM permissions.

The exam loves this directional relationship. A recurring KCSA signal: security flows inward, and trust flows from the outside in. If the Cloud layer is breached, no amount of Code-layer hardening saves you.

Layer	Protects	Owned mostly by
Cloud	Infrastructure, network, physical hosts, IAM	Cloud provider + platform team
Cluster	API server, etcd, nodes, workloads	Platform / cluster admins
Container	Image contents, runtime privileges	Developers + platform
Code	Application logic, dependencies, secrets in code	Developers

The Cloud Layer

The Cloud layer is the foundation. It covers the infrastructure your cluster runs on, whether that’s a managed Kubernetes service, self-managed VMs, or physical servers in your own datacenter.

What lives here

The cloud provider’s shared responsibility model — the provider secures the underlying hardware and hypervisor; you secure what you put on top.
Identity and Access Management (IAM) for the cloud account that owns the cluster.
Network security at the infrastructure level: VPCs, subnets, security groups, firewall rules.
Physical and host security of the nodes.

Threats and controls

The dominant risk at this layer is over-privileged cloud credentials. If a node’s instance role or service account can read every secret in the cloud account, a single compromised pod can pivot into the entire cloud environment. The KCSA expects you to know that node identities should follow least privilege and that cluster infrastructure should be network-isolated.

Key controls the exam associates with the Cloud layer:

Restrict access to the Kubernetes API server at the network level — it should not be openly reachable from the public internet without controls.
Lock down access to etcd, which holds the entire cluster state including secrets. Etcd should only be reachable by the API server, over TLS, on an isolated network.
Apply least-privilege IAM to nodes and the control plane.
Encrypt infrastructure-level storage and enforce host hardening.

A classic KCSA framing: “An attacker who gains access to which component would have access to the entire cluster’s data, including secrets?” — the answer is etcd, and securing it is a Cloud/Cluster-boundary concern.

The Cluster Layer

The Cluster layer is where Kubernetes-specific security lives. This is the layer most heavily weighted on the KCSA because it covers the components, configurations, and policies that define how the cluster behaves.

Securing the components

The Kubernetes control plane is a set of components, each with its own attack surface:

kube-apiserver — the front door to the cluster. Every request flows through authentication → authorization → admission control. Securing it means strong auth, tight RBAC, and admission controls.
etcd — the cluster datastore; must be encrypted at rest and access-controlled.
kube-controller-manager and kube-scheduler — should communicate over TLS and run with minimal privileges.
kubelet — runs on every node; its API must require authentication and authorization, because an unauthenticated kubelet can be a direct path to running commands in pods.

Authentication, authorization, admission

The KCSA wants you to understand the request flow through the API server, because security controls map directly onto its three stages:

Request → Authentication → Authorization (RBAC) → Admission Control → etcd

Authentication answers who are you? — certificates, tokens, OIDC.
Authorization answers are you allowed to do this? — almost always RBAC (Role-Based Access Control).
Admission control answers should this specific request be allowed/mutated? — validating and mutating admission controllers, including policy engines.

Workload and network policy

At the Cluster layer you also configure runtime guardrails:

RBAC with least-privilege Roles and RoleBindings — never grant cluster-admin casually.
NetworkPolicies to control pod-to-pod traffic. By default, Kubernetes allows all pods to talk to each other; a NetworkPolicy is how you enforce segmentation.
Pod Security Standards (PSS) — the Privileged, Baseline, and Restricted profiles enforced by the Pod Security Admission controller. The exam expects you to know these replaced the deprecated PodSecurityPolicy.
Secrets management — Kubernetes Secrets are only base64-encoded by default, so you should enable encryption at rest for etcd.

A common KCSA question shape: “Which Pod Security Standard should you apply to enforce the most restrictive, hardening-best-practice policy?” — the answer is Restricted.

For a structured walkthrough of how these cluster controls map to the exam’s domain weightings, the KCSA exam topics breakdown is a useful companion.

The Container Layer

The Container layer sits between your cluster and your code. It’s about the image you ship and the privileges the container runs with.

Image security

Containers are only as trustworthy as the images they run. The KCSA emphasizes:

Use minimal base images — fewer packages mean fewer vulnerabilities. Distroless or slim images shrink the attack surface.
Scan images for vulnerabilities before deployment, and continuously afterward.
Verify image provenance — use signed images and trusted registries so you know an image is what it claims to be.
Never bake secrets into images — they end up in image layers and registries.

Runtime privileges

How a container runs matters as much as what’s in it. The exam tests these securityContext settings:

securityContext:
  runAsNonRoot: true          # never run as root
  readOnlyRootFilesystem: true # block writes to the container FS
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL                    # drop all Linux capabilities, add back only what's needed

The principles the KCSA wants you to internalize:

Don’t run as root. A container running as root that escapes its boundary has root on the node.
Avoid privileged: true. A privileged container has near-full access to the host and effectively erases the container boundary.
Drop Linux capabilities to the minimum the workload needs.
Use a read-only root filesystem where possible.

A frequent KCSA framing pits two pod specs against each other and asks which is more secure. The answer almost always favors the one that is non-root, non-privileged, drops capabilities, and uses a read-only filesystem.

The Code Layer

The Code layer is the innermost ring — your application itself. It’s the layer developers control most directly, and the one most often neglected.

What the exam expects

Encrypt traffic with TLS, including service-to-service communication. Don’t assume the internal network is safe.
Limit exposed ports to only what the application needs.
Scan dependencies — third-party libraries are a major source of vulnerabilities (software supply chain risk).
Manage secrets properly — never hardcode credentials in source code; inject them at runtime.
Practice secure coding — validate input, avoid injection flaws, handle errors safely.

Why Code still matters in a hardened cluster

The 4Cs model is explicit that the inner layers cannot compensate for weak outer ones — but the reverse is also true in a subtle way. A vulnerable application is a foothold. Even with strong Cloud, Cluster, and Container controls, an exploitable code-level flaw (say, an unauthenticated admin endpoint) gives an attacker a starting position inside all those boundaries. The 4Cs are layers of reduction of risk, not guarantees. Defense in depth means assuming any single layer can fail.

Putting the 4Cs Together: A Worked Scenario

Consider a typical KCSA scenario: a company runs a payments service on managed Kubernetes. Walk the layers:

Cloud — The cluster’s node IAM role is scoped to only the resources it needs; the API server endpoint is private; etcd is encrypted and isolated.
Cluster — RBAC grants the payments team a namespaced Role, not cluster-admin; a NetworkPolicy blocks all ingress to payment pods except from the API gateway; the namespace enforces the Restricted Pod Security Standard.
Container — The image is a scanned, signed, distroless build; pods run as non-root with all capabilities dropped and a read-only root filesystem.
Code — All traffic is TLS; secrets come from a mounted Secret, not the image; dependencies are scanned in CI.

Now imagine a single weakness: the node IAM role has *:* permissions (a Cloud-layer failure). Every control inside still exists — but a compromised pod can now assume that role and read every secret in the cloud account. The strongest inner layers did not save the system, because the outer layer failed. That is the exam’s core lesson about the 4Cs, expressed as a scenario.

How the KCSA Tests the 4Cs

The KCSA is a multiple-choice exam. It won’t ask you to harden a real cluster — it asks you to place a control in the right layer and reason about layered dependencies. Expect questions like:

“Encrypting etcd at rest addresses a risk at which of the 4C layers?” → Cluster (with a Cloud-infrastructure dependency).
“A team wants to prevent a compromised library from being deployed. Which layer and control?” → Code (dependency scanning) and Container (image scanning).
“Which layer’s failure would most broadly compromise the others?” → Cloud, the outermost.

The meta-skill is the same every time: identify the symptom, map it to a layer, then pick the control that belongs to that layer.

Practice Beats Memorization

The 4Cs look simple as a diagram, but the KCSA rewards people who can apply the model under exam pressure — quickly classifying controls, reasoning about which layer a threat targets, and recognizing when an outer-layer weakness invalidates inner-layer hardening. That fluency comes from repetition against realistic, scenario-style questions, not from re-reading the diagram.

This is exactly where realistic mock exams help. Sailor.sh’s KCSA Mock Exam Bundle is built to mirror the real exam’s domain weightings and scenario style, so you practice classifying controls into the 4Cs the same way the exam asks you to. Working through full-length, timed sets surfaces the gaps in your mental model while there’s still time to fix them — and it builds the pattern-recognition that turns a hard scenario question into an easy elimination.

If you’re still mapping out your overall preparation, pair this with the KCSA study plan and, if you’re weighing the security-associate path against the hands-on CKS, the KCSA vs CKS comparison will help you sequence your certifications.

Conclusion

The 4Cs of Cloud Native Security — Cloud, Cluster, Container, Code — are not just a KCSA exam topic; they’re a durable way to reason about security in any Kubernetes environment. The model’s power is in its directionality: each layer depends on the one outside it, security flows inward, and defense in depth means no single layer is allowed to be your only line of defense.

Master the placement of controls — where IAM, etcd encryption, RBAC, NetworkPolicies, Pod Security Standards, image scanning, non-root containers, and TLS each belong — and you’ll find that a large share of KCSA questions resolve to a confident, reasoned answer. Learn the model, practice applying it, and the exam becomes a test of judgment you’ve already built.

FAQ

What are the 4Cs of Cloud Native Security?

The 4Cs are four nested security layers: Cloud (infrastructure), Cluster (Kubernetes components and policies), Container (image and runtime privileges), and Code (the application). Each layer wraps the one inside it, and securing the inner layers depends on the outer ones being secure first.

Why is the order of the 4Cs important for the KCSA?

Because security and trust flow from the outside in. A weakness in an outer layer (like an over-privileged cloud IAM role) undermines every control in the inner layers. The exam frequently tests this by asking which layer’s failure would most broadly compromise the cluster — the answer trends toward the outermost affected layer, usually Cloud.

Which 4C layer is most heavily tested on the KCSA?

The Cluster layer tends to carry the most weight, because it covers Kubernetes-specific controls — the API server request flow, RBAC, NetworkPolicies, Pod Security Standards, and etcd security — which span multiple KCSA domains.

Did Pod Security Standards replace PodSecurityPolicy?

Yes. PodSecurityPolicy was deprecated and removed. Pod Security Standards (Privileged, Baseline, Restricted), enforced by the Pod Security Admission controller, are the current mechanism, and the KCSA expects you to know the three profiles and when to use Restricted.

Are Kubernetes Secrets encrypted by default?

No. By default, Kubernetes Secrets are only base64-encoded in etcd, which is encoding, not encryption. You should enable encryption at rest for etcd and restrict access to it — a point the KCSA tests directly.

How should I practice for the 4Cs questions on the KCSA?

Use scenario-based mock exams that ask you to classify controls and reason about layered dependencies, rather than just memorizing the diagram. Sailor.sh’s KCSA Mock Exam Bundle is built around the real exam’s domains and scenario style to build that applied fluency.