LEARN. PRACTICE. GROW.Concept and mechanism
A reliable pipeline identifies what was built, how it was built, and which artifact was approved. A tag can be mutable; the same name can point to another digest after testing. Use stable artifact identity to connect evidence, approval, and deployment. Artifact Registry supports mutable or immutable tag policies; confirm the actual configuration. Provenance describes origin and construction process but does not automatically prove functional suitability. In the documented Cloud Build flow, declaring images in the build configuration enables image publication with provenance; an explicit docker push step does not generate that evidence through the same mechanism. Examine the produced result instead of inferring provenance from image presence in the registry.
Guided application
In a fictional release, digest A passed staging and the release tag moved to B. Promoting by name alone can deliver untested content. Retain the approved digest or validate B through the full process. Also confirm the effective build account: it can differ from runtime identity and defaults depend on project and policies. A publication error calls for investigating that principal and repository access rather than granting Owner to the application. If a Binary Authorization policy requires tests, attestation should be issued after those controls produce valid evidence. Protect the issuer and connect attestation to the correct artifact. Gate quality depends on this trust chain and its review.
A new tag named approved does not turn an untested image into an approved artifact.
Common pitfalls
Tag as digest; push as provenance; runtime account as build account; attestation before controls.
Related topics: State, caching, and asynchronous flows · Credentials, secrets, and access · Tests, emulators, and AI assistance
Promote an identified artifact with evidence of the process actually executed.
Reference: Cloud Build provenance · Current linked guide; edition date unconfirmed (2026-09-30 inspection)