LEARN. PRACTICE. GROW.Identify who executes each stage
A deployment passes through several identities. Record who starts the process, runs the build, publishes the revision and reads data at runtime. For a Cloud Build triggered build, the trigger’s service account is used; the configuration file’s serviceAccount field does not replace it. In the exercise, build-release has repository access, but the trigger uses build-trigger: reviewing only YAML leaves the cause unresolved. For Cloud Run, distinguish the deployment account from configured service identity. One can create the revision while the other cannot read its required bucket. Prepare an identity, action, resource and evidence matrix. During support, follow the rejected call’s effective identity and adjust only access needed for the approved task. Do not treat one stage’s success as proof of authorization for subsequent stages. Record the configured and observed identities separately.
Trace the application credential source
Application Default Credentials checks GOOGLE_APPLICATION_CREDENTIALS first, then the known local ADC file and then the attached account supplied through the metadata server. The exercise describes a valid older configuration inside the image. Even with run-current attached, that earlier source can explain the old identity in logs. Correction means removing the unintended source and checking identity used by the corrected revision. Do not broaden the wrong account’s permissions to hide the discrepancy. Also distinguish gcloud auth login on a laptop from ADC configuration inside the service: these are different contexts and credentials. During image review, inspect credential references and environment configuration without exposing sensitive values in tickets. Document expected source, observed source and subsequent validation. The question does not assume an invalid file triggers fallback; its scenario explicitly uses a valid file.
Link tested artifacts to deployed artifacts
A tag can change content between two decisions. In Cloud Run, deployment resolves the tag to a digest, and that revision continues serving the resolved digest. Moving release from D1 to D2 does not change existing revision R1; creating another revision from the tag can select D2. In the exercise, approval refers to D1, but candidate moved to D2 before deployment. Compare tested digest, approved digest and effective digest before assigning traffic. If they differ, do not automatically transfer approval: use the approved artifact or test and approve the alternative. An unchanged tag name does not establish equivalence. This discipline helps later investigation by linking each result to identifiable content. Also retain relevant revision configuration; fixing the image does not establish that permissions and dependencies work at the destination. Track these acceptance checks independently.
Fix dependencies and execute the reviewed plan
In Terraform,.terraform.lock.hcl records provider selection; it does not fix remote-module versions. For a Registry module, a broad constraint allows another eligible version during clean initialization. Use an exact version when the decision requires reproducing an approved selection and retain review of that change. Another boundary exists at apply: without a plan file, the command calculates a new plan. Having approved.tfplan in the directory does not make it automatically selected. If the team approved that artifact, the next stage should consume it explicitly under applicable context controls. If replanning is necessary, review the new result. auto-approve skips confirmation; it does not establish that the new result matches the earlier one. In the exercise, separately identify module version, provider lock, reviewed plan and the command the process intends to execute.
Control retries and state conflicts
Retry layers can multiply requests. In the fictional model, four total wrapper attempts and two total library requests per call allow eight requests if all fail and no deadline ends the sequence early. These numbers already include the initial attempt. Define retry ownership, a total duration limit and library behavior. For transient errors and operations safe to repeat, use the appropriate strategy with backoff and jitter; do not indiscriminately retry every failure. A 412 response to an update protected by generation and metageneration means the expected condition was not met. Read state, reconcile intent and only then prepare another conditional update if still valid. Removing conditions to obtain success removes protection. Merely replacing the numbers with current ones while keeping stale content can also hide a concurrent write that needed consideration. Preserve the original business intention when resolving the conflict.
Interpret asynchronous completion and data promotion
A successful HTTP response when querying an operation does not establish that asynchronous work succeeded. In an Operation resource, done=false means work remains in progress; done=true can contain error instead of response. The question’s synthetic excerpt has HTTP 200 and a permission error in the body. Automation should retain failure and block the stage requiring success, without assuming more polling will correct it. In another decision, promoting a continuous MySQL migration in Database Migration Service stops source reads and cannot be stopped or undone once started. A plan based on a nonexistent Undo button is not a recovery plan. Define beforehand how to address data and new writes if acceptance fails. Confirm source-write shutdown and outstanding-change requirements before crossing that boundary. Record the recovery decision separately from the migration job’s status.
Separate consumption, bursts and user authorization
In Apigee, a daily quota addresses a consumption agreement but does not establish that the backend can handle all that usage concentrated within seconds. SpikeArrest addresses bursts while a separate Quota retains the agreed limit. Avoid promising an exact distributed ceiling without examining applicable configuration and conditions. Access introduces another distinction: a consumer key identifies an app. If two users present the same key and have different rights over account A, validating only that key does not distinguish those rights. The design needs authenticated user identity and an authorization decision for the resource. Rotating the shared key does not resolve the difference. In the review exercise, draw three questions: may the app call, may this person view this account, and is the rate acceptable for the service? Each question needs its own control and evidence.
Prepare an evidence-supported release decision
Gemini Cloud Assist can help investigate or propose configuration, but plausible output does not replace validation. Check commands, permissions and assumptions against documentation and effective state; review the diff and test within an appropriate scope before the normal change process. The final case has two independent failures: D2 does not hold D1’s approval, and runtime-reader cannot read the bucket. The revision remains isolated without customer traffic. Hold promotion until both are resolved. As an exercise, deliver a small matrix containing gap, required evidence, owner and condition for proceeding. One alternative is to test and approve D2; another is to use D1. Either alternative must verify runtime access. These are original scenarios and synthetic excerpts supported by documentation; they represent neither execution of Google tools, Terraform or Apigee nor a financial institution’s internal procedures.
An isolated revision contains a different digest from the tested image and its runtime account fails data reads despite deployment-account success.
Common pitfalls
Confusing deployer with runtime, tag with digest, provider lock with module version and HTTP 200 with asynchronous operation success.
Related topics: Identity and permissions · Release reproducibility · API contracts
Identify effective artifact, identity and state at each stage; approval must match what will actually execute.
Reference: Run builds with a user-managed service account · Current linked standard guide; edition date unconfirmed (2026-09-30 inspection)