Courseiva
System Hardening →mediumMultiple Select

CKS Container Image Scanning Practice Question

Which THREE of the following are recommended practices for securing container images in a Kubernetes environment?

⚠ Common exam trap

CNCF often tests the misconception that imagePullSecrets (Option C) are used to restrict which images can be pulled from registries, but in reality, imagePullSecrets only authenticate to private registries and do not enforce any access control or policy on which images are allowed to be pulled; for restriction, you need an admission controller like OPA/Gatekeeper or a registry firewall.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Scan images for vulnerabilities before deployment

Scanning container images for vulnerabilities before deployment is a fundamental security practice in Kubernetes environments. Tools like Trivy, Clair, or Anchore Grype can identify known CVEs in the base image and application dependencies, allowing teams to remediate issues before the image is run. This aligns with the principle of shifting security left and is a key requirement for compliance with standards like the NIST Application Container Security Guide. Option C is correct because using imagePullSecrets is a recommended practice to authenticate to private container registries. While imagePullSecrets do not enforce access control policies on which images can be pulled, they securely store credentials and enable pods to pull images from private registries, which is essential for using images that are not publicly accessible. This prevents unauthorized access to private images and reduces the risk of using compromised public images. Option D is correct because using minimal base images such as distroless or scratch reduces the attack surface by eliminating unnecessary packages, libraries, and utilities. This aligns with the principle of least functionality and minimizes the number of potential vulnerabilities that could be exploited.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✓

    Scan images for vulnerabilities before deployment

    Why this is correct

    Scanning images for known vulnerabilities before deployment is a foundational security gate because containers inherit the package inventory of their base image and layers. Tools like Trivy or Grype compare installed packages against vulnerability databases in CI/CD, failing builds on critical flaws. Without this check, vulnerable images can run indefinitely, giving attackers a known path to exploit in production.

  • ✗

    Store sensitive configuration data directly in the image

    Why it's wrong here

    Baking secrets directly into an image is dangerous because every image layer retains the data, even after deletion from the source. Anyone with pull access to the registry can run docker history and extract credentials, and the secret remains in the image for its entire lifecycle. Instead, use Kubernetes Secrets or an external vault (e.g., HashiCorp Vault) to mount or inject secrets at runtime, enabling rotation without rebuilding and reducing the blast radius.

  • ✓

    Use imagePullSecrets to authenticate to private container registries

    Why this is correct

    ImagePullSecrets provide a secure, declarative way for the kubelet to authenticate to a private container registry using credentials stored in Kubernetes Secret objects. When a pod that references an imagePullSecret is scheduled, the kubelet uses that secret to pull the image, eliminating the need to place registry credentials on worker nodes or inside images. Attaching imagePullSecrets to a service account allows policy-based control over which workloads can access private repositories, reducing the risk of unauthorized image retrieval.

  • ✓

    Use minimal base images like distroless or scratch

    Why this is correct

    Choosing minimal base images like distroless or scratch reduces attack surface by omitting shells, package managers, and compilers that are often the target of post-exploitation activity. In a distroless image, there is no shell to execute in, and tools like curl or bash are absent, forcing attackers to use more limited techniques. Additionally, fewer packages mean a smaller vulnerability surface for scanning, and smaller images improve startup time and storage efficiency.

  • ✗

    Run containers as root to avoid permission issues

    Why it's wrong here

    Running containers as root violates the principle of least privilege because the container's UID 0 is typically mapped to kernel privileges and often to host root, so a compromised application can escalate to full host control. Even with Docker's default capabilities, root inside a container can manipulate its own environment and potentially escape via vulnerabilities. Instead, define a securityContext with runAsNonRoot and an arbitrary numeric UID to ensure workloads execute as an unprivileged user, and use seccomp/AppArmor profiles as an additional layer.

About these practice questions

One of 845 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.