CKS Supply Chain Security Practice Question
You are auditing a cluster's supply chain security. You find that many pods are running images from public registries without any pinning or verification. Which TWO actions would most effectively reduce the risk of pulling malicious images?
⚠ Common exam trap
CNCF often tests the distinction between runtime security controls (PodSecurityStandards, network policies) and supply chain controls (image pinning, registry proxies), and candidates mistakenly think blocking egress or restricting pod creation mitigates the risk of pulling malicious images, when those controls do not affect the image pull process itself.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Configure all deployments to use image digests instead of tags.
Using image digests (e.g., `nginx@sha256:abc123...`) pins the image to an immutable content hash, ensuring that the exact same image is pulled every time, even if the tag is updated to a malicious version. This prevents tag-mutation attacks where an attacker replaces a benign image tag with a compromised one. Digests are verified by the container runtime (containerd) against the registry's manifest, providing cryptographic assurance of image integrity.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Configure all deployments to use image digests instead of tags.
Why this is correct
Pinning images to content-addressable digests (e.g., sha256:...) makes the container runtime pull the exact manifest that was vetted at admission time, because tags are mutable references that can be overwritten in a registry. A tag like :latest may be shifted to a compromised build, whereas a digest is a hash of the image manifest, and any change to the image content alters that hash. This prevents tag-based mutation, typo-squatting, and stale cached pulls, and it is the foundation for verifying image signatures and provenance attestations.
- ✓
Set up a private registry proxy that mirrors approved public images and disable direct access to public registries via containerd configuration.
Why this is correct
A private registry proxy (pull-through cache) fronted by a mirror configuration in containerd's hosts.toml can enforce an allowlist of approved images and perform vulnerability scanning before images are cached. By setting containerd to fetch only from the proxy and blocking direct registry endpoints (via firewall, registry config, or containerd's 'capabilities'), the kubelet never contacts public registries directly. This gives the cluster a central control point for image provenance, reduces supply-chain attack surface, and ensures all images pass through the same verification pipeline.
- ✗
Implement RBAC to restrict which users can create pods.
Why it's wrong here
RBAC limits which users or service accounts can create pods, but it does nothing to validate the content of the images those authorized users select. An authenticated developer who is allowed to create a Deployment can still reference a public image with a malicious or tampered tag, and the kubelet will happily pull it. RBAC addresses authorization of actions, not the integrity or provenance of artifacts, so it is orthogonal to supply-chain security in this scenario.
- ✗
Enforce PodSecurityStandard baseline or restricted to block privileged containers.
Why it's wrong here
The PodSecurityStandard (baseline or restricted) constrains pod-level privileges such as running as root, adding capabilities, or sharing host namespaces, but it does not evaluate the image's source, authenticity, or embedded code. A malicious image can run as a non-root user without any privileged container fields and still contain malware, crypto-miners, or credential stealers. Therefore, enforcing these standards reduces container breakout risk but does not prevent pulling or executing untrusted images.
- ✗
Apply a network policy that blocks egress traffic to public registries.
Why it's wrong here
NetworkPolicies govern traffic between pods and to external endpoints as defined by the kubelet, but image pulling is performed by the container runtime (e.g., containerd) on the node before any pod network is set up. Even if a NetworkPolicy blocks egress from the pod, the kubelet's image pull traffic does not traverse the pod's network namespace; it uses the host's network. Consequently, blocking egress from pods to public registries has zero effect on image pulls, and the node would still need registry access unless a proxy or restricted endpoint is configured.
Go deeper
Related to this question
About these practice questions
One of 845 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.