Prepare and test your skills
Prepare and test your skills
Integrate Continuous Testing, Quality Gates, and Binary Authorization is the practice of adding automated checks to every pipeline stage so only verified container images reach production. Cloud Build builds and tests artifacts, Artifact Analysis scans images in Artifact Registry, Binary Authorization (opens in a new tab) blocks untrusted images at deploy time, and Cloud Deploy (opens in a new tab) enforces approval gates between environments. Test results and scan findings become signed attestations that deployment policy can verify before any Pod starts.
Continuous testing across rapid and full pipelines means every code change is validated automatically before its artifact can be promoted. A Cloud Build (opens in a new tab) trigger starts when code is committed to the source repository, then runs linting, static code analysis, expert code review, and application tests. Rapid pipelines give fast feedback on feature branches, while full pipelines run comprehensive checks on merge requests and commits to the main branch.
| Pipeline type | Typical duration | When to use it |
|---|---|---|
| Rapid pipeline | 10 minutes or less | Feature branches for fast iteration; may produce unstable artifacts |
| Full pipeline | Longer than 10 minutes | Merge requests and commits to main branch with comprehensive tests |
Application and image checks in the pipeline validate different layers of quality:
Because review checks and continuous integration (CI) checks run together, the same change is evaluated for style, correctness, image structure, and runtime exploitability before promotion.
Container vulnerability scanning with Artifact Analysis (opens in a new tab) is the automated quality gate that approves an image for deployment only when its known vulnerabilities are acceptable. Data flows from Cloud Build to Artifact Registry when the built image is pushed, then Artifact Analysis extracts system package information from the container and compares it to vulnerability sources maintained by Google Cloud. After the first scan, the service keeps monitoring stored image metadata against updated vulnerability feeds.
When new vulnerability data arrives, Artifact Analysis updates the metadata of scanned images, creates new vulnerability occurrences for new findings, and deletes occurrences that are no longer valid. An image with vulnerabilities above the allowed severity fails the gate and cannot advance. Specific vulnerabilities that do not apply to the application can be added to an allowlist so they do not block promotion. This continuous monitoring means an image that was clean at build time can be flagged later without changing scanner logic.
Deploy-time enforcement with Binary Authorization is the trust boundary between the registry and the runtime that allows only trusted images to run. Binary Authorization applies pre-deployment checks on supported platforms such as GKE, Cloud Run, and GKE Enterprise, blocking any image that is not exempt and lacks required attestations. An attestation is a signed digital document stating that a required process completed successfully for that exact image digest.
Required attestations turn earlier pipeline results into promotion criteria, and development, test, and production environments can require different attestations:
The ordered sequence from commit to signed image preserves the link between the tested digest and the deployed digest:
Images should be promoted rather than rebuilt as they move from development to QA to production. Rebuilding can introduce small differences or untested code, so the best practice is to build once, externalize environment-specific configuration to be read at runtime, and promote the same immutable digest through each target.
Post-deploy continuous validation is the Binary Authorization feature that keeps checking running Pods against current policy after admission. When enabled, Binary Authorization regularly evaluates running Pods and writes policy conformance results to Cloud Logging (opens in a new tab) throughout the Pod lifecycle. This creates an auditable trail that shows which workloads drifted out of compliance after they were already running.
Continuous validation catches three cases that pre-deployment blocking cannot catch: the policy changes after containers are deployed, Pods were admitted in dry run mode, and Pods were admitted with breakglass emergency override. For example, if a tightened vulnerability policy is published after deployment, continuous validation logs the Pods that now violate the updated policy even though they passed the earlier gate.
Exam tip: Binary Authorization policy blocks non-compliant images at deployment time, while continuous validation only logs non-compliance for already-running Pods in Cloud Logging.
Approval gates, security posture monitoring, and rollback readiness control how verified releases move forward and how risk is detected after rollout. Cloud Deploy defines a delivery pipeline with staging and production targets, generates a new release for each source change, stores Skaffold rendering sources and rendered manifests in a Cloud Storage bucket, and pauses for manual approval before production when configured. Deployment gating prevents unauthorized changes to application environments and records who approved each promotion.
Workload monitoring closes the loop by checking hardened configuration and supply-chain signals after rollout. The GKE security posture dashboard scans workload configuration across clusters against best practices such as Pod Security Standards, rates severity, returns actionable recommendations, and sends an auditable trail to Cloud Logging. The Cloud Run security panel shows software supply chain insights for running services, including Supply-chain Levels for Software Artifacts (SLSA) build level, build provenance, and found vulnerabilities. Because pipelines use immutable images and per-environment policies, a failed gate or newly discovered risk can roll back by redeploying the prior verified digest rather than patching a running container.
Designing application deployment pipelines and release strategies means connecting Cloud Build (opens in a new tab) for continuous integration to Cloud Deploy for continuous delivery, with Artifact Registry as the single store for immutable images. Code flows from the source repository through automated build, test, and security scans into a versioned release that is promoted through staging and production targets. Vulnerability scanning, Container Structure Tests, and Binary Authorization attestations decide whether an image is allowed to advance.
Immutable images and Kubernetes platform configuration provide the stable foundation that lets the same artifact run safely in every environment. An immutable image is never modified while running, so any code or patch change requires building a new image digest and redeploying it. Configuration must be externalized so the container reads environment-specific values at runtime instead of baking them into the image.
Each application repository includes Kubernetes manifests that Cloud Deploy applies to Google Kubernetes Engine (GKE) (opens in a new tab):
To reach clusters over a private network path, the pipeline interacts with GKE through the Connect gateway for kubeconfig authentication and runs builds in Cloud Build private pools.
The integration workflow with Cloud Build and Skaffold is the ordered CI chain that starts on every commit and ends with a signed, releasable image. A Cloud Build trigger rebuilds the application container, pushes the image to Artifact Registry with an image digest, stores build artifacts in a Cloud Storage bucket, runs tests, and then calls Cloud Deploy to create a release. Skaffold shares configuration across development, staging, and production, so developers validating locally with Cloud Code and minikube use the same rendering logic that later deploys to GKE.
Only the digest that passes every step is eligible for promotion, which keeps development, staging, and production consistent.
Central artifact storage and ongoing monitoring in Artifact Registry (opens in a new tab) manages the full lifecycle of versioned container images. Artifact Registry stores versioned images and integrates with CI/CD tools and Google Cloud runtimes, so builds, scans, and deployments all reference the same immutable artifact. Artifact Analysis automatically scans each new image on upload by extracting system package metadata and comparing it against known vulnerabilities.
After the initial scan, Artifact Analysis continuously monitors stored image metadata against new vulnerability information. When updates arrive, the service updates image metadata, creates new vulnerability occurrences, and deletes occurrences that are no longer valid. This means an image approved today can be flagged tomorrow without rebuilding, so promotion policies in Cloud Deploy can block affected releases from reaching production.
Progressive delivery with Cloud Deploy (opens in a new tab) automates the movement of each release through a defined sequence of targets. A delivery pipeline registers targets that represent staging and production GKE clusters and creates a Cloud Storage bucket to store the Skaffold rendering source and rendered manifests. Cloud Deploy generates a new release for each source change, deploys that release to staging first, and only after build and test success promotes the identical immutable image toward production.
Per-environment logic controls how much automation applies at each target, such as auto-deploy to development, quality assurance, and pre-production but manual approval for production. Because GKE provides built-in scaling and upgrade logic, teams compose deployment behavior rather than building rolling updates, zero-downtime upgrades, or blue-green patterns from scratch. The result is a repeatable promotion path where the production rollout uses the exact digest already verified in staging.
Exam tip: Cloud Build creates and validates the immutable image and calls Cloud Deploy, while Cloud Deploy creates the release and promotes that same image digest from staging to production with approvals.
Attestations, secure controls, and advanced rollout strategies ensure that only verified artifacts move between environments with minimal downtime and blast radius. Binary Authorization enforces deployment-time policy by checking configurable signatures that prove a required process completed for the image. At deployment to GKE or Cloud Run, the policy verifies that a specific build system created the image, that the image complies with a vulnerability signing policy, and that the image meets criteria for promotion from development to QA to production.
Complementary controls strengthen the pipeline and the running workload. Web Security Scanner (opens in a new tab) crawls App Engine, Compute Engine, and GKE web apps for cross-site scripting, code injection, mixed content, and insecure libraries, while Supply-chain Levels for Software Artifacts (SLSA) checks cover source, build process, and code provenance. Pipelines run as production systems with least privilege, private pools, Connect gateway private access, and VPC Service Controls to prevent a compromised deployment from reading unneeded data or exfiltrating data.
Automating Infrastructure as Code (IaC) and GitOps workflows means storing the desired environment state as declarative code in Git and using a pipeline to make live infrastructure match that state. Terraform (opens in a new tab) provides the declarative IaC language that predictably creates, changes, and improves infrastructure, while Cloud Build (opens in a new tab) acts as the continuous integration service that runs terraform plan and terraform apply in response to Git events.
The GitOps reconciliation model for Terraform makes the Git repository the single source of truth and Cloud Build the engine that reconciles desired state with actual state. A push of Terraform code to a tracked branch triggers Cloud Build, which then executes Terraform manifests against the matching Google Cloud environment. This flow runs from the repository to Cloud Build and then from Cloud Build to the target environment.
Declarative IaC is preferred over imperative scripting because declarative code defines what should exist rather than the manual steps to create it. Adopting declarative IaC creates repeatable infrastructure with a known good state, which improves rollback efficiency, change auditing, and troubleshooting. When combined with CI/CD automation, declarative IaC also enables policy as code, where infrastructure changes are audited over time and checked automatically before deployment.
Branch mapping and ordered environment promotion link Git branches directly to isolated environments and control how changes advance. For example, a dev branch maps to a dev Virtual Private Cloud (VPC) network and a prod branch maps to a prod VPC network in the same Google Cloud project. Pushes to any other branch, such as a feature branch, cause Cloud Build to run terraform plan only, with nothing applied to any environment.
The promotion workflow moves infrastructure proposals from review to production in a controlled order:
terraform plan report to the pull request for discussion and follow-up commits.dev branch, which triggers Cloud Build to deploy the infrastructure to the dev environment for testing.dev environment is tested and validated, the dev branch merges into the prod branch, which triggers Cloud Build to install the infrastructure into production.Exam tip: A push to a feature branch runs terraform plan for review only, while a merge into dev or prod runs terraform apply to that environment.
Shared state storage and pipeline identity give every pipeline execution a consistent record and the correct permissions to act on it. The Terraform state file is stored in a Cloud Storage (opens in a new tab) bucket rather than on a local workstation or build worker. The bucket holds the shared, authoritative record of managed resources, so every Cloud Build execution for an environment reads and updates the same state.
The pipeline identity is the Cloud Build service account that Cloud Build uses to access Google Cloud resources and the state bucket. Permissions must be granted to that service account so it can read the Terraform configuration, read and write the Cloud Storage state, and create or modify the target infrastructure. Connecting Cloud Build to the repository through triggers and the Cloud Build GitHub app completes the trust chain, where a Git event flows from the repository to Cloud Build and then to the target VPC environment.
Policy-as-code layers and preventive guardrails express security and governance rules as machine-checkable constraints that run before infrastructure is applied. Open Policy Agent (OPA) and Policy Controller enforce IaC constraints in the CI/CD pipeline to block cloud misconfigurations before deployment. Organization Policy Service (opens in a new tab) provides centralized predefined and custom constraints, such as limiting domain sharing, limiting service account use, and restricting resource locations, while VPC Service Controls creates perimeters around Google Cloud services for defense in depth.
The guardrails that surround IaC automation work at different layers:
Applying these checks early, including linting, static analysis, and expert review of production-bound code, reduces the time and cost of fixing risks after artifacts are built. The enterprise foundations blueprint packages this approach as an opinionated Terraform and Cloud Build design for secure landing-zone topology.
Central push versus local pull deployment models describe where deployment logic runs and how many resources it manages. The push model uses a central CI/CD system, such as Jenkins, GitLab, Terraform with Cloud Build, or Config Controller, to push changes outward to many projects and applications. The pull model uses an agent deployed alongside the resource, for example in the same GKE cluster, that pulls artifacts or source code from a central location and deploys them locally.
| Model | Where logic runs | Scope and flow |
|---|---|---|
| Push model | Central CI/CD system on Google Cloud, on-premises, or another cloud | One system manages many resources; artifacts flow from the central pipeline outward to target environments |
| Pull model | Agent alongside the resource, such as in the same Kubernetes cluster | Each agent manages one or two resources; the agent pulls desired state inward and applies it locally |
Choose the push model when centralized control, shared Terraform execution with Cloud Build, and consistent policy checks across development, test, and production are required. Choose the pull model when decentralized, environment-local reconciliation is needed, such as fleet agents that continuously sync cluster state. Declarative infrastructure with GitOps plus Config Sync helps both models keep pre-production close to production by duplicating cluster configuration and policy, with pre-production allowed to be a scaled-down replica for cost reasons.
terraform plan for review only, while a merge into the dev or prod branch runs terraform apply to that environment using shared state in a Cloud Storage bucket.Binary Authorization deployment-time enforcement blocks non-compliant images at deployment time on platforms such as Google Kubernetes Engine (GKE), Cloud Run, and GKE Enterprise unless they have required signed attestations, while continuous validation only logs policy conformance results for already-running Pods to Cloud Logging. Continuous validation catches cases that pre-deployment blocking cannot catch, such as policy changes after deployment, Pods admitted in dry run mode, and Pods admitted with breakglass emergency override.
Use a rapid pipeline lasting 10 minutes or less for feature branches for fast iteration where artifacts may be unstable, and use a full pipeline lasting longer than 10 minutes for merge requests and commits to the main branch with comprehensive tests. Both are started by a Cloud Build trigger on code commit that runs linting, static code analysis, expert code review, and application tests.
Artifact Analysis continuously monitors stored image metadata in Artifact Registry against updated vulnerability feeds maintained by Google Cloud. When new vulnerability data arrives, it updates the metadata of scanned images, creates new vulnerability occurrences for new findings, and deletes occurrences that are no longer valid, so an image that was clean at build time can be flagged later and fail promotion.
Cloud Build creates and validates the immutable container image and calls Cloud Deploy, while Cloud Deploy creates the release and promotes that same image digest from staging to production. Images should be promoted rather than rebuilt to avoid introducing small differences or untested code, with environment-specific configuration externalized to be read at runtime.
A DevOps team is designing an enterprise CI/CD pipeline on Google Cloud for a mission-critical application hosted on Google Kubernetes Engine (GKE). The pipeline architecture must satisfy the following technical and operational requirements:
Which end-to-end pipeline workflow should the team implement?
Last updated