Courseiva
Supply Chain Security →mediumMultiple Choice

CKS Supply Chain Security Practice Question

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

⚠ Common exam trap

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

Answer choices

Why each option matters

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

Correct answer & explanation

✓

cosign attest --type custom --predicate <file> <image>

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

Answer analysis

Option-by-option breakdown

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

  • ✗

    cosign verify-attestation <image>

    Why it's wrong here

    cosign verify-attestation is a read-only verification command. It checks the signature and certificate chain on an already-published attestation and confirms that its predicate satisfies the expected policy, but it never writes anything to the registry. If the image has no attestation yet, this command simply fails; it cannot be used to meet a requirement that every image must have an attestation.

  • ✗

    cosign sign --key <key> <image>

    Why it's wrong here

    cosign sign creates a signature over the image manifest using the supplied key, producing a standard Sigstore signature artifact. That is distinct from an in-toto attestation: a signed attestation carries a predicate payload and is stored/discovered as a separate 'attestation' blob. Signing alone gives no predicate data, so it does not create anything the policy can verify as an attestation.

  • ✗

    cosign download attestation <image>

    Why it's wrong here

    cosign download attestation retrieves attestation artifacts from the registry for the given image, often for auditing or debugging. It is purely a fetch operation — like pulling an object — and performs no cryptographic signing or writes. Running it does not add, update, or mint an attestation; even if output is redirected to a file, that file is a copy of an existing attestation, not a newly created one.

  • ✓

    cosign attest --type custom --predicate <file> <image>

    Why this is correct

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

About these practice questions

Courseiva writes every CKS question from scratch — 845 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

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