Behavioral interview: Tell me about a time you changed a release decision because build provenance was unverifiable

Question

Tell me about a time you found that a build passed tests but its provenance or signature could not be verified, and you changed the release decision. The interviewer is testing how you judge evidence, influence teams without direct authority, and restore delivery safely.

Context and boundaries

Use a real release, dependency upgrade, or supply-chain review. Explain what evidence existed, what was unknown, how tight the release window was, and what authority you had. Do not equate a missing signature with malicious code, and do not present evidence added later as if it had existed at the time.

What the interviewer is testing

The core skill is evidence judgment and risk communication: distinguish “the build succeeded” from “the build came through an authorized process,” then define gates using a verifiable digest, signature, identity, and timestamp. GitHub documents artifact attestations as a way to establish where and how software was built, with cryptographic verification of the signature and signer identity; Google SRE emphasizes factual decision records and follow-up work that improves the system.

Clarify these points first:

• Is the release an internal service, a customer-downloadable package, or a container image?
• Is the gap a signature, build identity, source link, SBOM, or the binding between those pieces of evidence?
• Who can approve the release, which actions are reversible, and when is the decision due?
• Can you limit scope, keep the previous version, or produce an auditable rebuild first?

30-second answer

Use STAR-L: Situation states the release goal and evidence gap; Task names the user or compliance outcome you protected; Action explains how you checked the digest, signature, and workflow identity, proposed graduated gates, and coordinated evidence collection; Result gives delay, scope, and risk change; Learning explains how the new proof check entered the pipeline.

Step-by-step deep dive

1. Freeze the conclusion: record the candidate artifact digest, test results, build workflow, and existing proof, separating facts from hypotheses.
2. Define minimum evidence: the digest must match the release object, and proof must bind the repository, commit, workflow, and signer identity; mark the case Unknown when any link is missing.
3. Offer graduated options: block high-risk artifacts; for low-risk artifacts keep the old version or use a small internal canary, without bypassing the audit record.
4. Verify together: share one evidence checklist with build, release, security, and business owners, assigning an owner and deadline for each item.
5. Restore and track: release only the digest-matching artifact after verification, recording the exception reason, approver, and follow-up actions.

Model answer

“An urgent fix passed every test, but the release system could not retrieve a signature bound to the commit SHA. I recorded the image digest, test results, and build logs first, confirming that the problem was missing proof rather than a digest mismatch. Because the version was customer-facing, I proposed pausing external release while keeping the old version and creating an internal canary. I worked with the build team to add workflow identity and signing, had security verify the signature with independent credentials, and agreed on a latest recovery time with the release owner. The release was delayed 90 minutes; the canary and rollback completed as planned. We then made digest matching, signature verification, and exception approval mandatory gates. I learned to encode evidence gates as automated checks before a crisis, leaving human judgment only for documented exceptions.”

Common mistakes

• Treating a green test suite as sufficient proof of trusted origin.
• Saying “add a signature” without explaining what it binds, who signs, or how it is verified.
• Using security risk to overrule the business goal without an old-version, canary, or deadline option.
• Describing the build team as the blocker instead of aligning on shared verification.
• Reporting only whether release succeeded, with no delay cost, scope, or follow-up gate.

A strong answer has a factual timeline, distinguishes artifact digest, build origin, and signer identity, proposes a reversible option matched to risk, explains influence without authority, and quantifies the result. A weak answer stays at “improve security” or treats personal intuition as evidence.

Follow-up questions and responses

What if the business owner asks you to ship now and add proof later?

Confirm the release audience and worst-case impact, then propose a reversible option such as keeping the old version, an internal canary, or narrower scope. If an exception remains necessary, record the unverified items, approver, deadline, and rollback condition; do not label the exception compliant.

If the signature is valid but the commit is from an unapproved repository or branch, can you ship?

Not from signature validity alone. Verify signer identity, repository, commit, workflow, and environment against policy; any failed binding moves to review or blocks release.

How do you show that the new gate does not create endless waiting?

Give each evidence item an automated check, owner, and deadline. Track blocks, mean recovery time, and exception rate; review every exception and reduce manual waiting over time.

Interview checklist

One-sentence takeaway

Upgrade “the build passed” to “the artifact, origin, identity, and decision are verifiable,” then use reversible options to balance delivery and risk.