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.

Secrets in images are exposed and should be injected at runtime.

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

Unverified images may contain malware or vulnerabilities.

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

Mutable tags make it impossible to guarantee which image version is running.

A
Scan images for vulnerabilities in a CI pipeline before deploying.
Scanning helps catch known vulnerabilities early.
B
Use image signing and verification (e.g., with cosign) to ensure image integrity.
Signing images ensures they have not been tampered with.
C
Embed API keys directly in container images for authentication.
Why wrong: Secrets in images are exposed and should be injected at runtime.
D
Allow all images from any registry without verification to speed up development.
Why wrong: Unverified images may contain malware or vulnerabilities.
E
Use mutable tags like 'latest' for easier updates.
Why wrong: Mutable tags make it impossible to guarantee which image version is running.

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.

Disabling admission controllers removes crucial security checks.

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

Running as root violates least privilege principle.

A
Use vulnerability scanning tools like Trivy or Grype in the CI/CD pipeline.
Scanning prevents deployment of images with known vulnerabilities.
B
Disable admission controllers to reduce latency in pod creation.
Why wrong: Disabling admission controllers removes crucial security checks.
C
Integrate image signature verification into the admission webhook (e.g., using cosign and Kyverno).
Verification ensures images are signed by trusted parties.
D
Run all containers as root inside the pod to avoid permission issues.
Why wrong: Running as root violates least privilege principle.
E
Enforce policies using OPA Gatekeeper or Kyverno to restrict allowed registries and image constraints.
Policy enforcement ensures only trusted images are used.

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 does not enforce admission policies.

Trap 2: Helm with signed charts

Helm charts are for packaging, not runtime verification.

Trap 3: etcd with encryption at rest

etcd stores cluster data, not admission control.

A
kubectl with --validate flag
Why wrong: kubectl does not enforce admission policies.
B
Helm with signed charts
Why wrong: Helm charts are for packaging, not runtime verification.
C
etcd with encryption at rest
Why wrong: etcd stores cluster data, not admission control.
D
Kyverno with a verifyImages rule
Kyverno supports image signature verification via cosign.
E
Prometheus with alerting rules
Why wrong: Prometheus monitors metrics, not admission control.

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…

Detection is important but does not prevent the vulnerability from existing.

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

Patching at runtime is not a long-term fix and may not persist.

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

This only prevents deployment, but the image still has the vulnerability; better to fix the source.

A
Use a runtime security tool like Falco to detect exploitation attempts.
Why wrong: Detection is important but does not prevent the vulnerability from existing.
B
Patch the vulnerability by installing a security update inside the running container.
Why wrong: Patching at runtime is not a long-term fix and may not persist.
C
Add an admission controller that rejects images with vulnerabilities.
Why wrong: This only prevents deployment, but the image still has the vulnerability; better to fix the source.
D
Rebuild the image using a patched base image and integrate vulnerability scanning into the CI pipeline.
Fixing the base image and scanning prevent vulnerable images from being built.
E
Switch to a different container runtime that is immune to the vulnerability.
Why wrong: The vulnerability is in the image, not the runtime.

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 control pod traffic, not image provenance.

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

This reduces risk but does not prevent the CI itself from being compromised.

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

This only checks the build instructions, not the built image.

A
Implement network policies to restrict egress from pods to the registry.
Why wrong: Network policies control pod traffic, not image provenance.
B
Grant registry write access only to the CI system's service account.
Why wrong: This reduces risk but does not prevent the CI itself from being compromised.
C
Use a static analysis tool to check the Dockerfile before building.
Why wrong: This only checks the build instructions, not the built image.
D
Use a unique registry path and restrict access via firewall rules.
Why wrong: Firewall rules do not prevent tampered images from being pushed if credentials are compromised.
E
Generate signed attestations with in-toto during the CI pipeline and verify them using an admission webhook like Kyverno.
Attestations provide non-repudiation and can be verified at admission time.

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…

This violates best practices, is error-prone, and changes are lost on restart.

Trap 2: Temporarily disable the admission controller that verifies…

Disabling admission control weakens security; updates should be done with verification.

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

The ReplicaSets still reference the old image; pods will be recreated with the vulnerable image.

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.
This ensures all pods are updated with a verified, patched image in a controlled manner.
B
SSH into each node, pull the new image, and use kubectl exec to update the library inside running containers.
Why wrong: This violates best practices, is error-prone, and changes are lost on restart.
C
Temporarily disable the admission controller that verifies signatures and then update the image tags.
Why wrong: Disabling admission control weakens security; updates should be done with verification.
D
Delete all running pods and let the ReplicaSets recreate them from the existing image.
Why wrong: The ReplicaSets still reference the old image; pods will be recreated with the vulnerable image.

Question 7mediummultiple choice

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

Trap 1: Configure a Kubernetes admission controller (e.g., Kyverno) to…

Admission controllers can check image metadata but require the image to be already pushed and scanned; they are a defense-in-depth layer, not the primary prevention mechanism.

Trap 2: Scan the base image before building the application image.

Does not cover vulnerabilities in the application layer.

Trap 3: Manually review vulnerability reports after the image is deployed.

Manual review is slow and does not prevent deployment of vulnerable images.

A
Configure a Kubernetes admission controller (e.g., Kyverno) to reject pods using images with critical vulnerabilities.
Why wrong: Admission controllers can check image metadata but require the image to be already pushed and scanned; they are a defense-in-depth layer, not the primary prevention mechanism.
B
Scan the base image before building the application image.
Why wrong: Does not cover vulnerabilities in the application layer.
C
Integrate an image scanner (e.g., Trivy) into the CI/CD pipeline to block builds with critical vulnerabilities.
Scans the final image and prevents vulnerable images from being pushed to the registry.
D
Manually review vulnerability reports after the image is deployed.
Why wrong: Manual review is slow and does not prevent deployment of vulnerable images.

Question 8hardmultiple 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 does not have built-in Cosign verification.

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

Does not verify signatures or scanning status.

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

Does not protect against direct pushes to the registry.

A
Configure Argo CD to verify Cosign signatures before syncing the application.
Why wrong: Argo CD does not have built-in Cosign verification.
B
Use imagePullSecrets in Kubernetes to ensure only Harbor images are used.
Why wrong: Does not verify signatures or scanning status.
C
Add a Cosign verification step in the CI pipeline before pushing images to Harbor, and rely on that guarantee.
Why wrong: Does not protect against direct pushes to the registry.
D
Enable Harbor's content trust feature to reject unsigned images, and use a Kyverno admission rule to verify Cosign signatures at deploy time.
Harbor blocks unsigned pushes, and Kyverno validates signatures at admission.

Question 9easymulti 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.

Does not prevent pulling malicious images by authorized users.

Trap 2: Enforce PodSecurityStandard baseline or restricted to block…

Does not control image source.

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

Network policies do not affect image pulling; kubelet pulls images before starting pods.

A
Configure all deployments to use image digests instead of tags.
Prevents tag mutation and ensures image integrity.
B
Set up a private registry proxy that mirrors approved public images and disable direct access to public registries via containerd configuration.
Proxies allow control and scanning of images.
C
Implement RBAC to restrict which users can create pods.
Why wrong: Does not prevent pulling malicious images by authorized users.
D
Enforce PodSecurityStandard baseline or restricted to block privileged containers.
Why wrong: Does not control image source.
E
Apply a network policy that blocks egress traffic to public registries.
Why wrong: Network policies do not affect image pulling; kubelet pulls images before starting pods.

Question 10hardmultiple choice

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

Trap 1: Enforce a PodSecurityStandard that restricts containers from…

Does not restrict image registry.

Trap 2: Apply a Kubernetes NetworkPolicy that blocks egress traffic from…

NetworkPolicy applies to pods, not nodes; kubelet pulls images before the pod network is set up.

Trap 3: Deploy an admission webhook (e.g., OPA/Gatekeeper) that denies pods…

Admission controllers run at pod creation time, but if the image pull later fails due to network restrictions, the pod remains in ImagePullBackOff; however, the admission controller can be effective, but it requires policy and may not block all existing workloads. Option B is more robust because it stops the pull at the kubelet level, affecting even existing pods that might get rescheduled.

A
Enforce a PodSecurityStandard that restricts containers from running with root privileges.
Why wrong: Does not restrict image registry.
B
Apply a Kubernetes NetworkPolicy that blocks egress traffic from nodes to Docker Hub.
Why wrong: NetworkPolicy applies to pods, not nodes; kubelet pulls images before the pod network is set up.
C
Configure the containerd configuration on each node to use Harbor as a mirror for all registries and set endpoint to Harbor only, disabling direct pull from public registries.
This forces all image pulls to go through Harbor, and if the image is not cached or allowed, the pull fails.
D
Deploy an admission webhook (e.g., OPA/Gatekeeper) that denies pods whose image registry is not the internal Harbor.
Why wrong: Admission controllers run at pod creation time, but if the image pull later fails due to network restrictions, the pod remains in ImagePullBackOff; however, the admission controller can be effective, but it requires policy and may not block all existing workloads. Option B is more robust because it stops the pull at the kubelet level, affecting even existing pods that might get rescheduled.

Question 11easymultiple choice

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

Trap 1: Scan all images for vulnerabilities using Trivy before pushing to…

Vulnerability scanning detects known CVEs but does not prevent malicious image tampering.

Trap 2: Restrict access to the registry using Kubernetes RBAC and service…

RBAC controls who can push/pull images but does not protect against tampered images.

Trap 3: Implement network policies to restrict traffic to the registry…

Network policies control traffic flow but do not verify image content.

A
Scan all images for vulnerabilities using Trivy before pushing to the registry.
Why wrong: Vulnerability scanning detects known CVEs but does not prevent malicious image tampering.
B
Restrict access to the registry using Kubernetes RBAC and service accounts.
Why wrong: RBAC controls who can push/pull images but does not protect against tampered images.
C
Implement network policies to restrict traffic to the registry endpoint.
Why wrong: Network policies control traffic flow but do not verify image content.
D
Sign all container images using a private key and verify the signature before deployment.
Image signing provides cryptographic assurance of image integrity and origin, a core supply chain security control.

Question 12hardmulti 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…

Rejecting 'latest' tag does not verify image source or integrity.

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

imagePullSecrets only provide authentication, not image validation.

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

NetworkPolicy controls network traffic, not image content.

A
Use OPA Gatekeeper to enforce a policy that rejects pods using images with the 'latest' tag.
Why wrong: Rejecting 'latest' tag does not verify image source or integrity.
B
Configure imagePullSecrets for each namespace to ensure only authorized service accounts can pull images.
Why wrong: imagePullSecrets only provide authentication, not image validation.
C
Deploy Kyverno with a policy that requires images to have a specific annotation indicating they passed a security scan.
Kyverno can enforce custom policies including image annotations that prove scanning.
D
Implement a NetworkPolicy that blocks egress traffic from the cluster to unauthorized container registries.
Why wrong: NetworkPolicy controls network traffic, not image content.
E
Set up an ImagePolicyWebhook admission controller that checks image signatures and only allows signed images from your registry.
ImagePolicyWebhook can enforce image provenance by validating signatures.

Question 13hardmultiple 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 identities; the spec includes an identities array.

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

The policy uses glob: registry.example.com/*, which matches all tags.

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

The registry is allowed, but the identity is also required to match.

A
The pod is admitted because keyless signing does not enforce identity matching.
Why wrong: Keyless signing does enforce identities; the spec includes an identities array.
B
The pod is admitted because the policy only applies to images with a tag 'v*'.
Why wrong: The policy uses glob: registry.example.com/*, which matches all tags.
C
The pod is admitted because the image is from the allowed registry.
Why wrong: The registry is allowed, but the identity is also required to match.
D
The pod is denied because the image's signer identity does not match the policy.
The identity check fails, so cosigned denies the admission.

Question 14mediumdrag 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

Question 15mediummatching

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

Question 16mediummultiple choice

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

Trap 1: ValidatingAdmissionWebhook

While a ValidatingAdmissionWebhook can be used to enforce custom policies, it is not specifically designed for image policy enforcement; ImagePolicyWebhook is the standard approach for image policy.

Trap 2: PodSecurityPolicy (PSP)

PSP is deprecated and does not perform image vulnerability checks; it controls security context and privilege escalation.

Trap 3: ResourceQuota

ResourceQuota limits resource consumption, not image security.

A
ImagePolicyWebhook
ImagePolicyWebhook is the admission controller designed to intercept image-related requests and can be configured to reject images based on external scanning results.
B
ValidatingAdmissionWebhook
Why wrong: While a ValidatingAdmissionWebhook can be used to enforce custom policies, it is not specifically designed for image policy enforcement; ImagePolicyWebhook is the standard approach for image policy.
C
PodSecurityPolicy (PSP)
Why wrong: PSP is deprecated and does not perform image vulnerability checks; it controls security context and privilege escalation.
D
ResourceQuota
Why wrong: ResourceQuota limits resource consumption, not image security.

Question 17mediummultiple choice

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

Trap 1: Hardcode passwords in Dockerfile as environment variables for…

Hardcoding secrets in images is insecure; they can be extracted from the image layers.

Trap 2: Use the latest tag for base images to get the newest features

Using the latest tag introduces uncertainty about which version is deployed, and may include breaking changes or unpatched vulnerabilities.

Trap 3: Run containers as root to simplify permission management

Running as root increases security risks; containers should run as non-root users.

A
Hardcode passwords in Dockerfile as environment variables for convenience
Why wrong: Hardcoding secrets in images is insecure; they can be extracted from the image layers.
B
Use minimal base images like distroless or Alpine
Minimal images reduce the attack surface and number of vulnerabilities.
C
Use the latest tag for base images to get the newest features
Why wrong: Using the latest tag introduces uncertainty about which version is deployed, and may include breaking changes or unpatched vulnerabilities.
D
Run containers as root to simplify permission management
Why wrong: Running as root increases security risks; containers should run as non-root users.

Question 18easymultiple 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 performs static analysis of Kubernetes resource manifests.

Trap 2: syft

Syft generates Software Bill of Materials (SBOM) for container images.

Trap 3: trivy

Trivy is a vulnerability scanner for container images.

A
kubesec
Why wrong: kubesec performs static analysis of Kubernetes resource manifests.
B
syft
Why wrong: Syft generates Software Bill of Materials (SBOM) for container images.
C
cosign
Cosign supports signing container images and verifying signatures.
D
trivy
Why wrong: Trivy is a vulnerability scanner for container images.

Question 19mediummultiple 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

runAsUser: 0 runs the container as root, which is not a non-root user.

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

This only validates that the image runs as non-root but does not set a specific UID.

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

runAsGroup sets the primary group ID, not the user ID.

A
spec.containers[].securityContext.runAsUser: 0
Why wrong: runAsUser: 0 runs the container as root, which is not a non-root user.
B
spec.containers[].securityContext.runAsNonRoot: true
Why wrong: This only validates that the image runs as non-root but does not set a specific UID.
C
spec.containers[].securityContext.runAsGroup: 1000
Why wrong: runAsGroup sets the primary group ID, not the user ID.
D
spec.containers[].securityContext.runAsUser: 1000
Setting runAsUser at the container level ensures the container runs with that UID.

Question 20hardmultiple 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.