Prepare and test your skills
Prepare and test your skills
Approval gates based on deployment risk and environment are mandatory checkpoints that stop a release until required checks and authorizations succeed. A gate ties promotion to the target environment and the contents of the change, so development stays fast while staging and production require verified artifacts and authorized approvers. On Google Cloud, gates are built with Cloud Deploy targets and approvals, Binary Authorization attestations, Artifact Analysis scans, and Identity and Access Management (IAM) roles, following patterns from secure deployment pipelines (opens in a new tab) and software supply chain security (opens in a new tab).
Approval gates in the deployment pipeline are integrity controls that prevent unauthorized, untested, or untrusted changes from reaching Google Cloud environments. The pipeline enforces the same verified process for every change, including code reviews and automated tests before each deployment. These controls also reduce accidental risk from typos, unawareness, or too many simultaneous changes. For gates to work, the pipeline itself, its configuration, its infrastructure, and all inputs it consumes must be protected so the gates cannot be bypassed.
Pipelines apply additional in-pipeline integrity controls before promotion:
Environment-tiered promotion policies are rules that make approval stricter as the target environment becomes more critical. Automated continuous integration and continuous delivery (CI/CD) pipelines remove manual errors, create standardized feedback loops, and allow different policies for development, test, and production. A typical progression promotes a passing build to preproduction for end-to-end tests and updates production only after those tests and required approvals succeed. The Supply-chain Levels for Software Artifacts (SLSA) framework provides the maturity model for these checks across source, build, and provenance.
Cloud Deploy automates delivery to a series of target environments in a defined sequence. Cloud Deploy delivers directly to Google Kubernetes Engine (GKE), GKE Enterprise, and Cloud Run, and it provides one-click approvals and rollbacks, enterprise security and audit, built-in delivery metrics, and security insights. Cloud Build runs builds on Google Cloud infrastructure with granular IAM permissions and isolated, ephemeral build environments. Cloud Build also supports SLSA Level 3 builds for container images and non-falsifiable build provenance that records image digests, source locations, toolchain, steps, and duration.
Binary Authorization is the approval enforcement service for GKE and Cloud Run that allows only trusted container images to deploy. Binary Authorization attaches configurable signatures to container images, called attestations, that prove a required process was completed. At deployment time, Binary Authorization checks those attestations against policy and blocks deployment when required signatures are missing or invalid.
The following attestation checks answer different approval questions for the same image:
| Attestation check | Approval question it answers |
|---|---|
| Verify build origin | Was the image created by a specific, trusted build system or CI pipeline? |
| Validate vulnerability policy | Is the image compliant with the vulnerability signing policy? |
| Verify promotion criteria | Did the image pass the criteria for promotion from one environment to the next, such as development to QA? |
Vulnerability evidence for these decisions comes from Artifact Analysis, which automatically scans container images when they are uploaded to Artifact Registry. Artifact Analysis extracts system package information, continuously monitors scanned image metadata for new vulnerabilities, updates image metadata when new information arrives, creates new occurrences for new findings, and deletes occurrences that are no longer valid.
Cloud Deploy targets, IAM, and separation of duties determine who can request promotion and who can authorize it. A target that represents a high-risk environment is configured with requireApproval: true, which places the rollout in a pending approval state until an authorized identity approves or rejects it. The account that issues the approval must hold the predefined IAM role roles/clouddeploy.approver, so deployment permission and approval permission can be assigned to different people or systems. This separation ensures production deployment depends on both a verified artifact and an independent approver.
Exam tip: Setting requireApproval: true on a Cloud Deploy target creates the gate, but only an identity with roles/clouddeploy.approver can clear it with gcloud deploy rollouts approve.
Audit trails from Cloud Deploy, Cloud Build provenance, and attestation records then show who built the image, what checks it passed, and who approved its promotion.
An external approval workflow with Pub/Sub is the ordered integration that connects Cloud Deploy to an organizational approval system such as a ticketing tool or review board. When a rollout on a target with requireApproval: true needs approval, Cloud Deploy publishes a message to the clouddeploy-approvals Pub/Sub topic and the external system returns the decision through the Cloud Deploy API. Data flows from Cloud Deploy to Pub/Sub to the workflow system, then back from the workflow system to Cloud Deploy as an approve or reject command.
The workflow runs in this order:
requireApproval: true in the Cloud Deploy target definition for the critical environment.clouddeploy-approvals Pub/Sub topic to consume approval messages."Action": "Required", it starts its configured approval process using the rollout reference in the form Resource: projects/.../locations/.../deliveryPipelines/.../releases/.../rollouts/....gcloud deploy rollouts approve ROLLOUT --delivery-pipeline=PIPELINE_NAME --region=REGION --release=RELEASE_NAME to approve, or gcloud deploy rollouts reject with the same flags to reject.Only after the approve command is accepted by Cloud Deploy does the rollout leave the approval-gated state and proceed to the target environment.
Integrating automated quality and security checks as approval criteria means a deployment pipeline blocks promotion until required validations succeed and only then allows manual approval. The pipeline runs scans, tests, and policy evaluations on every artifact, records the results as verifiable evidence, and the deployment system checks that evidence at release time. This design removes manual errors, creates standardized feedback loops, and ensures only verified artifacts move from development to test to production.
Automated CI/CD pipelines are policy enforcement points that embed security checks directly into the software development lifecycle (SDLC). Google Cloud supports this pattern with Cloud Build for building and testing, Cloud Deploy for progressive delivery, Web Security Scanner for application scanning, and Binary Authorization for deployment-time enforcement. Teams define different policies for development, test, and production environments so only artifacts that pass the checks for that environment can deploy. The Supply-chain Levels for Software Artifacts (SLSA) framework organizes these requirements across source code, build process, and code provenance, drawing on shift-left security (opens in a new tab) and software supply chain security (opens in a new tab) practices.
Binary Authorization is the deployment-time control that enforces approval processes for GKE and Cloud Run. Binary Authorization attaches configurable signatures called attestations to container images, and each attestation states that a required process was completed. At deployment time, traffic flows from the deployment request to the Binary Authorization policy engine, which allows the Pod or service to start only when the required attestations are present and valid. Because enforcement happens at the target platform, compromised pipeline configuration alone cannot cause untrusted code to run when the policy blocks images without valid attestations.
Binary Authorization can validate three types of approval evidence:
Artifact Analysis is the service that provides continuous vulnerability scanning for container images stored in Artifact Registry. Artifact Analysis scans a new image when the image is uploaded to Artifact Registry, extracts information about the system packages inside the container, and stores vulnerability metadata with the image. After the initial scan, Artifact Analysis continuously monitors the stored metadata against new and updated information from vulnerability sources. This continuous flow from Artifact Registry to Artifact Analysis to updated metadata means an image that was clean at build time can fail approval later.
When new vulnerability information arrives, Artifact Analysis updates each affected image in order:
A vulnerability signing policy can then withhold the attestation that Binary Authorization requires, so the image cannot deploy until it meets the policy again.
Exam tip: Artifact Analysis scans at upload time and monitors continuously in Artifact Registry, while Binary Authorization enforces at deployment time on GKE and Cloud Run by requiring attestations.
In-pipeline integrity controls are automated quality gates that run before a change reaches a human approver. The deployment pipeline applies these controls to code and configuration on every run, so reviewers approve only changes that already meet baseline quality and compliance rules. These controls catch typos, misconfigurations, and policy violations early, narrow the scope of manual security review, and preserve the ability to roll back to a known safe version.
Pipelines typically require three peer controls as prerequisites for approval:
Cloud Build strengthens these gates with isolated and ephemeral build environments, support for SLSA Level 3 builds for container images, and authenticated and non-falsifiable build provenance. Build provenance is verifiable metadata that flows from the build to security dashboards and includes image digests, input source locations, build toolchain, build steps, and build duration. Cloud Deploy then delivers approved applications to GKE, GKE Enterprise, and Cloud Run in a defined sequence with one-click approvals and rollbacks, enterprise security and audit, and built-in delivery metrics plus security insights.
Protecting the approval system means the deployment pipeline, its configuration, its infrastructure, and all inputs it consumes must meet integrity standards that match or exceed the resources the pipeline manages. The Biba model defines the allowed data flow for integrity: the deployment pipeline must not consume input artifacts of lower integrity, and the deployment pipeline must not write data to a resource of higher integrity. To apply this rule, teams first categorize the data, applications, and resources the pipeline accesses, then assign the pipeline the integrity category of the highest-integrity resource it manages.
Verification of inputs prevents compromised third-party artifacts such as Docker base images, .rpm or .deb packages, and Maven, .npm, or NuGet libraries from passing automated checks. Many package managers support code signing, with Pretty Good Privacy (PGP) for RPM and Maven packages and Authenticode for NuGet packages, so the pipeline can require signed artifacts, maintain a curated list of trusted publisher certificates or public keys, and verify each signature against that list. For artifacts that do not support signing and change infrequently, the pipeline verifies hashes instead. The underlying infrastructure depends on the same trust, so teams hold the CI/CD software, tools such as Terraform, kubectl, and Docker, and the operating system to the same integrity standards, obtain tools from trusted sources, rebuild infrastructure regularly from scratch, and run the pipeline on shielded virtual machines (VMs).
Approval workflows in Cloud Deploy (opens in a new tab) are gates that pause a rollout before it can promote to a target environment until an authorized decision is returned. Cloud Deploy publishes an approval request to Cloud Pub/Sub, an external workflow system routes that request through organizational approvers or automated checks, and the decision flows back to Cloud Deploy as an approve or reject command. This design separates delivery orchestration from approval policy so pipelines progress reliably while every promotion remains auditable.
Approval enforcement in Cloud Deploy is controlled per target by setting requireApproval: true in that target definition. When the flag is present, Cloud Deploy creates the rollout but does not deploy to the target until an approval is recorded, which protects production and other sensitive environments from automatic promotion. When the flag is absent, the rollout proceeds without a human or external gate. Use this flag selectively on targets where organizational policy, risk, or compliance requires an explicit decision before release.
External approval notifications in Cloud Deploy use the clouddeploy-approvals Pub/Sub topic to connect delivery pipelines to an outside workflow management system. Cloud Deploy acts as the publisher when a rollout needs approval, and the external system acts as the subscriber that starts the organization-specific approval chain. The published message carries "Action": "Required" plus a rollout reference in the form Resource: projects/.../locations/.../deliveryPipelines/.../releases/.../rollouts/..., so the workflow system knows exactly which rollout is blocked.
Setting up an external approval workflow follows an ordered sequence:
requireApproval: true to the target definition in the delivery pipeline.clouddeploy-approvals Pub/Sub topic."Action": "Required" arrives, kick off the configured approval chain and collect an approval or rejection decision.Because the workflow system sits outside Cloud Deploy, it can implement approver routing, escalation for unresponsive approvers, additional notifications, and audit logging according to organizational requirements without changing the delivery pipeline itself.
Approval decisions are returned to Cloud Deploy with the Google Cloud CLI commands gcloud deploy rollouts approve and gcloud deploy rollouts reject. Both commands require the rollout name, delivery pipeline name, release name, and region, for example gcloud deploy rollouts approve test-rollout --delivery-pipeline=web-app --release=test-release --region=us-central1. The rollout stays blocked until one of these commands succeeds, and a rejection stops that promotion while preserving the release history. The account that issues the approve command must have the predefined Identity and Access Management (IAM) role roles/clouddeploy.approver, so only trusted approvers or the workflow service account can unblock deployment.
Exam tip: Setting requireApproval: true only blocks the rollout; promotion resumes only after an identity with roles/clouddeploy.approver runs rollouts approve for that specific rollout, release, pipeline, and region.
Binary Authorization is an automated policy check that approves container deployments to GKE and Cloud Run based on verifiable attestations. An attestation is a signed statement attached to a container image, and Binary Authorization evaluates those attestations at deployment time before allowing the image to run. This enforces that only trusted code reaches the target platform even when a human approval has already occurred.
Binary Authorization can validate that:
Choose Binary Authorization when approval must prove build provenance, vulnerability compliance, or environment promotion rather than relying only on a manual decision.
Secure delivery in Cloud Deploy combines one-click approvals, rollbacks, enterprise audit, and built-in delivery metrics across a defined sequence of targets for GKE, GKE Enterprise, and Cloud Run. The approval gate enforces a consistent process for every configuration or code change, while automated tests, static analysis, and policy-as-code checks reduce accidental or malicious changes before deployment. Together, manual approvals, automated attestations, and security insights for built and deployed artifacts create a clear audit trail of who approved what, which image was verified, and where it was allowed to run. This trail links the secure deployment pipeline (opens in a new tab) configuration to the deployed result.
requireApproval: true until an identity with roles/clouddeploy.approver runs gcloud deploy rollouts approve.clouddeploy-approvals Pub/Sub topic with "Action": "Required" and a rollout reference, and the external workflow returns the decision through the Cloud Deploy API.Cloud Deploy pauses promotion on any target configured to require approval until an authorized identity approves or rejects the rollout. Only an identity with the predefined Identity and Access Management (IAM) role roles/clouddeploy.approver can clear the gate, which separates deployment permission from approval permission so production depends on both a verified artifact and an independent approver.
Artifact Analysis provides continuous vulnerability scanning for container images stored in Artifact Registry, scanning at upload and updating vulnerability metadata as new information arrives. Binary Authorization is the deployment-time enforcement service for Google Kubernetes Engine (GKE) and Cloud Run that allows images to run only when required attestations for build origin, vulnerability policy, or promotion criteria are present and valid.
When a rollout on a target that requires approval needs a decision, Cloud Deploy publishes a message to the clouddeploy-approvals Pub/Sub topic with an action of Required and a rollout reference. The external workflow system subscribes to that topic, starts its organizational review, and returns the decision through the Cloud Deploy API, and the rollout leaves the approval-gated state only after the approve command is accepted.
Your organization uses a GitOps workflow with Config Sync to manage Kubernetes resource manifests and security policies across multiple Google Kubernetes Engine (GKE) clusters.
To prevent broken configurations and security policy regressions from reaching production clusters, you need to establish an automated gating and approval process with the following requirements:
Which solution should you implement?
Last updated