Prompt and Context
Your platform stores images in an OCI registry, while the release pipeline must attach signatures, SBOMs, and vulnerability reports. Design a discovery and verification service: given a repository and image digest, return attached artifacts, filter by artifactType, support registries that lack the Referrers API, and block unverified images before deployment. Target a backend or platform engineer; focus on registry protocol and service boundaries rather than one cloud SDK.
What the Interviewer Evaluates
A strong answer treats the image digest as the immutable subject, not the tag. It understands that subject creates the association, artifactType describes purpose, and the Referrers API returns an OCI Index. It also covers legacy fallback tags, pagination, cache consistency, and the fact that discovering an artifact is separate from verifying a signature. “Read the image tag” or “an SBOM proves trust” reveals an incomplete security model.
Clarifications to Ask First
- Is the input a tag or a digest? If it is a tag, resolve it and pin the digest before verification.
- Must registries returning 404 be supported? If yes, implement the OCI fallback tag and handle concurrent updates.
- Will the result gate deployment? If yes, verify the signature, publisher identity, and digest inside the trust boundary.
- Can the association list exceed one page? If yes, pass through the opaque
nextTokenwithout interpreting it.
30-Second Answer Framework
“I resolve a tag to a digest first and use that digest as the subject for every association. I call /v2/{name}/referrers/{digest} and filter signatures, SBOMs, or reports by artifact type. A 404 from an older registry triggers the digest-derived fallback tag. Discovery is followed by signature and publisher verification before a policy decides whether deployment is allowed. The list API is paginated and short-TTL cached with a key that includes the digest and filter.”
Step-by-Step Deep Dive
OCI 1.1 uses a manifest subject to point at the manifest being referenced, while artifactType describes the attached artifact. The Referrers API returns an OCI Index whose descriptors include digest, media type, and artifact type:
GET /v2/{name}/referrers/{subject-digest}?artifactType={type}Reject verification requests without a digest. A tag is a mutable pointer and cannot be the primary key for signature verification. Resolve it once, record the resulting digest, and pass that digest through discovery, caching, and admission.
With a registry that supports the API, a 200 response containing an empty Index means no attached artifacts. With an older implementation returning 404, the client reads the fallback tag formed by replacing sha256: with sha256-. Clients maintain that fallback tag, so adding a new referrer is a read-modify-write race. Writers need conditional writes, optimistic retries, or a single-writer queue; readers must not treat the fallback as strongly consistent.
Process discovered signatures, SBOMs, and scan reports in three stages: filter by artifactType and policy; fetch the referenced manifest and content; verify that the signature covers the target digest, the publisher is trusted, and the artifact status is allowed. Microsoft’s guidance separates integrity, authenticity, and blocking before consumption, so “a signature was found” is not the same as “the image is trusted.”
The API can paginate. Preserve and pass through the opaque nextToken, cap page size, and include registry, repository, subject digest, artifact type, and authorization context in the cache key. Since a digest is immutable, discovery results can be cached briefly; revocation and status changes still require an explicit TTL and re-verification policy. On an admission path, cache may accelerate discovery but must not skip final verification.
High-Quality Sample Answer
I would make the digest the only subject identity. The client resolves a tag, calls the OCI Referrers API, and uses artifactType to separate signatures, SBOMs, and scan reports. A supporting registry returns an OCI Index; a 404 from an older registry triggers the digest-derived fallback tag with retries for concurrent updates. Discovery alone never grants deployment. The admission service verifies the signature’s target digest, publisher identity, and trust root, then applies policy. The endpoint passes through opaque pagination tokens and caches by digest and filter, while every deployment re-verifies instead of treating a cache entry as a trust decision.
Common Mistakes
- Mistake → using a tag as the signature key → Why it fails: tags can be retargeted → Fix: resolve and pin the digest first.
- Mistake → treating every 404 as “no attached artifacts” → Why it fails: an old registry may not implement Referrers → Fix: read the specification’s fallback tag.
- Mistake → allowing deployment as soon as a signature is found → Why it fails: publisher identity, coverage, and target digest remain unverified → Fix: separate discovery from cryptographic verification.
- Mistake → parsing or constructing
nextToken→ Why it fails: the token is an opaque server cursor → Fix: pass it through unchanged and cap page size and timeouts.
Follow-up Questions and Responses
Follow-up 1: Two builds update the fallback tag concurrently. What do you do?
Treat the fallback Index as a read-modify-write transaction. Use a registry conditional write, optimistic retry, or a single-writer queue. On conflict, read the newest Index and merge the new descriptor; never overwrite another build’s association.
Follow-up 2: The signature exists, but the SBOM references an older digest. What happens?
Check consistency against the current subject digest. Signatures, SBOMs, and reports must each reference the same digest. Mark an older reference inapplicable and block admission; matching only the image tag is unsafe.
Follow-up 3: The registry returns thousands of referrers. How do you protect the service?
Cap maxResults, pass through the opaque token, and use a short-TTL cache keyed by digest and artifact type. Query only policy-required types on the admission path. Background indexing can warm results, but deployment still verifies the returned manifest digest and trust status.