Platform Security for the KCSA Exam: Supply Chain, Image Security, Observability, Service Mesh, PKI & Admission Control

The Platform Security domain accounts for roughly 16% of the Kubernetes and Cloud Native Security Associate (KCSA) exam — and it’s the domain that trips up the most candidates, because it spans the widest range of topics. While the Kubernetes Security Fundamentals and Cluster Component Security domains focus on the cluster’s internals, Platform Security is about everything that surrounds and hardens the platform: the software supply chain, the image registry, security observability, the service mesh, the PKI that underpins trust, network connectivity, and admission control.

This guide maps the entire domain the way a practitioner would, with the exam cues that tell you which concept a question is really testing. Remember the format first: the KCSA is 60 multiple-choice questions in 90 minutes, entirely conceptual — you won’t type commands in the exam. But understanding what each mechanism does and why it matters is exactly what the Platform Security questions reward. Any commands below are for building intuition, not memorization.

What “Platform Security” Actually Covers

The KCSA exam guide breaks Platform Security into a set of connected concerns. Here’s the map, with where each fits:

Sub-topic	The core question it answers
Supply chain security	Can I trust how this software was built and delivered?
Image repository security	Can I trust the images I’m pulling and running?
Observability	Can I see what’s happening well enough to detect abuse?
Service mesh	How do I secure service-to-service traffic and policy?
PKI	How is trust (certificates, identity) established and rotated?
Connectivity	How is network traffic controlled between workloads?
Admission control	How do I enforce policy before an object is admitted?

Notice the pattern: Platform Security is about trust and enforcement at the platform layer — before, around, and between workloads — rather than the RBAC-and-secrets mechanics inside the cluster.

Supply Chain Security

The software supply chain is every step from source code to a running container: dependencies, build systems, artifacts, registries, and deployment. Each step is an attack surface, and the KCSA expects you to understand the defenses.

Key concepts to know:

SBOM (Software Bill of Materials) — a machine-readable inventory of every component and dependency in an artifact. If a new CVE lands, an SBOM tells you instantly whether you’re affected. Formats like SPDX and CycloneDX are the standards.
Artifact signing and verification — cryptographically signing build outputs so consumers can verify authenticity and integrity. Sigstore/cosign is the widely adopted open-source approach.
Provenance and attestation — verifiable metadata about how an artifact was built (which source, which builder). The SLSA framework describes maturity levels for build integrity.
Dependency and vulnerability scanning — catching known-vulnerable dependencies before they ship.

A useful mental model is the “four defenses”: scan (find known vulnerabilities), sign (prove authenticity), attest (prove provenance), and verify (enforce all of the above at admission). If a KCSA question mentions knowing exactly what components are in an image, the answer is an SBOM; if it mentions proving an image came from your trusted pipeline, think signing and provenance/attestation. For a hands-on, CKS-level treatment of these same ideas, see the supply chain security guide.

Image Repository and Registry Security

Container images are the unit you actually deploy, and the registry is where trust is enforced or lost. The KCSA tests several image-security concepts:

Use trusted, minimal base images. Smaller images (distroless, minimal bases) mean fewer packages and a smaller attack surface.
Scan images for vulnerabilities before and after they enter the registry.
Sign images and verify signatures at pull/deploy time so only trusted images run.
Use private registries with authentication and authorization, rather than pulling arbitrary public images.
Pin images by digest, not just tags. Tags are mutable (nginx:latest can change underneath you); a digest (nginx@sha256:...) is immutable and guarantees you run exactly what you reviewed.
Apply least privilege to registry access — separate push and pull permissions, and rotate credentials.

An exam cue: if a question describes preventing a mutable tag from silently changing what runs, the answer involves pinning to an image digest. If it describes only allowing images from an approved registry, that’s enforced at admission control (below), often by an admission policy that rejects images from unapproved sources.

Security Observability

You can’t defend what you can’t see. Observability in the security context means having the signals to detect, investigate, and respond. The three familiar pillars apply, plus a Kubernetes-specific one:

Signal	Security value
Audit logs	Who called the API, when, and what they did — the primary forensic trail
Metrics	Detect anomalies (spikes in denied requests, unusual resource use)
Logs	Application & system behavior for investigation
Traces	Follow a request across services to locate abuse

For Kubernetes specifically, the API server audit log is the highest-value security signal — it records every request to the control plane. Runtime security tooling like Falco watches syscalls to detect suspicious behavior inside running containers (a shell spawned in a container, an unexpected outbound connection). The KCSA cue: “detect malicious runtime behavior in a container” → runtime threat detection (Falco-style); “determine who deleted a resource” → audit logs.

Service Mesh

A service mesh (such as Istio or Linkerd) adds a layer that manages, secures, and observes service-to-service communication — usually via sidecar proxies injected next to each workload. For the KCSA, the security value of a mesh is what matters:

Mutual TLS (mTLS) — the mesh can automatically encrypt and mutually authenticate traffic between services, so each side proves its identity. This gives you encryption in transit and workload identity without changing application code.
Fine-grained authorization policies — allow or deny traffic between specific services (e.g., only the frontend may call the payments service).
Observability — the mesh sees all traffic, providing metrics and traces for security analysis.
Zero-trust networking — a mesh helps implement “never trust, always verify” between workloads, complementing (not replacing) NetworkPolicies.

The key exam takeaway: a service mesh provides mTLS-based encryption and identity plus L7 authorization between services, typically through sidecars, and it’s a common way to achieve zero-trust service-to-service security.

PKI and Certificate Management

Trust in Kubernetes rests on a Public Key Infrastructure (PKI) — a system of certificates and certificate authorities (CAs). The KCSA expects you to know that:

Kubernetes uses TLS certificates extensively: the API server, etcd, kubelets, and controller connections are all secured with certificates issued by the cluster CA.
The cluster CA signs certificates that establish component identity and encrypt control-plane traffic.
Certificate rotation matters — expired certificates break clusters, and short-lived, rotated certs reduce the blast radius of a compromised key.
Kubernetes provides a CertificateSigningRequest (CSR) API to request and issue certificates programmatically.
Service meshes and tools like cert-manager automate issuing and renewing certificates for workloads.

Exam cue: if a question asks what establishes and secures identity/trust between control-plane components, the answer is the cluster’s PKI / TLS certificates. If it stresses automated issuance and renewal of certs, think cert-manager or the CSR API.

Connectivity and Network Security

Controlling how workloads talk to each other is a Platform Security cornerstone. The main mechanisms:

NetworkPolicies — the native Kubernetes object for restricting Pod-to-Pod and Pod-to-external traffic. By default, all Pods can talk to all Pods; a NetworkPolicy lets you switch to default-deny and explicitly allow only required flows.
The CNI plugin — network policy enforcement depends on a CNI that supports it (Calico, Cilium, etc.). Not every CNI enforces NetworkPolicies.
Encryption in transit — via a service mesh (mTLS) or CNI-level encryption.

A minimal default-deny NetworkPolicy — the shape you should recognize:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: prod
spec:
  podSelector: {}        # selects all Pods in the namespace
  policyTypes:
    - Ingress            # with no ingress rules, all ingress is denied

The exam cue: “restrict which Pods can communicate” → NetworkPolicy; and a subtle-but-tested detail is that NetworkPolicies do nothing unless your CNI supports them. For deeper NetworkPolicy mechanics, the KCSA Security Fundamentals guide covers the object model in detail.

Admission Control: Enforcing Policy at the Door

Admission control is arguably the most important Platform Security mechanism, because it’s where policy is enforced before an object is persisted. After a request is authenticated and authorized, it passes through admission controllers — plugins that can validate (accept/reject) or mutate (modify) the request.

Two categories the KCSA tests:

Validating admission — reject non-compliant objects (e.g., “no privileged containers,” “images only from our registry,” “all Pods must have resource limits”).
Mutating admission — modify objects on the way in (e.g., inject a sidecar, add default labels or security context).

Modern policy enforcement is done with dynamic admission webhooks and dedicated policy engines:

Tool / feature	Role
Pod Security Admission (PSA)	Built-in controller enforcing the Pod Security Standards (privileged / baseline / restricted) per namespace
OPA Gatekeeper	Policy engine using Rego to enforce custom validating policies
Kyverno	Kubernetes-native policy engine (YAML policies) for validate/mutate/generate
ValidatingAdmissionPolicy	In-tree CEL-based validation, no external webhook required

The classic exam scenario: “How do you prevent anyone from deploying a privileged container cluster-wide?” The answer is admission control — either built-in Pod Security Admission enforcing the restricted standard, or a policy engine like Gatekeeper/Kyverno. Admission control is also how you enforce the earlier topics: “only signed images from the approved registry” is an admission policy that verifies image signatures at deploy time.

How the KCSA Frames Platform Security Questions

Once you’ve drilled enough questions, the phrasing patterns are recognizable:

“Inventory of all components in an image?” → SBOM.
“Prove an image came from your trusted build pipeline?” → signing + provenance/attestation (Sigstore/SLSA).
“Guarantee you run exactly the reviewed image?” → pin by digest.
“Encrypt and mutually authenticate service-to-service traffic without app changes?” → service mesh mTLS.
“What secures identity between control-plane components?” → PKI / TLS certificates.
“Restrict Pod-to-Pod traffic?” → NetworkPolicy (requires a supporting CNI).
“Reject privileged Pods before they’re created?” → admission control (PSA / Gatekeeper / Kyverno).
“Only allow images from an approved registry?” → admission policy verifying image source/signature.
“Detect a shell spawned inside a running container?” → runtime threat detection (Falco-style).

Almost every answer is a single mechanism. Match the verb in the question — inventory, prove, restrict, reject, encrypt, detect — to the right control, and the domain becomes fast points.

A Focused Study Sequence

To cover Platform Security efficiently:

Supply chain — learn SBOM, signing, provenance/attestation, and the “scan, sign, attest, verify” chain.
Images — trusted/minimal base images, scanning, signing, private registries, and digest pinning.
Observability — audit logs (who did what), metrics/logs/traces, and runtime detection (Falco).
Service mesh — mTLS, workload identity, L7 authorization, sidecars, zero-trust.
PKI — the cluster CA, TLS everywhere, rotation, the CSR API, cert-manager.
Connectivity — NetworkPolicies (default-deny) and the CNI dependency.
Admission control — validating vs. mutating, Pod Security Admission, Gatekeeper/Kyverno — the enforcement point that ties the rest together.

Pair this with the 4Cs of Cloud Native Security for the layered model, the Cluster Component Security guide for control-plane internals, and the KCSA exam guide for 2026 for the full domain map. If you’re weighing your next credential, KCSA vs. CKS shows how this conceptual foundation feeds into the hands-on CKS.

Practice Until the Controls Are Reflexive

Platform Security is a recognition domain: the exam describes a scenario, and you match it to the right control — SBOM, signing, mTLS, NetworkPolicy, admission control. That skill comes from repetition, not re-reading. With 60 questions in 90 minutes (about 90 seconds each), you need the SBOM-vs-signing and NetworkPolicy-vs-admission distinctions to be instant.

Sailor.sh’s KCSA mock exam bundle mirrors the real exam’s domain weights — so Platform Security gets the ~16% emphasis it deserves — and every question comes with an explanation of why the answer is correct, not just which option to pick. Warm up with the free KCSA practice questions, then close the gaps with full-length timed mocks and the structured KCSA study plan.

Conclusion

Platform Security is the broadest domain on the KCSA, but it’s unified by one idea: establishing trust and enforcing policy at the platform layer — around, between, and before your workloads. Anchor it to the flow of a container’s life: it’s built (supply chain: SBOM, signing, provenance), stored (image registry: scanning, digests, private registries), admitted (admission control: PSA, Gatekeeper/Kyverno), connected (NetworkPolicy, service mesh mTLS, PKI), and observed (audit logs, runtime detection). Learn the single control that answers each question’s verb, and this wide domain turns into a dependable source of points.

Master Platform Security and you’re not just passing a domain — you’re learning the exact controls that keep real clusters safe from supply-chain and runtime attacks, which is why the KCSA gives it such weight.

FAQ

How much of the KCSA exam is Platform Security?

The Platform Security domain is roughly 16% of the KCSA exam. It’s one of the broadest domains, covering supply chain security, image/registry security, observability, service mesh, PKI, connectivity, and admission control.

What is the difference between an SBOM and image signing?

An SBOM (Software Bill of Materials) is an inventory of every component and dependency in an artifact — it tells you what’s inside. Image signing cryptographically proves who produced the image and that it hasn’t been tampered with. You use an SBOM to assess vulnerability exposure and signing (with provenance/attestation) to verify authenticity and origin.

What does a service mesh add to Kubernetes security?

A service mesh (like Istio or Linkerd) provides mutual TLS (mTLS) to encrypt and mutually authenticate service-to-service traffic, workload identity, and fine-grained L7 authorization — usually via sidecar proxies and without changing application code. It’s a common way to implement zero-trust networking between workloads.

How do you stop privileged containers from being deployed?

Through admission control. The built-in Pod Security Admission controller can enforce the restricted Pod Security Standard per namespace, and policy engines like OPA Gatekeeper or Kyverno can reject non-compliant objects (including privileged Pods) before they’re created.

Why don’t my NetworkPolicies have any effect?

Because NetworkPolicy enforcement depends on your CNI plugin. Kubernetes defines the NetworkPolicy object, but a CNI that supports it (such as Calico or Cilium) must actually enforce the rules. With a non-enforcing CNI, policies are accepted but do nothing — a detail the KCSA likes to test.

Do I need hands-on skills for the KCSA Platform Security domain?

No. The KCSA is multiple choice and conceptual — you won’t run commands in the exam. You need to understand what each control does and when to use it. Drilling scenario questions with the KCSA mock exam bundle is an effective way to make those distinctions reflexive.