Chapter 29 - Worked Answers

1. Identity is not authorization

A digest can consistently identify malicious bytes. A trust decision needs accepted signature identity/key, subject binding and policy context, and even a valid trusted signature does not prove vulnerability absence or honest behavior. Baseline digest policy checks supplied metadata; it does not activate the signing/scanning designs. Keep registry access credentials separate from publisher trust and never send a private signing key merely to verify.

2. Three proposed points

Admission gives early feedback, rollout binds the selected version and agent verification protects the final delayed execution/bypass boundary. All must bind the same digest/namespace/policy and handle expiry. Those signature-verification hooks are proposed in the document, not active baseline calls. The actual baseline has image parsing/policy and ordinary service admission. The book fake-verdict contract tests only its own acceptance truth table.

3. Freshness changes without changed bytes

A new vulnerability database can identify a problem in an unchanged image. Record scanner/database version and expiry as well as digest, trusted producer and completion state. A completed old result is not automatically fresh evidence. The design proposes these records; the book does not run an external scanner or ingest an SBOM. Missing, pending, unavailable, expired and policy-violating results need distinct reasons and explicit fail behavior.

4. Exception ordering

If a pending-scan allow branch runs before subject/signature checks, a pending verdict for another namespace/digest/policy or an untrusted signature can be accepted. Keep binding/trust/expiry checks first. The executed test explicitly sets pending plus untrusted and expects denial, and the binding test varies namespace/digest/policy. Add combinations if widening the exception. allow_with_audit remains an obligation for a future caller, not an actual durable audit operation in this teaching function.

These answers use chapter 29 and its scoped claim/execution records. Design changes remain proposals until separately implemented and tested.