Courseiva

CCNA Cks Supply Chain Questions

75 of 164 questions · Page 1/3 · Cks Supply Chain topic · Answers revealed

Practice these questionsExam hubAll questions
1
MCQmedium

A developer wants to ensure that a pod always uses a specific version of an image that cannot be changed without updating the manifest. Which image reference should be used?

A.myimage@sha256:abcdef...
B.myimage:latest
C.myimage:v1.0
D.myimage:1.0.0
AnswerA

A digest reference pins the pod to the exact image content by its sha256 hash. Unlike a mutable tag, the digest cannot be repointed, so the running image stays identical unless the manifest is edited to a new digest.

Why this answer

(myimage@sha256:abcdef...) uses a digest-based image reference, which pins the image to an immutable content hash. This ensures that the exact same image is always pulled, regardless of tag updates, and any change to the image would require updating the manifest. This aligns with the requirement that the image version cannot be changed without modifying the manifest.

Exam trap

A common misconception is that semantic version tags (e.g., 'v1.0' or '1.0.0') are immutable, but in reality, tags are mutable pointers that can be reassigned, whereas only digest references provide true immutability.

How to eliminate wrong answers

Option B (myimage:latest) is wrong because the 'latest' tag is mutable and can be updated to point to a different image without changing the manifest, violating the requirement. Option C (myimage:v1.0) is wrong because tags like 'v1.0' can be reassigned to a different image digest, allowing the image to change without a manifest update. Option D (myimage:1.0.0) is wrong for the same reason as C—semantic version tags are mutable and can be overwritten, so they do not guarantee immutability.

Practice this question →
2
MCQmedium

A security engineer needs to verify that a container image pulled from a private registry was signed by the organization's authorized build pipeline before allowing it to run in the cluster. The signatures are stored alongside the image in the OCI registry. Which command should the engineer use to perform this verification?

A.cosign verify --key cosign.pub registry.example.com/app:1.2.3
B.cosign sign --key cosign.key registry.example.com/app:1.2.3
C.cosign attach signature --signature sig.json registry.example.com/app:1.2.3
D.cosign generate-key-pair
AnswerA

This command uses the cosign public key to verify the signature attached to the image in the OCI registry. It checks that the image was signed by the corresponding private key, ensuring authenticity and integrity before deployment. This directly addresses the requirement to confirm the image was signed by the authorized pipeline.

Why this answer

To verify an image's signature in an OCI registry, cosign verify is the correct command. It uses the public key to validate the signature, ensuring the image was signed by the trusted private key. This step is critical in a supply chain security workflow to prevent running unauthorized or tampered images.

Exam trap

The trap here is confusing signing operations with verification, assuming that any cosign command involving signatures will check authenticity.

Practice this question →
3
MCQeasy

A developer wants to verify the signature of a container image before deploying it. Which command should they use along with Cosign?

A.cosign verify
B.cosign generate-key-pair
C.cosign sign
D.cosign attest
AnswerA

cosign verify is the correct command because it validates an image's digital signature against a specified public key, confirming both the image's integrity and its authenticated origin. It fetches the image's signature from a registry or OCI artifact, decrypts it with the provided public key, and compares the digest to the image's current digest, failing if they do not match. This is the standard verification step in a supply chain security workflow, often used in CI/CD pipelines to enforce that only signed images are deployed.

Why this answer

The `cosign verify` command is used to check the cryptographic signature of a container image against a public key, ensuring the image's integrity and authenticity. This is the correct tool for a developer who needs to confirm that the image has not been tampered with and was signed by a trusted entity before deployment.

Exam trap

The CNCF CKS exam often tests the distinction between signing and verifying, so candidates may confuse `cosign sign` (which creates a signature) with `cosign verify` (which validates one), especially when the question asks about verifying an existing signature.

How to eliminate wrong answers

Option B is wrong because `cosign generate-key-pair` creates a new public/private key pair for signing, not for verifying an existing signature. Option C is wrong because `cosign sign` applies a signature to an image, which is the opposite of verification. Option D is wrong because `cosign attest` creates an in-toto attestation (a signed metadata statement about the image), but it does not directly verify the image's signature; verification of attestations requires a separate command like `cosign verify-attestation`.

Practice this question →
4
MCQeasy

You want to scan a container image for vulnerabilities before deploying it. Which command uses the Trivy tool to scan an image?

A.trivy check nginx:latest
B.trivy image nginx:latest
C.trivy fs nginx:latest
D.trivy scan nginx:latest
AnswerB

The trivy image subcommand targets a container image reference, pulling and analysing its layers for known CVEs. Specifying nginx:latest scans that image directly, satisfying the requirement to check vulnerabilities before deployment without needing a running container or exported filesystem.

Why this answer

Trivy uses the `image` subcommand to scan a container image for vulnerabilities. The correct syntax is `trivy image <image_name>`, which pulls the image (if not already present) and scans its OS packages and application dependencies against known vulnerability databases. Option B is correct because it follows this exact syntax.

Exam trap

CNCF-CKS often tests the exact subcommand names for tools like Trivy, expecting candidates to know that `image` is the correct subcommand for scanning container images, not generic verbs like `check` or `scan`.

How to eliminate wrong answers

Option A is wrong because `trivy check` is not a valid Trivy subcommand; Trivy uses `image` for container image scanning. Option C is wrong because `trivy fs` scans a filesystem directory, not a container image. Option D is wrong because `trivy scan` is not a valid Trivy subcommand; the correct subcommand for image scanning is `image`.

Practice this question →
5
MCQeasy

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

A.Clair
B.Kubesec
C.Trivy
D.Syft
AnswerD

Syft scans container images and outputs a Software Bill of Materials listing packages and versions, satisfying the requirement to generate an SBOM. It inspects image layers directly, supporting formats such as SPDX and CycloneDX, which is precisely the artefact the question demands.

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 a pluggable cataloger system to extract package metadata (e.g., dpkg, RPM, APK, Python, Java JARs) and outputs the SBOM in formats like CycloneDX or SPDX, which are the standard formats for supply chain transparency.

Exam trap

The CKS exam often tests the distinction between dedicated SBOM tools (Syft) and vulnerability scanners that may also generate SBOMs (Trivy), so candidates mistakenly choose Trivy because it is more widely known, but Syft is the correct answer for the specific task of SBOM generation.

How to eliminate wrong answers

Option A is wrong because Clair is a static analysis tool for vulnerability scanning of container images, not an SBOM generator; it compares packages against CVE databases. Option B is wrong because Kubesec is a Kubernetes resource security scanner that evaluates Pod security contexts and RBAC, not container image content or SBOM generation. Option C is wrong because Trivy is a comprehensive vulnerability scanner that can also produce SBOMs as a secondary feature, but its primary purpose is vulnerability detection, and the question specifically asks for the tool 'used to generate an SBOM' — Syft is the dedicated, purpose-built SBOM tool, while Trivy's SBOM generation is a later-added capability and not its core function.

Practice this question →
6
Multi-Selectmedium

Which TWO are best practices for Dockerfile security? (Select 2)

Select 2 answers
A.Use a non-root user
B.Use a minimal base image (distroless)
C.Store secrets in environment variables
D.Install SSH server for debugging
E.Run the container as root
AnswersA, B

Running as non-root limits the impact of a breach. Containers share the host kernel, so a root process escaping the container can gain root on the host. In the Dockerfile, use the USER directive to switch to an unprivileged user, and in Kubernetes set securityContext.runAsUser/runAsNonRoot. This ensures that even if the application is compromised, the attacker only has the privileges of that user, not root.

Why this answer

Running containers as a non-root user reduces the risk of privilege escalation attacks. If an attacker compromises the container, they will not have root privileges, limiting their ability to modify system files or escape the container. This is enforced by using the USER directive in the Dockerfile to specify a non-root UID (e.g., USER 1001).

Exam trap

The CKS exam often tests the misconception that environment variables are a safe way to pass secrets to containers, but in reality they are easily leaked through Docker metadata and runtime introspection.

Practice this question →
7
MCQeasy

Which Kubernetes admission controller ensures that a pod only uses images from a specific registry?

A.NamespaceLifecycle
B.ImagePolicyWebhook
C.PodNodeSelector
D.AlwaysPullImages
AnswerB

ImagePolicyWebhook delegates admission decisions to an external HTTP service, which inspects each pod's image reference and rejects anything outside the permitted registry. Built-in controllers such as NodeRestriction or PodSecurityPolicy cannot enforce registry allow-lists, so this satisfies the stem's registry restriction.

Why this answer

The ImagePolicyWebhook admission controller allows you to define a webhook that validates container images against a policy, such as restricting them to a specific registry. When a pod is created, Kubernetes sends an admission review to the webhook, which can reject images not from the allowed registry. This is the correct choice because it directly enforces image source policies.

Exam trap

The CKS exam often tests the distinction between AlwaysPullImages (which only affects pull behavior, not source validation) and ImagePolicyWebhook (which enforces registry restrictions), leading candidates to confuse operational controls with policy enforcement.

How to eliminate wrong answers

Option A is wrong because NamespaceLifecycle ensures that objects are created only in existing namespaces and prevents deletion of system namespaces, not image registry restrictions. Option C is wrong because PodNodeSelector enforces namespace-level node selector constraints on pods, not image registry validation. Option D is wrong because AlwaysPullImages forces image pull policy to Always, ensuring images are pulled every time, but it does not restrict which registry images can come from.

Practice this question →
8
MCQmedium

Which tool can be used to perform static analysis of Kubernetes manifests for security issues?

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

Kubesec is a static analysis tool that evaluates Kubernetes resource manifests against a set of security best practice rules, scoring them and flagging risks such as running as root, privilege escalation, and insecure capabilities. It returns a risk score and provides remediation advice directly from the manifest, making it suitable for CI/CD integration. This is exactly the capability needed for static analysis of Kubernetes manifests, unlike the other tools listed.

Why this answer

Kubesec is a static analysis tool specifically designed to evaluate Kubernetes resource manifests against a set of built-in security best practices. It scans YAML or JSON manifests for common misconfigurations such as running containers as root, missing resource limits, or insecure capability assignments, and returns a risk score. This makes it the correct choice for static analysis of Kubernetes manifests for security issues.

Exam trap

The trap here is that candidates often confuse general vulnerability scanners (like Trivy) or image signing tools (like Cosign) with dedicated Kubernetes manifest static analysis tools, leading them to pick a tool that is not specifically designed for scanning YAML security configurations.

How to eliminate wrong answers

Option A is wrong because Syft is a software bill of materials (SBOM) generator that analyzes container images and filesystems to list packages and dependencies, not a static analyzer of Kubernetes manifests. Option B is wrong because Cosign is a tool for signing and verifying container image signatures and attestations, not for scanning Kubernetes manifest files for security misconfigurations. Option D is wrong because Trivy is a comprehensive vulnerability scanner that primarily scans container images, filesystems, and Git repositories for known CVEs, and while it can scan IaC files including Kubernetes manifests, its core focus is vulnerability detection rather than dedicated static analysis of Kubernetes security configurations; Kubesec is the more specialized and direct tool for this purpose.

Practice this question →
9
MCQmedium

A security team wants to ensure that all container images in a cluster are scanned for critical CVEs before they are run. They decide to use an admission controller. Which Kubernetes built-in admission controller should they configure?

A.MutatingAdmissionWebhook
B.ValidatingAdmissionPolicy
C.ImagePolicyWebhook
D.PodSecurity
AnswerC

ImagePolicyWebhook satisfies the requirement by calling an external HTTPS endpoint during admission, letting the team's scanner reject pods whose images contain critical CVEs before they run. It is the only built-in admission controller that inspects image metadata at admission time, so scanning gates deployment rather than merely reporting afterwards.

Why this answer

The ImagePolicyWebhook admission controller is the correct choice because it allows an external webhook to validate container images against a policy (e.g., scanning for critical CVEs) before they are admitted into the cluster. It intercepts Pod creation requests and queries an external service to decide whether the image is allowed, making it ideal for enforcing image security scanning at admission time.

Exam trap

The CKS exam often tests the distinction between admission controllers that enforce security contexts (PodSecurity) versus those that integrate with external scanning services (ImagePolicyWebhook), leading candidates to mistakenly choose PodSecurity because it sounds security-related.

How to eliminate wrong answers

Option A is wrong because MutatingAdmissionWebhook is used to mutate (modify) objects during admission, not to validate image security policies; it can be used for injecting sidecars or annotations but does not natively enforce image scanning. Option B is wrong because ValidatingAdmissionPolicy (using CEL expressions) is a declarative validation mechanism that cannot call external scanning services; it is limited to simple in-cluster checks and cannot integrate with external CVE databases. Option D is wrong because PodSecurity is a built-in admission controller that enforces Pod Security Standards (e.g., restricted, baseline) but does not scan container images for CVEs; it only checks pod-level security contexts and capabilities.

Practice this question →
10
MCQhard

Developer A runs 'cosign verify --key cosign.pub myregistry/myimage:tag' and receives an error: 'No signatures found'. Developer B previously ran 'cosign sign --key cosign.key myregistry/myimage:tag'. What is the most likely cause of the verification failure?

A.The image tag does not exist in the registry
B.The signing command failed to push the signature to the registry
C.Developer B used a different private key to sign than the public key used for verification
D.Developer A used the public key instead of the private key
AnswerB

Cosign signing computes a signature over the image digest and pushes it as a separate OCI artifact (typically under a tag like 'sha256-<digest>.sig') to the same registry. If the `cosign sign` command fails during that push—due to missing write permissions, expired credentials, or a network interruption—no signature object is persisted. When verification later queries the registry for that signature tag and finds nothing, it reports 'No signatures found', even though the image itself is perfectly valid. This directly matches the scenario, so it is the correct explanation.

Why this answer

The error 'No signatures found' indicates that the verification process could not locate any signature associated with the image in the registry. Since Developer B attempted to sign the image with 'cosign sign', the most likely cause is that the signing command failed to push the signature artifact (typically stored as a separate tag like 'myimage:sha256-<digest>.sig' in the same registry) to the registry. Without the signature being successfully uploaded, the 'cosign verify' command finds nothing to validate against the provided public key.

Exam trap

The CKS exam often tests the distinction between signature absence (no signatures found) and signature mismatch (invalid signature), where candidates mistakenly think a key mismatch would cause a 'no signatures' error instead of a validation failure.

How to eliminate wrong answers

Option A is wrong because if the image tag did not exist, the error would typically be 'manifest unknown' or a 404 from the registry, not 'No signatures found'. Option C is wrong because if a different private key was used, the verification would fail with a signature mismatch error (e.g., 'invalid signature') rather than a missing signature error. Option D is wrong because 'cosign verify' expects a public key (--key cosign.pub) to verify the signature; using a private key would be a command syntax error, not a 'No signatures found' error.

Practice this question →
11
MCQmedium

A developer wants to create a Deployment that runs as a non-root user. Which YAML snippet correctly sets the security context to run the container with UID 1000?

A.spec.containers[].securityContext.runAsUser: 0
B.spec.containers[].securityContext.runAsNonRoot: true
C.spec.containers[].securityContext.runAsGroup: 1000
D.spec.containers[].securityContext.runAsUser: 1000
AnswerD

Setting spec.containers[].securityContext.runAsUser: 1000 explicitly forces the container's main process to run with UID 1000, which is a standard non-root user. This overrides any default user in the image and ensures the process is not run as root. It is the direct, concrete way to satisfy the developer's requirement, and it also works in conjunction with pod-level settings.

Why this answer

`securityContext.runAsUser: 1000` explicitly sets the container's user ID to 1000, ensuring the container process runs as a non-root user. This is the direct way to enforce a specific UID in Kubernetes, meeting the developer's requirement to run as a non-root user.

Exam trap

Candidates often confuse `runAsUser` (sets the UID) with `runAsGroup` (sets the GID) or with `runAsNonRoot: true` (which only ensures the container does not run as root, but does not set a specific UID). The question explicitly asks to run with UID 1000, so `runAsUser: 1000` is required.

How to eliminate wrong answers

Option A is wrong because `runAsUser: 0` sets the container to run as root (UID 0), which is the opposite of the non-root requirement. Option B is wrong because `runAsNonRoot: true` only prevents the container from running as root but does not specify a particular UID; it relies on the container image's default user, which may not be UID 1000. Option C is wrong because `runAsGroup: 1000` sets the group ID, not the user ID, so it does not control which user runs the container process.

Practice this question →
12
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 parses Kubernetes manifests statically and scores them against security checks such as privileged containers, host mounts and missing resource limits. This satisfies the stem's requirement for a static manifest analysis tool without needing a running cluster.

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 →
13
MCQmedium

What is the correct way to specify a container image using a SHA digest instead of a tag for immutable deployments?

A.image: myapp:latest
B.image: myapp:stable
C.image: myapp@sha256:abc123...
D.image: myapp:1.0.0
AnswerC

The digest (in the format sha256:...) is a cryptographic hash of the image manifest, making it a content-addressed identifier. Pulling by digest always fetches the exact same image, regardless of any tag changes, thereby ensuring reproducibility and supply-chain integrity. This is the correct way to specify an immutable container image reference.

Why this answer

Using the `@sha256:` syntax pins the container image to an immutable content digest, ensuring that every pull returns the exact same image regardless of tag updates. This eliminates the risk of tag mutability, where a tag like `latest` can be overwritten with a different image, breaking supply chain integrity and reproducibility.

Exam trap

The exam often tests the misconception that version tags (e.g., `1.0.0`) are immutable, but the trap here is that tags are mutable by default and only a digest reference provides cryptographic immutability for supply chain security.

How to eliminate wrong answers

Option A is wrong because `myapp:latest` is a mutable tag that can be overwritten at any time, violating the principle of immutable deployments and introducing supply chain risks. Option B is wrong because `myapp:stable` is also a mutable tag, subject to the same overwrite risk as `latest`, and provides no cryptographic guarantee of image identity. Option D is wrong because `myapp:1.0.0` is a version tag that, while more stable than `latest`, can still be reassigned or deleted by a registry, and does not provide content-addressable immutability like a SHA digest does.

Practice this question →
14
MCQeasy

What is the purpose of using a non-root user in a container image?

A.To reduce the attack surface and limit potential damage if the container is compromised
B.To improve performance
C.To comply with Kubernetes requirements
D.To allow the container to bind to privileged ports
AnswerA

Running as non-root removes the container's default privileged UID 0, so a process escaping the application cannot write to root-owned paths or perform privileged kernel operations. This limits blast radius if compromised, satisfying the stem's damage-limitation requirement.

Why this answer

Running containers as a non-root user reduces the attack surface by ensuring that even if an attacker exploits a vulnerability in the application, they do not gain root privileges inside the container. This limits the potential damage, such as modifying system binaries, escaping the container via kernel exploits, or accessing host resources. In Kubernetes, this is enforced by setting `securityContext.runAsNonRoot: true` or specifying a non-root user in the Dockerfile with `USER` directive.

Exam trap

CKS often tests the misconception that Kubernetes mandates non-root containers, but the trap is that it is a security best practice, not a hard requirement, and the default behavior is to run as root unless explicitly configured.

How to eliminate wrong answers

Option B is wrong because using a non-root user does not improve performance; performance is primarily affected by resource limits, CPU/memory allocation, and kernel scheduling, not the user ID. Option C is wrong because Kubernetes does not require containers to run as non-root; it is a best practice for security, but the default is to run as root unless explicitly configured. Option D is wrong because binding to privileged ports (ports below 1024) requires the `CAP_NET_BIND_SERVICE` capability or root privileges, and a non-root user cannot bind to these ports without additional capabilities or host-level configuration.

Practice this question →
15
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 →
16
MCQmedium

Which Kyverno policy action is used to automatically mutate a resource to add a sidecar container for security?

A.validate
B.verifyImages
C.mutate
D.generate
AnswerC

Kyverno's `mutate` action rewrites matching resources during admission, applying JSON patches or strategic merge to inject the sidecar container automatically. This satisfies the stem's requirement for automatic modification, unlike `validate`, which only permits or denies requests without altering them.

Why this answer

The `mutate` action in Kyverno is specifically designed to modify incoming Kubernetes resources before they are persisted. Adding a sidecar container (e.g., a security agent like Istio or Falco) is a classic mutation use case, where the policy patches the Pod spec to inject the container definition. This is distinct from validation, image verification, or resource generation.

Exam trap

The CKS exam often tests the distinction between `mutate` and `validate` by describing a scenario that requires a change to the resource, leading candidates to incorrectly choose `validate` because they confuse 'enforcing a policy' with 'modifying the resource'.

How to eliminate wrong answers

Option A is wrong because `validate` only checks whether a resource conforms to a policy and can enforce admission rules, but it cannot modify the resource to add a sidecar. Option B is wrong because `verifyImages` is a dedicated action for checking image signatures and attestations (e.g., using Sigstore/cosign), not for mutating Pod specs. Option D is wrong because `generate` creates new resources (e.g., NetworkPolicies or ConfigMaps) based on a trigger, but it does not mutate the triggering resource itself.

Practice this question →
17
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 →
18
Multi-Selecthard

Which THREE are valid methods to enforce that only images from a specific registry can be deployed in a Kubernetes cluster? (Select three.)

Select 3 answers
A.PodSecurityPolicy (PSP)
B.ImagePolicyWebhook admission controller
C.Kyverno policy validating image registry
D.OPA/Gatekeeper constraint to validate registry
E.NetworkPolicy to restrict egress to registries
AnswersB, C, D

ImagePolicyWebhook delegates admission decisions to an external HTTPS service that inspects the pod's image reference and returns allow or deny. Configuring it to reject images outside the specified registry enforces the restriction at admission time, satisfying the registry-only deployment requirement.

Why this answer

Option B (ImagePolicyWebhook admission controller) is correct because it is a built-in Kubernetes admission controller that calls an external HTTP webhook during admission to approve or reject a Pod based on its container image, so the webhook can enforce that images originate only from an allowed registry. Option C (Kyverno policy validating image registry) is correct because Kyverno is a Kubernetes-native admission policy engine whose validating policies can match on Pod specs and deny any container whose image field does not reference the approved registry. Option D (OPA/Gatekeeper constraint to validate registry) is correct because Gatekeeper runs OPA as a validating admission webhook and its ConstraintTemplates/Constraints (e.g., using Rego on input.review.object.spec.containers[_].image) can reject workloads that pull from unapproved registries.

Option A (PodSecurityPolicy) is not correct because PSP only governed pod security attributes such as privileged mode, host namespaces, and volume types, not image registry provenance. Option E (NetworkPolicy) is not correct because it only controls L3/L4 network traffic (e.g., egress to registry IPs/ports) and cannot inspect or validate the image reference used in a Pod specification.

Exam trap

The CKS exam often tests that candidates confuse PodSecurityPolicy (PSP) with image registry validation, but PSP only controls pod security attributes, not image sources; the trap is assuming PSP can filter registries because it has 'policy' in its name.

Practice this question →
19
MCQmedium

Which tool can generate an SBOM for a container image?

A.Trivy
B.Cosign
C.Kubescape
D.Syft
AnswerD

Syft is a purpose-built SBOM generator from Anchore that scans container images and filesystems to inventory packages, libraries, and dependencies. It outputs standard formats like CycloneDX, SPDX, and Syft JSON, making it the definitive tool for converting an image into a software bill of materials.

Why this answer

Syft is a CLI tool specifically designed to generate a Software Bill of Materials (SBOM) for container images and filesystems. It scans the image layers and package managers (e.g., APT, RPM, pip, npm) to produce an SBOM in formats like CycloneDX or SPDX, directly addressing the question's requirement.

Exam trap

The trap here is that candidates confuse Trivy (a vulnerability scanner that can also output SBOMs) with Syft (a dedicated SBOM generator), but the CKS exam expects you to know the primary purpose of each tool in the CNCF supply chain security toolkit.

How to eliminate wrong answers

Option A is wrong because Trivy is a vulnerability scanner that can output SBOMs as a secondary feature, but its primary purpose is security scanning, not SBOM generation; the question asks for a tool that 'can generate an SBOM', and while Trivy can, Syft is the dedicated SBOM tool. Option B is wrong because Cosign is used for signing and verifying container images and attestations, not for generating SBOMs. Option C is wrong because Kubescape is a Kubernetes security scanner that checks cluster configurations and compliance, not a tool for generating SBOMs from container images.

Practice this question →
20
MCQeasy

Which of the following is a BEST practice for securing container images in a Dockerfile?

A.Use the USER directive to specify a non-root user
B.Store secrets in environment variables in the image
C.Run the container as root to simplify permission management
D.Use the 'latest' tag to always get the newest base image
AnswerA

The USER directive in a Dockerfile (or pod securityContext runAsNonRoot) enforces a non-root user for the container's process. This follows the principle of least privilege, limiting filesystem access and kernel namespace capabilities, so an attacker who compromises the application does not inherit root privileges on the host. Combined with a properly configured group and file ownership, it significantly reduces the blast radius of a container breakout.

Why this answer

The USER directive in a Dockerfile sets the user for the container process, and using a non-root user (e.g., USER 1000) follows the principle of least privilege. This reduces the attack surface by preventing an attacker who gains code execution from having root access to the host or container, which is a critical security requirement for containerized workloads.

Exam trap

The CKS exam often tests the misconception that running as root is acceptable if you drop capabilities or use a read-only filesystem, but it emphasizes that a non-root user is a fundamental defense-in-depth layer that must be explicitly set in the Dockerfile.

How to eliminate wrong answers

Option B is wrong because storing secrets in environment variables in the image embeds them in the image layers, making them accessible via `docker history` or image inspection, and they persist even if the container is restarted — this violates secret management best practices (use secrets mounts or external vaults instead). Option C is wrong because running as root inside the container grants unnecessary privileges; if the container is compromised, the attacker gains root access to the container and potentially to the host via kernel vulnerabilities or misconfigured capabilities. Option D is wrong because using the 'latest' tag introduces unpredictability and breaks reproducibility; the base image can change without notice, potentially introducing vulnerabilities or breaking changes — always pin to a specific digest or version tag.

Practice this question →
21
MCQeasy

Which command is used with Cosign to sign a container image?

A.cosign verify <image>
B.cosign attest <image>
C.cosign sign <image>
D.cosign generate <image>
AnswerC

cosign sign is the dedicated command for signing a container image by creating an OCI signature object that references the image digest, either with a private key, a Cosign key pair, or keyless signing via Fulcio and Rekor. It computes a signature over the image manifest and stores the signature as a separate tag/artifact (e.g., sha256-...-key.sig) in the registry. This is the standard command for integrity and provenance verification workflows.

Why this answer

The `cosign sign <image>` command is used to sign a container image by attaching a digital signature to the image manifest in the container registry. This signature, typically stored as a separate tag or in an OCI artifact, allows verification of the image's origin and integrity using the corresponding public key.

Exam trap

The trap for CKS candidates is confusing the `cosign sign` command with `cosign attest` or `cosign verify`. Signing creates a signature artifact attached to the image, attestation adds a signed in-toto statement, and verification validates signatures. In the context of container supply chain security as tested on the CKS exam, understanding this distinction is key.

How to eliminate wrong answers

Option A is wrong because `cosign verify <image>` is used to verify an existing signature on an image, not to create one. Option B is wrong because `cosign attest <image>` creates an in-toto attestation (a signed statement about the image's build process or metadata), not a simple signature on the image itself. Option D is wrong because `cosign generate <image>` is not a valid command; the correct command for generating a key pair is `cosign generate-key-pair`, and `cosign generate` does not exist.

Practice this question →
22
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 →
23
MCQmedium

A security policy requires that all container images must have a signed attestation. Which Cosign command would an admin add to the CI pipeline to create this attestation?

A.cosign verify-attestation <image>
B.cosign sign --key <key> <image>
C.cosign download attestation <image>
D.cosign attest --type custom --predicate <file> <image>
AnswerD

cosign attest constructs an in-toto attestation in a DSSE envelope and signs it, binding the supplied predicate file to the image's digest. --type custom and --predicate <file> let you attach an arbitrary JSON/DSL predicate rather than a built-in provenance or SLSA type. This is the only command among the options that creates a new, signed attestation artifact, directly satisfying the security policy requirement.

Why this answer

The `cosign attest` command is specifically designed to create an in-toto attestation for a container image, attaching a signed predicate (e.g., a SLSA provenance file) that satisfies the policy requirement for a signed attestation. The `--type custom` flag allows specifying a custom predicate type, and `--predicate <file>` provides the attestation payload, which is then signed and stored in the image's OCI manifest as an attached attestation.

Exam trap

The CNCF CKS exam often tests the distinction between a simple image signature (`cosign sign`) and an attestation (`cosign attest`), where candidates mistakenly choose `cosign sign` because they think signing alone creates an attestation, but attestation requires a structured predicate and the `--type` flag.

How to eliminate wrong answers

Option A is wrong because `cosign verify-attestation` is used to verify an existing attestation, not to create one. Option B is wrong because `cosign sign --key <key> <image>` creates a simple signature on the image digest, not an attestation (which is a signed statement about the image's provenance or metadata). Option C is wrong because `cosign download attestation` retrieves an existing attestation from the registry, it does not create a new one.

Practice this question →
24
MCQmedium

You need to enforce that all images deployed in the cluster are signed by a trusted key. Which Kubernetes admission control mechanism would you use?

A.ResourceQuota
B.NetworkPolicy
C.PodSecurityPolicy
D.ImagePolicyWebhook
AnswerD

ImagePolicyWebhook is a Kubernetes admission controller that intercepts pod creation and sends the image references to an external HTTP(S) webhook for evaluation. This external service can verify image signatures against trusted keys, enforce allowlists of registries, or require specific digests, effectively blocking unsigned or disallowed images. Because it runs during the admission phase, it can deny a pod's creation before it is persisted, making it an appropriate tool for enforcing a cluster-wide image signature policy.

Why this answer

The ImagePolicyWebhook admission controller is specifically designed to enforce that container images are signed by a trusted key. It intercepts Pod creation requests and validates the image signatures against a configured webhook endpoint, rejecting unsigned or untrusted images. This directly addresses the requirement for supply chain security by ensuring only cryptographically verified images are deployed.

Exam trap

The trap here is that candidates may confuse PodSecurityPolicy (which deals with pod security contexts) with image trust enforcement, but PodSecurityPolicy never validates image signatures—it only controls runtime security attributes.

How to eliminate wrong answers

Option A is wrong because ResourceQuota is used to limit resource consumption (CPU, memory, storage) per namespace, not to validate image signatures. Option B is wrong because NetworkPolicy controls pod-to-pod and pod-to-service network traffic using labels and ports, not image signing or trust. Option C is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) enforces security context constraints like privileged containers, host namespaces, and volume types, but does not validate image signatures or trust.

Practice this question →
25
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 →
26
MCQmedium

An organization uses Kyverno to enforce policies. Which Kyverno rule action would you use to require that all images come from a specific registry?

A.verifyImages
B.generate
C.mutate
D.validate
AnswerD

The validate action checks incoming resources against a matching rule and rejects those that fail, so a rule requiring images from a specific registry blocks any pod whose image path does not match. Mutate would rewrite rather than enforce, and generate only creates supporting resources.

Why this answer

The `validate` action in Kyverno is used to enforce policies that check resource attributes against specified rules. To require that all images come from a specific registry, you would use a `validate` rule with a pattern or deny clause that inspects the image field (e.g., `spec.containers[*].image`) and rejects any that do not match the allowed registry prefix. This ensures non-compliant resources are blocked at admission time.

Exam trap

A common trap is confusing `validate` (which rejects non-compliant resources) with `mutate` (which modifies resources). For requiring a specific registry, only `validate` can block disallowed images at admission time.

How to eliminate wrong answers

Option A is wrong because `verifyImages` is used for image signature verification (e.g., checking cosign signatures or attestations), not for enforcing a specific registry source. Option B is wrong because `generate` creates new resources based on a trigger resource (e.g., creating a NetworkPolicy when a Namespace is created), not for validating existing resource fields. Option C is wrong because `mutate` modifies resources to meet policy requirements (e.g., adding labels or sidecars), but it does not block non-compliant images; it only alters them, which is insufficient for enforcing a mandatory registry.

Practice this question →
27
MCQhard

A Kubernetes cluster uses the ImagePolicyWebhook admission controller to enforce image signature verification. The administrator notices that pods are being admitted even when the webhook backend is unreachable. The cluster is configured with defaultAllow: true in the admission configuration. What is the most likely cause of this behavior?

A.The webhook backend is not configured with a valid TLS certificate, causing the API server to skip the webhook.
B.The defaultAllow: true setting in the admission configuration causes the API server to allow pods when the webhook fails to respond.
C.The ImagePolicyWebhook admission controller is not enabled in the API server's --enable-admission-plugins flag.
D.The webhook backend is returning an allow response for all requests due to a misconfiguration in its policy logic.
AnswerB

The defaultAllow field in the ImagePolicyWebhook configuration determines the fallback behavior when the webhook backend cannot be reached. When set to true, the API server allows the pod to be admitted if the webhook call fails (e.g., due to network issues or backend downtime). This explains why pods are admitted despite the webhook being unreachable. Setting it to false would deny pods on webhook failure.

Why this answer

The defaultAllow field in the ImagePolicyWebhook admission configuration controls whether pods are admitted when the webhook backend is unreachable. When set to true, the API server allows pods on webhook failure, which explains the observed behavior. The other options either do not apply because the webhook is configured and attempted, or they describe different failure modes.

Exam trap

The trap here is assuming that a webhook failure always results in denial, but the defaultAllow setting can override that to allow.

Practice this question →
28
Multi-Selectmedium

Which THREE of the following are best practices for securing the software supply chain in a CI/CD pipeline?

Select 3 answers
A.Sign images with Cosign after building
B.Generate an SBOM for each image
C.Scan container images for vulnerabilities using Trivy
D.Use a non-minimal base image to ensure all libraries are available
E.Store secrets in the Dockerfile as build args
AnswersA, B, C

Cosign signing produces a verifiable signature binding the image digest to a trusted identity, enabling admission policies to reject unsigned artefacts. This satisfies the supply-chain requirement by proving provenance and integrity from build through deployment.

Why this answer

Option A is correct because signing images with Cosign (part of the Sigstore project) after building produces a cryptographic signature that allows downstream consumers and admission controllers to verify image provenance and integrity, preventing tampered or unauthorized images from being deployed. Option B is correct because generating a Software Bill of Materials (SBOM) for each image provides a machine-readable inventory of components and dependencies, enabling rapid vulnerability triage and license/compliance auditing when new CVEs emerge. Option C is correct because scanning container images with Trivy detects known CVEs in OS packages and application dependencies before the image is promoted, catching vulnerabilities early in the CI/CD pipeline.

Option D is incorrect because best practice favors minimal base images (e.g., distroless or Alpine) to reduce attack surface, not bloated images with unnecessary libraries. Option E is incorrect because storing secrets in a Dockerfile as build args embeds them in image layers and build history, exposing them to anyone who can pull the image; secrets should instead come from a vault or secret manager at runtime.

Exam trap

CNCF-CKS often tests the misconception that a larger base image is more secure because it includes more libraries, when in fact minimal images (e.g., distroless or scratch) reduce the attack surface and are a supply chain best practice.

Practice this question →
29
MCQhard

A DevOps team wants to enforce that all Deployments must have a specific label 'app.kubernetes.io/name'. Which tool can be used to validate this in the admission controller stage?

A.Trivy
B.Cosign
C.Kyverno
D.Syft
AnswerC

Kyverno is a Kubernetes-native admission controller that validates resources against policies written as YAML, so a rule can require the app.kubernetes.io/name label on Deployments and reject non-compliant manifests at admission time, satisfying the stem's enforcement requirement.

Why this answer

Kyverno is a Kubernetes-native policy engine that can validate, mutate, and generate resources using admission webhooks. It can enforce that all Deployments carry the label 'app.kubernetes.io/name' by defining a 'validate' rule in a ClusterPolicy, which checks the resource during the admission controller stage before it is persisted to etcd.

Exam trap

This exam often tests the distinction between tools that operate on container images (Trivy, Cosign, Syft) versus tools that enforce policies on Kubernetes resources at admission time (Kyverno, OPA/Gatekeeper), leading candidates to confuse image scanning with admission control.

How to eliminate wrong answers

Option A is wrong because Trivy is a vulnerability scanner for container images, filesystems, and Git repositories; it does not enforce admission policies on Kubernetes resources. Option B is wrong because Cosign is a tool for signing and verifying container images using Sigstore, not for validating Kubernetes object metadata like labels. Option D is wrong because Syft is a software bill of materials (SBOM) generator that analyzes container images and filesystems, not an admission controller policy engine.

Practice this question →
30
MCQeasy

Which YAML field in a Deployment specifies the container user should not run as root?

A.spec.containers[].securityContext.readOnlyRootFilesystem
B.spec.containers[].securityContext.runAsUser: 0
C.spec.containers[].securityContext.runAsNonRoot
D.spec.containers[].securityContext.allowPrivilegeEscalation
AnswerC

runAsNonRoot is a Boolean field in the container's securityContext that enforces non-root execution. When set to true, the kubelet checks that the container's user ID is non-zero, and if the image or a runAsUser setting would cause the process to run as UID 0, the pod is denied with an error. This is the standard mechanism to guarantee the container does not run as root, either by validating an existing non-root USER in the image or by pairing with a non-zero runAsUser value.

Why this answer

`spec.containers[].securityContext.runAsNonRoot: true` explicitly enforces that the container's user ID is non-zero, preventing the container from running as root. This is a key Pod Security Standard (PSS) control for the 'Restricted' profile, ensuring compliance with the principle of least privilege. The field rejects the container if the user is set to root (UID 0) or if no user is specified and the image defaults to root.

Exam trap

The CKS exam often tests the distinction between `runAsNonRoot` (which enforces a non-root user) and `runAsUser: 0` (which explicitly sets root), and candidates mistakenly think setting `runAsUser` to a non-zero value is equivalent to `runAsNonRoot`, but `runAsNonRoot` is a boolean enforcement that rejects root regardless of the image's default user.

How to eliminate wrong answers

Option A is wrong because `readOnlyRootFilesystem` only makes the container's root filesystem read-only, which prevents writes to the filesystem but does not restrict the user ID; a root user can still run with UID 0. Option B is wrong because `runAsUser: 0` explicitly sets the container to run as root (UID 0), which is the opposite of preventing root execution. Option D is wrong because `allowPrivilegeEscalation` controls whether a process can gain more privileges than its parent (e.g., via setuid binaries), but it does not prevent the container from running as root initially.

Practice this question →
31
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 →
32
MCQhard

A CI/CD pipeline uses cosign attest to add an SBOM attestation to an image. Later, during deployment, which command verifies the attestation?

A.cosign verify --key cosign.pub myimage:latest
B.cosign attest --key cosign.key --predicate sbom.json myimage:latest
C.cosign verify-attestation --key cosign.pub myimage:latest
D.cosign download attestation myimage:latest
AnswerC

cosign verify-attestation is specifically designed to cryptographically verify that the image's attestations are valid and signed by the trusted public key. It decodes the DSSE envelope, checks the in-toto statement's signature, and outputs the payload only if authentication succeeds. This is the only command here that directly addresses the SBOM attestation's integrity and the signer's identity, making it the correct choice for a pipeline's verification step.

Why this answer

`cosign verify-attestation` is the specific command designed to verify an in-toto attestation (such as an SBOM) attached to a container image. It checks the signature on the attestation using the provided public key (`--key cosign.pub`) and validates that the attestation's payload matches the image digest, ensuring the SBOM was generated and signed by the trusted party.

Exam trap

The CKS exam often tests the distinction between `cosign verify` (for image signatures) and `cosign verify-attestation` (for attestations), and the trap here is that candidates mistakenly choose `cosign verify` thinking it covers all signed artifacts, but it does not handle the in-toto attestation envelope.

How to eliminate wrong answers

Option A is wrong because `cosign verify` verifies the image's signature (typically a simple digest signature), not an attestation payload like an SBOM; it does not parse or validate the in-toto envelope. Option B is wrong because `cosign attest` is the command used to create and attach an attestation (the action performed in the CI/CD pipeline), not to verify it; it requires a private key and a predicate file. Option D is wrong because `cosign download attestation` only retrieves the raw attestation data from the registry without performing any cryptographic verification of the signature or the attestation's integrity.

Practice this question →
33
MCQeasy

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

A.Syft
B.Kubesec
C.Checkov
D.Trivy
AnswerA

Syft is a purpose-built CLI tool from Anchore that generates Software Bills of Materials (SBOMs) for container images and filesystems. It inventories all installed packages, libraries, and application dependencies, emitting them in standardized formats such as SPDX and CycloneDX for downstream security analysis. Because SBOM generation is its core function, Syft directly answers the question.

Why this answer

Syft is an open-source CLI tool specifically designed to generate a Software Bill of Materials (SBOM) from container images and filesystems. It uses static analysis to extract package metadata (e.g., dpkg, RPM, APK, Python, Java) and outputs the SBOM in formats like CycloneDX or SPDX, which are the industry standards for supply chain transparency. This makes Syft the correct tool for generating an SBOM from a container image.

Exam trap

The CNCF CKS exam often tests the distinction between a dedicated SBOM generator (Syft) and a multi-purpose security scanner (Trivy), leading candidates to pick Trivy because they know it can produce SBOMs, but the question explicitly asks for the tool 'used to generate' an SBOM, and Syft is the correct, specialized answer.

How to eliminate wrong answers

Option B (Kubesec) is wrong because it is a static analysis tool for Kubernetes resource manifests, not for generating SBOMs from container images. Option C (Checkov) is wrong because it is a policy-as-code scanner for infrastructure-as-code (e.g., Terraform, CloudFormation, Kubernetes YAML), not an SBOM generator. Option D (Trivy) is wrong because while Trivy can detect vulnerabilities and has an SBOM generation feature (via `trivy image --format cyclonedx`), its primary purpose is vulnerability scanning, and the question specifically asks for the tool used to generate an SBOM; Syft is the dedicated, purpose-built tool for SBOM generation, whereas Trivy's SBOM capability is secondary to its vulnerability scanning.

Practice this question →
34
MCQhard

A security engineer is using cosign to sign a container image. The engineer runs 'cosign sign --key cosign.key registry.example.com/app:1.0' and receives an error: 'Error: signing [registry.example.com/app:1.0]: getting signer: reading key: PEM decode failed: invalid pem block'. What is the most likely cause of this error?

A.The cosign.key file was encrypted and requires a password that was not provided.
B.The image reference is invalid because it lacks a digest.
C.The private key file cosign.key is not in the correct PEM format or is corrupted.
D.The image registry requires authentication, and the engineer has not logged in.
AnswerC

The error message indicates a PEM decode failure, meaning Cosign could not parse the private key file. This typically happens if the file is not a valid PEM-encoded private key, perhaps due to corruption, incorrect file contents, or using the wrong file. The engineer should ensure that cosign.key contains a valid private key generated by cosign generate-key-pair.

Why this answer

The error 'PEM decode failed: invalid pem block' indicates that Cosign could not parse the private key file. This is most likely because the file is not a valid PEM-encoded key, perhaps due to corruption, wrong file, or incorrect format. The other options would produce different errors related to registry authentication, image reference, or key decryption.

Exam trap

The trap here is assuming that signing errors are always due to registry or image issues, but key file problems are a common cause of PEM decode failures.

Practice this question →
35
MCQhard

A pod is stuck in Pending state. 'kubectl describe pod' shows '0/1 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate.' The pod does not specify any tolerations. What is the most likely cause?

A.The pod's image pull secret is missing
B.The pod uses an untrusted image that was rejected by an admission webhook
C.The pod's resource requests exceed the available node capacity
D.The cluster only has control-plane nodes and the pod does not tolerate the control-plane taint
AnswerD

The scheduler reports only one node, tainted node-role.kubernetes.io/control-plane, and the pod declares no tolerations, so no node satisfies its scheduling requirements. With no worker nodes present, the pod remains Pending indefinitely until the taint is tolerated or capacity is added.

Why this answer

The error message '0/1 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate' indicates that the only node in the cluster is a control-plane node, which by default has the node-role.kubernetes.io/control-plane taint. Since the pod does not specify any tolerations, it cannot be scheduled on that node, leaving it stuck in Pending state. This is the most likely cause because the cluster lacks worker nodes, and the pod is not designed to run on the control-plane.

Exam trap

The CKAD/CKS exams often test the distinction between different pod failure states (Pending vs. ImagePullBackOff vs. CrashLoopBackOff) and expect candidates to recognize that taint-related scheduling issues produce a specific message in 'kubectl describe pod', not resource or image errors.

How to eliminate wrong answers

Option A is wrong because a missing image pull secret would cause an ImagePullBackOff or ErrImagePull error, not a Pending state with a taint-related scheduling failure. Option B is wrong because an untrusted image rejected by an admission webhook would result in a pod creation failure (e.g., admission webhook denial), not a Pending state with a node taint message. Option C is wrong because resource requests exceeding node capacity would show a different error like 'Insufficient cpu' or 'Insufficient memory', not a taint-related message.

Practice this question →
36
MCQhard

A cluster administrator wants to allow only images from a specific registry (e.g., 'myregistry.io') to be deployed in the cluster. Which tool can be used to enforce this via admission control?

A.OPA/Gatekeeper
B.Helm
C.Calico
D.Prometheus
AnswerA

OPA/Gatekeeper is a validating admission webhook that intercepts API requests before they are persisted. It uses ConstraintTemplates written in Rego to define policies, such as restricting container images to a trusted registry, and Constraints to enforce them across namespaces. Because it integrates directly with the API server's admission phase, it can block any Pod that references an image outside the approved allowlist.

Why this answer

OPA/Gatekeeper is a Kubernetes admission controller that allows you to enforce custom policies, such as restricting container images to a specific registry. By defining a ConstraintTemplate and a Constraint that checks the image prefix (e.g., 'myregistry.io/'), Gatekeeper can reject any Pod creation that uses images from unauthorized registries. This directly addresses the requirement for registry-based admission control.

Exam trap

The trap here is that candidates often confuse Helm (a deployment tool) with an admission controller, or assume Calico (a network policy tool) can enforce image registry restrictions, when only OPA/Gatekeeper or similar admission webhooks can perform this validation.

How to eliminate wrong answers

Option B (Helm) is wrong because Helm is a package manager for Kubernetes that deploys charts, not an admission controller; it cannot enforce runtime policies on image registries. Option C (Calico) is wrong because Calico is a networking and network security solution (e.g., NetworkPolicies), not an admission control tool for validating image sources. Option D (Prometheus) is wrong because Prometheus is a monitoring and alerting system that collects metrics, not an admission controller that can block resource creation based on image registry.

Practice this question →
37
MCQeasy

A developer is building a container image and wants to ensure that the image is free from known vulnerabilities before pushing it to a registry. The developer decides to use Trivy. Which command should the developer run to scan the image for vulnerabilities?

A.trivy fs --security-checks vuln myapp:latest
B.trivy config myapp:latest
C.trivy repository myapp:latest
D.trivy image myapp:latest
AnswerD

The trivy image command scans a container image for vulnerabilities. It pulls the image from the local Docker daemon or a registry, analyzes the installed packages, and reports any known CVEs. This is the standard way to use Trivy for image scanning. The command outputs a table of vulnerabilities by default.

Why this answer

The trivy image command is designed to scan container images for vulnerabilities. It retrieves the image, analyzes its layers, and matches installed packages against vulnerability databases. The other options either target different artifact types (filesystem, configuration files) or use a non-existent subcommand, so they would not achieve the desired scan.

Exam trap

The trap here is mixing up Trivy subcommands, such as using fs or config when the target is a container image rather than a directory or IaC file.

Practice this question →
38
Multi-Selectmedium

Which TWO of the following are tools for image signing and verification? (Select TWO)

Select 2 answers
A.Cosign
B.Trivy
C.kubesec
D.Syft
E.Notary
AnswersA, E

Cosign is a CLI tool from the Sigstore project specifically designed for signing and verifying container images. It supports traditional key-based signing as well as keyless signing using ephemeral keys bound to OIDC identities, and it stores signatures as separate tags in an OCI registry. Verification retrieves the signature and checks it against the image digest, optionally enforcing policy at deploy time through admission controllers like Kyverno.

Why this answer

Cosign is correct because it is a tool specifically designed for container image signing and verification, leveraging Sigstore's keyless signing capabilities and integration with OCI registries. It enables developers to sign images using ephemeral keys and verify signatures against transparency logs, ensuring supply chain integrity.

Exam trap

The CKS exam often tests the distinction between tools that perform signing/verification versus those that scan for vulnerabilities or generate SBOMs, leading candidates to confuse Trivy or Syft with signing tools.

Practice this question →
39
MCQmedium

A DevOps engineer wants to ensure that a container image is signed and the signature is verified before deployment. Which Cosign command verifies an image signature?

A.cosign sign
B.cosign check
C.cosign verify
D.cosign attest
AnswerC

cosign verify is the correct command because it verifies the digital signature of a container image against a trusted public key. It checks that the signature is valid for the image's digest and that the image has not been tampered with. If the signature is missing or invalid, the command fails, thereby confirming the image's authenticity and integrity.

Why this answer

The `cosign verify` command is used to check the signature of a container image against the public key that was used to sign it. This ensures the image's integrity and authenticity before deployment, which is a core requirement of the CKS Supply Chain Security domain.

Exam trap

The trap here is that candidates confuse `cosign verify` with `cosign attest`, as both deal with image integrity, but `attest` creates metadata while `verify` checks the actual signature.

How to eliminate wrong answers

Option A is wrong because `cosign sign` is used to create and attach a signature to a container image, not to verify an existing signature. Option B is wrong because `cosign check` is not a valid Cosign command; the correct command for verification is `cosign verify`. Option D is wrong because `cosign attest` is used to create an in-toto attestation (a signed metadata statement about the image), not to verify the image's signature.

Practice this question →
40
Multi-Selecthard

Which THREE of the following are best practices for securing the software supply chain in Kubernetes?

Select 3 answers
A.Run containers as root to avoid permission issues
B.Sign container images and verify signatures in the CI/CD pipeline
C.Use admission controllers like OPA/Gatekeeper to enforce image policies
D.Use mutable tags like 'latest' for easier updates
E.Scan container images for known vulnerabilities before deployment
AnswersB, C, E

Signing images with tools like Cosign and verifying those signatures during CI/CD ensures tampered or unauthorised artefacts never reach the registry or cluster. This satisfies the supply chain requirement by establishing cryptographic provenance before deployment, catching compromise at the earliest pipeline stage.

Why this answer

Option B is correct because cryptographically signing container images (e.g., with Sigstore/Cosign or Notary) and verifying those signatures in the CI/CD pipeline ensures that only trusted, unmodified images are deployed, preventing tampering and supply-chain injection. Option C is correct because admission controllers such as OPA/Gatekeeper (or Kyverno) enforce policies at admission time, blocking images that violate rules like untrusted registries, missing signatures, or disallowed configurations before pods are created. Option E is correct because scanning images for known CVEs (e.g., with Trivy, Grype, or Clair) before deployment identifies vulnerable dependencies and base images, allowing remediation prior to production.

Option A is not a best practice: running containers as root violates least privilege and increases the blast radius of a compromise; instead, use non-root users and restricted security contexts. Option D is not a best practice: mutable tags like 'latest' are non-deterministic and can silently pull different images, undermining reproducibility and integrity; immutable, digest-pinned tags should be used instead.

Exam trap

The CNCF CKS exam often tests the misconception that running containers as root is acceptable for 'simplicity' or that mutable tags are harmless, but both directly undermine supply chain security guarantees.

Practice this question →
41
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 →
42
MCQhard

A cluster has the ImagePolicyWebhook admission controller enabled. A pod creation is denied with the message 'image policy check failed'. The webhook server returns an error. Which of the following could be a valid reason?

A.The image is not signed by a trusted authority
B.The container runtime is out of date
C.The image tag does not exist in the registry
D.The pod specification has a hostNetwork: true
AnswerA

The ImagePolicyWebhook admission controller is deliberately configured to forward each image reference to an external webhook that can enforce a trust policy, typically requiring a cryptographic signature from an approved signer (e.g., via Sigstore/cosign or a private PKI). When no valid signature is found, or the signature chain does not resolve to a configured trusted authority, the webhook returns an 'admit=false' verdict, and kube-apiserver rejects the Pod before it is stored. Therefore, a denial by this controller directly indicates that the image failed the trust/signature check, not that the image is missing from the registry or that the node is misconfigured.

Why this answer

The ImagePolicyWebhook admission controller intercepts pod creation requests and queries an external webhook server to determine whether the image should be allowed. If the webhook returns an error (e.g., HTTP 5xx or a denial response), the admission controller fails the request with 'image policy check failed'. A common reason for the webhook to deny the request is that the image is not signed by a trusted authority, as the webhook may be configured to enforce image signature verification (e.g., using Notary or Sigstore).

Exam trap

The trap here is that candidates confuse admission controller errors with runtime or registry errors, but the ImagePolicyWebhook specifically checks image policy (e.g., signing) and not image existence, runtime compatibility, or pod security contexts.

How to eliminate wrong answers

Option B is wrong because an outdated container runtime does not cause an admission webhook to fail; it would cause runtime errors, not admission denial. Option C is wrong because a missing image tag would result in a pull error from the container runtime, not an admission webhook policy check failure. Option D is wrong because hostNetwork: true is a security context setting that may be restricted by PodSecurityPolicy or other admission controllers, but it is not evaluated by the ImagePolicyWebhook, which only inspects image metadata.

Practice this question →
43
Multi-Selectmedium

Which two of the following are best practices for container image security? (Select TWO.)

Select 2 answers
A.Maximize the number of layers to improve caching
B.Run containers as a non-root user
C.Use pinned SHA digests for base images
D.Use the 'latest' tag for flexibility
E.Use old base images to avoid breaking changes
AnswersB, C

Running containers as a non-root user follows the principle of least privilege. If a process is compromised, a non-root user inside the container cannot perform privileged operations on the host kernel, such as writing to host system files or using raw sockets. Even with a container escape, the attacker would lack root privileges on the host, significantly reducing the blast radius. Use USER instructions in the Dockerfile and avoid privileged containers.

Why this answer

Running containers as a non-root user follows the principle of least privilege, reducing the risk of privilege escalation if the container is compromised. By default, Docker containers run as root, but using the USER directive in the Dockerfile or specifying a non-root user at runtime (e.g., --user 1000) limits the attacker's ability to modify system files or escape the container.

Exam trap

A common trap is thinking that the 'latest' tag is safe for production because it always gets the newest version. Actually, 'latest' is mutable and can point to any arbitrary image, including malicious ones, making it a supply chain risk.

Practice this question →
44
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

A minimal base image such as distroless or alpine reduces the attack surface by excluding shells, package managers and unnecessary libraries, directly satisfying the CKS requirement to minimise vulnerabilities in the container image. Distroless removes the package manager entirely, while alpine uses musl libc and a smaller package set.

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 →
45
Multi-Selecthard

Which TWO practices improve supply chain security for container images? (Select two.)

Select 2 answers
A.Scanning images for CVEs before deployment
B.Storing secrets in the Dockerfile
C.Signing images with Cosign
D.Using the 'latest' tag for easy updates
E.Running containers as root
AnswersA, C

Scanning images for CVEs before deployment is a preventive security control that identifies known vulnerabilities in base images and installed packages by comparing them against up-to-date CVE databases. Integrating this scan into the CI/CD pipeline prevents compromised or outdated images from reaching production, reducing the risk of exploitation from publicly documented flaws and enabling teams to remediate critical issues before they are deployed.

Why this answer

Scanning images for CVEs before deployment is a core supply chain security practice because it identifies known vulnerabilities in the base image and installed packages before the container enters production. Tools like Trivy, Grype, or Clair compare the image's package inventory against vulnerability databases (e.g., NVD, OSV), allowing teams to reject or patch images with critical flaws. This proactive measure prevents attackers from exploiting unpatched software in the runtime environment.

Exam trap

A common mistake is to assume that vulnerability scanning alone is sufficient for supply chain security, while overlooking the need for image signing (e.g., with Cosign) to ensure integrity and authenticity. Both are correct answers in this question.

Practice this question →
46
MCQmedium

An administrator wants to perform static analysis on Kubernetes manifest files to find security misconfigurations. Which tool is specifically designed for this?

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

Kubesec parses manifest YAML directly, without a running cluster, and scores it against security controls such as privileged containers, host namespaces and missing resource limits. That static, file-based scanning satisfies the stem's requirement to find misconfigurations before deployment, unlike runtime admission controllers or cluster-wide audit tools.

Why this answer

Kubesec (option C) is specifically designed for static analysis of Kubernetes manifest files to identify security misconfigurations. It evaluates YAML or JSON manifests against a set of built-in security best practices, such as ensuring containers run as non-root, avoiding privileged escalation, and setting read-only root filesystems. While Trivy can also scan Kubernetes manifests for misconfigurations as part of its broader vulnerability and IaC scanning capabilities, Kubesec is purpose-built for Kubernetes manifest security analysis and is the most specific tool among the choices.

Exam trap

CNCF often tests the distinction between general-purpose security scanners and purpose-built Kubernetes manifest analyzers. Although Trivy is a popular scanner that includes Kubernetes manifest misconfiguration scanning, it is a broader tool not specifically designed for this task; Kubesec is the dedicated tool for static analysis of Kubernetes YAML manifests. Candidates may choose Trivy due to its popularity, but Kubesec is the correct answer for a tool specifically designed for Kubernetes manifest security.

How to eliminate wrong answers

Option A (Trivy) is wrong because it is a vulnerability scanner for container images, filesystems, and Git repositories, not a static analyzer for Kubernetes manifest files. Option B (Cosign) is wrong because it is a tool for signing and verifying container image signatures, not for analyzing Kubernetes manifest configurations. Option D (Syft) is wrong because it generates a Software Bill of Materials (SBOM) from container images and filesystems, not for static analysis of Kubernetes manifests.

Practice this question →
47
MCQeasy

Which of the following is a recommended Dockerfile best practice to improve container security?

A.Hardcode secrets in environment variables in the Dockerfile
B.Run the container as root to simplify permission management
C.Use a non-root user with USER directive
D.Copy the entire host filesystem into the image
AnswerC

The USER directive drops container processes from root to an unprivileged account, so a compromised workload cannot write to protected paths or escalate host privileges. This directly satisfies the Dockerfile best-practice requirement by enforcing least privilege at runtime.

Why this answer

Running containers as root is a major security risk; if an attacker compromises the container, they gain root access to the container and potentially the host via kernel exploits. The USER directive in a Dockerfile switches the container's runtime user to a non-root user (e.g., USER 1000), reducing the blast radius by limiting privileges within the container. This aligns with the principle of least privilege and is a recommended best practice in the CKS exam for supply chain security.

Exam trap

A common trap in the CKS exam is assuming root inside a container is safe due to namespace isolation, but root still has dangerous capabilities (e.g., CAP_SYS_ADMIN) and can exploit kernel vulnerabilities to escape the container.

How to eliminate wrong answers

Option A is wrong because hardcoding secrets in environment variables in the Dockerfile embeds sensitive data in the image layers, making them accessible to anyone who can pull the image or inspect the layers; secrets should be injected at runtime via Kubernetes Secrets or Docker secrets. Option B is wrong because running the container as root unnecessarily elevates privileges, increasing the risk of container breakout and host compromise; containers should run with the least privileges needed. Option D is wrong because copying the entire host filesystem into the image (e.g., COPY / /app) creates a massive, insecure image that exposes all host files and directories, violating supply chain security and image minimization principles.

Practice this question →
48
MCQhard

A security engineer wants to enforce that all images in the cluster must come from a trusted registry 'trusted-registry.io'. They are using OPA/Gatekeeper. Which constraint template and constraint combination would achieve this?

A.A constraint template that checks 'spec.containers[*].image' contains 'trusted-registry.io' and a constraint that denies if it does.
B.A constraint template that allows all images and a constraint that audits violations.
C.A constraint template that checks 'spec.containers[*].image' starts with 'trusted-registry.io/' and a constraint that denies if it does not.
D.A constraint template that checks 'spec.containers[*].image' equals 'trusted-registry.io' and a constraint that denies if it does not.
AnswerC

Gatekeeper's `K8sAllowedRepos` template evaluates each container's `image` field against an allowed-prefix list, denying any pod whose image does not begin with `trusted-registry.io/`. This directly satisfies the stem's constraint that every image originate from the trusted registry, enforced at admission before workloads are created.

Why this answer

The constraint template must enforce that container images originate from the trusted registry by checking that the image string starts with 'trusted-registry.io/'. This ensures that only images from that specific registry are allowed, and the constraint denies any pod that does not meet this condition. OPA/Gatekeeper uses Rego policies to evaluate the image field and reject non-compliant resources during admission control.

Exam trap

The CKS exam often tests the difference between 'contains' and 'startswith' in Rego policies, where candidates mistakenly choose 'contains' thinking it is sufficient, but it fails to prevent images from untrusted registries that include the trusted string in their path.

How to eliminate wrong answers

Option A is wrong because checking that the image 'contains' the registry string is too permissive; an image like 'malicious-registry.io/trusted-registry.io' would incorrectly pass. Option B is wrong because allowing all images with only audit violations does not enforce denial; Gatekeeper must actively deny non-compliant resources to enforce the policy. Option D is wrong because checking that the image 'equals' the registry string is too restrictive; it would require the entire image reference to be exactly 'trusted-registry.io', which is not a valid image path and would reject all legitimate images from that registry.

Practice this question →
49
MCQeasy

A developer wants to sign a container image using Cosign. Which command should they run after building and pushing the image to a registry?

A.cosign sign myrepo/myapp:latest
B.cosign verify myrepo/myapp:latest
C.cosign attest myrepo/myapp:latest
D.cosign generate-key-pair
AnswerA

Cosign stores signatures as OCI artefacts in the same registry as the image, so signing requires only the image reference. Running cosign sign against myrepo/myapp:latest generates a keyless or key-based signature attached to that digest, satisfying the post-push signing requirement.

Why this answer

The `cosign sign` command is used to sign a container image and attach the signature to the image in the registry. After building and pushing the image, running `cosign sign myrepo/myapp:latest` generates a digital signature using a private key and stores it as an OCI artifact (e.g., `sha256-...sig`) in the same registry, enabling later verification of the image's integrity and origin.

Exam trap

The CKS exam often tests the distinction between signing (`cosign sign`) and verification (`cosign verify`), trapping candidates who confuse the action of creating a signature with the action of checking one.

How to eliminate wrong answers

Option B is wrong because `cosign verify` is used to validate an existing signature against a public key, not to create a signature. Option C is wrong because `cosign attest` attaches an in-toto attestation (a signed statement about the image's provenance or metadata) rather than a simple signature; it is not the primary command for signing. Option D is wrong because `cosign generate-key-pair` creates a new public/private key pair but does not sign any image; it is a prerequisite step, not the signing command itself.

Practice this question →
50
MCQmedium

An administrator wants to ensure that only images from a specific registry (e.g., myregistry.internal) can run in the cluster. Which tool can be used to enforce this via admission control?

A.Cosign
B.Notary
C.Trivy
D.OPA/Gatekeeper
AnswerD

OPA/Gatekeeper is the correct choice because it is an admission controller that integrates with Kubernetes as a validating webhook. Using Constraint Templates and constraint manifests, an administrator can write a Rego policy that inspects each Pod's container images and denies creation if any image does not come from an approved registry. This provides real-time, cluster-wide enforcement of registry allowlists, which is exactly what the administrator wants.

Why this answer

OPA/Gatekeeper is a Kubernetes admission controller that can enforce policies on pod creation, including restricting which container image registries are allowed. By writing a ConstraintTemplate and Constraint that checks the image field against a whitelist of registries, Gatekeeper can reject any pod that attempts to use an image from an unauthorized source. This directly addresses the requirement to enforce registry restrictions at admission time.

Exam trap

The trap here is that candidates confuse tools for image signing or scanning (Cosign, Notary, Trivy) with admission control tools that enforce runtime policies, but only OPA/Gatekeeper provides the Kubernetes-native admission webhook mechanism to block pods based on image registry origin.

How to eliminate wrong answers

Option A is wrong because Cosign is a tool for signing and verifying container image signatures, not for enforcing admission policies based on registry origin. Option B is wrong because Notary is a framework for managing and signing image metadata (e.g., using TUF), but it does not act as a Kubernetes admission controller to block images from specific registries. Option C is wrong because Trivy is a vulnerability scanner for container images and filesystems; it does not enforce admission control policies on which registries can be used.

Practice this question →
51
MCQmedium

An admin wants to scan a local filesystem for vulnerabilities using Trivy. Which command should they use?

A.trivy image
B.trivy config
C.trivy fs
D.trivy repo
AnswerC

`trivy fs` is the correct subcommand to scan a local filesystem, as it takes a directory path and analyzes OS packages, language-specific dependencies, and other artifacts against Trivy's vulnerability database. It works without a container runtime and can be pointed at a source tree or a whole root filesystem, making it ideal for CI pipelines or vulnerability audits of a machine.

Why this answer

`trivy fs` scans a local filesystem for vulnerabilities, misconfigurations, and secrets. This command is specifically designed to analyze directories and files on disk, making it the appropriate choice for scanning a local filesystem as described in the question.

Exam trap

The trap here is that candidates often confuse `trivy image` (for container images) with `trivy fs` (for filesystems), or assume `trivy config` covers all local scanning, when in fact each subcommand targets a distinct artifact type.

How to eliminate wrong answers

Option A is wrong because `trivy image` scans container images (e.g., Docker images) for vulnerabilities, not a local filesystem. Option B is wrong because `trivy config` scans Infrastructure as Code (IaC) files (e.g., Terraform, Kubernetes YAML) for misconfigurations, not general filesystem vulnerabilities. Option D is wrong because `trivy repo` scans a remote Git repository for vulnerabilities, not a local filesystem.

Practice this question →
52
MCQmedium

You need to ensure that all containers in your cluster run with a read-only root filesystem. Which field should be set in the container's security context?

A.readOnlyRootFilesystem: true
B.allowPrivilegeEscalation: false
C.capabilities.drop: ['ALL']
D.runAsNonRoot: true
AnswerA

readOnlyRootFilesystem: true mounts the container's root filesystem as read-only, preventing processes from writing to binaries, libraries, or configuration files. This blocks runtime tampering with the container's filesystem layer. Note that writable tmpfs mounts or volumes are still allowed, but the root filesystem itself is immutable.

Why this answer

Setting `readOnlyRootFilesystem: true` in the container's security context mounts the container's root filesystem as read-only, preventing any writes to the root filesystem. This directly enforces the requirement that all containers run with a read-only root filesystem, which is a key supply chain security control to limit the impact of a compromised container.

Exam trap

This question tests the distinction between security context fields that limit privileges (like allowPrivilegeEscalation or capabilities.drop) and those that enforce filesystem immutability (readOnlyRootFilesystem). Candidates often confuse privilege reduction with filesystem write protection.

How to eliminate wrong answers

Option B is wrong because `allowPrivilegeEscalation: false` prevents a process from gaining more privileges than its parent (e.g., via setuid binaries), but it does not make the root filesystem read-only. Option C is wrong because `capabilities.drop: ['ALL']` removes all Linux capabilities from the container, reducing its privileges, but it does not affect the writability of the root filesystem. Option D is wrong because `runAsNonRoot: true` forces the container to run as a non-root user, which limits the impact of a compromise, but it does not prevent writes to the root filesystem.

Practice this question →
53
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 →
54
MCQmedium

A security team wants to automatically reject any Pod that uses an image tagged with 'latest'. Which tool can be used to define this policy at the admission level?

A.ResourceQuota
B.NetworkPolicy
C.PodSecurityPolicy (PSP)
D.OPA/Gatekeeper
AnswerD

OPA/Gatekeeper is a validating admission webhook that integrates with Kubernetes' AdmissionReview API, allowing you to define custom policies as ConstraintTemplates written in Rego. These policies can inspect every field in the Pod spec, including container image references, and either mutate or reject the request at admission time. By writing a Rego rule that denies any image whose tag equals 'latest' (or that lacks an explicit tag), Gatekeeper can automatically reject violating pods before they are persisted, making it the correct tool for this requirement.

Why this answer

OPA/Gatekeeper is the correct tool because it allows you to define and enforce custom admission control policies via ConstraintTemplates and Constraints. You can create a policy that rejects any Pod using an image tagged with 'latest' by inspecting the `spec.containers[].image` field at admission time, which is not possible with native Kubernetes resources.

Exam trap

A common misconception is that PodSecurityPolicy (PSP) can enforce image-related policies, but PSP is deprecated and handles only security context constraints, not image tags or registries.

How to eliminate wrong answers

Option A is wrong because ResourceQuota only limits aggregate resource consumption (CPU, memory, storage, count) per namespace and cannot inspect or reject Pods based on image tags. Option B is wrong because NetworkPolicy controls network traffic between Pods and Services at L3/L4, not admission decisions about Pod specifications. Option C is wrong because PodSecurityPolicy (PSP) is deprecated and only restricts security context settings (e.g., privileged containers, host namespaces, SELinux), not image tags.

Practice this question →
55
Multi-Selecthard

Which three of the following are valid ways to enforce supply chain security in a Kubernetes cluster? (Select THREE.)

Select 3 answers
A.Use Cosign to sign images and configure verification in the cluster
B.Configure ImagePolicyWebhook to reject images from untrusted registries
C.Use ResourceQuota to limit the number of images that can be pulled
D.Use NetworkPolicy to block egress traffic to unknown registries
E.Use OPA/Gatekeeper to enforce that container images come from an allowed list of registries
AnswersA, B, E

Cosign lets you sign container images with a private key or use sigstore's keyless flow, then store the signature in a registry alongside the image. To enforce in the cluster, you pair Cosign with an admission controller such as the sigstore policy-controller, which verifies the signature on the image manifest during pod creation. Only images signed by trusted keys are admitted, blocking tampered or unofficial images directly at the API server.

Why this answer

A is correct because Cosign is a tool for signing container images using cryptographic keys, and by integrating it with Kubernetes admission controllers (e.g., via the Cosign webhook or Kyverno), the cluster can verify image signatures before allowing a pod to run. This ensures that only images signed by trusted parties are deployed, directly enforcing supply chain integrity.

Exam trap

The CKS exam often tests the distinction between resource management (ResourceQuota) and security controls (image verification), and the trap here is that candidates confuse limiting pull counts with enforcing image trust, or assume NetworkPolicy can filter by registry identity when it only works at the IP/port level.

Practice this question →
56
Multi-Selecthard

Which THREE of the following are correct statements about Kubernetes admission controllers in the context of supply chain security? (Select 3)

Select 3 answers
A.Admission controllers are executed in a specific order that can affect the final state of the resource
B.ValidatingAdmissionWebhook can be used to enforce policies like requiring all images to be signed
C.MutatingAdmissionWebhook can only modify pods, not other resources
D.ImagePolicyWebhook is used to validate container images against an external policy
E.OPA/Gatekeeper uses MutatingAdmissionWebhook to enforce policies
AnswersA, B, D

The order of admission controllers can impact the final resource, especially when mutating and validating are mixed.

Why this answer

Admission controllers are executed in a specific order: mutating controllers run first, then validating controllers. This ordering is critical because a mutating webhook can modify the resource before a validating webhook evaluates it, potentially bypassing intended policies if the order is not carefully managed. The Kubernetes API server processes admission controllers sequentially based on the order defined in the API server flags or the built-in chain, which directly affects the final resource state.

Exam trap

A common misconception is that MutatingAdmissionWebhook is limited to pods, when in fact it can intercept and mutate any Kubernetes resource type. Another is that OPA/Gatekeeper relies on mutating webhooks, whereas its primary enforcement mechanism is validating webhooks.

Practice this question →
57
MCQmedium

You run 'trivy image myapp:latest' and the scan reports several critical CVEs. What is the best action to take?

A.Use kubectl delete pod to remove the running container
B.Delete the image from the registry
C.Rebuild the image with updated base images and re-deploy
D.Ignore the CVEs because the image is running in a non-production environment
AnswerC

Rebuilding the image with updated base images ensures that the vulnerable layers are replaced with patched versions, eliminating the reported CVEs. After rebuilding, re-deploying the workload (e.g., by updating the Deployment's image tag) forces nodes to pull the new image and run a clean container. This is the correct remediation because it addresses the root cause—vulnerable dependencies in the image—rather than mitigating symptoms.

Why this answer

Rebuilding the image with updated base images directly addresses the root cause of the CVEs—outdated or vulnerable packages in the container image. After rebuilding, you must re-deploy the updated image to replace the running vulnerable containers. This aligns with the supply chain security principle of maintaining a secure software bill of materials (SBOM) and ensuring images are patched against known vulnerabilities before deployment.

Exam trap

A common misconception is that deleting the pod or image is sufficient remediation, when the correct action is to patch the image at the source and re-deploy to eliminate the vulnerability from the running environment.

How to eliminate wrong answers

Option A is wrong because deleting the running pod does not fix the underlying vulnerable image; any new pod created from the same image will still have the same CVEs. Option B is wrong because deleting the image from the registry removes the artifact but does not remediate the running containers, which continue to execute the vulnerable code. Option D is wrong because ignoring CVEs in a non-production environment is still a security risk; vulnerabilities can be exploited to pivot to production systems, and the CKS exam emphasizes consistent security practices across all environments.

Practice this question →
58
MCQmedium

An administrator runs 'trivy image myapp:1.0' and receives an output with several CRITICAL vulnerabilities. What is the best next step to ensure the image is secure before deployment?

A.Delete the image entirely and do not deploy
B.Rebuild the image using updated base images and fix the identified vulnerabilities
C.Deploy the image anyway because vulnerabilities are common
D.Ignore the output and re-run the scan
AnswerB

Rebuilding the image is the correct remediation because Trivy's findings are tied to the exact package versions present in the image layers. By updating the base image tag (e.g., switching to a newer Alpine or Ubuntu release) and re-installing dependencies with patched versions, you eliminate the vulnerable components. After rebuilding, run Trivy again to confirm the image is clean before deployment.

Why this answer

The best practice for addressing container image vulnerabilities is to rebuild the image using updated base images and apply patches for the identified CVEs. Trivy reports vulnerabilities in the image layers, and simply deleting or ignoring them does not resolve the security issues; rebuilding with patched dependencies ensures the image is secure before deployment.

Exam trap

CNCF often tests the misconception that deleting or ignoring vulnerable images is acceptable, when the correct action is to remediate by rebuilding with updated base images and patching dependencies.

How to eliminate wrong answers

Option A is wrong because deleting the image entirely is an overreaction and does not provide a deployable solution; the goal is to fix the vulnerabilities, not discard the image. Option C is wrong because deploying an image with CRITICAL vulnerabilities violates supply chain security best practices and could expose the cluster to exploitation. Option D is wrong because ignoring the output and re-running the scan does not address the underlying vulnerabilities; it only repeats the same findings without remediation.

Practice this question →
59
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 →
60
MCQeasy

Which command would you use to sign a container image with Cosign?

A.cosign push <image>
B.cosign verify <image>
C.cosign attest <image>
D.cosign sign <image>
AnswerD

Cosign signs container images stored in an OCI registry, binding a signature to the image digest. Running cosign sign against the image reference creates and uploads that signature, satisfying the requirement to cryptographically sign the container image.

Why this answer

The `cosign sign <image>` command is used to sign a container image with Cosign, attaching a digital signature to the image manifest in the container registry. This signature can later be verified to ensure the image's integrity and origin, which is a core requirement for supply chain security in Kubernetes environments.

Exam trap

The exam often tests the distinction between `cosign sign` (which signs the image) and `cosign attest` (which creates a signed attestation about the image's metadata), causing candidates to confuse the two commands.

How to eliminate wrong answers

Option A is wrong because `cosign push` is used to push an image to a registry, not to sign it. Option B is wrong because `cosign verify` is used to check an existing signature against an image, not to create one. Option C is wrong because `cosign attest` is used to create an in-toto attestation (a signed statement about the image's provenance or build process), not to directly sign the image itself.

Practice this question →
61
Multi-Selecthard

Which THREE of the following can be used to enforce policies on container images in a Kubernetes cluster? (Select 3)

Select 3 answers
A.Kyverno
B.ImagePolicyWebhook
C.Trivy
D.OPA/Gatekeeper
E.kubectl
AnswersA, B, D

Kyverno is a Kubernetes-native admission controller that validates and mutates resources against policies written as YAML, so it can block non-compliant container images at admission time without requiring a separate policy language or external agent.

Why this answer

Kyverno (A) is correct because it is a Kubernetes-native policy engine that runs as an admission controller and can validate, mutate, and generate resources, including enforcing rules on container images (e.g., allowed registries, required signatures, or tag restrictions) via ClusterPolicy/Policy resources. ImagePolicyWebhook (B) is correct because it is a built-in Kubernetes admission controller plugin that sends image admission requests to an external HTTP webhook, which can approve or reject pods based on image policy decisions. OPA/Gatekeeper (D) is correct because Gatekeeper deploys Open Policy Agent as a validating admission webhook in Kubernetes, using ConstraintTemplates and Constraints to enforce policies such as restricting container image registries or requiring trusted images.

Trivy (C) is not correct here because it is a vulnerability and misconfiguration scanner for images and filesystems, not an admission-time policy enforcement mechanism. kubectl (E) is not correct because it is the Kubernetes command-line client for interacting with the API server, not a policy engine or admission controller.

Exam trap

The trap here is that candidates confuse vulnerability scanning tools (like Trivy) with policy enforcement engines, or assume kubectl can enforce policies via commands, when in fact only admission controllers or policy engines like Kyverno, OPA/Gatekeeper, and ImagePolicyWebhook can enforce image policies at the cluster level.

Practice this question →
62
MCQmedium

What is the purpose of an SBOM (Software Bill of Materials) in the context of supply chain security?

A.To sign container images
B.To scan images for vulnerabilities
C.To provide a list of all software components and dependencies in an artifact
D.To enforce runtime security policies
AnswerC

An SBOM (Software Bill of Materials) is a formal, structured record that enumerates every software component, library, package, and dependency included in an artifact, along with metadata such as version numbers and often licenses. It provides a complete supply-chain inventory, making it possible to trace exactly which code is present and why it was included. This transparency is foundational for license compliance, security analysis, and incident response.

Why this answer

An SBOM is a formal, machine-readable inventory of all software components, libraries, and dependencies that make up an artifact such as a container image. Its purpose is to provide transparency into the supply chain so that when a new vulnerability is disclosed, you can quickly determine whether your artifact contains the affected component. It does not itself perform signing, scanning, or runtime enforcement.

Exam trap

The trap here is confusing the purpose of an SBOM with that of a vulnerability scanner or a signing tool; candidates often pick 'scan images for vulnerabilities' because SBOMs are used in vulnerability management, but the SBOM itself is only the inventory.

How to eliminate wrong answers

Option A is wrong because signing container images is done by tools like cosign or Notary, not by an SBOM; an SBOM is a list, not a signature. Option B is wrong because scanning images for vulnerabilities is performed by scanners like Trivy or Clair, which may consume an SBOM but the SBOM itself is not a scanner. Option D is wrong because runtime security policies are enforced by tools like Falco, AppArmor, or seccomp, not by an SBOM.

Practice this question →
63
MCQmedium

A security policy requires that all container images must be signed using Cosign. Which admission controller enforces signature verification at pod creation time?

A.ImagePolicyWebhook
B.MutatingAdmissionWebhook
C.ValidatingAdmissionWebhook
D.ResourceQuota
AnswerA

ImagePolicyWebhook is the dedicated Kubernetes admission controller that evaluates container image policies at pod creation time. It is enabled via --enable-admission-plugins and reads an external webhook configuration file; for every Pod that references images, the API server sends an ImageReview request containing the image names, and the webhook returns an allowed/denied verdict with a reason. This integrates with external image verification services such as Sigstore/cosign or Notary to enforce signature checks, making it the built-in, purpose-specific mechanism for this requirement.

Why this answer

The ImagePolicyWebhook admission controller is the correct choice because it is specifically designed to enforce image signature verification at pod creation time. It intercepts pod creation requests and queries an external webhook (e.g., a Cosign-based policy engine) to validate that the container image has a valid cryptographic signature before allowing the pod to be admitted. This directly meets the requirement for Cosign-based signature enforcement.

Exam trap

The CKS exam often tests the distinction between generic webhooks (MutatingAdmissionWebhook, ValidatingAdmissionWebhook) and purpose-built admission controllers like ImagePolicyWebhook, leading candidates to incorrectly choose ValidatingAdmissionWebhook because they assume any validation can be done there, missing that ImagePolicyWebhook is the specific controller for image signature enforcement.

How to eliminate wrong answers

Option B is wrong because MutatingAdmissionWebhook modifies objects (e.g., injecting sidecars) but does not enforce image signature verification; it operates before validation but lacks the specific image policy checking logic. Option C is wrong because ValidatingAdmissionWebhook can validate arbitrary policies but is not purpose-built for image signature verification; it would require custom logic to replicate ImagePolicyWebhook's built-in image policy enforcement. Option D is wrong because ResourceQuota is a built-in admission controller that enforces resource limits (CPU, memory) and object counts, not image signature verification.

Practice this question →
64
MCQmedium

You need to sign a container image using cosign with a key stored in an environment variable. Which command should you use?

A.cosign sign myimage:latest --key cosign.pub
B.cosign sign --key env://COSIGN_PRIVATE_KEY myimage:latest
C.cosign sign --key $COSIGN_PRIVATE_KEY myimage:latest
D.cosign sign --key file://cosign.key myimage:latest
AnswerB

cosign sign --key env://COSIGN_PRIVATE_KEY myimage:latest is the correct syntax for supplying a private key from an environment variable. The env:// URI scheme tells cosign to interpret COSIGN_PRIVATE_KEY as the name of an environment variable whose value contains the actual key material, rather than as a file system path. This approach keeps the private key out of the filesystem and out of the visible command line, which is the intended method for in-memory key handling with cosign.

Why this answer

`cosign sign --key env://COSIGN_PRIVATE_KEY` instructs Cosign to read the private key from the environment variable named `COSIGN_PRIVATE_KEY` using the `env://` URI scheme. This is the standard way to reference a key stored in an environment variable, avoiding exposure on the command line or in files.

Exam trap

The CKS exam often tests the distinction between shell variable expansion (`$VAR`) and Cosign's native `env://` URI scheme, tricking candidates into thinking that simply passing the variable value as an argument is sufficient, when in fact the `env://` prefix is required for secure key retrieval.

How to eliminate wrong answers

Option A is wrong because `cosign.pub` is a public key file, but signing requires a private key, not a public key. Option C is wrong because `$COSIGN_PRIVATE_KEY` would expand the variable value directly on the command line, potentially exposing the key material in process listings or logs, and Cosign expects a URI scheme like `env://` to read from an environment variable. Option D is wrong because `file://cosign.key` uses a file URI scheme, but the question explicitly states the key is stored in an environment variable, not a file.

Practice this question →
65
MCQeasy

What does SBOM stand for in the context of supply chain security?

A.Software Bill of Materials
B.Systematic Bug and Oversight Manager
C.Secure Build Orchestration Manager
D.Source Binary Object Model
AnswerA

SBOM stands for Software Bill of Materials, a formal, machine-readable inventory of all components, libraries, and dependencies in a software artifact. It enables organizations to track vulnerabilities, license compliance, and supply chain risk by knowing exactly what is inside their code. Standards like SPDX and CycloneDX define its format, and it is essential for responding to incidents like Log4Shell quickly.

Why this answer

SBOM stands for Software Bill of Materials. It is a formal, machine-readable inventory of all components, libraries, and dependencies used to build a software artifact. In supply chain security, an SBOM enables organizations to quickly identify and remediate vulnerabilities (e.g., Log4Shell) by tracking which versions of open-source or third-party components are included in a release.

Exam trap

The CKS exam often tests the exact acronym expansion to catch candidates who confuse SBOM with unrelated security terms like 'SBOM' being mistaken for a management tool or a model, rather than a simple inventory list.

How to eliminate wrong answers

Option B is wrong because 'Systematic Bug and Oversight Manager' is a fabricated term; there is no such standard concept in supply chain security or Kubernetes. Option C is wrong because 'Secure Build Orchestration Manager' is not a recognized acronym; while build orchestration tools exist (e.g., Tekton), they are not referred to as SBOM. Option D is wrong because 'Source Binary Object Model' is a misnomer; SBOM specifically refers to a bill of materials for software, not a model for source or binary objects.

Practice this question →
66
MCQmedium

An administrator wants to ensure that a Deployment uses a specific image digest (SHA256) instead of a tag. Which field in the Deployment YAML should be modified?

A.spec.replicas
B.spec.template.spec.containers[].imagePullPolicy
C.spec.template.spec.containers[].image
D.spec.template.metadata.annotations
AnswerC

The spec.template.spec.containers[].image field accepts a full image reference, and using a digest (e.g., 'image@sha256:...') makes the reference immutable and content-addressed. Unlike tags, a digest uniquely identifies the exact image manifest, ensuring every Pod from this Deployment runs the exact same container build. This is the correct way to constrain a Deployment to a specific image, overriding any mutable tag in the registry. It also prevents accidental or malicious tag overwrites from affecting the running workload.

Why this answer

The `image` field under `spec.template.spec.containers[]` is where you specify the container image, and to enforce immutable deployment, you replace the tag with the SHA256 digest (e.g., `nginx@sha256:abc123...`). This ensures the exact image content is used, preventing tag mutation or accidental updates.

Exam trap

Kubernetes often tests the distinction between image reference (`image` field) and image pull behavior (`imagePullPolicy`), trapping candidates who confuse 'how to pull' with 'what to pull'.

How to eliminate wrong answers

Option A is wrong because `spec.replicas` controls the number of pod replicas, not the image reference. Option B is wrong because `imagePullPolicy` determines when to pull the image (e.g., Always, IfNotPresent, Never) but does not specify the image digest. Option D is wrong because `spec.template.metadata.annotations` are arbitrary key-value metadata for pods, not used for image identification.

Practice this question →
67
MCQhard

An organization wants to implement supply chain security by signing all container images and verifying them before deployment. Which combination of tools is appropriate?

A.Snyk and OPA
B.Cosign and Kyverno
C.Trivy and Syft
D.Clair and Notary
AnswerB

Cosign signs and verifies container image signatures using keyless or key-based attestations, while Kyverno's admission policies enforce that only signed images deploy. Together they satisfy the requirement to sign all images and verify them before deployment, blocking unsigned workloads at admission time.

Why this answer

Cosign is the tool for signing container images and storing signatures in an OCI-compliant registry, while Kyverno is a Kubernetes admission controller that can enforce policies to verify those signatures before allowing pod deployment. Together, they implement the full supply chain security workflow: signing images at build time and verifying them at deploy time via Kyverno's `verifyImages` rule.

Exam trap

The exam often tests the distinction between vulnerability scanning tools (Snyk, Trivy, Clair) and supply chain signing/verification tools (Cosign, Notary), leading candidates to confuse scanning for vulnerabilities with cryptographic signing and policy enforcement.

How to eliminate wrong answers

Option A is wrong because Snyk is a vulnerability scanner for dependencies and container images, not a signing tool, and OPA (Open Policy Agent) is a general-purpose policy engine that lacks native support for image signature verification without custom Rego rules. Option C is wrong because Trivy is a vulnerability scanner and Syft is a software bill of materials (SBOM) generator; neither tool provides image signing or signature verification capabilities. Option D is wrong because Clair is a vulnerability scanner for container images, and Notary is a tool for signing and verifying content trust in Docker images but is deprecated in favor of Cosign and is not integrated with Kubernetes admission controllers like Kyverno.

Practice this question →
68
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 analyses Kubernetes manifests directly, scoring workloads against security controls such as privileged containers, host namespaces, and capability escalation. It satisfies the stem's constraint of evaluating manifests against best practices, unlike runtime tools or general linters. Its risk-scoring output pinpoints misconfigurations before deployment.

Why this answer

kubesec is a static analysis tool specifically designed to scan Kubernetes manifests and identify security risks, such as running containers as root, missing resource limits, or privileged mode. It evaluates YAML files against a set of security best practices and assigns a risk score. This makes it the correct tool for evaluating Kubernetes manifests against security best practices.

Exam trap

CKS often tests the distinction between tools that scan images (clair, trivy, syft) and tools that scan manifests (kubesec, kube-score, checkov), so candidates must match the tool to the artifact being analyzed.

How to eliminate wrong answers

Option A is wrong because cosign is a tool for signing and verifying container images, not for analyzing Kubernetes manifests. Option B is wrong because syft is a Software Bill of Materials (SBOM) generation tool that inventories container images and filesystems, not a manifest security analyzer. Option D is wrong because clair is a vulnerability scanner for container images, focusing on known CVEs in packages, not on Kubernetes manifest security configurations.

Practice this question →
69
MCQeasy

Which static analysis tool can be used to check Kubernetes manifests for security misconfigurations?

A.kubesec
B.kubectl apply
C.trivy image
D.helm template
AnswerA

Kubesec statically scans Kubernetes manifests and returns a security score, flagging misconfigurations such as privileged containers, host namespaces and missing security contexts before deployment. It satisfies the stem's requirement for a static analysis tool by evaluating YAML definitions directly, without needing a running cluster or admission controller.

Why this answer

Kubesec is a static analysis tool specifically designed to evaluate Kubernetes YAML manifests against a set of security best practices, such as ensuring containers run as non-root, enforcing read-only root filesystems, and dropping unnecessary Linux capabilities. It outputs a risk score and highlights misconfigurations without requiring a running cluster, making it ideal for early detection in CI/CD pipelines.

Exam trap

The trap here is that candidates often confuse static analysis of manifests (Kubesec) with image vulnerability scanning (Trivy image) or deployment commands (kubectl apply), because all three are security-related but operate at different stages of the supply chain.

How to eliminate wrong answers

Option B is wrong because 'kubectl apply' is a command to deploy manifests to a cluster, not a static analysis tool; it will apply misconfigurations without any security validation. Option C is wrong because 'trivy image' scans container images for vulnerabilities in OS packages and libraries, not Kubernetes manifest misconfigurations. Option D is wrong because 'helm template' renders Helm charts into Kubernetes manifests locally but performs no security scanning; it is a templating tool, not a static analyzer.

Practice this question →
70
MCQhard

An organization uses a GitOps workflow with Argo CD to deploy applications to Kubernetes. The security team wants to ensure that container images are immutable and signed. They currently use a private container registry (Harbor) with vulnerability scanning and Cosign for signing. Which combination of controls best enforces that only signed and scanned images are deployed?

A.Configure Argo CD to verify Cosign signatures before syncing the application.
B.Use imagePullSecrets in Kubernetes to ensure only Harbor images are used.
C.Add a Cosign verification step in the CI pipeline before pushing images to Harbor, and rely on that guarantee.
D.Enable Harbor's content trust feature to reject unsigned images, and use a Kyverno admission rule to verify Cosign signatures at deploy time.
AnswerD

Enabling Harbor's content trust feature causes the registry to reject pushes of unsigned images, meaning only images that carry the required signature can be stored and later pulled. A Kyverno admission rule with a `verifyImages` check validates the Cosign signature again at the moment Kubernetes attempts to create a Pod, so even if an image is replaced or a signed tag is moved to a different digest, the admission controller blocks it. Together these enforce signature integrity at both the registry boundary and the cluster boundary, providing defense-in-depth that a single control cannot achieve.

Why this answer

It enforces a two-layer defense: Harbor's content trust rejects unsigned images at the registry level, and a Kyverno admission rule verifies Cosign signatures at deploy time. This ensures that even if an unsigned image bypasses the registry, it will be blocked by Kubernetes admission control, providing defense in depth for supply chain security.

Exam trap

CNCF often tests the concept that imagePullSecrets only handle authentication, not integrity or signing, leading candidates to mistakenly choose Option B as a security control.

How to eliminate wrong answers

Option A is wrong because Argo CD does not natively verify Cosign signatures before syncing; it relies on external admission controllers or pre-sync hooks for such checks. Option B is wrong because imagePullSecrets only control authentication to pull images from a registry, not image integrity or signature verification. Option C is wrong because relying solely on CI pipeline verification is insufficient; an attacker could bypass the pipeline or push unsigned images directly to the registry, and there is no runtime enforcement.

Practice this question →
71
MCQeasy

What is the primary purpose of an SBOM in supply chain security?

A.To list all open source and third-party components in an image
B.To scan images for secrets
C.To sign container images
D.To enforce network policies
AnswerA

An SBOM (Software Bill of Materials) is a formal, machine-readable inventory that enumerates all open source and third-party components, their exact versions, and dependency relationships inside a container image. Its primary purpose is to provide transparency and traceability for software supply chain security, enabling vulnerability correlation, license compliance, and provenance verification. Without an SBOM, you cannot systematically identify which component is affected by a newly disclosed CVE or audit what third-party code actually ships in production.

Why this answer

An SBOM (Software Bill of Materials) is a formal, machine-readable inventory of all components—including open source and third-party libraries—used to build a software artifact. In supply chain security, its primary purpose is to provide transparency and enable vulnerability tracking by listing every dependency, so that when a new CVE is disclosed, teams can quickly determine if their images are affected. This aligns directly with option A.

Exam trap

The CKS exam often tests the distinction between an SBOM (a list of components) and image signing (a cryptographic verification), causing candidates to confuse the two because both are part of supply chain security but serve different purposes.

How to eliminate wrong answers

Option B is wrong because scanning images for secrets is the job of tools like Trivy or secret scanners, not an SBOM, which is a metadata document. Option C is wrong because signing container images is done with tools like Cosign or Notary to ensure integrity and provenance, while an SBOM is a separate artifact that lists components. Option D is wrong because enforcing network policies is a runtime security control managed by Kubernetes NetworkPolicy resources or service meshes, unrelated to the composition of software artifacts.

Practice this question →
72
Multi-Selectmedium

Which TWO of the following are valid ways to verify a container image signature using cosign?

Select 2 answers
A.cosign validate myimage:latest
B.cosign verify-attestation --key cosign.pub myimage:latest
C.cosign check myimage:latest
D.cosign attest --key cosign.key myimage:latest
E.cosign verify --key cosign.pub myimage:latest
AnswersB, E

This command is correct because `cosign verify-attestation` checks the integrity and authenticity of an in-toto attestation attached to the image, using the provided public key (`cosign.pub`). It verifies that the attestation (e.g., SLSA provenance) was signed by the holder of the corresponding private key and has not been tampered with. This is a valid way to verify claims about an image beyond just its signature.

Why this answer

`cosign verify-attestation --key cosign.pub myimage:latest` validates an in-toto attestation attached to a container image using a public key, which is a valid method to verify the image's provenance and integrity. Option E is correct because `cosign verify --key cosign.pub myimage:latest` directly verifies the container image's signature against the provided public key, confirming the image was signed by the holder of the corresponding private key.

Exam trap

The CKS exam often tests the distinction between signing (`cosign sign`, `cosign attest`) and verifying (`cosign verify`, `cosign verify-attestation`) commands, and candidates may confuse `attest` (which creates a signature) with `verify-attestation` (which checks one).

Practice this question →
73
Multi-Selectmedium

Which TWO are benefits of using a distroless base image over a full OS image like Ubuntu? (Select two.)

Select 2 answers
A.Faster image build times
B.Smaller image size
C.Better compatibility with Kubernetes security contexts
D.Smaller attack surface
E.Easier debugging
AnswersB, D

Distroless images strip away shells, package managers, and non-essential OS utilities, retaining only the runtime environment (e.g., JVM, Python runtime) and necessary libraries. This reduces compressed image size from hundreds of MB to tens of MB, directly accelerating image pull times and lowering storage and bandwidth costs on Kubernetes clusters. For large deployments, the cumulative effect of smaller images can significantly improve pod startup latency and cluster resource consumption.

Why this answer

Distroless images contain only the application and its runtime dependencies, omitting package managers, shells, and other OS utilities. This results in a significantly smaller image size compared to full OS images like Ubuntu, which include a complete userland and filesystem. Smaller images reduce storage costs, network transfer times, and container startup latency.

Exam trap

A common trap is confusing image size with build performance: while distroless images are smaller, build times are dominated by layer caching and dependency installation, not the final image size.

Practice this question →
74
MCQmedium

A security policy requires that all container images use SHA-based digests instead of tags. Which approach ensures this in a Deployment YAML?

A.Use the 'image' field with a tag and also set 'digest' field
B.Set imagePullPolicy: Always and use tags
C.Use the image field with a digest, e.g., 'image: nginx@sha256:abc123'
D.Set imagePullPolicy: IfNotPresent and use tags
AnswerC

Referencing the image by its sha256 digest pins the exact immutable manifest, so Kubernetes pulls precisely that content. Tags are mutable and can be repointed, so the digest form is the only field syntax that satisfies the SHA-based digest policy.

Why this answer

Kubernetes supports using a SHA-based digest in the `image` field, which ensures the exact image content is pulled regardless of tag changes. By specifying the image as `nginx@sha256:abc123`, the container runtime fetches the image by its immutable digest, guaranteeing supply chain integrity and compliance with the security policy.

Exam trap

The CKS exam often tests the misconception that a separate `digest` field exists in the Kubernetes API, when in reality the digest must be appended to the image name using the `@sha256:` syntax.

How to eliminate wrong answers

Option A is wrong because there is no separate `digest` field in a Deployment YAML; the digest must be appended to the image name in the `image` field. Option B is wrong because setting `imagePullPolicy: Always` with tags still allows the tag to be updated to a different image, violating the requirement for immutable digest-based references. Option D is wrong because `imagePullPolicy: IfNotPresent` with tags does not enforce digest usage; the tag can still point to a different image over time, breaking the security policy.

Practice this question →
75
Multi-Selecthard

Which TWO of the following admission controllers are relevant for supply chain security in Kubernetes?

Select 2 answers
A.MutatingAdmissionWebhook (for sidecar injection)
B.ImagePolicyWebhook
C.AlwaysPullImages
D.NodeRestriction
E.ValidatingAdmissionWebhook (used by Kyverno/Gatekeeper)
AnswersB, E

ImagePolicyWebhook is a built-in admission controller that queries an external service to validate image references before pods are admitted. It directly supports supply chain security by blocking images that fail registry or signature policy checks at admission time.

Why this answer

ImagePolicyWebhook (B) is correct because it is the built-in admission controller that forwards pod image decisions to an external image policy service, enabling enforcement of trusted registries, signature verification, and vulnerability policies before a workload is admitted. ValidatingAdmissionWebhook (E) is correct because policy engines such as Kyverno and OPA Gatekeeper use it to validate resources against supply chain rules, for example rejecting images that lack a valid Cosign signature or that come from unapproved registries. MutatingAdmissionWebhook (A) is not the right answer here since its typical use is sidecar injection and defaulting, not supply chain verification.

AlwaysPullImages (C) only forces image pulls on every pod start to avoid stale cached images and does not verify provenance or trust. NodeRestriction (D) limits what kubelets can modify on Node and Pod objects, which is a node-security control rather than a supply chain control.

Exam trap

The CKS exam often tests the difference between the purpose-built ImagePolicyWebhook and generic admission webhooks. ValidatingAdmissionWebhook is relevant when used by policy engines such as Kyverno/Gatekeeper to enforce supply chain policies, but MutatingAdmissionWebhook for sidecar injection, AlwaysPullImages, and NodeRestriction are not supply chain security controllers in this context.

Practice this question →
Page 1 of 3 · 164 questions totalNext →

Ready to test yourself?

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

Start 20-question session