CKS Supply Chain Security Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  The public key is incorrect

  Why it's wrong here

  A mismatched or rotated public key would trigger a signature verification failure during `cosign verify` (e.g., "invalid signature" or "key mismatch"), not the observed error about being unable to locate signatures. The message indicates that no signed artifact exists for the current image digest, which is a state-of-the-image problem, not a cryptographic key problem. Even if the key were wrong, cosign would still find the signature tag and then fail to verify it, producing a distinctly different diagnostic.

• ✗

  The registry requires authentication

  Why it's wrong here

  Registry authentication errors surface during the initial manifest fetch or token exchange, typically as `unauthorized: authentication required` or `denied: requested access to the resource is denied`. Since the pipeline reached the signature-lookup stage, cosign had already authenticated and retrieved the image manifest; otherwise it would not know the image digest. A registry permission issue that only affected `.sig` tags would return an explicit access-denied error for that tag, not a generic "unable to" absence message.

• ✗

  Cosign is not installed correctly

  Why it's wrong here

  If cosign were missing, misconfigured, or installed incorrectly, the shell would fail with `cosign: command not found` or a dynamic library loading error, stopping before any signature logic runs. The fact that the pipeline prints a cosign-specific error about failing to retrieve or locate signatures proves the binary executed correctly. A correct installation is a prerequisite for producing this error; the root cause therefore lies not in the tooling but in the absent signature payload for the current image.

• ✓

  The image tag was overwritten without signing

  Why this is correct

  Cosign stores the signature for an image in a separate tag derived from the image digest (e.g., `sha256-<digest>.sig`) and does not use mutable tags like `latest` for signature lookup. When a CI pipeline overwrites a tag with a newly built image, the new image digest does not yet have a corresponding signature tag, so `cosign verify` finds no signatures for that digest. The old signature is still present but only applies to the previous digest, so verification fails with a "missing signature" error until the new image is explicitly signed after the push.

Go deeper

Related to this question