Supply Chain Security practice questions

Which TWO of the following are best practices for securing the container supply chain?

Trap 1: Embed API keys directly in container images for authentication.

Baking API keys into container images is dangerous because images are immutable and often shared via registries; any user with pull access can extract secrets by unpacking layers. Secrets also leak from intermediate build layers, so even removing them later in the Dockerfile doesn't remove them from the final image. Instead, mount secrets at runtime via Kubernetes Secrets, a sidecar, or a tool like External Secrets Operator, and rotate them regularly.

Trap 2: Allow all images from any registry without verification to speed up…

Allowing images from any registry without verification removes a key trust boundary, letting attackers push malicious or vulnerable images that then execute with the service account's privileges. Without an allowlist, admission control, and signature verification, you cannot establish provenance or know who built the artifact and from what source. This practice increases the attack surface from a single compromised or malicious registry to the entire internet, and undermines any supply chain security investments.

Trap 3: Use mutable tags like 'latest' for easier updates.

Using mutable tags like 'latest' means a tag can be overwritten, making it impossible to audit or rollback to the exact code that ran historically, because the tag no longer points to the same digest. An attacker can also overwrite a mutable tag to point to a compromised image, and the cluster would pull it on the next restart. Reproducible deployments require immutable tags derived from commit SHAs or explicit image digests (sha256:...), and you should refer to the digest for immutable deployments.

A
Scan images for vulnerabilities in a CI pipeline before deploying.
Scanning images for known vulnerabilities in CI, using tools like Trivy or Grype, catches flaws in OS packages and language dependencies before they reach production. Integrate these scans with policy checks that fail the build on critical or high severity CVEs, and also rescan base images on a schedule, since new vulnerabilities are disclosed after the image is built. This is a reactive measure against known issues, distinct from verifying who built the image or that it hasn't been altered.
B
Use image signing and verification (e.g., with cosign) to ensure image integrity.
Image signing with cosign cryptographically binds the image manifest to a key held by the publisher, proving identity and origin. Verify the signature in the Kubernetes cluster using an admission controller, such as Kyverno or OPA Gatekeeper, to reject unsigned or tampered images; consider holding keys in a KMS like Vault or AWS KMS. Signing addresses integrity and provenance, whereas vulnerability scanning only identifies known flaws, not whether the artifact is authentic.
C
Embed API keys directly in container images for authentication.
Why wrong: Baking API keys into container images is dangerous because images are immutable and often shared via registries; any user with pull access can extract secrets by unpacking layers. Secrets also leak from intermediate build layers, so even removing them later in the Dockerfile doesn't remove them from the final image. Instead, mount secrets at runtime via Kubernetes Secrets, a sidecar, or a tool like External Secrets Operator, and rotate them regularly.
D
Allow all images from any registry without verification to speed up development.
Why wrong: Allowing images from any registry without verification removes a key trust boundary, letting attackers push malicious or vulnerable images that then execute with the service account's privileges. Without an allowlist, admission control, and signature verification, you cannot establish provenance or know who built the artifact and from what source. This practice increases the attack surface from a single compromised or malicious registry to the entire internet, and undermines any supply chain security investments.
E
Use mutable tags like 'latest' for easier updates.
Why wrong: Using mutable tags like 'latest' means a tag can be overwritten, making it impossible to audit or rollback to the exact code that ran historically, because the tag no longer points to the same digest. An attacker can also overwrite a mutable tag to point to a compromised image, and the cluster would pull it on the next restart. Reproducible deployments require immutable tags derived from commit SHAs or explicit image digests (sha256:...), and you should refer to the digest for immutable deployments.

Question 2hardmulti select

Which THREE of the following are required to implement a secure software supply chain using Kubernetes native features?

Trap 1: Disable admission controllers to reduce latency in pod creation.

Admission controllers are a mandatory phase of the Kubernetes API request lifecycle that intercept requests to the API server after authentication and authorization but before object persistence. Disabling them, for example by removing the corresponding plugins from the API server's --enable-admission-plugins flag, would bypass built-in security controls such as PodSecurity admission, LimitRanger, ResourceQuota, and custom validating or mutating webhooks. These plugins enforce crucial restrictions like disallowing privileged containers, requiring security contexts, and validating resource usage; eliminating them to reduce latency would leave the cluster exposed to misconfigured or malicious pods, while providing negligible performance benefit because the checks are simple in-memory evaluations.

Trap 2: Run all containers as root inside the pod to avoid permission…

Running all containers as root is a direct violation of the principle of least privilege and dramatically increases the impact of a container compromise. Even within a container, the root user shares the same kernel user ID (UID 0) as the host's root, and if the container is able to exploit a kernel vulnerability, a container breakout could grant root access to the host node. Kubernetes provides securityContext fields like runAsNonRoot, runAsUser, and allowPrivilegeEscalation to force workloads to run with unprivileged UIDs and drop dangerous capabilities; forcing root defeats these protections and makes the entire cluster highly fragile.

A
Use vulnerability scanning tools like Trivy or Grype in the CI/CD pipeline.
Running vulnerability scanners such as Trivy or Grype inside the CI/CD pipeline integrates security analysis directly into the build and release lifecycle. These tools compare the image's installed packages and application dependencies against public and private CVE databases, and can be configured to fail the pipeline when critical or high-severity vulnerabilities are present. This prevents container images with known, exploitable weaknesses from ever reaching a registry or being deployed, enforcing a shift-left security model that catches issues before runtime rather than after an attack.
B
Disable admission controllers to reduce latency in pod creation.
Why wrong: Admission controllers are a mandatory phase of the Kubernetes API request lifecycle that intercept requests to the API server after authentication and authorization but before object persistence. Disabling them, for example by removing the corresponding plugins from the API server's --enable-admission-plugins flag, would bypass built-in security controls such as PodSecurity admission, LimitRanger, ResourceQuota, and custom validating or mutating webhooks. These plugins enforce crucial restrictions like disallowing privileged containers, requiring security contexts, and validating resource usage; eliminating them to reduce latency would leave the cluster exposed to misconfigured or malicious pods, while providing negligible performance benefit because the checks are simple in-memory evaluations.
C
Integrate image signature verification into the admission webhook (e.g., using cosign and Kyverno).
Integrating image signature verification into an admission webhook using tools like cosign and Kyverno adds a cryptographic trust check directly at the moment a Pod is created or updated. When an image is pushed, a signature is generated using a private key, typically within a Sigstore-based workflow; at admission time, the webhook verifies that the image's signature matches a trusted public key, proving the image was signed by an authorized party and has not been tampered with since signing. This is distinct from simply scanning for vulnerabilities, because it authenticates the provenance and integrity of the artifact itself, preventing an attacker from substituting a malicious but equally vulnerable image under the same name from a compromised or untrusted source.
D
Run all containers as root inside the pod to avoid permission issues.
Why wrong: Running all containers as root is a direct violation of the principle of least privilege and dramatically increases the impact of a container compromise. Even within a container, the root user shares the same kernel user ID (UID 0) as the host's root, and if the container is able to exploit a kernel vulnerability, a container breakout could grant root access to the host node. Kubernetes provides securityContext fields like runAsNonRoot, runAsUser, and allowPrivilegeEscalation to force workloads to run with unprivileged UIDs and drop dangerous capabilities; forcing root defeats these protections and makes the entire cluster highly fragile.
E
Enforce policies using OPA Gatekeeper or Kyverno to restrict allowed registries and image constraints.
Enforcing policies with OPA Gatekeeper or Kyverno allows cluster administrators to define and automatically enforce image-related constraints as code, such as allowing images only from approved registries, requiring images to have immutable digest references, or blocking tags like 'latest' that introduce non-reproducible deployments. These tools act as validating or mutating admission webhooks that evaluate each Pod spec against policy rules derived from Kubernetes objects like ConstraintTemplates and ClusterPolicies, rejecting non-compliant requests before they are persisted. This provides centralized, audit-friendly governance that ensures development teams cannot accidentally or intentionally use untrusted image sources, even if such images have passed the CI/CD pipeline.

Question 3easymultiple choice

A DevOps team wants to ensure that only signed images from a trusted registry are deployed in the cluster. They plan to use a webhook to intercept pod creation. Which tool is best suited for this task?

Trap 1: kubectl with --validate flag

kubectl with --validate is incorrect because that flag performs only client-side OpenAPI schema validation of a manifest against the Kubernetes API's published schema, catching field name or type errors. It does not enforce any admission policy, image signature checks, or security constraints; it runs entirely on the client machine before the request is sent. The cluster's admission controllers run server-side after the request reaches the API server, so kubectl cannot substitute for them.

Trap 2: Helm with signed charts

Helm with signed charts is the wrong tool because Helm chart signing only cryptographically verifies the integrity and provenance of the chart package during `helm install` — it runs client-side and never touches the Kubernetes API server at pod creation time. Signed charts do not enforce which container images are allowed to run; they merely assure the chart's templates and defaults haven't been tampered with. Runtime image signature verification requires an admission controller, not a package manager.

Trap 3: etcd with encryption at rest

etcd encryption at rest is incorrect because it protects sensitive cluster data (like Secrets) while stored on disk, but it has no role in admission control or image verification. When a Pod is created, the API server reads from etcd but does not consult etcd to decide whether an image's signature is valid. Encryption at rest addresses data confidentiality, not supply-chain security for container images.

A
kubectl with --validate flag
Why wrong: kubectl with --validate is incorrect because that flag performs only client-side OpenAPI schema validation of a manifest against the Kubernetes API's published schema, catching field name or type errors. It does not enforce any admission policy, image signature checks, or security constraints; it runs entirely on the client machine before the request is sent. The cluster's admission controllers run server-side after the request reaches the API server, so kubectl cannot substitute for them.
B
Helm with signed charts
Why wrong: Helm with signed charts is the wrong tool because Helm chart signing only cryptographically verifies the integrity and provenance of the chart package during `helm install` — it runs client-side and never touches the Kubernetes API server at pod creation time. Signed charts do not enforce which container images are allowed to run; they merely assure the chart's templates and defaults haven't been tampered with. Runtime image signature verification requires an admission controller, not a package manager.
C
etcd with encryption at rest
Why wrong: etcd encryption at rest is incorrect because it protects sensitive cluster data (like Secrets) while stored on disk, but it has no role in admission control or image verification. When a Pod is created, the API server reads from etcd but does not consult etcd to decide whether an image's signature is valid. Encryption at rest addresses data confidentiality, not supply-chain security for container images.
D
Kyverno with a verifyImages rule
Kyverno with a verifyImages rule is correct because Kyverno runs as a dynamic admission controller inside the cluster and intercepts Pod creation requests before they are persisted. The verifyImages rule leverages cosign to check each container image's digital signature against the specified public keys, failing admission if the signature is missing or invalid. This enforces a policy that only signed images from trusted registries can run, at the exact point Kubernetes decides to allow the workload.
E
Prometheus with alerting rules
Why wrong: Prometheus with alerting rules is wrong because Prometheus is a metrics and alerting system that scrapes time-series data after workloads are already running. It cannot inspect image signatures during the admission phase, nor can it block a Pod from being created. Alerts may notify you that an unsigned image is running, but they provide no preventive control and are not part of the Kubernetes API request path.

Question 4mediummultiple choice

A security audit reveals that a container image running in production contains a critical vulnerability (CVE-2024-1234). The image was built from a base image that had the vulnerability. What is the MOST effective long-term solution to prevent such issues?

Trap 1: Use a runtime security tool like Falco to detect exploitation…

Falco is a runtime security tool that generates alerts when containers exhibit suspicious behavior, such as spawning a shell or accessing unexpected files. However, detection alone does not remediate the vulnerability; the vulnerable package remains in the running image and an attacker can still exploit it before an alert triggers a response. Furthermore, relying on Falco presupposes that detection rules are comprehensive and continuously updated, which is not a substitute for eliminating the vulnerable dependency at the source.

Trap 2: Patch the vulnerability by installing a security update inside the…

Installing a security update inside a running container modifies only the container's writable layer, which is ephemeral and will be lost as soon as the container is restarted or replaced. This approach also introduces configuration drift, making the container's state inconsistent with the image definition and the rest of the cluster. The underlying image in the registry remains vulnerable, so every future instance spun from that image will still be exposed. A proper fix requires rebuilding the image from a patched base image so the vulnerable layer is replaced permanently.

Trap 3: Add an admission controller that rejects images with…

An admission controller that blocks images with known vulnerabilities stops them from being deployed in the cluster, but it does not address the fact that the vulnerable image still exists in the container registry and could be pulled and run in other environments. This is a reactive, policy-based control that depends on an up-to-date vulnerability database and can be bypassed if the scan results are stale or the controller is misconfigured. The root cause lies in the image build process—using an outdated base image or failing to update dependencies—which must be fixed by rebuilding the image and scanning during CI/CD.

A
Use a runtime security tool like Falco to detect exploitation attempts.
Why wrong: Falco is a runtime security tool that generates alerts when containers exhibit suspicious behavior, such as spawning a shell or accessing unexpected files. However, detection alone does not remediate the vulnerability; the vulnerable package remains in the running image and an attacker can still exploit it before an alert triggers a response. Furthermore, relying on Falco presupposes that detection rules are comprehensive and continuously updated, which is not a substitute for eliminating the vulnerable dependency at the source.
B
Patch the vulnerability by installing a security update inside the running container.
Why wrong: Installing a security update inside a running container modifies only the container's writable layer, which is ephemeral and will be lost as soon as the container is restarted or replaced. This approach also introduces configuration drift, making the container's state inconsistent with the image definition and the rest of the cluster. The underlying image in the registry remains vulnerable, so every future instance spun from that image will still be exposed. A proper fix requires rebuilding the image from a patched base image so the vulnerable layer is replaced permanently.
C
Add an admission controller that rejects images with vulnerabilities.
Why wrong: An admission controller that blocks images with known vulnerabilities stops them from being deployed in the cluster, but it does not address the fact that the vulnerable image still exists in the container registry and could be pulled and run in other environments. This is a reactive, policy-based control that depends on an up-to-date vulnerability database and can be bypassed if the scan results are stale or the controller is misconfigured. The root cause lies in the image build process—using an outdated base image or failing to update dependencies—which must be fixed by rebuilding the image and scanning during CI/CD.
D
Rebuild the image using a patched base image and integrate vulnerability scanning into the CI pipeline.
Rebuilding the image from a patched base image directly eliminates the vulnerable package from the image filesystem, ensuring that the vulnerability is no longer present in the artifact itself. Integrating vulnerability scanning into the CI pipeline shifts security left, allowing teams to detect and block vulnerable images before they are pushed to a registry or deployed. This approach is sustainable and reproducible, as every build is validated and known vulnerabilities trigger a pipeline failure, forcing developers to update dependencies promptly. It addresses the source of the issue rather than applying after-the-fact controls.
E
Switch to a different container runtime that is immune to the vulnerability.
Why wrong: The vulnerability resides in the container image's layers—specifically, the packaged software and libraries—not in the container runtime that executes the image. Switching from containerd to CRI-O, or to any other runtime, does not change the image content; the vulnerable package will still be present and can be exploited just the same. While a different runtime might offer different security features (e.g., seccomp or SELinux), those do not render the image 'immune' to the known vulnerability. Therefore, this action is ineffective because the attack surface remains unchanged at the image level.

Question 5hardmultiple choice

An organization uses a private container registry and wants to ensure that only images built from a specific CI/CD pipeline are deployed. Which combination of measures provides the strongest guarantee?

Trap 1: Implement network policies to restrict egress from pods to the…

Network policies operate at the network layer, filtering traffic based on IP addresses, ports, and labels; they cannot inspect the contents or provenance of container images. Restricting egress to the registry only limits where pods can connect, not which images are allowed to run, so a malicious image already pulled and launched would remain unaffected. Admission-time verification of signed attestations is required to establish trust in image provenance before a workload is scheduled.

Trap 2: Grant registry write access only to the CI system's service account.

Granting registry write access solely to the CI system's service account follows least privilege, but it still leaves the CI pipeline as a single point of failure. If an attacker compromises the CI system—for example, via a malicious dependency or stolen credentials—they can push arbitrary images to the registry, and the cluster will blindly run them. This control reduces the attack surface but provides no cryptographic proof that the images were built by the intended, unmodified pipeline.

Trap 3: Use a static analysis tool to check the Dockerfile before building.

Static analysis of a Dockerfile examines the declared build steps, such as base images and RUN commands, but it cannot inspect the fully built image or its layers. Problems like a vulnerable base image that is pulled at build time, a compromised package repository, or a tampered build cache will not be detected by Dockerfile linting alone. Such tools are useful for security hygiene but do not create verifiable evidence of the image's origin or content.

A
Implement network policies to restrict egress from pods to the registry.
Why wrong: Network policies operate at the network layer, filtering traffic based on IP addresses, ports, and labels; they cannot inspect the contents or provenance of container images. Restricting egress to the registry only limits where pods can connect, not which images are allowed to run, so a malicious image already pulled and launched would remain unaffected. Admission-time verification of signed attestations is required to establish trust in image provenance before a workload is scheduled.
B
Grant registry write access only to the CI system's service account.
Why wrong: Granting registry write access solely to the CI system's service account follows least privilege, but it still leaves the CI pipeline as a single point of failure. If an attacker compromises the CI system—for example, via a malicious dependency or stolen credentials—they can push arbitrary images to the registry, and the cluster will blindly run them. This control reduces the attack surface but provides no cryptographic proof that the images were built by the intended, unmodified pipeline.
C
Use a static analysis tool to check the Dockerfile before building.
Why wrong: Static analysis of a Dockerfile examines the declared build steps, such as base images and RUN commands, but it cannot inspect the fully built image or its layers. Problems like a vulnerable base image that is pulled at build time, a compromised package repository, or a tampered build cache will not be detected by Dockerfile linting alone. Such tools are useful for security hygiene but do not create verifiable evidence of the image's origin or content.
D
Use a unique registry path and restrict access via firewall rules.
Why wrong: Using a unique registry path and firewall rules provides access control based on network location and obscurity, but it does not ensure that images pushed to that path are legitimate. If the CI credentials or a developer's token are stolen, the attacker can push a malicious image to that same path, and the firewall will allow it because it originates from a permitted network. This approach cannot detect or prevent tampering; it only reduces the chance of outside access.
E
Generate signed attestations with in-toto during the CI pipeline and verify them using an admission webhook like Kyverno.
In-toto attestations are cryptographically signed metadata generated during the CI pipeline that describe the build steps, materials, and results, providing non-repudiation for the image's origin. An admission webhook such as Kyverno can be configured to verify these signatures and attestations at admission time, ensuring that only images produced by the trusted pipeline and with valid provenance are allowed to run. This combination enables robust supply-chain security by tying the runtime state to an auditable, tamper-evident build process.

Question 6hardmultiple choice

You are the lead security engineer for a large financial institution. The organization runs a Kubernetes cluster with 500+ microservices. The supply chain security team has implemented the following measures: (1) All images are built from a minimal base image (distroless) and scanned with Trivy before being pushed to a private registry. (2) Images are signed using cosign with a key stored in a hardware security module (HSM). (3) Kyverno policies enforce that only signed images from the private registry can run, and also enforce that containers run as non-root. (4) A binary authorization (binauthz) style admission controller verifies attestations. Recently, a critical vulnerability (CVE-2024-0001) was discovered in a popular open-source library used by several microservices. The library is included as a dependency in the base image. The vulnerability is remotely exploitable and has a CVSS score of 9.8. The security team needs to remediate this quickly. They have already patched the library and updated the base image. What is the BEST course of action to ensure all running pods use the new image?

Trap 1: SSH into each node, pull the new image, and use kubectl exec to…

SSHing into nodes and editing files inside running containers fundamentally breaks the container immutability principle and the changes are lost on any restart or reschedule because they are not captured in the image or the pod spec. Furthermore, kubectl exec only affects a live container; the node still holds the original image and the kubelet will never re-pull the new image for existing pods, so the vulnerability remains on any new replica. This is also operationally unscalable and violates security best practices like immutable infrastructure and traceable configuration.

Trap 2: Temporarily disable the admission controller that verifies…

Temporarily removing the admission control check creates a window during which any image—even one that is malicious or unverified—can be deployed, undermining the entire supply chain security model. Even if you re-enable it afterwards, the deployment that goes through during the disabled period is never scrutinized, and you might accidentally leave the policy off in a production cluster. The correct behavior is to keep image verification active and ensure the patched image meets the established signature and attestation requirements, as disabling policy for convenience is a common security anti-pattern.

Trap 3: Delete all running pods and let the ReplicaSets recreate them from…

Deleting all pods does not alter the image reference stored in each ReplicaSet's PodTemplate; the ReplicaSet controller will simply recreate pods with the exact same vulnerable image, and you'll have incurred downtime for zero remediation. This is equivalent to a hard restart, not an update, and it lacks the gradual, health-checked rollout that a Deployment rolling update provides. Without changing the Deployment's spec, the cluster will keep using the old, unpatched container image indefinitely.

A
Update the image tag in each Deployment's spec to point to the new patched image, then perform a rolling update. The admission controller will verify signatures and attestations for the new image.
Updating the image tag in each Deployment's PodTemplateSpec is the correct declarative approach: it triggers a rolling replacement of the underlying ReplicaSets, so old pods are terminated only after new ones become Ready. During pod creation, the cluster's validating/mutating admission controller (e.g., Kyverno or OPA via cosign) checks the image's cryptographic signature and attestations; if the patched image is signed and passes policy, the update proceeds. This ensures every pod runs a verified, patched image with zero downtime.
B
SSH into each node, pull the new image, and use kubectl exec to update the library inside running containers.
Why wrong: SSHing into nodes and editing files inside running containers fundamentally breaks the container immutability principle and the changes are lost on any restart or reschedule because they are not captured in the image or the pod spec. Furthermore, kubectl exec only affects a live container; the node still holds the original image and the kubelet will never re-pull the new image for existing pods, so the vulnerability remains on any new replica. This is also operationally unscalable and violates security best practices like immutable infrastructure and traceable configuration.
C
Temporarily disable the admission controller that verifies signatures and then update the image tags.
Why wrong: Temporarily removing the admission control check creates a window during which any image—even one that is malicious or unverified—can be deployed, undermining the entire supply chain security model. Even if you re-enable it afterwards, the deployment that goes through during the disabled period is never scrutinized, and you might accidentally leave the policy off in a production cluster. The correct behavior is to keep image verification active and ensure the patched image meets the established signature and attestation requirements, as disabling policy for convenience is a common security anti-pattern.
D
Delete all running pods and let the ReplicaSets recreate them from the existing image.
Why wrong: Deleting all pods does not alter the image reference stored in each ReplicaSet's PodTemplate; the ReplicaSet controller will simply recreate pods with the exact same vulnerable image, and you'll have incurred downtime for zero remediation. This is equivalent to a hard restart, not an update, and it lacks the gradual, health-checked rollout that a Deployment rolling update provides. Without changing the Deployment's spec, the cluster will keep using the old, unpatched container image indefinitely.

Question 7hardmultiple choice

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?

Trap 1: Configure Argo CD to verify Cosign signatures before syncing the…

Argo CD is a GitOps controller that reconciles state from Git, but it has no built-in support for verifying Cosign signatures on container images. While external integrations or plugins might be added, the native sync process will not inspect image signatures, so unsigned images could still be deployed. Additionally, Argo CD only manages applications it is configured to sync, leaving non-GitOps or direct deployments outside its protective scope.

Trap 2: Use imagePullSecrets in Kubernetes to ensure only Harbor images are…

imagePullSecrets merely provide Kubernetes with credentials to authenticate to a private registry like Harbor; they do not inspect the image's signature, trust status, or vulnerability scan results. An imagePullSecret will happily pull an unsigned or compromised image if the credentials are valid, because it only handles authentication and not content assurance. Therefore, while imagePullSecrets are necessary for private registry access, they do nothing to enforce a signature or scanning policy.

Trap 3: Add a Cosign verification step in the CI pipeline before pushing…

Adding a Cosign verification step in the CI pipeline ensures that images built through your official pipeline are signed before being pushed to Harbor, but it provides no protection against direct pushes to the registry. If an attacker compromises registry credentials or has insider access, they can push an unsigned or malicious image that bypasses the CI check entirely. Since Kubernetes does not re-verify the signature at runtime or deploy time, relying solely on CI verification leaves a critical supply chain gap that should be closed by registry-side enforcement and admission control.

A
Configure Argo CD to verify Cosign signatures before syncing the application.
Why wrong: Argo CD is a GitOps controller that reconciles state from Git, but it has no built-in support for verifying Cosign signatures on container images. While external integrations or plugins might be added, the native sync process will not inspect image signatures, so unsigned images could still be deployed. Additionally, Argo CD only manages applications it is configured to sync, leaving non-GitOps or direct deployments outside its protective scope.
B
Use imagePullSecrets in Kubernetes to ensure only Harbor images are used.
Why wrong: imagePullSecrets merely provide Kubernetes with credentials to authenticate to a private registry like Harbor; they do not inspect the image's signature, trust status, or vulnerability scan results. An imagePullSecret will happily pull an unsigned or compromised image if the credentials are valid, because it only handles authentication and not content assurance. Therefore, while imagePullSecrets are necessary for private registry access, they do nothing to enforce a signature or scanning policy.
C
Add a Cosign verification step in the CI pipeline before pushing images to Harbor, and rely on that guarantee.
Why wrong: Adding a Cosign verification step in the CI pipeline ensures that images built through your official pipeline are signed before being pushed to Harbor, but it provides no protection against direct pushes to the registry. If an attacker compromises registry credentials or has insider access, they can push an unsigned or malicious image that bypasses the CI check entirely. Since Kubernetes does not re-verify the signature at runtime or deploy time, relying solely on CI verification leaves a critical supply chain gap that should be closed by registry-side enforcement and admission control.
D
Enable Harbor's content trust feature to reject unsigned images, and use a Kyverno admission rule to verify Cosign signatures at deploy time.
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.

Question 8easymulti select

You are auditing a cluster's supply chain security. You find that many pods are running images from public registries without any pinning or verification. Which TWO actions would most effectively reduce the risk of pulling malicious images?

Trap 1: Implement RBAC to restrict which users can create pods.

RBAC limits which users or service accounts can create pods, but it does nothing to validate the content of the images those authorized users select. An authenticated developer who is allowed to create a Deployment can still reference a public image with a malicious or tampered tag, and the kubelet will happily pull it. RBAC addresses authorization of actions, not the integrity or provenance of artifacts, so it is orthogonal to supply-chain security in this scenario.

Trap 2: Enforce PodSecurityStandard baseline or restricted to block…

The PodSecurityStandard (baseline or restricted) constrains pod-level privileges such as running as root, adding capabilities, or sharing host namespaces, but it does not evaluate the image's source, authenticity, or embedded code. A malicious image can run as a non-root user without any privileged container fields and still contain malware, crypto-miners, or credential stealers. Therefore, enforcing these standards reduces container breakout risk but does not prevent pulling or executing untrusted images.

Trap 3: Apply a network policy that blocks egress traffic to public…

NetworkPolicies govern traffic between pods and to external endpoints as defined by the kubelet, but image pulling is performed by the container runtime (e.g., containerd) on the node before any pod network is set up. Even if a NetworkPolicy blocks egress from the pod, the kubelet's image pull traffic does not traverse the pod's network namespace; it uses the host's network. Consequently, blocking egress from pods to public registries has zero effect on image pulls, and the node would still need registry access unless a proxy or restricted endpoint is configured.

A
Configure all deployments to use image digests instead of tags.
Pinning images to content-addressable digests (e.g., sha256:...) makes the container runtime pull the exact manifest that was vetted at admission time, because tags are mutable references that can be overwritten in a registry. A tag like :latest may be shifted to a compromised build, whereas a digest is a hash of the image manifest, and any change to the image content alters that hash. This prevents tag-based mutation, typo-squatting, and stale cached pulls, and it is the foundation for verifying image signatures and provenance attestations.
B
Set up a private registry proxy that mirrors approved public images and disable direct access to public registries via containerd configuration.
A private registry proxy (pull-through cache) fronted by a mirror configuration in containerd's hosts.toml can enforce an allowlist of approved images and perform vulnerability scanning before images are cached. By setting containerd to fetch only from the proxy and blocking direct registry endpoints (via firewall, registry config, or containerd's 'capabilities'), the kubelet never contacts public registries directly. This gives the cluster a central control point for image provenance, reduces supply-chain attack surface, and ensures all images pass through the same verification pipeline.
C
Implement RBAC to restrict which users can create pods.
Why wrong: RBAC limits which users or service accounts can create pods, but it does nothing to validate the content of the images those authorized users select. An authenticated developer who is allowed to create a Deployment can still reference a public image with a malicious or tampered tag, and the kubelet will happily pull it. RBAC addresses authorization of actions, not the integrity or provenance of artifacts, so it is orthogonal to supply-chain security in this scenario.
D
Enforce PodSecurityStandard baseline or restricted to block privileged containers.
Why wrong: The PodSecurityStandard (baseline or restricted) constrains pod-level privileges such as running as root, adding capabilities, or sharing host namespaces, but it does not evaluate the image's source, authenticity, or embedded code. A malicious image can run as a non-root user without any privileged container fields and still contain malware, crypto-miners, or credential stealers. Therefore, enforcing these standards reduces container breakout risk but does not prevent pulling or executing untrusted images.
E
Apply a network policy that blocks egress traffic to public registries.
Why wrong: NetworkPolicies govern traffic between pods and to external endpoints as defined by the kubelet, but image pulling is performed by the container runtime (e.g., containerd) on the node before any pod network is set up. Even if a NetworkPolicy blocks egress from the pod, the kubelet's image pull traffic does not traverse the pod's network namespace; it uses the host's network. Consequently, blocking egress from pods to public registries has zero effect on image pulls, and the node would still need registry access unless a proxy or restricted endpoint is configured.

Question 9hardmulti select

You are securing a Kubernetes cluster that runs workloads from multiple teams. The cluster uses a private container registry and an admission controller to enforce image policies. Which TWO of the following actions are most effective in preventing the use of unapproved or tampered container images? (Choose two correct answers.)

Trap 1: Use OPA Gatekeeper to enforce a policy that rejects pods using…

OPA Gatekeeper can enforce tag-based policies, but checking that an image doesn't use the 'latest' tag only regulates a naming convention. It does nothing to verify the image's cryptographic signature, digest, or origin, so a compromised image simply retagged as 'stable' would pass. Such a policy also breaks legitimate GitOps/rolling update patterns that rely on moving 'latest'.

Trap 2: Configure imagePullSecrets for each namespace to ensure only…

imagePullSecrets provide registry credentials so kubelet can authenticate to a private repository; they neither verify the image's content nor enforce that a particular pod should run a particular image. A compromised or malicious image from an authorized registry will be pulled just fine, and the secret itself becomes a sensitive credential that must be rotated. These secrets are about authentication, not validation, so they do not secure the cluster against untrusted or vulnerable images.

Trap 3: Implement a NetworkPolicy that blocks egress traffic from the…

NetworkPolicy controls traffic at L3/L4 using labels and CIDR rules; it cannot inspect the contents of a registry response or decide whether an image is trustworthy. Denying egress to certain registry IPs is brittle because modern registries use elastic CDNs with frequently changing addresses, and it does not block malicious images served from an allowed registry. It is a network-level control, not an image-integrity control.

A
Use OPA Gatekeeper to enforce a policy that rejects pods using images with the 'latest' tag.
Why wrong: OPA Gatekeeper can enforce tag-based policies, but checking that an image doesn't use the 'latest' tag only regulates a naming convention. It does nothing to verify the image's cryptographic signature, digest, or origin, so a compromised image simply retagged as 'stable' would pass. Such a policy also breaks legitimate GitOps/rolling update patterns that rely on moving 'latest'.
B
Configure imagePullSecrets for each namespace to ensure only authorized service accounts can pull images.
Why wrong: imagePullSecrets provide registry credentials so kubelet can authenticate to a private repository; they neither verify the image's content nor enforce that a particular pod should run a particular image. A compromised or malicious image from an authorized registry will be pulled just fine, and the secret itself becomes a sensitive credential that must be rotated. These secrets are about authentication, not validation, so they do not secure the cluster against untrusted or vulnerable images.
C
Deploy Kyverno with a policy that requires images to have a specific annotation indicating they passed a security scan.
Kyverno operates as a validating and mutating admission controller and can inspect pod specs at admission time. A policy can require a custom annotation (e.g., `security-scan: pass`) on every container image, rejecting pods whose images do not carry proof that a scan completed. This directly enforces the organization's image-validation workflow at the point of deployment, and Kyverno can also mutate images to add digests for stronger guarantees.
D
Implement a NetworkPolicy that blocks egress traffic from the cluster to unauthorized container registries.
Why wrong: NetworkPolicy controls traffic at L3/L4 using labels and CIDR rules; it cannot inspect the contents of a registry response or decide whether an image is trustworthy. Denying egress to certain registry IPs is brittle because modern registries use elastic CDNs with frequently changing addresses, and it does not block malicious images served from an allowed registry. It is a network-level control, not an image-integrity control.
E
Set up an ImagePolicyWebhook admission controller that checks image signatures and only allows signed images from your registry.
ImagePolicyWebhook is a specialized admission controller that delegates image admission decisions to an external service, which can verify the image's digital signature and attestation. Because it validates cryptographically the signer of the image digest, it is far stronger than tag- or annotation-based checks; an attacker would need to possess the private signing key to pass. This directly addresses the goal of only allowing signed images from your registry, providing strong provenance.

Question 10hardmultiple choice

Refer to the exhibit. A cluster has the ClusterImagePolicy shown. A developer creates a pod with an image from registry.example.com/myapp:v1, which was built and signed by a GitHub Actions workflow that is NOT defined in the policy (different workflow). Which behavior will occur when the pod is created?

Exhibit

Refer to the exhibit.

apiVersion: cosigned.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: image-policy
spec:
  images:
  - glob: registry.example.com/*
  authorities:
  - keyless:
      identities:
      - issuer: https://accounts.example.com
        subject: https://github.com/example/actions/.github/workflows/release.yml@refs/heads/main

Trap 1: The pod is admitted because keyless signing does not enforce…

Keyless signing does enforce identity matching: in a ClusterImagePolicy, the `spec.authorities[].identities` field lists expected Fulcio issuer and subject values. The policy evaluator compares the signer's certificate identity against that list, and a mismatch triggers denial rather than admission. Therefore the assertion that keyless signing ignores identity is factually incorrect.

Trap 2: The pod is admitted because the policy only applies to images with…

The policy's image glob is `registry.example.com/*`, and the glob wildcard `*` matches any suffix after the slash, including every tag, digest, and even untagged images. This means the policy is not restricted to tags beginning with 'v'; it applies to all images under the allowed registry path. Since the pod's image falls into that matched pattern, the tag-based exemption claim is false.

Trap 3: The pod is admitted because the image is from the allowed registry.

Matching the allowed registry only satisfies the image-name portion of the policy; the ClusterImagePolicy also requires the signature's identity to match an entry in `spec.authorities[].identities`. An image from registry.example.com is still rejected if its signer's Fulcio issuer or subject is not present in that list. Registry allow-listing is necessary but not sufficient for admission.

A
The pod is admitted because keyless signing does not enforce identity matching.
Why wrong: Keyless signing does enforce identity matching: in a ClusterImagePolicy, the `spec.authorities[].identities` field lists expected Fulcio issuer and subject values. The policy evaluator compares the signer's certificate identity against that list, and a mismatch triggers denial rather than admission. Therefore the assertion that keyless signing ignores identity is factually incorrect.
B
The pod is admitted because the policy only applies to images with a tag 'v*'.
Why wrong: The policy's image glob is `registry.example.com/*`, and the glob wildcard `*` matches any suffix after the slash, including every tag, digest, and even untagged images. This means the policy is not restricted to tags beginning with 'v'; it applies to all images under the allowed registry path. Since the pod's image falls into that matched pattern, the tag-based exemption claim is false.
C
The pod is admitted because the image is from the allowed registry.
Why wrong: Matching the allowed registry only satisfies the image-name portion of the policy; the ClusterImagePolicy also requires the signature's identity to match an entry in `spec.authorities[].identities`. An image from registry.example.com is still rejected if its signer's Fulcio issuer or subject is not present in that list. Registry allow-listing is necessary but not sufficient for admission.
D
The pod is denied because the image's signer identity does not match the policy.
Cosigned's admission webhook evaluates both the image reference and the signature's identity. Because the keyless certificate presented for this image has an issuer or subject that does not appear in the policy's `identities` array, the admission request is denied. This is the expected behavior when identity matching is enforced, so the pod cannot be admitted.

Question 11mediumdrag order

Arrange the steps to secure etcd in a Kubernetes cluster.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Configure etcd with TLS, then generate TLS certificates, then…

Configuring etcd to use TLS before any certificates are generated is logically impossible. The etcd configuration parameters, such as --cert-file, --key-file, and --trusted-ca-file, must reference existing PEM files; without them, the process will fail to start or silently fall back to plaintext communication. Additionally, any attempt to validate the configuration with clients will fail because they cannot securely connect without a certificate to present. Certificate generation must always occur first.

Trap 2: Generate TLS certificates, then restart etcd, then configure etcd…

Restarting etcd immediately after generating certificates but before updating its configuration to enable TLS leaves the service running with its previous non-TLS settings, so the newly created certificates are never loaded. This creates a risky window where etcd is still exposed on plaintext HTTP despite having the necessary certificate material on disk, allowing potential data interception. The restart only applies TLS if the configuration has already been edited to reference the certificates, making this ordering functionally incorrect.

Trap 3: Restrict network access to etcd, then generate TLS certificates,…

Applying network restrictions to etcd before provisioning TLS can sever administrative access needed to generate or distribute certificates. For example, if certificate generation depends on cloud provider APIs, an external CA, or communication with peer nodes, firewalling etcd ports first may block that connectivity entirely. Even if certificates are pre-staged, restricting the network without enabling TLS does not encrypt data, leaving data at rest and in transit vulnerable. TLS should be established first to secure the communication channels, then the network surface can be safely limited to trusted peers.

A
Generate TLS certificates, then configure etcd with TLS, then restart etcd, then verify health and restrict network access
This is the correct order because TLS certificates must be generated before configuring etcd to use them, then etcd must be restarted to apply the changes, and finally health verification and network restriction ensure the setup is secure and functional.
B
Configure etcd with TLS, then generate TLS certificates, then restart etcd, then verify health and restrict network access
Why wrong: Configuring etcd to use TLS before any certificates are generated is logically impossible. The etcd configuration parameters, such as --cert-file, --key-file, and --trusted-ca-file, must reference existing PEM files; without them, the process will fail to start or silently fall back to plaintext communication. Additionally, any attempt to validate the configuration with clients will fail because they cannot securely connect without a certificate to present. Certificate generation must always occur first.
C
Generate TLS certificates, then restart etcd, then configure etcd with TLS, then verify health and restrict network access
Why wrong: Restarting etcd immediately after generating certificates but before updating its configuration to enable TLS leaves the service running with its previous non-TLS settings, so the newly created certificates are never loaded. This creates a risky window where etcd is still exposed on plaintext HTTP despite having the necessary certificate material on disk, allowing potential data interception. The restart only applies TLS if the configuration has already been edited to reference the certificates, making this ordering functionally incorrect.
D
Restrict network access to etcd, then generate TLS certificates, then configure etcd with TLS, then restart etcd
Why wrong: Applying network restrictions to etcd before provisioning TLS can sever administrative access needed to generate or distribute certificates. For example, if certificate generation depends on cloud provider APIs, an external CA, or communication with peer nodes, firewalling etcd ports first may block that connectivity entirely. Even if certificates are pre-staged, restricting the network without enabling TLS does not encrypt data, leaving data at rest and in transit vulnerable. TLS should be established first to secure the communication channels, then the network surface can be safely limited to trusted peers.

Question 12mediummatching

Match each Kubernetes API server flag to its security function.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Enables RBAC authorization

Comma-separated list of admission controllers to enable

Disables anonymous requests to the API server

Path to a CA file for verifying kubelet certificates

File containing PEM-encoded x509 RSA or ECDSA private or public keys for service account token signing

Trap 1: --authorization-mode=RBAC: Enables anonymous authentication

This is incorrect because `--authorization-mode=RBAC` governs what an already-identified user is allowed to do, not whether unauthenticated users may access the API. Anonymous authentication is a separate authentication-layer control, toggled by the `--anonymous-auth` flag, which defaults to allowed. RBAC alone does not grant or deny anonymous identity; it merely enforces rules on the user or service account that is presented after authentication.

Trap 2: --anonymous-auth=false: Enables RBAC

This is incorrect because `--anonymous-auth=false` only prevents unauthenticated requests from being mapped to the `system:anonymous` user; it does not enable any authorization mechanism. RBAC is a distinct authorization mode that must be explicitly turned on with `--authorization-mode=RBAC`. Even if anonymous access is disabled, the API server will still fall back to its configured authorization mode, which could be `AlwaysAllow` or another mode unless RBAC is separately enabled.

Trap 3: --profiling=false: Enables audit logging

This is incorrect because audit logging is controlled by independent flags such as `--audit-log-path`, `--audit-log-maxage`, and `--audit-policy-file`, which record API requests for security review. The `--profiling` flag exclusively toggles the pprof debugging endpoints and has no effect on audit log creation or configuration. Setting `--profiling=false` only disables information disclosure via profiling; it does not turn on any kind of logging or auditing.

A
--authorization-mode=RBAC: Enables RBAC authorization
The `--authorization-mode=RBAC` flag configures the API server to use RBAC as the authorization mechanism. RBAC enforces access control by evaluating requests against Role, ClusterRole, RoleBinding, and ClusterRoleBinding objects, which specify which verbs (e.g., get, create, delete) a user or service account may execute on which API resources. Authentication must already be completed for a request to reach this stage, so this flag does not influence authentication or anonymous access.
B
--anonymous-auth=false: Disables anonymous authentication
Setting `--anonymous-auth=false` explicitly disables the API server's default behavior of treating requests without any provided credentials as originating from the `system:anonymous` user. By denying these unauthenticated requests, the flag prevents unknown actors from reaching the authorization layer, thereby reducing the attack surface. It is a common hardening step but does not affect authenticated identities like valid service account tokens or client certificates.
C
--profiling=false: Disables profiling to prevent information disclosure
`--profiling=false` turns off the API server's profiler endpoints under `/debug/pprof`, which expose sensitive runtime information such as goroutine stack traces, heap memory usage, and ongoing CPU profiles. An attacker who reaches these endpoints can gather system internals to craft a more effective exploit. Disabling profiling aligns with security baselines like CIS Kubernetes Benchmark, and it is recommended even though the flag defaults to true.
D
--authorization-mode=RBAC: Enables anonymous authentication
Why wrong: This is incorrect because `--authorization-mode=RBAC` governs what an already-identified user is allowed to do, not whether unauthenticated users may access the API. Anonymous authentication is a separate authentication-layer control, toggled by the `--anonymous-auth` flag, which defaults to allowed. RBAC alone does not grant or deny anonymous identity; it merely enforces rules on the user or service account that is presented after authentication.
E
--anonymous-auth=false: Enables RBAC
Why wrong: This is incorrect because `--anonymous-auth=false` only prevents unauthenticated requests from being mapped to the `system:anonymous` user; it does not enable any authorization mechanism. RBAC is a distinct authorization mode that must be explicitly turned on with `--authorization-mode=RBAC`. Even if anonymous access is disabled, the API server will still fall back to its configured authorization mode, which could be `AlwaysAllow` or another mode unless RBAC is separately enabled.
F
--profiling=false: Enables audit logging
Why wrong: This is incorrect because audit logging is controlled by independent flags such as `--audit-log-path`, `--audit-log-maxage`, and `--audit-policy-file`, which record API requests for security review. The `--profiling` flag exclusively toggles the pprof debugging endpoints and has no effect on audit log creation or configuration. Setting `--profiling=false` only disables information disclosure via profiling; it does not turn on any kind of logging or auditing.

Question 13easymultiple choice

A security engineer wants to ensure that only images signed with a specific key are allowed to run in the cluster. Which tool can be used to sign container images?

Trap 1: kubesec

kubesec is a static manifest analyzer that scores Kubernetes YAML against security best practices (e.g., checking for privileged containers, hostNetwork, or writable root filesystems). It does not interact with container image registries at all, so it cannot verify an image's cryptographic signature or provenance. Its output is a risk score, not a trust decision.

Trap 2: syft

syft is a tool for generating Software Bills of Materials (SBOMs) from container images or filesystems by enumerating packages and their versions. It has no signature creation or verification capability, and it does not connect to a registry's signature store. Identifying the inventory of an image is fundamentally different from proving that the image was signed by an authorized publisher.

Trap 3: trivy

trivy is a vulnerability scanner that checks container images and filesystems for known CVEs and misconfigurations, often used in CI/CD pipelines. It intentionally has no signing capability; signature verification is out of its scope. While a signed image can still be vulnerable, trivy's purpose is security defect detection, not provenance or authenticity assurance.

A
kubesec
Why wrong: kubesec is a static manifest analyzer that scores Kubernetes YAML against security best practices (e.g., checking for privileged containers, hostNetwork, or writable root filesystems). It does not interact with container image registries at all, so it cannot verify an image's cryptographic signature or provenance. Its output is a risk score, not a trust decision.
B
syft
Why wrong: syft is a tool for generating Software Bills of Materials (SBOMs) from container images or filesystems by enumerating packages and their versions. It has no signature creation or verification capability, and it does not connect to a registry's signature store. Identifying the inventory of an image is fundamentally different from proving that the image was signed by an authorized publisher.
C
cosign
cosign is part of the Sigstore project and natively supports signing container images and verifying those signatures, including keyless signing via Fulcio and transparency logs (Rekor). It stores signatures as separate OCI artifacts, typically tagged like 'sha256-<digest>.sig', and can enforce that only verified images are admitted. Because it directly addresses the requirement to ensure images are signed, it is the only correct choice here.
D
trivy
Why wrong: trivy is a vulnerability scanner that checks container images and filesystems for known CVEs and misconfigurations, often used in CI/CD pipelines. It intentionally has no signing capability; signature verification is out of its scope. While a signed image can still be vulnerable, trivy's purpose is security defect detection, not provenance or authenticity assurance.

Question 14mediummultiple choice

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?

Trap 1: spec.containers[].securityContext.runAsUser: 0

Setting runAsUser: 0 explicitly assigns UID 0, which is the root user inside the container. Root has unrestricted privileges within the container, so this directly contradicts the developer's requirement to run as a non-root user. Even if the image's default user is non-root, this setting overrides it and grants root access, which is a security risk.

Trap 2: spec.containers[].securityContext.runAsNonRoot: true

The runAsNonRoot: true field is an assertion that the container will run as a non-root user, not a declaration of which user to use. It relies on the image having a non-root user configured; if the image's default user is root or unspecified, the container will fail to start instead of falling back to a safe UID. To guarantee running as a non-root user, you must explicitly set runAsUser to a non-zero value.

Trap 3: spec.containers[].securityContext.runAsGroup: 1000

runAsGroup: 1000 configures the primary group ID (GID) for the container's processes, not the user ID. This does not affect which user the process runs as, so if the image defaults to root (UID 0), the process remains root regardless of the group. A non-zero group alone does not satisfy the requirement for a non-root user; it must be paired with runAsUser.

A
spec.containers[].securityContext.runAsUser: 0
Why wrong: Setting runAsUser: 0 explicitly assigns UID 0, which is the root user inside the container. Root has unrestricted privileges within the container, so this directly contradicts the developer's requirement to run as a non-root user. Even if the image's default user is non-root, this setting overrides it and grants root access, which is a security risk.
B
spec.containers[].securityContext.runAsNonRoot: true
Why wrong: The runAsNonRoot: true field is an assertion that the container will run as a non-root user, not a declaration of which user to use. It relies on the image having a non-root user configured; if the image's default user is root or unspecified, the container will fail to start instead of falling back to a safe UID. To guarantee running as a non-root user, you must explicitly set runAsUser to a non-zero value.
C
spec.containers[].securityContext.runAsGroup: 1000
Why wrong: runAsGroup: 1000 configures the primary group ID (GID) for the container's processes, not the user ID. This does not affect which user the process runs as, so if the image defaults to root (UID 0), the process remains root regardless of the group. A non-zero group alone does not satisfy the requirement for a non-root user; it must be paired with runAsUser.
D
spec.containers[].securityContext.runAsUser: 1000
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.

Question 15hardmultiple choice

You are configuring an ImagePolicyWebhook admission controller to allow only images from a trusted registry 'trusted-registry.io'. Which flag must be set in the kube-apiserver configuration to enable the webhook?

Trap 1: --pod-security-policy

This is the deprecated flag for PodSecurityPolicy.

Trap 2: --image-policy-webhook-config

This is not a valid kube-apiserver flag.

Trap 3: --enable-admission-plugins=ImagePolicyWebhook

This enables the plugin but does not provide the configuration file.

A
--pod-security-policy
Why wrong: This is the deprecated flag for PodSecurityPolicy.
B
--admission-control-config-file
This flag points to a file that contains the configuration for ImagePolicyWebhook and other admission plugins.
C
--image-policy-webhook-config
Why wrong: This is not a valid kube-apiserver flag.
D
--enable-admission-plugins=ImagePolicyWebhook
Why wrong: This enables the plugin but does not provide the configuration file.

Question 16mediummultiple choice

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?

Trap 1: ResourceQuota

ResourceQuota is a built-in admission controller that enforces aggregate resource limits on a namespace, capping metrics like requests.cpu, requests.memory, limits.cpu, limits.memory, and object counts such as persistentvolumeclaims and pods. Its evaluation logic only inspects the resource request/limit fields of a pod, not the container image reference or tag. Thus, while it can reject a pod for exceeding quota, it has no mechanism to validate or deny based on image tag policies.

Trap 2: NetworkPolicy

NetworkPolicy is a Kubernetes resource that governs pod-to-pod communication via selected labels, namespaces, and CIDR blocks, with ingress and egress rules enforced by the CNI plugin in the dataplane, not by the API server. It operates after a pod has been successfully created and runs, filtering network traffic at L3/L4, so it never inspects the pod's image field during admission. Therefore, it cannot reject a pod before creation based on an image tag restriction.

Trap 3: PodSecurityPolicy (PSP)

PodSecurityPolicy (PSP) was a cluster-level admission controller that enforced security-sensitive fields such as privileged containers, host namespaces, volumes, and SELinux options. It was deprecated in Kubernetes 1.21 and removed in 1.25, and its policy schema never included a field for specifying allowed image tags or registries, so it could not express a denial of the 'latest' tag. Even when PSP existed, it could only restrict pod security context, not image provenance, making it ineffective for this use case.

A
ResourceQuota
Why wrong: ResourceQuota is a built-in admission controller that enforces aggregate resource limits on a namespace, capping metrics like requests.cpu, requests.memory, limits.cpu, limits.memory, and object counts such as persistentvolumeclaims and pods. Its evaluation logic only inspects the resource request/limit fields of a pod, not the container image reference or tag. Thus, while it can reject a pod for exceeding quota, it has no mechanism to validate or deny based on image tag policies.
B
NetworkPolicy
Why wrong: NetworkPolicy is a Kubernetes resource that governs pod-to-pod communication via selected labels, namespaces, and CIDR blocks, with ingress and egress rules enforced by the CNI plugin in the dataplane, not by the API server. It operates after a pod has been successfully created and runs, filtering network traffic at L3/L4, so it never inspects the pod's image field during admission. Therefore, it cannot reject a pod before creation based on an image tag restriction.
C
PodSecurityPolicy (PSP)
Why wrong: PodSecurityPolicy (PSP) was a cluster-level admission controller that enforced security-sensitive fields such as privileged containers, host namespaces, volumes, and SELinux options. It was deprecated in Kubernetes 1.21 and removed in 1.25, and its policy schema never included a field for specifying allowed image tags or registries, so it could not express a denial of the 'latest' tag. Even when PSP existed, it could only restrict pod security context, not image provenance, making it ineffective for this use case.
D
OPA/Gatekeeper
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.

Question 17hardmultiple choice

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?

Trap 1: The image tag does not exist in the registry

The 'No signatures found' error occurs only after cosign successfully retrieves the image manifest and computes its digest, then searches for a signature artifact tagged from that digest (e.g., 'sha256-<digest>.sig'). If the image tag itself does not exist, the registry returns a 404 MANIFEST_UNKNOWN error during manifest resolution, which happens before any signature lookup is attempted. Therefore, a non-existent tag yields a completely different failure message, not the signature-absence error, making this option incorrect.

Trap 2: Developer B used a different private key to sign than the public…

When a signature exists but was created using a different private key, the registry will contain a signature artifact, so cosign's discovery step will successfully list it. Only after retrieving the signature does cosign attempt cryptographic verification against the public key provided via `--key`; that step would fail with an 'invalid signature' or 'signature verification failed' error, not with 'No signatures found'. The 'No signatures found' message indicates that zero signature artifacts were discovered in the registry, meaning the failure occurs before key-based verification can even begin.

Trap 3: Developer A used the public key instead of the private key

Using a public key instead of the private key during signing would cause `cosign sign` itself to reject the operation, because generating a signature requires the private key component; the command would exit with a key-format or cipher error. Such a failure would either leave no signature pushed or produce a signing error that the developer would immediately observe, not a verification-time 'No signatures found'. The observed error is about the absence of signature artifacts in the registry, which is independent of whether the wrong key type was attempted at signing time.

A
The image tag does not exist in the registry
Why wrong: The 'No signatures found' error occurs only after cosign successfully retrieves the image manifest and computes its digest, then searches for a signature artifact tagged from that digest (e.g., 'sha256-<digest>.sig'). If the image tag itself does not exist, the registry returns a 404 MANIFEST_UNKNOWN error during manifest resolution, which happens before any signature lookup is attempted. Therefore, a non-existent tag yields a completely different failure message, not the signature-absence error, making this option incorrect.
B
The signing command failed to push the signature to the registry
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.
C
Developer B used a different private key to sign than the public key used for verification
Why wrong: When a signature exists but was created using a different private key, the registry will contain a signature artifact, so cosign's discovery step will successfully list it. Only after retrieving the signature does cosign attempt cryptographic verification against the public key provided via `--key`; that step would fail with an 'invalid signature' or 'signature verification failed' error, not with 'No signatures found'. The 'No signatures found' message indicates that zero signature artifacts were discovered in the registry, meaning the failure occurs before key-based verification can even begin.
D
Developer A used the public key instead of the private key
Why wrong: Using a public key instead of the private key during signing would cause `cosign sign` itself to reject the operation, because generating a signature requires the private key component; the command would exit with a key-format or cipher error. Such a failure would either leave no signature pushed or produce a signing error that the developer would immediately observe, not a verification-time 'No signatures found'. The observed error is about the absence of signature artifacts in the registry, which is independent of whether the wrong key type was attempted at signing time.

Question 18easymultiple choice

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

Trap 1: kubesec

Kubesec is a Kubernetes security scanner that statically analyzes resource manifests like Deployments and Pods, scoring them against best practices such as disallowing privileged containers or host network access. It operates entirely on YAML/JSON declarations and never inspects container image layers, package metadata, or filesystem contents. Since generating an SBOM requires enumerating the actual software components inside an image or directory, kubesec lacks the fundamental capability to produce a software bill of materials.

Trap 2: trivy

Trivy is primarily a vulnerability scanner: it scans container images and filesystems for known CVEs by matching installed package versions against NVD and other databases. Although recent versions include an 'sbom' subcommand that can output SPDX or CycloneDX, that functionality is an auxiliary feature built on top of its scanning engine rather than a comprehensive cataloger. Trivy's SBOM output omits some dependency relationships and metadata that syft captures, so while it can produce a partial SBOM, the dedicated and conventional choice for SBOM generation is syft.

Trap 3: cosign

Cosign is a supply-chain security tool from the sigstore project that cryptographically signs container images and artifacts, and verifies signatures during developer workflows or cluster admission control. It enables keyless signing using Fulcio and transparency logs, and it can also sign an SBOM artifact to authenticate its provenance. However, signing requires an SBOM to already exist; cosign does not analyze images, inspect folders, or enumerate packages, so it has no role in the actual creation of a software bill of materials.

A
kubesec
Why wrong: Kubesec is a Kubernetes security scanner that statically analyzes resource manifests like Deployments and Pods, scoring them against best practices such as disallowing privileged containers or host network access. It operates entirely on YAML/JSON declarations and never inspects container image layers, package metadata, or filesystem contents. Since generating an SBOM requires enumerating the actual software components inside an image or directory, kubesec lacks the fundamental capability to produce a software bill of materials.
B
syft
Syft is a dedicated, purpose-built SBOM generator from Anchore that catalogs packages from container images, OCI layout archives, and directory trees. It supports a broad range of ecosystems — dpkg, RPM, APK, Python, npm, Go modules, Java archives, etc. — and emits standardized formats like SPDX, CycloneDX, and its own custom Syft format. Because its sole mission is to inventory components with precise versions and package URLs, syft is the authoritative and most commonly used tool for generating SBOMs in cloud-native environments.
C
trivy
Why wrong: Trivy is primarily a vulnerability scanner: it scans container images and filesystems for known CVEs by matching installed package versions against NVD and other databases. Although recent versions include an 'sbom' subcommand that can output SPDX or CycloneDX, that functionality is an auxiliary feature built on top of its scanning engine rather than a comprehensive cataloger. Trivy's SBOM output omits some dependency relationships and metadata that syft captures, so while it can produce a partial SBOM, the dedicated and conventional choice for SBOM generation is syft.
D
cosign
Why wrong: Cosign is a supply-chain security tool from the sigstore project that cryptographically signs container images and artifacts, and verifies signatures during developer workflows or cluster admission control. It enables keyless signing using Fulcio and transparency logs, and it can also sign an SBOM artifact to authenticate its provenance. However, signing requires an SBOM to already exist; cosign does not analyze images, inspect folders, or enumerate packages, so it has no role in the actual creation of a software bill of materials.

Question 19mediummultiple choice

A DevOps engineer is setting up a CI/CD pipeline to scan container images for vulnerabilities. They want to fail the pipeline if any critical vulnerabilities are found. Which command should they use to scan the image and produce a JSON output that can be parsed?

Trap 1: trivy fs --severity CRITICAL --output json .

The `fs` subcommand performs a filesystem scan, not a container image scan, so it only inspects the current directory's sources and dependency manifests (e.g., package-lock.json, go.sum) for known vulnerabilities. This approach misses OS-level packages and library versions installed inside the built image layers, so the pipeline would not catch critical vulnerabilities present in the actual `myimage:tag` artifact. For container image scanning, the correct target is `trivy image`.

Trap 2: trivy image --format table myimage:tag

The `--format table` flag produces a human-readable ASCII table, which is fine for console output but difficult to parse reliably in automated CI/CD scripts because of variable column widths and alignment. It also does not restrict severity, so the output will include low, medium, high, and critical vulnerabilities, burying the critical findings in noise. For automation, JSON (or SARIF) is the required machine-parseable format, often combined with `--severity CRITICAL` to reduce output size.

Trap 3: trivy image --severity HIGH myimage:tag

The `--severity HIGH` flag filters the results to include only HIGH-severity vulnerabilities, explicitly excluding CRITICAL vulnerabilities, which are exactly the ones the pipeline is supposed to catch. Even if some critical vulnerabilities might be considered higher than high, Trivy's severity filter is strict — specifying HIGH limits output to HIGH only, so critical issues are not scanned for. Additionally, the default output format is a table, which is not machine-readable for CI/CD, although the primary failure is the incorrect severity scope.

A
trivy fs --severity CRITICAL --output json .
Why wrong: The `fs` subcommand performs a filesystem scan, not a container image scan, so it only inspects the current directory's sources and dependency manifests (e.g., package-lock.json, go.sum) for known vulnerabilities. This approach misses OS-level packages and library versions installed inside the built image layers, so the pipeline would not catch critical vulnerabilities present in the actual `myimage:tag` artifact. For container image scanning, the correct target is `trivy image`.
B
trivy image --severity CRITICAL --output json myimage:tag
This is the correct command because it targets the container image (`trivy image`), restricts results to only critical-severity vulnerabilities with `--severity CRITICAL`, and outputs machine-readable JSON via `--output json`. The JSON format is ideally suited for CI/CD automation, allowing the pipeline to parse vulnerability data programmatically (e.g., with jq) and enforce policy based on exact vulnerability IDs. It directly matches the requirement to scan the built image and flag critical issues.
C
trivy image --format table myimage:tag
Why wrong: The `--format table` flag produces a human-readable ASCII table, which is fine for console output but difficult to parse reliably in automated CI/CD scripts because of variable column widths and alignment. It also does not restrict severity, so the output will include low, medium, high, and critical vulnerabilities, burying the critical findings in noise. For automation, JSON (or SARIF) is the required machine-parseable format, often combined with `--severity CRITICAL` to reduce output size.
D
trivy image --severity HIGH myimage:tag
Why wrong: The `--severity HIGH` flag filters the results to include only HIGH-severity vulnerabilities, explicitly excluding CRITICAL vulnerabilities, which are exactly the ones the pipeline is supposed to catch. Even if some critical vulnerabilities might be considered higher than high, Trivy's severity filter is strict — specifying HIGH limits output to HIGH only, so critical issues are not scanned for. Additionally, the default output format is a table, which is not machine-readable for CI/CD, although the primary failure is the incorrect severity scope.

Question 20hardmultiple choice

You have configured Kyverno to enforce that all Pods must have an image from a trusted registry. However, a newly created Pod is not being rejected even though it uses an untrusted image. What is the most likely reason?

Trap 1: Kyverno is not an admission controller; it only mutates resources

Kyverno is fundamentally an admission controller: it installs both a MutatingAdmissionWebhook and a ValidatingAdmissionWebhook into the cluster. These webhooks intercept API requests at the admission phase, allowing Kyverno to not only mutate resources (like adding default labels) but also validate them and reject noncompliant requests. The claim that it 'only mutates resources' conflates one of its capabilities with its full role; validation and generation are also core features.

Trap 2: The Kyverno policy requires an external registry to compare images,…

Kyverno policies can enforce image rules (e.g., disallowing the 'latest' tag, requiring a specific registry prefix, or checking for an allowed image signature) using YAML pattern matching and conditional anchors directly on the Pod's image field. These rules are evaluated from the resource definition alone, requiring no external network calls. Only specific policy types like 'verifyImages' explicitly query a container registry, and your scenario does not indicate that such a policy is in use.

Trap 3: The Pod was created by a Deployment controller, which bypasses…

Kubernetes admission controllers run for every API request, regardless of whether the requester is a human user, a Deployment controller, or any other automation. When a Deployment creates a ReplicaSet, and that ReplicaSet later creates a Pod, each of those create requests is processed by the API server's admission chain, including any dynamically configured admission webhooks. Thus a Pod created by a Deployment is not bypassing admission control; its Pod creation request still triggers Kyverno's webhook if the webhook's rules match Pod resources.

A
Kyverno is not an admission controller; it only mutates resources
Why wrong: Kyverno is fundamentally an admission controller: it installs both a MutatingAdmissionWebhook and a ValidatingAdmissionWebhook into the cluster. These webhooks intercept API requests at the admission phase, allowing Kyverno to not only mutate resources (like adding default labels) but also validate them and reject noncompliant requests. The claim that it 'only mutates resources' conflates one of its capabilities with its full role; validation and generation are also core features.
B
The Kyverno policy requires an external registry to compare images, which is unavailable
Why wrong: Kyverno policies can enforce image rules (e.g., disallowing the 'latest' tag, requiring a specific registry prefix, or checking for an allowed image signature) using YAML pattern matching and conditional anchors directly on the Pod's image field. These rules are evaluated from the resource definition alone, requiring no external network calls. Only specific policy types like 'verifyImages' explicitly query a container registry, and your scenario does not indicate that such a policy is in use.
C
The Kyverno webhook is not invoked because the failure policy is set to Ignore or the resource is not matched by the policy's rules
The failurePolicy field in Kyverno's ValidatingWebhookConfiguration controls what happens when the webhook cannot be invoked or errors. If set to 'Ignore', any webhook failure is silently ignored and the request proceeds, so the policy would not block the Pod if, for example, the webhook endpoint is unavailable. Additionally, Kyverno policies can have match statements (e.g., specific kinds, namespaces, label selectors) — if this Pod does not match those criteria, the webhook receives the request but the policy simply does not apply to it.
D
The Pod was created by a Deployment controller, which bypasses admission control
Why wrong: Kubernetes admission controllers run for every API request, regardless of whether the requester is a human user, a Deployment controller, or any other automation. When a Deployment creates a ReplicaSet, and that ReplicaSet later creates a Pod, each of those create requests is processed by the API server's admission chain, including any dynamically configured admission webhooks. Thus a Pod created by a Deployment is not bypassing admission control; its Pod creation request still triggers Kyverno's webhook if the webhook's rules match Pod resources.