Courseiva

CCNA Supply Chain Security Questions

21 questions · Supply Chain Security · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQeasy

Which tool can be used to generate an SBOM (Software Bill of Materials) for a container image?

A.trivy
B.kubesec
C.checkov
D.syft
AnswerD

Syft generates SBOMs from container images.

Why this answer

Syft is a CLI tool specifically designed to generate a Software Bill of Materials (SBOM) from container images and filesystems. It uses static analysis to catalog packages (e.g., APK, DEB, RPM, Python, Java) and outputs the SBOM in formats like SPDX or CycloneDX, which are industry standards for supply chain transparency. This makes it the correct choice for generating an SBOM from a container image in a CKS context.

Exam trap

CKS often tests the distinction between a dedicated SBOM generator (Syft) and a vulnerability scanner that can also produce SBOMs (Trivy), leading candidates to pick Trivy because they associate it with container security, but the question specifically asks for a tool 'to generate an SBOM', not to scan for vulnerabilities.

How to eliminate wrong answers

Option A is wrong because Trivy is primarily a vulnerability scanner that can also produce SBOMs as a secondary feature, but it is not the dedicated tool for SBOM generation; Syft is the purpose-built tool. Option B is wrong because Kubesec is a static analysis tool for Kubernetes resource manifests (e.g., PodSecurityPolicy checks), not for container image SBOM generation. Option C is wrong because Checkov is an infrastructure-as-code scanner for misconfigurations in Terraform, CloudFormation, and Kubernetes YAML, not a tool for extracting package metadata from container images.

Practice this question →
2
MCQmedium

Which of the following is a static analysis tool for Kubernetes manifests that can be used to find misconfigurations?

A.Trivy
B.Kubesec
C.Syft
D.Cosign
AnswerB

Kubesec scans Kubernetes manifests for security issues.

Why this answer

Kubesec is a static analysis tool specifically designed to evaluate Kubernetes manifests against a set of built-in security policies. It scans YAML or JSON resource definitions and assigns a risk score based on misconfigurations such as running containers as root, missing resource limits, or insecure capability assignments. This makes it the correct choice for identifying misconfigurations in Kubernetes manifests without executing them.

Exam trap

The CKS exam often tests the distinction between tools that scan container images (like Trivy) versus tools that scan Kubernetes manifest files (like Kubesec), causing candidates to confuse vulnerability scanning with static configuration analysis.

How to eliminate wrong answers

Option A is wrong because Trivy is primarily a vulnerability scanner for container images, filesystems, and Git repositories, not a static analysis tool for Kubernetes manifests. Option C is wrong because Syft is a software bill of materials (SBOM) generator that produces a list of packages and dependencies from container images or filesystems, not a Kubernetes manifest scanner. Option D is wrong because Cosign is a tool for signing and verifying container images and blobs using cryptographic signatures, not for static analysis of Kubernetes manifests.

Practice this question →
3
MCQmedium

You are implementing supply chain security for container images. Which tool would you use to scan a local directory of Dockerfiles and Kubernetes manifests for known vulnerabilities?

A.kubectl scan
B.syft
C.cosign sign
D.trivy fs
AnswerD

trivy fs is a valid and appropriate choice because it scans local filesystem paths, including Dockerfiles and Kubernetes manifests, for vulnerabilities and misconfigurations. It parses the base image references and dependency files in those directories, then cross-references them against vulnerability databases, and also performs configuration checks for insecure settings. This makes it a comprehensive scanner for code and Infrastructure-as-Code artifacts in a supply-chain context.

Why this answer

D is correct because `trivy fs` scans a local filesystem (including directories containing Dockerfiles and Kubernetes manifests) for known vulnerabilities. It parses these files, checks base images against vulnerability databases, and detects misconfigurations or CVEs. This tool is designed for supply chain security, covering both package vulnerabilities and infrastructure-as-code issues.

The `fs` subcommand of trivy combines filesystem scanning with configuration analysis, making it suitable for the stated task.

Exam trap

The trap is that candidates might think `trivy fs` only scans packages, but it can also scan configuration files like Dockerfiles and Kubernetes manifests for vulnerabilities. The exam tests the understanding that `trivy` is a multi-purpose tool, and `fs` is the appropriate subcommand for local directory scanning, not just `trivy image`.

How to eliminate wrong answers

Option A is wrong because `kubectl scan` is not a valid kubectl subcommand; kubectl does not have a built-in vulnerability scanning feature. Option B is wrong because `syft` generates a Software Bill of Materials (SBOM) from container images or filesystems but does not scan for known vulnerabilities; it catalogs packages but lacks a vulnerability database. Option C is wrong because `cosign sign` is used for signing container images to ensure integrity and provenance, not for scanning local directories for vulnerabilities.

Practice this question →
4
MCQmedium

A development team uses a custom container image for their application, built from a base image that includes multiple CVEs. The security team requires that no container runs with known critical vulnerabilities. Which approach best ensures that only images with no critical vulnerabilities are deployed in production?

A.Configure a Kubernetes admission controller (e.g., Kyverno) to reject pods using images with critical vulnerabilities.
B.Scan the base image before building the application image.
C.Integrate an image scanner (e.g., Trivy) into the CI/CD pipeline to block builds with critical vulnerabilities.
D.Manually review vulnerability reports after the image is deployed.
AnswerC

Integrating a scanner like Trivy into the CI/CD pipeline creates a build-time quality gate: it scans the final image after all layers are assembled and fails the pipeline if critical vulnerabilities are found, so vulnerable images are never pushed to the container registry. This shift-left approach automates prevention at the earliest practical stage and provides a clear signal to developers before the image reaches deployment. This is the recommended primary control for supply chain security.

Why this answer

Integrating an image scanner like Trivy into the CI/CD pipeline ensures that any image with critical vulnerabilities is blocked before it is even built or pushed to a registry. This shift-left approach prevents vulnerable images from ever reaching the production environment, aligning with the security team's requirement to deploy only images with no critical vulnerabilities.

Exam trap

CNCF often tests the distinction between shift-left security (preventing vulnerabilities at build time) versus runtime enforcement (admission controllers), and the trap here is that candidates choose admission controllers (Option A) because they seem to block vulnerable images, but they fail to realize that the image must already exist in the registry and may have been built with vulnerabilities, whereas CI/CD scanning prevents the image from being created in the first place.

How to eliminate wrong answers

Option A is wrong because a Kubernetes admission controller like Kyverno can only reject pods at deployment time, but the image may already be in the registry with known CVEs, and the admission controller relies on metadata or external scans that may not be up-to-date; it also does not prevent the image from being built or stored. Option B is wrong because scanning only the base image before building the application image does not account for vulnerabilities introduced by the application layer or dependencies added during the build process, leaving the final image potentially vulnerable. Option D is wrong because manually reviewing vulnerability reports after deployment is reactive and does not prevent vulnerable images from running in production, violating the requirement to ensure no container runs with critical vulnerabilities.

Practice this question →
5
MCQhard

An administrator runs 'kubectl describe pod secure-pod' and sees that the pod is in a Pending state with the event 'Error: ImagePullBackOff' and the message 'unauthorized: authentication required'. The image is stored in a private registry. What is the most likely cause?

A.Missing imagePullSecret in the pod spec or in the namespace's default service account
B.The registry requires TLS 1.3 but the kubelet uses TLS 1.2
C.The image tag is misspelled
D.The registry hostname is not resolvable
AnswerA

The 'unauthorized' status in Kubernetes events indicates the image registry rejected the pull because the kubelet did not present valid credentials. Private registries require a kubernetes.io/dockerconfigjson secret referenced in the pod's `imagePullSecrets` field or in the pod's service account. If only the namespace's default service account has the secret and the pod explicitly uses another service account, the secret is not automatically attached, so replication and credential scoping must be checked.

Why this answer

The error 'unauthorized: authentication required' indicates that the kubelet cannot authenticate to the private registry. Kubernetes requires an imagePullSecret, which contains registry credentials (typically a Docker config JSON), to be attached either directly to the pod spec or to the namespace's default service account. Without this secret, the kubelet cannot pull the image, resulting in the ImagePullBackOff state.

Exam trap

The CKS exam often tests the distinction between authentication failures (ImagePullBackOff with 'unauthorized') and other pull errors (e.g., DNS, TLS, or image name issues), so candidates must recognize that 'authentication required' points specifically to missing or invalid registry credentials.

How to eliminate wrong answers

Option B is wrong because TLS version mismatch (e.g., kubelet using TLS 1.2 vs registry requiring TLS 1.3) would cause a TLS handshake failure, not an 'unauthorized: authentication required' message; the error would be something like 'tls: protocol version not supported'. Option C is wrong because a misspelled image tag would produce an 'ImagePullBackOff' with a 'manifest unknown' or 'not found' error, not an authentication error. Option D is wrong because an unresolvable registry hostname would cause a 'dial tcp: lookup' or 'no such host' error, not an authentication failure.

Practice this question →
6
MCQmedium

A security admin runs 'trivy image --severity CRITICAL,HIGH myrepo/myapp:latest' and sees many CVEs. The admin wants to ensure that only images with no CRITICAL or HIGH severity vulnerabilities are deployed to the cluster. Which admission controller should be configured to enforce this policy?

A.PodSecurityPolicy
B.ValidatingAdmissionWebhook
C.MutatingAdmissionWebhook
D.ImagePolicyWebhook
AnswerD

ImagePolicyWebhook is the Kubernetes-native admission controller that delegates image policy decisions to an external backend service. When a Pod is created, it sends an ImagePolicyReview containing the container image references to a configured HTTPS backend, which returns an allow or deny response based on the organization's policy—such as rejecting images that Trivy flagged as critical or high. This is the correct mechanism to integrate image vulnerability scanning into the admission path, and it is the only option listed that is purpose-built for this exact scenario.

Why this answer

The ImagePolicyWebhook admission controller is specifically designed to evaluate container images against an external policy backend before they are admitted into the cluster. By configuring it to reject images with CRITICAL or HIGH severity vulnerabilities (as reported by Trivy), the admin can enforce that only compliant images are deployed. This controller intercepts Pod creation requests and queries an external webhook to decide whether to allow or deny the image based on the policy.

Exam trap

The CKS exam often tests the distinction between generic admission webhooks (ValidatingAdmissionWebhook, MutatingAdmissionWebhook) and the purpose-built ImagePolicyWebhook, leading candidates to choose a generic webhook when the question explicitly asks for the controller designed for image policy enforcement.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) enforces security context constraints on Pods (e.g., privileged containers, host namespaces), not image vulnerability policies. Option B is wrong because ValidatingAdmissionWebhook can be used to validate arbitrary resources, but it is a generic mechanism that requires writing a custom webhook; the question specifically asks for the admission controller designed for image policy enforcement, which is ImagePolicyWebhook. Option C is wrong because MutatingAdmissionWebhook modifies resources during admission (e.g., injecting sidecars), but it does not perform image vulnerability checks or enforce image policies based on severity.

Practice this question →
7
MCQeasy

A DevOps team uses a CI/CD pipeline to build container images and push them to a private registry. To minimize the risk of supply chain attacks, which of the following is the most effective security control to implement?

A.Scan all images for vulnerabilities using Trivy before pushing to the registry.
B.Restrict access to the registry using Kubernetes RBAC and service accounts.
C.Implement network policies to restrict traffic to the registry endpoint.
D.Sign all container images using a private key and verify the signature before deployment.
AnswerD

Signing container images with a private key (e.g., using cosign or Docker Content Trust) and verifying the signature before deployment provides a cryptographic guarantee that the image's digest matches the signed digest and that the signing key belongs to a trusted publisher. Verification typically happens during admission control—for example, through MutatingAdmissionWebhooks or policy engines like Kyverno or OPA Gatekeeper—so that only images bearing a valid signature from an authorized key are allowed to run. This directly mitigates supply chain tampering because any alteration to the image after signing invalidates the signature, and it also proves the image's origin, which vulnerability scanning, RBAC, and network policies cannot do.

Why this answer

Signing container images with a private key and verifying the signature before deployment ensures image integrity and authenticity, directly mitigating supply chain attacks where an attacker could tamper with images in transit or at rest. This control, often implemented using tools like Notary or Cosign (part of the Sigstore project), provides cryptographic proof that the image was produced by a trusted source and has not been altered. Without signature verification, even a vulnerability-scanned image could be replaced with a malicious one, bypassing other controls.

Exam trap

The trap here is that candidates often confuse vulnerability scanning (which detects known flaws) with image signing (which ensures integrity and provenance), and mistakenly choose scanning as the primary defense against supply chain attacks, overlooking that a scanned image can still be replaced or tampered with.

How to eliminate wrong answers

Option A is wrong because vulnerability scanning (e.g., with Trivy) only identifies known CVEs in the image content; it does not prevent an attacker from replacing the image with a different, malicious one after scanning or during transit. Option B is wrong because restricting registry access via Kubernetes RBAC and service addresses only controls who can push or pull images, but does not verify the integrity or origin of the image itself—an authorized user could still push a tampered image. Option C is wrong because network policies limit traffic to the registry endpoint but do not protect against image tampering; an attacker who gains access to the registry or intercepts traffic could still modify images without detection.

Practice this question →
8
MCQmedium

Which of the following is a best practice for securing container images?

A.Hardcode passwords in Dockerfile as environment variables for convenience
B.Use minimal base images like distroless or Alpine
C.Use the latest tag for base images to get the newest features
D.Run containers as root to simplify permission management
AnswerB

Minimal base images like distroless or Alpine drastically reduce the attack surface by containing only the essential libraries and binaries needed to run the application, eliminating package managers, shells, and other utilities that attackers could exploit. This reduces both the number of known Common Vulnerabilities and Exposures (CVEs) and the potential for privilege escalation through less hardened components. Distroless images go further by having no shell or package manager, making them immutable and harder to compromise at runtime, while Alpine provides a small footprint and a package manager for easier dependency management. Choosing a minimal base is a foundational step in a defense-in-depth strategy.

Why this answer

Using minimal base images like distroless or Alpine significantly reduces the attack surface by eliminating unnecessary packages, libraries, and utilities that could contain vulnerabilities. Distroless images contain only the application and its runtime dependencies, while Alpine uses musl libc and BusyBox to keep the image size small and minimize the number of Common Vulnerabilities and Exposures (CVEs) that need to be patched.

Exam trap

The CKS exam tests the misconception that using the 'latest' tag is safe for development or that running as root is acceptable for simplicity, but it strictly enforces immutable tags and non-root execution as part of supply chain security.

How to eliminate wrong answers

Option A is wrong because hardcoding passwords in a Dockerfile as environment variables exposes secrets in plaintext within the image layers, making them accessible to anyone with access to the image or registry, and violates the principle of least privilege. Option C is wrong because using the 'latest' tag for base images introduces unpredictability and breaks reproducibility, as the tag can point to different image versions over time, potentially pulling in breaking changes or unpatched vulnerabilities. Option D is wrong because running containers as root violates the Pod Security Standards (PSS) 'restricted' profile and Kubernetes security best practices, as it allows the container to escape to the host via kernel vulnerabilities, and should be avoided by using a non-root user in the Dockerfile or the securityContext.runAsNonRoot field.

Practice this question →
9
MCQeasy

Which of the following is a best practice when writing a Dockerfile for a containerized application?

A.Run the application as the root user for file permissions
B.Use a minimal base image such as distroless or alpine
C.Hardcode credentials in the Dockerfile for convenience
D.Use the latest tag for the base image to get the newest features
AnswerB

Minimal images reduce the number of packages and potential vulnerabilities.

Why this answer

Using a minimal base image like distroless or alpine reduces the attack surface by eliminating unnecessary packages, libraries, and utilities that could be exploited. This aligns with the principle of least privilege and minimizes the number of Common Vulnerabilities and Exposures (CVEs) in the container, which is critical for supply chain security in Kubernetes environments.

Exam trap

A common pitfall is assuming that using the 'latest' tag is safe because it gets security patches automatically, but in reality, 'latest' is mutable and can introduce unexpected vulnerabilities or break reproducibility, which is critical for supply chain security in Kubernetes environments.

How to eliminate wrong answers

Option A is wrong because running the application as root inside a container violates the principle of least privilege; if the container is compromised, an attacker gains root access on the host (due to shared kernel), and Kubernetes security contexts should enforce non-root users. Option C is wrong because hardcoding credentials in a Dockerfile exposes secrets in the image layers, making them accessible to anyone with image pull access and violating secure supply chain practices; secrets should be injected via Kubernetes Secrets or external vaults at runtime. Option D is wrong because using the 'latest' tag introduces unpredictability and breaks reproducibility; base image updates can introduce breaking changes or new vulnerabilities without explicit version pinning, which undermines supply chain integrity.

Practice this question →
10
MCQhard

You are a security engineer at a fintech startup. The company runs a Kubernetes cluster in production with hundreds of microservices. Recently, a container image from a public registry was compromised, and the attacker injected a backdoor that exfiltrated customer data. The CISO mandates that all images must come from an internal registry that only stores approved, scanned, and signed images. Currently, developers build images locally and push them to Docker Hub, then reference those images in Kubernetes manifests. You have deployed Harbor as a private registry with vulnerability scanning and Cosign for signing. However, you notice that some pods are still running images directly from Docker Hub. You need to enforce that only images from your internal Harbor registry can be used in the cluster. You cannot change the Kubernetes manifests immediately because of a large backlog. You have access to the cluster's kubelet configuration and can modify cluster-level components. Which single action will most effectively block any pod that tries to use an image not hosted on your internal registry?

A.Enforce a PodSecurityStandard that restricts containers from running with root privileges.
B.Apply a Kubernetes NetworkPolicy that blocks egress traffic from nodes to Docker Hub.
C.Configure the containerd configuration on each node to use Harbor as a mirror for all registries and set endpoint to Harbor only, disabling direct pull from public registries.
D.Deploy an admission webhook (e.g., OPA/Gatekeeper) that denies pods whose image registry is not the internal Harbor.
AnswerC

Configuring containerd to use Harbor as a mirror and setting endpoint to Harbor only forces all image pulls to go through the internal registry. This works at the runtime level and doesn't require changes to manifests, making it the most immediate and effective solution.

Why this answer

Configuring containerd to use Harbor as a mirror for all registries and setting the endpoint to Harbor only effectively blocks pulls from any external registry at the container runtime level. This approach works even if Kubernetes manifests reference Docker Hub images, as the kubelet will redirect all image pull requests to the internal Harbor registry, preventing direct pulls from public registries. It enforces the policy without requiring immediate changes to existing manifests, which aligns with the constraint of not modifying them due to a large backlog.

Option D (admission webhook) would require either modification of existing manifests or the webhook to deny pods that do not use the internal registry, but since manifests cannot be changed immediately, this would not affect already running pods unless they are recreated, making it less effective than runtime configuration. Option B (NetworkPolicy) only blocks network traffic but does not prevent the kubelet from pulling images from Docker Hub if the registry is reachable via a different path, and cached images can still be used.

Exam trap

CNCF often tests the distinction between admission control (webhooks) and runtime enforcement (container runtime configuration), where candidates mistakenly choose an admission webhook because it seems like a direct policy enforcement tool, but the question explicitly states that manifests cannot be changed immediately, making runtime-level enforcement the only viable option to block pulls without modifying existing resources.

How to eliminate wrong answers

Option A is wrong because PodSecurityStandard restricting root privileges does not control which image registry is used; it only enforces security context constraints on containers, not image source validation. Option B is wrong because a Kubernetes NetworkPolicy that blocks egress traffic to Docker Hub only prevents network-level communication from nodes to Docker Hub, but it does not prevent the kubelet or container runtime from pulling images if the DNS resolution or caching still allows it; moreover, it does not block pulls from other public registries and can be bypassed if the image is cached locally. Option D is wrong because deploying an admission webhook like OPA/Gatekeeper would require modifying Kubernetes manifests or applying policies that could be circumvented if the webhook is not properly configured or if there is a delay in policy enforcement; it also does not address the immediate need to block images without changing manifests, as the webhook would deny pods at admission time but does not prevent runtime pulls if the image is already cached or if the webhook is bypassed.

Practice this question →
11
MCQmedium

A DevOps engineer wants to enforce that all container images running in the cluster are signed using Cosign. Which Kubernetes admission controller is designed for this purpose?

A.MutatingAdmissionWebhook
B.ImagePolicyWebhook
C.PodSecurityPolicy (deprecated)
D.ValidatingAdmissionWebhook
AnswerB

The ImagePolicyWebhook is an admission controller that contacts an external webhook service to evaluate every Pod's image references at creation time. The external service can verify signatures, digest pins, or other supply-chain criteria, returning an allow/deny decision (and optionally an image rewrite). This is the built-in, dedicated mechanism for enforcing image signing and provenance policies, distinct from generic webhooks.

Why this answer

The ImagePolicyWebhook admission controller is specifically designed to enforce that container images meet certain criteria, such as being signed with Cosign, by querying an external webhook service that validates image signatures before admitting a pod. It intercepts pod creation requests and checks the image references against a configured policy, making it the correct choice for this Cosign-based image signing enforcement scenario.

Exam trap

The trap here is that candidates confuse the generic ValidatingAdmissionWebhook (a Kubernetes admission controller) with the dedicated ImagePolicyWebhook, which is the specific admission controller designed for image policy enforcement in Kubernetes.

How to eliminate wrong answers

Option A is wrong because MutatingAdmissionWebhook is used to mutate (modify) objects during admission, not to enforce image signing policies; it can be used in conjunction with an image validation webhook but is not the dedicated controller for this purpose. Option C is wrong because PodSecurityPolicy (deprecated) is a cluster-level resource that controls security-sensitive aspects of pod specification (e.g., privilege escalation, host namespaces) and does not validate container image signatures. Option D is wrong because ValidatingAdmissionWebhook is a generic webhook for validating any aspect of an admission request, but the question specifically asks for the admission controller designed for image policy enforcement, which is the ImagePolicyWebhook.

Practice this question →
12
MCQmedium

Which static analysis tool is specifically designed to evaluate Kubernetes manifests against security best practices?

A.cosign
B.syft
C.kubesec
D.clair
AnswerC

Kubesec scans Kubernetes manifests for security issues like privileged containers or host network access.

Why this answer

Kubesec is a static analysis tool that evaluates Kubernetes manifests (YAML files) against security best practices and provides a security score. Cosign (A) is for container signing and verification, Syft (B) is for generating SBOMs, and Clair (D) is for container vulnerability scanning. Therefore, option C is correct.

Practice this question →
13
MCQhard

You are asked to generate an SBOM for a container image and attach it as an attestation using cosign. Which two commands would you run in sequence?

A.trivy image --format spdx myimage:latest > sbom.spdx && cosign verify --key cosign.pub myimage:latest
B.syft myimage:latest -o spdx > sbom.spdx && cosign attest --type spdx --predicate sbom.spdx myimage:latest
C.cosign sign --key cosign.key myimage:latest && syft myimage:latest -o spdx
D.crane ls myimage:latest && cosign attest --type spdx --predicate sbom.spdx myimage:latest
AnswerB

This correctly generates an SBOM in SPDX format and attaches it as an in-toto attestation.

Why this answer

It first uses Syft to generate an SPDX-format SBOM from the container image, then uses cosign attest to attach that SBOM as an in-toto attestation to the image. This sequence satisfies the requirement to generate an SBOM and attach it as an attestation using cosign.

Exam trap

In CNCF/CKS exams, a common trap is confusing cosign sign (image signature) with cosign attest (attach an attestation). Also, the SBOM must be generated before it can be attached.

How to eliminate wrong answers

Option A is wrong because cosign verify is used to verify signatures, not to attach an attestation; it does not generate or attach an SBOM. Option C is wrong because cosign sign signs the image but does not attach an SBOM attestation, and the order is reversed (signing before generating the SBOM is illogical). Option D is wrong because crane ls lists image tags and does not generate an SBOM; cosign attest requires a predicate file (the SBOM) which is not provided.

Practice this question →
14
MCQmedium

A pod is running in a namespace that has a Kyverno policy requiring all images to come from a trusted registry. The pod is using an image from an untrusted registry. What will happen when the pod is created?

A.The pod will be created but immediately terminated
B.The pod creation will be rejected with an admission error
C.The pod will be created and run successfully
D.The pod will be created but the image will be replaced with a trusted one
AnswerB

Kyverno acts as a validating admission controller that evaluates the pod manifest against the configured policy. If a rule is violated, the API server receives a denial response and reports an admission error to the client, preventing the pod from being created. The request is rejected pre-persist, so the pod never runs.

Why this answer

Kyverno operates as an admission controller in Kubernetes. When a pod is created, the Kyverno admission webhook intercepts the creation request and evaluates it against the configured policies. If the policy requires all images to come from a trusted registry and the pod uses an image from an untrusted registry, the admission webhook rejects the request, preventing the pod from being created.

This results in an admission error, not a post-creation termination.

Exam trap

The trap here is that candidates confuse admission control with post-creation enforcement (like OPA Gatekeeper's audit mode or Kubernetes security contexts), assuming the pod is created and then terminated, rather than understanding that Kyverno policies block creation at the admission webhook stage before the pod is ever persisted.

How to eliminate wrong answers

Option A is wrong because Kyverno policies are enforced at admission time via a MutatingAdmissionWebhook or ValidatingAdmissionWebhook, not after the pod is created; the pod is never scheduled or run, so it cannot be 'immediately terminated'. Option C is wrong because the policy explicitly blocks images from untrusted registries, so the pod cannot be created and run successfully. Option D is wrong because Kyverno does not automatically replace images; it either allows or denies the request based on the policy, and image substitution would require a mutation rule explicitly defined in the policy, which is not implied by the scenario.

Practice this question →
15
MCQhard

You are configuring ImagePolicyWebhook admission controller to reject images not signed by a trusted authority. After deploying the webhook, you notice that pods are being rejected even for images that are properly signed. Which configuration change is MOST likely to fix this?

A.Increase the memory limit of the API server
B.Change the webhook from 'MutatingAdmissionWebhook' to 'ValidatingAdmissionWebhook'
C.Set failurePolicy to Ignore in the webhook configuration
D.Grant the webhook service account cluster-admin role
AnswerC

When the webhook cannot be reached, the API server rejects the request. Setting failurePolicy: Ignore allows pods to be admitted even if the webhook is unavailable, but this is a temporary fix. The root cause might be network connectivity to the webhook service.

Why this answer

The ImagePolicyWebhook admission controller uses a webhook to validate images. When the webhook is unreachable or returns an error, the default behavior is to reject the request. Setting `failurePolicy` to `Ignore` allows the API server to admit the pod when the webhook fails, which is necessary if the webhook is temporarily unavailable or misconfigured but images are properly signed.

Exam trap

The CKS exam often tests the distinction between `failurePolicy: Fail` (default) and `failurePolicy: Ignore`, tricking candidates into thinking the issue is with webhook type or permissions rather than the failure handling behavior.

How to eliminate wrong answers

Option A is wrong because increasing the API server's memory limit does not affect webhook communication or failure handling; it addresses resource constraints, not admission control logic. Option B is wrong because ImagePolicyWebhook is inherently a validating admission webhook, not a mutating one; changing the type does not resolve failures from webhook errors. Option D is wrong because granting cluster-admin to the webhook service account would not fix image rejection due to webhook failures; it would only escalate privileges unnecessarily and does not affect the admission controller's failure policy.

Practice this question →
16
MCQhard

A Kyverno policy is written to require all images to use SHA256 digests instead of tags. The policy uses a 'validate' rule with 'pattern' on 'spec.containers[*].image'. Which pattern would match an image reference like 'registry.example.com/myapp@sha256:abc123...'?

A.*@sha256*
B."*@*"
C."*@sha256:*"
D."*:*"
AnswerC

Correct: In Kyverno's wildcard matching, this pattern requires an image reference that has '@sha256:' followed by any sequence of characters. That means the immutable part of the reference is a SHA256 digest with the standard 'algorithm:digest' format; the leading '*' accounts for the registry/repository/name, and the trailing '*' consumes the 64-character hex digest. This precisely ensures images are pinned to a SHA256 digest and not to a mutable tag.

Why this answer

Option C ('*@sha256:*') correctly matches image references using SHA256 digest. It ensures the digest algorithm is exactly 'sha256' followed by a colon and digest. Option A ('*@sha256*') is too permissive as it matches any image reference containing 'sha256' as a substring, potentially allowing other algorithms like 'sha256-extra'.

Option B ('*@*') matches any digest algorithm, not specifically SHA256. Option D ('*:*') matches tags, not digests. Therefore, only C meets the requirement.

Exam trap

Candidates may mistakenly choose option A, noticing that both A and C contain 'sha256', but A is not strict enough and would match non-SHA256 digests. The difference between a wildcard match and a colon is subtle but crucial.

How to eliminate wrong answers

Option A is wrong because '*@sha256:*' is identical to Option C, but the question lists it as a duplicate with the same text, and only one is marked as correct; the correct answer is the one explicitly labeled [CORRECT]. Option B is wrong because '*@*' would match any image reference containing an '@' symbol, including those with non-SHA256 digests (e.g., 'registry.example.com/myapp@sha512:...' or even 'user@host' patterns), which does not enforce the SHA256 requirement. Option D is wrong because '*:*' matches image references using tags (e.g., 'registry.example.com/myapp:latest'), not digests, and would allow non-compliant tag-based references.

Practice this question →
17
MCQeasy

In a CI/CD pipeline, which step is MOST effective for detecting known vulnerabilities in a container image before deployment?

A.Run a vulnerability scan on the container image
B.Check the image size
C.Run unit tests on the application code
D.Lint the Dockerfile
AnswerA

Scanning the image for CVEs identifies known security issues.

Why this answer

Running a vulnerability scan on the container image (Option A) is the most effective step because it directly checks the image layers and installed packages against known Common Vulnerabilities and Exposures (CVEs) databases, such as the National Vulnerability Database (NVD). This identifies security flaws in base images and dependencies before deployment, which is a core requirement of supply chain security in Kubernetes.

Exam trap

The CKS exam often tests the distinction between static analysis of build files (like Dockerfile linting) and runtime or image-level security scanning, leading candidates to mistakenly choose linting as a vulnerability detection method.

How to eliminate wrong answers

Option B is wrong because checking the image size only helps with storage and performance optimization, not with detecting known vulnerabilities. Option C is wrong because unit tests validate application logic and functionality, not the security posture of the container image or its dependencies. Option D is wrong because linting the Dockerfile checks for syntax errors and best practices in the build instructions, but it does not scan the resulting image for known CVEs.

Practice this question →
18
MCQmedium

You are tasked with ensuring that all container images in your cluster are scanned for vulnerabilities before being deployed. You have set up Trivy in your CI/CD pipeline and want to enforce that only images with no critical vulnerabilities are allowed. Which admission controller should you configure to reject pods using non-compliant images?

A.ImagePolicyWebhook
B.ValidatingAdmissionWebhook
C.PodSecurityPolicy (PSP)
D.ResourceQuota
AnswerA

ImagePolicyWebhook is a dedicated Kubernetes admission controller that intercepts Pod creation and update requests, extracts the image references, and sends them to an external HTTP(S) backend for a decision based on scanning or policy rules. It is designed specifically for image policy enforcement, with configuration for fail-open/fail-closed behavior and support for default image policies like allowed registries or prefixes. This makes it the standard mechanism to reject images that fail security scanning before they are scheduled.

Why this answer

The ImagePolicyWebhook admission controller is specifically designed to evaluate container images against an external policy backend (e.g., Trivy) before they are admitted into the cluster. It intercepts pod creation requests, sends the image reference to an external webhook for validation, and rejects pods whose images contain critical vulnerabilities. This makes it the correct choice for enforcing image vulnerability policies at admission time.

Exam trap

A common trap is confusing ImagePolicyWebhook (purpose-built for image policy) with ValidatingAdmissionWebhook (generic validation). Candidates often choose ValidatingAdmissionWebhook because they overlook the specialized nature of ImagePolicyWebhook for image scanning enforcement in Kubernetes.

How to eliminate wrong answers

Option B (ValidatingAdmissionWebhook) is wrong because it is a generic mechanism for any custom validation logic, but it is not purpose-built for image scanning policies; you would have to implement the entire image-checking logic yourself, whereas ImagePolicyWebhook is designed specifically for this use case. Option C (PodSecurityPolicy) is wrong because it enforces security context constraints (e.g., privileged containers, host namespaces) and does not evaluate container image vulnerabilities. Option D (ResourceQuota) is wrong because it only limits resource consumption (CPU, memory, storage) and has no capability to inspect or reject images based on vulnerability scans.

Practice this question →
19
MCQhard

A cluster has both ImagePolicyWebhook and a mutating webhook that adds a sidecar. The admin notices that even when ImagePolicyWebhook rejects an image, the mutating webhook has already added the sidecar. What admission ordering issue is occurring?

A.Validating webhooks should run before mutating webhooks
B.Use a validating webhook instead of ImagePolicyWebhook
C.The mutating webhook should be configured to skip pods with certain images
D.The ImagePolicyWebhook should be placed before the mutating webhook in the webhook configuration
AnswerA

Correct. This describes the issue exactly: validating webhooks should run before mutating webhooks, but the fixed order causes them to run after, leading to the sidecar being added even when the image is rejected.

Why this answer

In Kubernetes, admission controllers are invoked in a fixed order: mutating admission controllers (including MutatingAdmissionWebhook) run before validating ones (including ImagePolicyWebhook and ValidatingAdmissionWebhook). Therefore, the mutating webhook that adds the sidecar runs before ImagePolicyWebhook validates the image. This means even if ImagePolicyWebhook rejects the image, the sidecar has already been added.

The issue is that validating webhooks should run before mutating webhooks to prevent such problems, but the fixed order prevents this. Option B is wrong because using a validating webhook still runs after mutating webhooks. Option C is a workaround but not related to the ordering issue.

Option D is incorrect because you cannot change the order of built-in admission controllers; the order is fixed.

Exam trap

The trap is that candidates think they can reorder admission controllers, but Kubernetes enforces a fixed order: mutating runs before validating. Therefore, placing a validating controller before a mutating one is not possible.

How to eliminate wrong answers

Option A is wrong because the Kubernetes admission order is mutating webhooks first, then validating webhooks, not the reverse; placing validating before mutating would break the standard flow. Option B is wrong because using a validating webhook instead of ImagePolicyWebhook does not change the ordering issue; the problem is the sequence, not the type of webhook. Option C is wrong because configuring the mutating webhook to skip pods with certain images is a workaround, but it does not address the fundamental ordering problem and may not be feasible if the image is not known until after the mutating webhook runs.

Practice this question →
20
MCQeasy

Which of the following is a best practice for securing container images?

A.Run containers as root to ensure all permissions are available
B.Use the 'latest' tag for base images to get the latest features
C.Use distroless base images to minimize the attack surface
D.Embed secrets directly in the Dockerfile for easy access
AnswerC

Distroless base images contain only the minimal runtime libraries and timezone data necessary to execute the application, with no shell, package manager, or other utilities that an attacker could use for post-exploitation; this dramatically reduces the attack surface because many privilege-escalation and lateral-movement techniques rely on tools like curl, wget, or a shell that are simply absent. However, this also means debugging directly inside the container is harder, so distroless images should be paired with robust structured logging and centralized observability to maintain visibility without sacrificing a minimal, hardened runtime footprint.

Why this answer

Distroless base images contain only the application and its runtime dependencies, omitting package managers, shells, and other utilities that could be exploited. This dramatically reduces the attack surface and aligns with the principle of least functionality, making it a best practice for securing container images in Kubernetes environments.

Exam trap

A common trap in the CKS exam is the belief that using the 'latest' tag for base images is safe because it provides the newest security patches. However, 'latest' is mutable and can introduce breaking changes or vulnerabilities without version pinning, violating supply chain security best practices.

How to eliminate wrong answers

Option A is wrong because running containers as root violates the principle of least privilege; if the container is compromised, an attacker gains root access to the container and potentially the host via kernel vulnerabilities. Option B is wrong because using the 'latest' tag introduces unpredictability and breaks reproducibility; the image may change without notice, potentially pulling a vulnerable or malicious version. Option D is wrong because embedding secrets directly in a Dockerfile exposes them in the image layers, making them accessible to anyone who can pull the image, and they persist in the image history even if later removed.

Practice this question →
21
Multi-Selectmedium

Which TWO of the following tools can generate an SBOM (Software Bill of Materials) for a container image?

Select 2 answers
A.syft
B.cosign attest
C.Clair
D.kubesec
E.Snyk
AnswersA, B

syft is a dedicated SBOM generation tool.

Why this answer

Syft (A) is a CLI tool specifically designed to generate a Software Bill of Materials (SBOM) from container images and filesystems. Cosign attest (B) can also generate an SBOM for a container image using the `--type sbom` flag and attach it as an in-toto attestation. Both tools are capable of producing SBOMs.

Exam trap

Candidates often assume that only dedicated SBOM tools (like Syft) can generate an SBOM, forgetting that Cosign attest with the `--type sbom` flag also produces an SBOM. This leads to selecting only one correct answer.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Supply Chain Security questions.

Start 20-question session