Professional Cloud DevOps Engineer

Continuous Integration (CI) with Cloud Build

Triggering and Executing Builds

When a developer pushes code to a version control system, a webhook triggers Cloud Build to start a build pipeline. The build pipeline executes a series of build steps defined in a configuration file, where each step runs inside a specific container image. These steps execute sequentially by default, but you can configure them to run in parallel to reduce build times. The service account associated with the build determines what Google Cloud resources the pipeline can access.

Worker Pools and Network Boundaries

By default, Cloud Build runs workloads in a multi-tenant, public hosted environment. Organizations with strict security compliance or private network requirements can use private pools instead. Private pools allow builds to access resources inside a private virtual private cloud (VPC) via a secure connection, such as private Kubernetes clusters or databases. Choosing between public and private pools involves trading off the zero-management simplicity of public pools against the network isolation and custom machine sizes of private pools.

Continuous Delivery (CD) with Cloud Deploy, including Kustomize and Skaffold

Pipeline Orchestration and Deployment Targets

Cloud Deploy manages the delivery pipeline by promoting application releases through a sequence of target environments, such as development, staging, and production. To initiate this process, a build tool creates a Cloud Deploy release, which binds the application's container image and configuration manifests together. Cloud Deploy then generates a rollout for the first target in the pipeline, executing the deployment to target platforms like Google Kubernetes Engine, Anthos, or Cloud Run. Operators can configure manual approval gates between targets to ensure production deployments only happen after verification.

Manifest Management with Skaffold and Kustomize

The continuous delivery pipeline relies on Skaffold to orchestrate the build, push, and deployment operations across different environments. Skaffold works alongside Kustomize to manage environment-specific configurations without duplicating base manifest files. Kustomize applies overlays to the base Kubernetes manifests, modifying values like replica counts or environment variables for different stages of the pipeline. If a deployment fails in a downstream target, Cloud Deploy can automatically or manually initiate a rollback to a previous stable state, restoring services quickly.

Artifact Registry Configuration

Repository Architecture and Access Control

Artifact Registry serves as the central storage system for build artifacts, supporting container images, language packages, and OS packages. Administrators can organize repositories by region to keep artifacts close to compute resources, reducing latency and data transfer costs. Access to these repositories is secured using Identity and Access Management roles, separating permissions between CI systems that write artifacts and deployment runtimes that read them.

Lifecycle and Security Scanning

To prevent vulnerable software from running in production, Artifact Registry integrates with Container Analysis to perform automatic vulnerability scanning on pushed container images. Organizations can define cleanup policies to automatically delete old or unused container tags, keeping storage costs manageable. To optimize multi-cloud and hybrid environments, virtual repositories can group multiple local and remote repositories under a single endpoint, simplifying client configuration and dependency resolution.

Widely Used Third-Party Tooling

Self-Managed CI/CD and GitOps Tools

While Google Cloud offers native services, many architectures integrate third-party tools like Jenkins to coordinate complex build workflows across hybrid environments. In contrast to push-based deployment tools, Argo CD implements a GitOps model by continuously monitoring a Git repository for changes in application state. Argo CD runs inside a Kubernetes cluster and automatically pulls the desired state from Git, reconciling any drift between the repository and the live environment.

Infrastructure Packaging and Configuration

To prepare consistent base environments, teams use Packer to automate the creation of virtual machine images for Compute Engine. These pre-configured machine images reduce startup times and guarantee consistency across auto-scaling groups. For managing Kubernetes configurations, kpt allows platform teams to package, publish, and customize resource manifests using a git-to-git workflow, maintaining a clear path for upstream updates.

Security of CI/CD Tooling

Establishing the Software Supply Chain Boundary

Securing the software supply chain requires restricting network and IAM access to the deployment pipeline components. VPC Service Controls establish a security perimeter around Cloud Build and Artifact Registry to prevent data exfiltration by blocking API calls outside the trust boundary. Within this boundary, least-privilege IAM service accounts ensure that the build runner can only write to specific registries and cannot modify production infrastructure directly.

Attestations and Binary Authorization

To guarantee that only trusted code runs in production, organizations implement Binary Authorization on Kubernetes clusters. During the build phase, Cloud Build generates secure metadata attestations, signing them with keys managed in Cloud Key Management Service (KMS). Before GKE deploys a container, Binary Authorization intercepts the request and verifies the signature on the attestation, blocking any image that was not built by the official pipeline.