{"id":591,"date":"2026-04-14T15:58:23","date_gmt":"2026-04-14T15:58:23","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-build-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-application-development\/"},"modified":"2026-04-14T15:58:23","modified_gmt":"2026-04-14T15:58:23","slug":"google-cloud-build-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-application-development","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-build-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-application-development\/","title":{"rendered":"Google Cloud Build Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Application development"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Application development<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Cloud Build is Google Cloud\u2019s managed build service for compiling source code, running tests, and producing deployable artifacts such as container images and packages. It\u2019s commonly used as the \u201cCI\u201d (continuous integration) engine inside a broader CI\/CD pipeline, but it can also perform deployments when you define those steps in your build.<\/p>\n\n\n\n<p>In simple terms: you give Cloud Build a source snapshot (from a Git repo or a local directory upload), and it runs a repeatable set of steps (like <code>npm test<\/code>, <code>docker build<\/code>, <code>docker push<\/code>, <code>gcloud run deploy<\/code>) inside Google-managed build workers. Each build produces logs and (optionally) outputs artifacts to services like Artifact Registry or Cloud Storage.<\/p>\n\n\n\n<p>Technically, Cloud Build executes a build as a sequence of container-based steps defined in a build config file (<code>cloudbuild.yaml<\/code> or <code>cloudbuild.json<\/code>) or defined inline via API\/CLI. Each step runs in an isolated container image (Google-provided \u201cbuilders\u201d or your own). Cloud Build integrates tightly with Cloud Logging, IAM, Artifact Registry, Secret Manager, and deployment targets like Cloud Run and GKE. For private network access, Cloud Build supports private worker pools (often called \u201cprivate pools\u201d in practice) so builds can run inside your VPC.<\/p>\n\n\n\n<p><strong>What problem it solves:<\/strong> Cloud Build replaces self-managed build servers (Jenkins agents, custom runners) with a managed, scalable service that is consistent, auditable, and integrates with Google Cloud security and governance.<\/p>\n\n\n\n<blockquote>\n<p>Service naming\/status note: <strong>Cloud Build<\/strong> is the current product name and is active. Some adjacent products have evolved over time (for example, <strong>Container Registry is legacy in favor of Artifact Registry<\/strong>, and some source repository integrations have changed). When integrating Cloud Build with specific SCM providers, <strong>verify the current supported options and recommended connection method in the official docs<\/strong>.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Cloud Build?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>Cloud Build is a managed service on Google Cloud for building software and creating artifacts from source code. It is designed to run automated builds, tests, and packaging steps, and to integrate with CI\/CD workflows.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Declarative builds<\/strong> via <code>cloudbuild.yaml<\/code> or <code>cloudbuild.json<\/code><\/li>\n<li><strong>Container-based build steps<\/strong> using builder images (Google-provided or custom)<\/li>\n<li><strong>Artifact creation and publishing<\/strong>, especially container images to <strong>Artifact Registry<\/strong><\/li>\n<li><strong>Build triggers<\/strong> to run builds automatically based on source changes or events<\/li>\n<li><strong>Centralized logging and auditability<\/strong> via Cloud Logging and Cloud Audit Logs<\/li>\n<li><strong>Private builds in VPC<\/strong> via private worker pools for network-restricted environments<\/li>\n<li><strong>Integration with IAM<\/strong> and service accounts for least-privilege automation<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Build<\/strong>: A single execution run with steps, logs, status, and metadata.<\/li>\n<li><strong>Build config<\/strong> (<code>cloudbuild.yaml<\/code>): Steps, environment variables, substitutions, artifacts, timeout, options, and more.<\/li>\n<li><strong>Steps<\/strong>: Container executions (e.g., run tests, compile code, build container).<\/li>\n<li><strong>Builder images<\/strong>: Container images used by steps (e.g., <code>gcr.io\/cloud-builders\/docker<\/code>).<\/li>\n<li><strong>Triggers<\/strong>: Rules that start builds automatically (e.g., on Git pushes).<\/li>\n<li><strong>Artifacts<\/strong>: Outputs like container images or files uploaded to Cloud Storage.<\/li>\n<li><strong>Service account<\/strong>: Identity used by the build to access Google Cloud resources.<\/li>\n<li><strong>Private worker pool<\/strong> (private pool): A set of build workers in your VPC network.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Fully managed, API-driven build execution service (CI engine).<\/li>\n<li>\u201cServerless\u201d in the sense that you don\u2019t manage build VMs directly for default builds.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope: regional\/global\/project considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Build is used <strong>per Google Cloud project<\/strong> and is controlled by <strong>project IAM<\/strong>.<\/li>\n<li>Builds can interact with <strong>regional resources<\/strong> (Artifact Registry repositories, Cloud Run services, GKE clusters), so you must choose regions for those resources.<\/li>\n<li>Some features (such as private worker pools) have <strong>regional placement<\/strong> and <strong>network dependencies<\/strong>. <strong>Verify current region availability and constraints in official docs<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Cloud Build often sits at the center of \u201cApplication development\u201d on Google Cloud:\n&#8211; Source change \u2192 build trigger \u2192 run tests \u2192 build artifacts \u2192 publish to Artifact Registry \u2192 deploy to Cloud Run\/GKE \u2192 observe via Cloud Logging\/Monitoring.\n&#8211; Works with <strong>Artifact Registry<\/strong> (recommended), <strong>Cloud Storage<\/strong>, <strong>Cloud Run<\/strong>, <strong>GKE<\/strong>, <strong>Secret Manager<\/strong>, <strong>Cloud Deploy<\/strong>, <strong>Binary Authorization<\/strong> (in container security workflows), <strong>Cloud Logging<\/strong>, and <strong>Cloud Monitoring<\/strong>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Cloud Build?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Lower operational burden<\/strong>: No build server patching, scaling, or availability engineering.<\/li>\n<li><strong>Faster delivery<\/strong>: Standardizes builds and reduces pipeline drift between teams.<\/li>\n<li><strong>Auditability<\/strong>: Central build history and logs support internal controls and audits.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reproducible builds<\/strong>: Build steps run in defined container images.<\/li>\n<li><strong>Flexible pipelines<\/strong>: Compose any workflow as steps (tests, linting, packaging, scanning, deployment).<\/li>\n<li><strong>Artifact-first workflows<\/strong>: Native fit with Artifact Registry and container-based deployments.<\/li>\n<li><strong>Extensibility<\/strong>: Use custom builder images for specialized toolchains.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Elastic scaling<\/strong> for builds without pre-provisioning runners (default pool).<\/li>\n<li><strong>Central logs<\/strong> in Cloud Logging and build status in Cloud Build history.<\/li>\n<li><strong>API\/CLI automation<\/strong>: Easy integration with GitOps, ChatOps, or internal portals.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM-controlled access<\/strong> to start builds and to access resources from builds.<\/li>\n<li><strong>Service account separation<\/strong> between build-time and runtime identities.<\/li>\n<li><strong>Private networking options<\/strong> (private pools) for restricted environments.<\/li>\n<li><strong>Audit logs<\/strong> for build creation, configuration changes, and resource access (where applicable).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Parallelism is possible by defining independent steps (and using <code>waitFor<\/code> patterns).<\/li>\n<li>Machine types can be selected (depending on current Cloud Build options) to speed up CPU-heavy builds. <strong>Verify current machine type options and pricing SKUs<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You want a managed CI system tightly integrated with Google Cloud.<\/li>\n<li>You build container images and deploy to Cloud Run or GKE.<\/li>\n<li>You need a central, policy-controlled build platform for multiple teams.<\/li>\n<li>You need private network access to internal dependencies (via private pools).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You need a single CI\/CD platform across multiple clouds with identical primitives and you already standardized on another system (e.g., GitHub Actions, GitLab CI, Jenkins).<\/li>\n<li>You need extremely customized runner environments that are easier to manage on self-hosted runners (though custom builders and private pools reduce this gap).<\/li>\n<li>Your organization requires on-prem-only build execution with no cloud build execution (in that case, self-managed CI is more appropriate).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Cloud Build used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SaaS and technology companies shipping frequently<\/li>\n<li>Financial services and healthcare (especially with private networking and audit requirements)<\/li>\n<li>Retail\/e-commerce (high release velocity, multiple microservices)<\/li>\n<li>Media and gaming (build and packaging automation)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams building internal developer platforms (IDP)<\/li>\n<li>DevOps\/SRE teams standardizing CI pipelines<\/li>\n<li>Application teams needing a reliable build-and-deploy path<\/li>\n<li>Security engineering teams integrating scanning and policy checks into builds<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Containerized web APIs and background workers<\/li>\n<li>Microservices (many small builds, high parallelism)<\/li>\n<li>Serverless deployments (Cloud Run, Cloud Functions build workflows)<\/li>\n<li>Data and ML tool packaging (images for pipelines\/jobs)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Monorepos with multiple build targets<\/li>\n<li>Polyrepo microservices with per-service triggers<\/li>\n<li>GitOps-style workflows (build artifacts then deploy via a separate promotion system)<\/li>\n<li>Private dependency builds that require VPC-only access<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build on commit to main branch, publish to Artifact Registry<\/li>\n<li>Build on pull request for validation tests<\/li>\n<li>Nightly builds for vulnerability scanning and SBOM\/provenance generation<\/li>\n<li>Release builds that tag images and push deployment manifests<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Dev\/test<\/strong>: PR validation, unit tests, quick container builds, ephemeral preview deployments.<\/li>\n<li><strong>Production<\/strong>: Controlled release triggers, signed\/provenanced artifacts, staged deployments (often with Cloud Deploy), and strict IAM boundaries.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Cloud Build is commonly used in Google Cloud \u201cApplication development\u201d.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) CI for containerized microservices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Many services need consistent builds and tests.<\/li>\n<li><strong>Why Cloud Build fits:<\/strong> Simple YAML-based pipelines; integrates with Artifact Registry.<\/li>\n<li><strong>Example:<\/strong> Each service repo triggers <code>pytest<\/code>, builds a container image, pushes <code>:sha<\/code> and <code>:main<\/code> tags.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Build-and-deploy to Cloud Run<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Teams want a single, repeatable pipeline from commit to running service.<\/li>\n<li><strong>Why Cloud Build fits:<\/strong> Build container + run <code>gcloud run deploy<\/code> as a step.<\/li>\n<li><strong>Example:<\/strong> On merge to <code>main<\/code>, build image, deploy to Cloud Run in <code>us-central1<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) GKE image build pipelines<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Kubernetes workloads need images built and published reliably.<\/li>\n<li><strong>Why Cloud Build fits:<\/strong> Builds images and pushes to Artifact Registry; integrates with deployment tooling.<\/li>\n<li><strong>Example:<\/strong> Build image, update a Helm chart value, and trigger a deployment workflow.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Private builds for internal dependencies (VPC-only)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Builds must access private package registries, internal APIs, or private Git servers.<\/li>\n<li><strong>Why Cloud Build fits:<\/strong> Private worker pools can run in your VPC.<\/li>\n<li><strong>Example:<\/strong> Build accesses an internal Maven repository reachable only via VPC.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Supply chain security: provenance\/attestations pipeline<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need traceability from source \u2192 build \u2192 artifact.<\/li>\n<li><strong>Why Cloud Build fits:<\/strong> Can emit build metadata and integrate with policy checks. <strong>Verify current provenance\/attestation features and recommended setup.<\/strong><\/li>\n<li><strong>Example:<\/strong> Build produces an image and provenance, then a deploy system enforces policy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Monorepo selective builds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A monorepo change shouldn\u2019t rebuild everything.<\/li>\n<li><strong>Why Cloud Build fits:<\/strong> Use substitutions and scripts to detect changed paths, build only impacted targets.<\/li>\n<li><strong>Example:<\/strong> A build step runs <code>git diff<\/code> logic, then builds only affected services.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Infrastructure validation builds (IaC checks)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Terraform or Kubernetes manifests need formatting and policy checks.<\/li>\n<li><strong>Why Cloud Build fits:<\/strong> Runs lint\/validate steps and posts results to logs\/PR checks (depending on integration).<\/li>\n<li><strong>Example:<\/strong> On PR, run <code>terraform fmt -check<\/code>, <code>terraform validate<\/code>, <code>tflint<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Scheduled security scanning builds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Re-scan dependencies or images periodically.<\/li>\n<li><strong>Why Cloud Build fits:<\/strong> Trigger builds on schedules (or via external scheduler) and run scanners.<\/li>\n<li><strong>Example:<\/strong> Nightly rebuild base image, run vulnerability scan tool, export results.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Multi-environment promotion builds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need dev \u2192 staging \u2192 prod with different configs.<\/li>\n<li><strong>Why Cloud Build fits:<\/strong> Parameterized builds using substitutions; can be used with Cloud Deploy for promotion.<\/li>\n<li><strong>Example:<\/strong> Same build config deploys to different Cloud Run services based on <code>_ENV<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Build artifacts for non-container apps<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need zips\/jars\/binaries built and stored for release.<\/li>\n<li><strong>Why Cloud Build fits:<\/strong> Build steps can produce files and upload them to Cloud Storage.<\/li>\n<li><strong>Example:<\/strong> Build a Java JAR, upload to a versioned GCS bucket, publish checksum.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Integration tests against ephemeral environments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Integration tests require a temporary stack.<\/li>\n<li><strong>Why Cloud Build fits:<\/strong> Steps can provision ephemeral resources, run tests, then tear them down.<\/li>\n<li><strong>Example:<\/strong> Spin up a temporary Cloud Run service, run integration tests, delete service.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Cross-project builds (centralized platform team)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Shared build platform must deploy into multiple projects securely.<\/li>\n<li><strong>Why Cloud Build fits:<\/strong> Central build project with controlled IAM and impersonation patterns. <strong>Verify recommended cross-project patterns.<\/strong><\/li>\n<li><strong>Example:<\/strong> Build in a \u201cci-tools\u201d project; deploy into env projects using least privilege.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>This section focuses on important, commonly used Cloud Build features. For exact limits and newest capabilities, verify the official Cloud Build documentation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Build configuration (<code>cloudbuild.yaml<\/code> \/ <code>cloudbuild.json<\/code>)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Defines steps, images, substitutions, artifacts, options, and timeouts.<\/li>\n<li><strong>Why it matters:<\/strong> Makes builds repeatable and reviewable (code-reviewed pipeline).<\/li>\n<li><strong>Practical benefit:<\/strong> Teams can standardize builds across repos and languages.<\/li>\n<li><strong>Caveats:<\/strong> YAML mistakes can be subtle (indentation, quoting). Validate builds in a non-prod project first.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Container-based build steps (builders)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Each step runs in a container image (e.g., Docker builder, gcloud builder, language toolchains).<\/li>\n<li><strong>Why it matters:<\/strong> Isolates tool versions and dependencies.<\/li>\n<li><strong>Practical benefit:<\/strong> Reduces \u201cworks on my machine\u201d by pinning tool images.<\/li>\n<li><strong>Caveats:<\/strong> If you rely on \u201clatest\u201d tags, builds can change unexpectedly. Prefer pinned versions\/digests for critical pipelines.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Build triggers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Automatically starts builds on source events (e.g., pushes, PRs) or other supported events.<\/li>\n<li><strong>Why it matters:<\/strong> Enables CI automation.<\/li>\n<li><strong>Practical benefit:<\/strong> Standard CI pattern without running external runners.<\/li>\n<li><strong>Caveats:<\/strong> SCM integration options can vary over time; verify the current recommended integration path in Google Cloud docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Artifact publishing (especially container images)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Pushes container images to <strong>Artifact Registry<\/strong> and\/or uploads files to Cloud Storage.<\/li>\n<li><strong>Why it matters:<\/strong> Separates build from deploy; artifacts become immutable release inputs.<\/li>\n<li><strong>Practical benefit:<\/strong> Enables rollback, promotion, and repeatable deployments.<\/li>\n<li><strong>Caveats:<\/strong> Artifact Registry is regional; ensure region strategy is intentional.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM and service accounts for builds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Controls who can run builds and what builds can access.<\/li>\n<li><strong>Why it matters:<\/strong> Build systems are high-value targets; least privilege is essential.<\/li>\n<li><strong>Practical benefit:<\/strong> You can restrict build permissions to only required actions (e.g., push images, deploy).<\/li>\n<li><strong>Caveats:<\/strong> Over-permissioned build service accounts are a common security gap.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Private worker pools (private pools)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Runs builds on workers connected to your VPC network.<\/li>\n<li><strong>Why it matters:<\/strong> Enables access to private resources and restricts egress paths.<\/li>\n<li><strong>Practical benefit:<\/strong> Builds can fetch dependencies from private endpoints, connect to private databases for tests (carefully), or reach internal services.<\/li>\n<li><strong>Caveats:<\/strong> Additional cost and operational design (IP ranges, NAT, firewall, routing). Verify current setup requirements.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Build logs and history<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Captures build output and metadata.<\/li>\n<li><strong>Why it matters:<\/strong> Troubleshooting and audit trail.<\/li>\n<li><strong>Practical benefit:<\/strong> Central logs in Cloud Logging with searchable history.<\/li>\n<li><strong>Caveats:<\/strong> Logs retention and export can have cost implications (see Cloud Logging pricing).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Substitutions and parameterization<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Injects variables into builds (e.g., <code>_REGION<\/code>, <code>_SERVICE<\/code>, commit SHA).<\/li>\n<li><strong>Why it matters:<\/strong> Reuse build definitions across environments.<\/li>\n<li><strong>Practical benefit:<\/strong> A single build config can support multiple deploy targets.<\/li>\n<li><strong>Caveats:<\/strong> Treat substitutions as inputs; avoid leaking secrets via substitutions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Notifications and eventing (ecosystem integration)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Emits build status and logs; can integrate with event-driven flows.<\/li>\n<li><strong>Why it matters:<\/strong> Enables ChatOps, incident response hooks, and downstream automation.<\/li>\n<li><strong>Practical benefit:<\/strong> Trigger follow-up workflows based on build success\/failure.<\/li>\n<li><strong>Caveats:<\/strong> Exact integration patterns evolve; verify current supported mechanisms in docs (Pub\/Sub\/Eventarc patterns may apply depending on current product capabilities).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>A build is triggered (manually via CLI\/API or automatically via a trigger).<\/li>\n<li>Cloud Build fetches a source snapshot (or receives an uploaded source archive).<\/li>\n<li>Cloud Build runs build <strong>steps<\/strong> in containers on managed workers (default) or a private pool.<\/li>\n<li>Steps may:\n   &#8211; Pull dependencies from registries\n   &#8211; Run tests\n   &#8211; Build artifacts (binaries, zips, container images)\n   &#8211; Push artifacts to Artifact Registry or Cloud Storage\n   &#8211; Deploy to runtime services (Cloud Run\/GKE) if configured<\/li>\n<li>Build logs go to Cloud Logging, and build metadata is stored in Cloud Build history.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane:<\/strong> Build creation, trigger configuration, IAM, and metadata.<\/li>\n<li><strong>Data plane:<\/strong> Source upload\/download, artifact pushes\/pulls, and build log streaming.<\/li>\n<li><strong>Key principle:<\/strong> Your build steps run code. Treat build configs as sensitive operational code.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services (common)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Artifact Registry<\/strong>: store container images and packages.<\/li>\n<li><strong>Cloud Run<\/strong> \/ <strong>GKE<\/strong>: deployment targets via <code>gcloud<\/code> or Kubernetes tooling.<\/li>\n<li><strong>Secret Manager<\/strong>: provide secrets to build steps (recommended over embedding secrets).<\/li>\n<li><strong>Cloud Logging<\/strong>: build output and structured logs.<\/li>\n<li><strong>Cloud Monitoring<\/strong>: observe build metrics (via available metrics\/log-based metrics).<\/li>\n<li><strong>IAM<\/strong>: secure who can trigger builds and what builds can do.<\/li>\n<li><strong>Cloud Storage<\/strong>: source staging, artifact output, caches.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<p>Typical Cloud Build pipeline dependencies:\n&#8211; Artifact Registry repository (regional)\n&#8211; Cloud Storage bucket for source staging (if using <code>gcloud builds submit<\/code>)\n&#8211; Secret Manager secrets (optional)\n&#8211; Network egress paths (NAT\/proxy) if accessing external resources<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Builds execute under a <strong>service account<\/strong> (default or specified).<\/li>\n<li>Access to Google Cloud APIs is controlled via IAM roles on that service account.<\/li>\n<li>Permissions to create triggers and run builds are controlled via IAM on the project.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Default builds run on Google-managed infrastructure with internet egress (subject to Google Cloud\u2019s implementation).<\/li>\n<li>Private pools allow builds to run with <strong>VPC connectivity<\/strong>, enabling private access and more controlled egress.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Centralize build logs in Cloud Logging; consider log sinks for long-term retention.<\/li>\n<li>Use Cloud Audit Logs to track who changed triggers\/configurations and who invoked builds.<\/li>\n<li>Standardize naming, tagging\/labels, and repository mapping for governance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  Dev[Developer \/ Git push] --&gt; Trigger[Cloud Build Trigger]\n  Trigger --&gt; Build[Cloud Build: Steps in containers]\n  Build --&gt; AR[Artifact Registry: Container image]\n  Build --&gt; Logs[Cloud Logging]\n  AR --&gt; CR[Cloud Run Deployment]\n  Build --&gt; CR\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph SCM[Source Control]\n    Repo[Git Repository]\n  end\n\n  subgraph GCP[Google Cloud Project]\n    Tr[Cloud Build Trigger]\n    CB[Cloud Build]\n    WP[Private Worker Pool (optional)]\n    SM[Secret Manager]\n    AR[Artifact Registry]\n    CL[Cloud Logging]\n    CA[Cloud Audit Logs]\n    MON[Cloud Monitoring]\n    CR[Cloud Run]\n    GKE[GKE (optional)]\n  end\n\n  Repo --&gt; Tr\n  Tr --&gt; CB\n\n  CB --&gt;|default workers| CB\n  CB --&gt;|optional| WP\n\n  SM --&gt; CB\n  CB --&gt; AR\n  CB --&gt;|deploy step| CR\n  CB --&gt;|deploy step| GKE\n\n  CB --&gt; CL\n  CB --&gt; CA\n  CL --&gt; MON\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/project requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A Google Cloud account with a <strong>Google Cloud project<\/strong>.<\/li>\n<li><strong>Billing enabled<\/strong> on the project (Cloud Build usage is billable; some free tier may apply\u2014verify current terms).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>You need permissions to:\n&#8211; Enable APIs\n&#8211; Create Artifact Registry repositories\n&#8211; Deploy to Cloud Run (for the tutorial)\n&#8211; Run Cloud Build builds<\/p>\n\n\n\n<p>Common roles involved (exact least-privilege varies by org):\n&#8211; For the human user running the lab:\n  &#8211; <code>roles\/cloudbuild.builds.editor<\/code> (or a more restrictive role as appropriate)\n  &#8211; <code>roles\/artifactregistry.admin<\/code> (for repo creation) or <code>roles\/artifactregistry.writer<\/code> (if repo exists)\n  &#8211; <code>roles\/run.admin<\/code> (for Cloud Run deployment) and <code>roles\/iam.serviceAccountUser<\/code> (to allow deploying with a runtime service account)\n&#8211; For the Cloud Build service account executing the build:\n  &#8211; <code>roles\/artifactregistry.writer<\/code> (push images)\n  &#8211; <code>roles\/run.admin<\/code> and <code>roles\/iam.serviceAccountUser<\/code> (if the build performs deployment)<\/p>\n\n\n\n<p><strong>Important:<\/strong> Use least privilege. The roles above are common but may be broader than necessary.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Active billing account attached to the project.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/cloud.google.com\/sdk\/docs\/install\">Google Cloud SDK (<code>gcloud<\/code>)<\/a><\/li>\n<li>Docker is <strong>not<\/strong> required locally for Cloud Build, but helpful for local testing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Artifact Registry and Cloud Run are regional. Choose a region supported by both.<\/li>\n<li>Cloud Build private pools have regional availability constraints. <strong>Verify availability for your region in docs<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Build has quotas (concurrent builds, API requests, etc.).<\/li>\n<li>Cloud Run and Artifact Registry also have quotas.<\/li>\n<li><strong>Verify current quotas in the Cloud Console<\/strong>: IAM &amp; Admin \u2192 Quotas (or service-specific quotas pages).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services\/APIs<\/h3>\n\n\n\n<p>Enable APIs:\n&#8211; Cloud Build API\n&#8211; Artifact Registry API\n&#8211; Cloud Run Admin API\n&#8211; IAM API (commonly needed for service account operations)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Cloud Build pricing is <strong>usage-based<\/strong>. Exact SKUs, included free tier, and per-unit rates can change and may vary by region or feature. Use official sources for current values:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Official pricing page: https:\/\/cloud.google.com\/build\/pricing  <\/li>\n<li>Pricing calculator: https:\/\/cloud.google.com\/products\/calculator<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (typical)<\/h3>\n\n\n\n<p>Cloud Build costs are generally driven by:\n&#8211; <strong>Build execution time<\/strong> (e.g., build minutes) and <strong>resource class\/machine type<\/strong> used for workers (options vary).\n&#8211; <strong>Private pool costs<\/strong> (if using private worker pools), typically based on provisioned capacity\/time.\n&#8211; <strong>Storage and artifact costs<\/strong>:\n  &#8211; Artifact Registry storage and operations (push\/pull)\n  &#8211; Cloud Storage staging bucket (source uploads) and any output artifacts\n&#8211; <strong>Logging costs<\/strong> (Cloud Logging ingestion\/retention\/export beyond free allotments)\n&#8211; <strong>Network egress<\/strong>:\n  &#8211; Pulling dependencies from the internet\n  &#8211; Cross-region artifact pulls\/pushes\n  &#8211; Egress from private pools through NAT (if configured)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<p>Cloud Build has historically offered a free tier of build minutes. <strong>Do not rely on memory\u2014verify current free tier amounts and constraints on the official pricing page<\/strong>. Free tier availability may depend on build type\/region and may exclude private pools.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers (what usually makes bills grow)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>High build frequency (many commits, many repos)<\/li>\n<li>Long-running test suites<\/li>\n<li>Building large container images frequently without caching strategies<\/li>\n<li>Using higher resource classes unnecessarily<\/li>\n<li>Storing many image versions and large artifacts<\/li>\n<li>Heavy log volume (verbose builds) and long retention<\/li>\n<li>Private pool fixed\/provisioned capacity costs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Artifact Registry<\/strong>: storing hundreds of image tags and layers adds up.<\/li>\n<li><strong>Cloud Logging<\/strong>: verbose test output in every build can create large ingestion volume.<\/li>\n<li><strong>Cloud Storage<\/strong>: source staging objects and artifacts may accumulate if not lifecycle-managed.<\/li>\n<li><strong>Cloud Run\/GKE deployments<\/strong>: downstream runtime costs are separate from build costs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep Artifact Registry in the same region as the deploy target where possible.<\/li>\n<li>Be mindful of egress when builds pull dependencies from external sources repeatedly; consider dependency caching strategies (language-level caches, artifact proxies, or private registries).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Reduce build frequency with smarter triggers (avoid building on doc-only changes).<\/li>\n<li>Split CI (tests) and CD (deploy) builds; deploy only on merges\/tags.<\/li>\n<li>Use smaller base images and multi-stage Docker builds.<\/li>\n<li>Reuse dependencies (where feasible) and minimize repeated downloads.<\/li>\n<li>Set log verbosity appropriately; consider structured summaries rather than dumping entire verbose logs.<\/li>\n<li>Apply retention policies:<\/li>\n<li>Artifact Registry cleanup policies (where supported)<\/li>\n<li>Cloud Storage lifecycle rules for build staging buckets<\/li>\n<li>Logging sinks\/retention policies aligned with compliance needs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (model, not a quote)<\/h3>\n\n\n\n<p>A small team might:\n&#8211; Run a few builds per day\n&#8211; Build small images\n&#8211; Deploy occasionally<\/p>\n\n\n\n<p>Costs will typically be dominated by build minutes and artifact storage. Use the pricing calculator with:\n&#8211; Estimated builds\/day \u00d7 average build duration\n&#8211; Artifact Registry storage growth (GB-month)\n&#8211; Logging ingestion (GB\/month)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, consider:\n&#8211; Peak concurrent builds (quota + cost)\n&#8211; Private pool capacity planning\n&#8211; Multi-region artifact strategy (replication vs pull)\n&#8211; Logging\/metrics export to SIEM or data lake (additional ingestion\/storage)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab builds and deploys a real containerized application using <strong>Cloud Build<\/strong>, <strong>Artifact Registry<\/strong>, and <strong>Cloud Run<\/strong>. It is designed to be low-cost and easy to clean up.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create a small Python web app with a unit test<\/li>\n<li>Use Cloud Build to:\n  1) run tests<br\/>\n  2) build a container image<br\/>\n  3) push it to Artifact Registry<br\/>\n  4) deploy it to Cloud Run<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Set up your Google Cloud project and enable APIs.\n2. Create an Artifact Registry Docker repository.\n3. Create a Cloud Run runtime service account (least privilege baseline).\n4. Write a small app + Dockerfile + tests.\n5. Create a <code>cloudbuild.yaml<\/code> that runs tests, builds, pushes, and deploys.\n6. Run the build with <code>gcloud builds submit<\/code>.\n7. Validate the deployed service.\n8. Clean up all resources.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set variables and select a project<\/h3>\n\n\n\n<p>Choose a project you can bill to.<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud auth login\ngcloud config set project YOUR_PROJECT_ID\n\n# Choose a region supported by Cloud Run + Artifact Registry\nexport REGION=\"us-central1\"\nexport SERVICE_NAME=\"cb-hello\"\nexport REPO_NAME=\"cb-demo\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> <code>gcloud<\/code> is authenticated and targeting your project.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config get-value project\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Enable required APIs<\/h3>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable \\\n  cloudbuild.googleapis.com \\\n  artifactregistry.googleapis.com \\\n  run.googleapis.com \\\n  iam.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> APIs enabled successfully.<\/p>\n\n\n\n<p>Verify (optional):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled --filter=\"name:cloudbuild.googleapis.com\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create an Artifact Registry Docker repository<\/h3>\n\n\n\n<p>Artifact Registry is the recommended registry for container images on Google Cloud.<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts repositories create \"${REPO_NAME}\" \\\n  --repository-format=docker \\\n  --location=\"${REGION}\" \\\n  --description=\"Demo repo for Cloud Build tutorial\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> A Docker repository exists in the chosen region.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts repositories list --location=\"${REGION}\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create a Cloud Run runtime service account<\/h3>\n\n\n\n<p>This is the identity Cloud Run uses at runtime (not the build identity).<\/p>\n\n\n\n<pre><code class=\"language-bash\">export RUNTIME_SA_NAME=\"cr-runtime-sa\"\nexport RUNTIME_SA=\"${RUNTIME_SA_NAME}@$(gcloud config get-value project).iam.gserviceaccount.com\"\n\ngcloud iam service-accounts create \"${RUNTIME_SA_NAME}\" \\\n  --description=\"Runtime SA for Cloud Run service deployed by Cloud Build\" \\\n  --display-name=\"Cloud Run runtime SA (Cloud Build demo)\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> A service account exists.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud iam service-accounts describe \"${RUNTIME_SA}\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Grant Cloud Build permissions to push and deploy<\/h3>\n\n\n\n<p>Cloud Build runs builds using a service account. By default, many projects use:\n&#8211; <code>PROJECT_NUMBER@cloudbuild.gserviceaccount.com<\/code><\/p>\n\n\n\n<p>Get your project number:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export PROJECT_NUMBER=\"$(gcloud projects describe $(gcloud config get-value project) --format='value(projectNumber)')\"\nexport CB_SA=\"${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com\"\necho \"${CB_SA}\"\n<\/code><\/pre>\n\n\n\n<p>Grant the Cloud Build service account permissions:\n&#8211; Push images to Artifact Registry\n&#8211; Deploy to Cloud Run\n&#8211; Act as (impersonate) the runtime service account during deployment<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud projects add-iam-policy-binding \"$(gcloud config get-value project)\" \\\n  --member=\"serviceAccount:${CB_SA}\" \\\n  --role=\"roles\/artifactregistry.writer\"\n\ngcloud projects add-iam-policy-binding \"$(gcloud config get-value project)\" \\\n  --member=\"serviceAccount:${CB_SA}\" \\\n  --role=\"roles\/run.admin\"\n\ngcloud iam service-accounts add-iam-policy-binding \"${RUNTIME_SA}\" \\\n  --member=\"serviceAccount:${CB_SA}\" \\\n  --role=\"roles\/iam.serviceAccountUser\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Cloud Build can push images and deploy to Cloud Run using the runtime SA.<\/p>\n\n\n\n<p>Verification tip: If deployment fails later with permission errors, re-check these bindings.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Create a sample Python app with a unit test<\/h3>\n\n\n\n<p>Create a working directory and files:<\/p>\n\n\n\n<pre><code class=\"language-bash\">mkdir cloudbuild-demo &amp;&amp; cd cloudbuild-demo\n<\/code><\/pre>\n\n\n\n<p>Create <code>app.py<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; app.py &lt;&lt;'EOF'\nfrom flask import Flask\n\napp = Flask(__name__)\n\n@app.get(\"\/\")\ndef hello():\n    return \"Hello from Cloud Build on Google Cloud!\\n\"\n\nif __name__ == \"__main__\":\n    # Cloud Run sets PORT environment variable\n    import os\n    port = int(os.environ.get(\"PORT\", \"8080\"))\n    app.run(host=\"0.0.0.0\", port=port)\nEOF\n<\/code><\/pre>\n\n\n\n<p>Create <code>requirements.txt<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; requirements.txt &lt;&lt;'EOF'\nFlask==3.0.3\ngunicorn==22.0.0\nEOF\n<\/code><\/pre>\n\n\n\n<p>Create a minimal test <code>test_app.py<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; test_app.py &lt;&lt;'EOF'\nfrom app import app\n\ndef test_root_returns_expected_message():\n    client = app.test_client()\n    resp = client.get(\"\/\")\n    assert resp.status_code == 200\n    assert b\"Hello from Cloud Build\" in resp.data\nEOF\n<\/code><\/pre>\n\n\n\n<p>Create <code>Dockerfile<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; Dockerfile &lt;&lt;'EOF'\nFROM python:3.12-slim\n\nWORKDIR \/app\nCOPY requirements.txt .\nRUN pip install --no-cache-dir -r requirements.txt\n\nCOPY app.py .\nENV PORT=8080\n\n# Use gunicorn for production web serving\nCMD [\"gunicorn\", \"-b\", \":8080\", \"app:app\"]\nEOF\n<\/code><\/pre>\n\n\n\n<p>Create <code>pytest<\/code> dependency just for CI testing by adding a <code>requirements-dev.txt<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; requirements-dev.txt &lt;&lt;'EOF'\npytest==8.3.2\nEOF\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have a small app + Dockerfile + test.<\/p>\n\n\n\n<p>Optional local test (if you have Python locally):<\/p>\n\n\n\n<pre><code class=\"language-bash\">python -m venv .venv &amp;&amp; source .venv\/bin\/activate\npip install -r requirements.txt -r requirements-dev.txt\npytest -q\ndeactivate\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Create a Cloud Build config (<code>cloudbuild.yaml<\/code>)<\/h3>\n\n\n\n<p>This build:\n1. Runs unit tests (inside a Python container)\n2. Builds a Docker image\n3. Pushes it to Artifact Registry\n4. Deploys to Cloud Run<\/p>\n\n\n\n<p>Create <code>cloudbuild.yaml<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; cloudbuild.yaml &lt;&lt;'EOF'\nsubstitutions:\n  _REGION: \"us-central1\"\n  _REPO: \"cb-demo\"\n  _SERVICE: \"cb-hello\"\n  _RUNTIME_SA: \"cr-runtime-sa@PROJECT_ID.iam.gserviceaccount.com\"\n\nsteps:\n  # 1) Run unit tests\n  - name: \"python:3.12-slim\"\n    entrypoint: \"bash\"\n    args:\n      - \"-c\"\n      - |\n        pip install --no-cache-dir -r requirements.txt -r requirements-dev.txt\n        pytest -q\n\n  # 2) Build container image\n  - name: \"gcr.io\/cloud-builders\/docker\"\n    args:\n      - \"build\"\n      - \"-t\"\n      - \"${_REGION}-docker.pkg.dev\/$PROJECT_ID\/${_REPO}\/${_SERVICE}:$SHORT_SHA\"\n      - \".\"\n\n  # 3) Push container image to Artifact Registry\n  - name: \"gcr.io\/cloud-builders\/docker\"\n    args:\n      - \"push\"\n      - \"${_REGION}-docker.pkg.dev\/$PROJECT_ID\/${_REPO}\/${_SERVICE}:$SHORT_SHA\"\n\n  # 4) Deploy to Cloud Run\n  - name: \"gcr.io\/google.com\/cloudsdktool\/cloud-sdk:slim\"\n    entrypoint: \"gcloud\"\n    args:\n      - \"run\"\n      - \"deploy\"\n      - \"${_SERVICE}\"\n      - \"--image\"\n      - \"${_REGION}-docker.pkg.dev\/$PROJECT_ID\/${_REPO}\/${_SERVICE}:$SHORT_SHA\"\n      - \"--region\"\n      - \"${_REGION}\"\n      - \"--service-account\"\n      - \"${_RUNTIME_SA}\"\n      - \"--allow-unauthenticated\"\n      - \"--quiet\"\n\nimages:\n  - \"${_REGION}-docker.pkg.dev\/$PROJECT_ID\/${_REPO}\/${_SERVICE}:$SHORT_SHA\"\nEOF\n<\/code><\/pre>\n\n\n\n<p>Now replace the placeholder <code>PROJECT_ID<\/code> inside <code>_RUNTIME_SA<\/code> with your actual project ID:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sed -i.bak \"s\/PROJECT_ID\/$(gcloud config get-value project)\/g\" cloudbuild.yaml\nrm -f cloudbuild.yaml.bak\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> <code>cloudbuild.yaml<\/code> exists and references your project correctly.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat cloudbuild.yaml\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Run the build with Cloud Build<\/h3>\n\n\n\n<p>Submit the build context (current directory) to Cloud Build:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud builds submit --config cloudbuild.yaml .\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong>\n&#8211; Build runs tests\n&#8211; Builds and pushes image to Artifact Registry\n&#8211; Deploys a new Cloud Run service revision\n&#8211; Command prints a build ID and logs URL<\/p>\n\n\n\n<p>Verify build status:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud builds list --limit=5\n<\/code><\/pre>\n\n\n\n<p>View logs for the most recent build (replace BUILD_ID):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud builds log BUILD_ID\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 9: Validate the deployment<\/h3>\n\n\n\n<p>Get the Cloud Run service URL:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud run services describe \"${SERVICE_NAME}\" \\\n  --region \"${REGION}\" \\\n  --format=\"value(status.url)\"\n<\/code><\/pre>\n\n\n\n<p>Then curl it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -s \"$(gcloud run services describe \"${SERVICE_NAME}\" --region \"${REGION}\" --format=\"value(status.url)\")\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You see:\n&#8211; <code>Hello from Cloud Build on Google Cloud!<\/code><\/p>\n\n\n\n<p>Also verify the image exists in Artifact Registry:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts docker images list \"${REGION}-docker.pkg.dev\/$(gcloud config get-value project)\/${REPO_NAME}\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>You have successfully validated if:\n&#8211; Cloud Build shows a <strong>SUCCESS<\/strong> build.\n&#8211; Artifact Registry contains an image tagged with the commit short SHA.\n&#8211; Cloud Run serves the expected response at the service URL.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and fixes:<\/p>\n\n\n\n<p>1) <strong><code>PERMISSION_DENIED<\/code> during push to Artifact Registry<\/strong>\n&#8211; Ensure Cloud Build SA has <code>roles\/artifactregistry.writer<\/code>.\n&#8211; Confirm you are pushing to the correct repository path and region.<\/p>\n\n\n\n<p>2) <strong><code>PERMISSION_DENIED<\/code> during <code>gcloud run deploy<\/code><\/strong>\n&#8211; Ensure Cloud Build SA has <code>roles\/run.admin<\/code>.\n&#8211; Ensure Cloud Build SA has <code>roles\/iam.serviceAccountUser<\/code> on the runtime service account.\n&#8211; Confirm Cloud Run API is enabled.<\/p>\n\n\n\n<p>3) <strong>Build fails running tests (pip\/pytest issues)<\/strong>\n&#8211; Check that <code>requirements-dev.txt<\/code> is included in the build context.\n&#8211; Confirm dependencies are pinned to compatible versions.\n&#8211; Review the test output in Cloud Logging.<\/p>\n\n\n\n<p>4) <strong>Cloud Run deploy succeeds but service returns 500<\/strong>\n&#8211; Confirm <code>Dockerfile<\/code> starts the app correctly.\n&#8211; Check Cloud Run logs:\n  <code>bash\n  gcloud logs read --region=\"${REGION}\" --project=\"$(gcloud config get-value project)\" \\\n    --limit=50 --format=\"value(textPayload)\" \\\n    'resource.type=\"cloud_run_revision\"'<\/code>\n  (Log query patterns vary; use Cloud Console Logs Explorer for best results.)<\/p>\n\n\n\n<p>5) <strong><code>gcloud builds submit<\/code> is slow<\/strong>\n&#8211; Build context might include large files. Add a <code>.gcloudignore<\/code> (or <code>.gitignore<\/code>) to exclude <code>node_modules<\/code>, <code>.venv<\/code>, test artifacts, etc.<\/p>\n\n\n\n<p>Create <code>.gcloudignore<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; .gcloudignore &lt;&lt;'EOF'\n.gcloudignore\n.git\n.gitignore\n**\/__pycache__\/\n.venv\/\nEOF\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing costs, delete the resources you created:<\/p>\n\n\n\n<p>1) Delete Cloud Run service:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud run services delete \"${SERVICE_NAME}\" --region \"${REGION}\" --quiet\n<\/code><\/pre>\n\n\n\n<p>2) Delete Artifact Registry repository (deletes contained images):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts repositories delete \"${REPO_NAME}\" --location \"${REGION}\" --quiet\n<\/code><\/pre>\n\n\n\n<p>3) Delete runtime service account:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud iam service-accounts delete \"${RUNTIME_SA}\" --quiet\n<\/code><\/pre>\n\n\n\n<p>4) (Optional) Remove IAM bindings you added for Cloud Build SA:\n&#8211; If this is a dedicated lab project, you might delete the project instead.\n&#8211; Otherwise, remove bindings carefully using <code>gcloud projects remove-iam-policy-binding<\/code> and <code>gcloud iam service-accounts remove-iam-policy-binding<\/code>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Separate CI and CD concerns<\/strong>:<\/li>\n<li>CI build: compile\/test\/build image, push to Artifact Registry with immutable tags (e.g., commit SHA).<\/li>\n<li>CD deploy: promote a previously built artifact to environments.<\/li>\n<li><strong>Use Artifact Registry as the source of truth<\/strong> for images\/packages.<\/li>\n<li><strong>Design for reproducibility<\/strong>:<\/li>\n<li>Pin builder image versions (or digests) for critical pipelines.<\/li>\n<li>Pin language dependencies (lockfiles).<\/li>\n<li><strong>Prefer immutable tagging<\/strong> (<code>:sha<\/code>) and optionally add mutable tags (<code>:main<\/code>, <code>:release<\/code>) for convenience.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Use least privilege<\/strong> for the Cloud Build service account:<\/li>\n<li>Separate \u201cbuild-only\u201d from \u201cdeploy\u201d builds.<\/li>\n<li>For deployments, scope permissions to only required services\/regions\/projects.<\/li>\n<li><strong>Use dedicated service accounts per pipeline<\/strong> where practical (especially in regulated environments).<\/li>\n<li><strong>Restrict who can create\/edit triggers<\/strong>, since triggers can become a path to privilege escalation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Minimize unnecessary triggers (skip builds on docs-only changes).<\/li>\n<li>Use smaller images and multi-stage builds.<\/li>\n<li>Apply retention and cleanup policies in Artifact Registry.<\/li>\n<li>Control logging verbosity; export only what you need.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Run independent steps in parallel when possible (carefully manage dependencies).<\/li>\n<li>Avoid downloading the world on every build; optimize dependency installation steps.<\/li>\n<li>Keep build context small with <code>.gcloudignore<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Add explicit timeouts appropriate to your workload.<\/li>\n<li>Fail fast: run lint\/unit tests before expensive image builds.<\/li>\n<li>Use deterministic dependencies and consistent tool versions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standardize build config templates across teams.<\/li>\n<li>Use labels\/tags and naming conventions for triggers and repositories.<\/li>\n<li>Create dashboards\/alerts for build failure rates (via log-based metrics).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Name triggers by repo + branch + purpose (e.g., <code>svc-a-main-ci<\/code>, <code>svc-a-release<\/code>).<\/li>\n<li>Label resources (Artifact Registry repositories, Cloud Run services) by <code>env<\/code>, <code>owner<\/code>, <code>cost-center<\/code>.<\/li>\n<li>Store build configs in the repo to keep changes code-reviewed.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Build invoker permissions<\/strong>: control who can start builds or run triggers.<\/li>\n<li><strong>Build runtime identity<\/strong>: the service account used by Cloud Build to call Google Cloud APIs.<\/li>\n<li><strong>Runtime identity<\/strong>: for deployed services (e.g., Cloud Run runtime service account).<\/li>\n<\/ul>\n\n\n\n<p><strong>Recommendation:<\/strong> Separate these identities and minimize privileges at each layer.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data in transit uses TLS.<\/li>\n<li>Artifacts in Artifact Registry and objects in Cloud Storage are encrypted at rest by default (Google-managed keys by default).<\/li>\n<li>If you require customer-managed encryption keys (CMEK), check service support and configure accordingly. <strong>Verify CMEK support and configuration per service in official docs.<\/strong><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Default builds may access the public internet for dependency downloads.<\/li>\n<li>For restricted environments:<\/li>\n<li>Use <strong>private worker pools<\/strong> in a VPC<\/li>\n<li>Use controlled egress (NAT\/proxy) and firewall rules<\/li>\n<li>Prefer private endpoints for dependencies where feasible<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<p>Common secure patterns:\n&#8211; Use <strong>Secret Manager<\/strong> and inject secrets at build time (avoid committing secrets in repo).\n&#8211; Avoid printing secrets to logs.\n&#8211; Prefer short-lived credentials and workload identity patterns where applicable.<\/p>\n\n\n\n<p><strong>Common mistake:<\/strong> Putting secrets in <code>cloudbuild.yaml<\/code> substitutions or environment variables that end up in logs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use Cloud Audit Logs to track:<\/li>\n<li>Trigger creation\/changes<\/li>\n<li>Build invocations<\/li>\n<li>IAM changes related to build service accounts<\/li>\n<li>Export logs to a centralized security project\/SIEM if required.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep build logs and artifacts retention aligned with policy.<\/li>\n<li>For regulated workloads:<\/li>\n<li>Use private pools<\/li>\n<li>Restrict IAM tightly<\/li>\n<li>Consider provenance\/attestation patterns<\/li>\n<li>Segment projects per environment (dev\/stage\/prod)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Giving Cloud Build SA <code>Owner<\/code> or broad admin roles.<\/li>\n<li>Allowing anyone in the org to edit triggers in prod projects.<\/li>\n<li>Running untrusted code (e.g., PRs from forks) with credentials that can deploy or access secrets.<\/li>\n<li>Not pinning builder versions (supply chain drift).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use separate pipelines:<\/li>\n<li>PR validation: no deploy permissions, no prod secrets<\/li>\n<li>Release pipeline: restricted access, controlled promotion<\/li>\n<li>Apply policy controls (IAM + org policy where applicable).<\/li>\n<li>If using attestations\/provenance and policy enforcement, ensure the enforcement happens at deploy time (e.g., admission controls). <strong>Verify exact Google Cloud products and setup for enforcement in your environment.<\/strong><\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Cloud Build is highly capable, but there are practical boundaries. Always verify current quotas and limits in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations \/ operational constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Quotas on concurrent builds<\/strong> and API usage can block bursts.<\/li>\n<li><strong>Build timeouts<\/strong> exist and must be configured for long-running jobs (exact defaults\/max: verify in docs).<\/li>\n<li>Large build contexts slow down <code>gcloud builds submit<\/code> because it uploads your directory to Cloud Storage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Artifact Registry repositories are regional.<\/li>\n<li>Cloud Run services are regional.<\/li>\n<li>Private worker pools are region-bound and depend on VPC network design.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Artifact Registry storage growth from many image tags.<\/li>\n<li>Cloud Logging ingestion from verbose builds.<\/li>\n<li>Private pool capacity cost even when idle (depending on configuration and billing model\u2014verify on pricing page).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Some build tools expect privileged access (e.g., certain Docker-in-Docker patterns). Cloud Build supports common Docker workflows via builders, but edge cases may require adjusted build strategies.<\/li>\n<li>If using custom builders, ensure they\u2019re compatible with Cloud Build\u2019s execution environment and authentication patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Triggers can be a security boundary:<\/strong> A trigger that runs on untrusted code can exfiltrate secrets if secrets are accessible.<\/li>\n<li><strong>Using \u201clatest\u201d tags<\/strong> for builder images can break builds unexpectedly.<\/li>\n<li><strong>Staging buckets<\/strong> used for source uploads can accumulate objects if not lifecycle-managed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Migrating from Jenkins\/GitHub Actions often requires:<\/li>\n<li>Replacing plugin behavior with explicit steps<\/li>\n<li>Reworking secrets handling<\/li>\n<li>Redesigning caching strategies<\/li>\n<li>Adjusting IAM (service accounts vs runner credentials)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Build steps are container executions; think \u201ccontainerized tasks,\u201d not \u201cshell on a VM\u201d.<\/li>\n<li>Deployment steps that call <code>gcloud<\/code> must run in an image that contains <code>gcloud<\/code> and must have IAM permissions via the build service account.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Cloud Build is primarily a managed build runner. Depending on your needs, you might combine it with other tools for end-to-end CI\/CD.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Google Cloud Build<\/strong><\/td>\n<td>Google Cloud-native CI, image builds, Artifact Registry workflows<\/td>\n<td>Managed scaling, IAM integration, strong Google Cloud ecosystem fit<\/td>\n<td>SCM integration choices can be confusing; advanced CD often needs additional tooling<\/td>\n<td>You deploy primarily on Google Cloud and want managed CI<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Cloud Deploy<\/strong><\/td>\n<td>Progressive delivery\/promotion to GKE\/Cloud Run<\/td>\n<td>Deployment orchestration, promotion stages, governance<\/td>\n<td>Not a build system; you still need artifact builds<\/td>\n<td>You already build artifacts and need controlled promotion<\/td>\n<\/tr>\n<tr>\n<td><strong>GitHub Actions<\/strong><\/td>\n<td>Repo-centric CI\/CD with marketplace ecosystem<\/td>\n<td>Tight GitHub integration, many actions<\/td>\n<td>Runner management for self-hosted; cloud permissions setup required<\/td>\n<td>Your repos are on GitHub and you want CI\/CD close to code<\/td>\n<\/tr>\n<tr>\n<td><strong>GitLab CI<\/strong><\/td>\n<td>Integrated SCM + CI\/CD + security scanning<\/td>\n<td>Strong end-to-end platform<\/td>\n<td>Can require runner management; SaaS vs self-managed tradeoffs<\/td>\n<td>Your org standardizes on GitLab<\/td>\n<\/tr>\n<tr>\n<td><strong>Jenkins (self-managed)<\/strong><\/td>\n<td>Highly customizable CI\/CD, legacy pipelines<\/td>\n<td>Ultimate flexibility; huge plugin ecosystem<\/td>\n<td>Operational overhead, scaling, security maintenance<\/td>\n<td>You need deep customization and accept ops burden<\/td>\n<\/tr>\n<tr>\n<td><strong>Tekton (self-managed\/on Kubernetes)<\/strong><\/td>\n<td>Kubernetes-native pipelines<\/td>\n<td>Cloud-native pipeline primitives, portable<\/td>\n<td>Requires K8s ops, more setup<\/td>\n<td>You want Kubernetes-native CI and portability<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS CodeBuild<\/strong><\/td>\n<td>AWS-native build service<\/td>\n<td>Tight AWS integration<\/td>\n<td>Not Google Cloud-native<\/td>\n<td>Your primary platform is AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Pipelines<\/strong><\/td>\n<td>Azure-native CI\/CD<\/td>\n<td>Integrates with Azure DevOps<\/td>\n<td>Not Google Cloud-native<\/td>\n<td>Your primary platform is Azure<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example (regulated environment)<\/h3>\n\n\n\n<p><strong>Problem:<\/strong> A bank needs to build container images for microservices with strict audit, controlled egress, and separation between dev\/stage\/prod. Builds must access private artifact repositories and internal APIs not exposed publicly.<\/p>\n\n\n\n<p><strong>Proposed architecture:<\/strong>\n&#8211; Use Cloud Build with <strong>private worker pools<\/strong> attached to a controlled VPC.\n&#8211; Source repos in enterprise SCM (connected via a supported integration; verify current best practice).\n&#8211; Build pipeline:\n  &#8211; Run tests\n  &#8211; Build container images\n  &#8211; Push to regional Artifact Registry\n  &#8211; Emit build metadata and logs to centralized logging project via sinks\n&#8211; Promotion\/deploy:\n  &#8211; Use a separate controlled deployment process (often Cloud Deploy or an internal deploy system).\n&#8211; Security controls:\n  &#8211; Dedicated service accounts per pipeline with least privilege\n  &#8211; Secrets in Secret Manager\n  &#8211; Firewall + NAT\/proxy for controlled egress\n  &#8211; Audit logs exported to SIEM<\/p>\n\n\n\n<p><strong>Why Cloud Build was chosen:<\/strong>\n&#8211; Managed scaling and strong IAM\/audit integration on Google Cloud\n&#8211; Private pool capability for VPC-only access\n&#8211; Artifact Registry integration and centralized build history<\/p>\n\n\n\n<p><strong>Expected outcomes:<\/strong>\n&#8211; Reduced build infrastructure maintenance\n&#8211; Improved traceability and auditability\n&#8211; More consistent builds across teams<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example (fast iteration)<\/h3>\n\n\n\n<p><strong>Problem:<\/strong> A small SaaS team wants simple CI to build and deploy a containerized API to Cloud Run on every merge to <code>main<\/code>.<\/p>\n\n\n\n<p><strong>Proposed architecture:<\/strong>\n&#8211; Cloud Build trigger on <code>main<\/code>\n&#8211; Steps: tests \u2192 build \u2192 push \u2192 deploy to Cloud Run\n&#8211; Artifact Registry for images\n&#8211; Minimal IAM and one runtime service account<\/p>\n\n\n\n<p><strong>Why Cloud Build was chosen:<\/strong>\n&#8211; Minimal setup and no runner management\n&#8211; Works well with Cloud Run and Artifact Registry\n&#8211; Pay-per-use economics (plus any free tier) suitable for small teams<\/p>\n\n\n\n<p><strong>Expected outcomes:<\/strong>\n&#8211; Faster releases with consistent deployment process\n&#8211; Lower operational load versus self-hosted CI<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Cloud Build a CI tool or a CD tool?<\/strong><br\/>\nCloud Build is primarily a <strong>build\/CI execution engine<\/strong>. It can perform deployments by running deployment commands as steps, but many teams pair it with a deployment orchestrator (e.g., Cloud Deploy) for controlled promotions.<\/p>\n\n\n\n<p>2) <strong>What does a Cloud Build \u201cstep\u201d run on?<\/strong><br\/>\nA step runs inside a <strong>container image<\/strong> (a builder). Steps execute on Google-managed build workers by default, or on private worker pools if configured.<\/p>\n\n\n\n<p>3) <strong>Do I need Docker installed locally to use Cloud Build?<\/strong><br\/>\nNo. You can submit source to Cloud Build and let it run Docker builds. Docker is only needed locally if you want to test locally.<\/p>\n\n\n\n<p>4) <strong>Where do Cloud Build logs go?<\/strong><br\/>\nTypically to <strong>Cloud Logging<\/strong> and the Cloud Build build history. Exact log behavior can be configured; verify in docs for advanced setups.<\/p>\n\n\n\n<p>5) <strong>How does Cloud Build access Google Cloud resources securely?<\/strong><br\/>\nThrough IAM using the <strong>Cloud Build service account<\/strong> (default or specified). Grant only the roles required for the build.<\/p>\n\n\n\n<p>6) <strong>Can Cloud Build build non-container artifacts?<\/strong><br\/>\nYes. Steps can compile binaries or build packages and upload them to Cloud Storage or other destinations.<\/p>\n\n\n\n<p>7) <strong>What\u2019s the difference between Artifact Registry and Container Registry?<\/strong><br\/>\nArtifact Registry is the recommended, current service for container images and other artifact types. Container Registry is legacy; verify current migration guidance in official docs.<\/p>\n\n\n\n<p>8) <strong>How do I avoid deploying from untrusted pull requests?<\/strong><br\/>\nUse separate triggers\/pipelines. PR validation should run with restricted permissions and no production secrets. Deployment should only happen on trusted branches\/tags with restricted access.<\/p>\n\n\n\n<p>9) <strong>Can Cloud Build run builds inside my VPC?<\/strong><br\/>\nYes, using <strong>private worker pools<\/strong> (private pools). This is common for private dependencies and controlled egress.<\/p>\n\n\n\n<p>10) <strong>How do I store secrets for builds?<\/strong><br\/>\nUse <strong>Secret Manager<\/strong> and inject secrets at build time. Avoid hardcoding secrets in <code>cloudbuild.yaml<\/code> or source.<\/p>\n\n\n\n<p>11) <strong>Does Cloud Build support parallel steps?<\/strong><br\/>\nYes, by defining step dependencies (e.g., using <code>waitFor<\/code>). Design carefully to avoid race conditions and ensure artifacts are available when needed.<\/p>\n\n\n\n<p>12) <strong>How do I tag images for traceability?<\/strong><br\/>\nUse immutable tags like commit SHA (<code>$SHORT_SHA<\/code>) and optionally add release tags (semantic versions) during release builds.<\/p>\n\n\n\n<p>13) <strong>Can Cloud Build deploy to GKE?<\/strong><br\/>\nYes. A build step can run <code>kubectl<\/code>, <code>helm<\/code>, or other deployment tooling, as long as networking and IAM are configured correctly.<\/p>\n\n\n\n<p>14) <strong>How do I control build costs?<\/strong><br\/>\nReduce unnecessary builds, shorten build duration, right-size worker types, manage artifact retention, and control log volume. Use the Cloud Build pricing page and calculator for estimates.<\/p>\n\n\n\n<p>15) <strong>What\u2019s a good pipeline structure for production?<\/strong><br\/>\nA common pattern:<br\/>\n&#8211; PR: lint + unit tests (no deploy)<br\/>\n&#8211; Main: build + push artifact<br\/>\n&#8211; Release: promote\/deploy artifact with approvals and policy checks<\/p>\n\n\n\n<p>16) <strong>Can I centralize builds for multiple projects?<\/strong><br\/>\nYes, but it requires careful IAM design and sometimes cross-project impersonation patterns. Verify recommended reference architectures and security guidance for your organization.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Cloud Build<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Cloud Build docs: https:\/\/cloud.google.com\/build\/docs<\/td>\n<td>Canonical reference for concepts, APIs, configs, and best practices<\/td>\n<\/tr>\n<tr>\n<td>Official pricing page<\/td>\n<td>Cloud Build pricing: https:\/\/cloud.google.com\/build\/pricing<\/td>\n<td>Current SKUs, free tier, and pricing dimensions<\/td>\n<\/tr>\n<tr>\n<td>Pricing calculator<\/td>\n<td>Google Cloud Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Build realistic estimates for build minutes, logging, storage, and registry<\/td>\n<\/tr>\n<tr>\n<td>Official quickstart<\/td>\n<td>Cloud Build quickstarts (start here): https:\/\/cloud.google.com\/build\/docs\/quickstarts<\/td>\n<td>Step-by-step getting started guides maintained by Google<\/td>\n<\/tr>\n<tr>\n<td>Artifact Registry docs<\/td>\n<td>Artifact Registry: https:\/\/cloud.google.com\/artifact-registry\/docs<\/td>\n<td>Best practices for storing and managing container images and packages<\/td>\n<\/tr>\n<tr>\n<td>Cloud Run docs<\/td>\n<td>Cloud Run: https:\/\/cloud.google.com\/run\/docs<\/td>\n<td>Deployment target frequently used with Cloud Build<\/td>\n<\/tr>\n<tr>\n<td>IAM docs<\/td>\n<td>IAM overview: https:\/\/cloud.google.com\/iam\/docs\/overview<\/td>\n<td>How to design least-privilege roles for build and deploy<\/td>\n<\/tr>\n<tr>\n<td>Skills\/labs<\/td>\n<td>Google Cloud Skills Boost: https:\/\/www.cloudskillsboost.google<\/td>\n<td>Hands-on labs (search for \u201cCloud Build\u201d labs)<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>Google Cloud Architecture Center: https:\/\/cloud.google.com\/architecture<\/td>\n<td>Reference architectures for CI\/CD, security, and platform engineering<\/td>\n<\/tr>\n<tr>\n<td>Official samples (GitHub)<\/td>\n<td>GoogleCloudPlatform GitHub org: https:\/\/github.com\/GoogleCloudPlatform<\/td>\n<td>Many official samples; search within for Cloud Build examples<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<p>The following training providers are listed as requested; verify course availability, syllabus, and delivery mode on their websites.<\/p>\n\n\n\n<p>1) <strong>DevOpsSchool.com<\/strong><br\/>\n&#8211; <strong>Suitable audience:<\/strong> DevOps engineers, SREs, developers, platform teams<br\/>\n&#8211; <strong>Likely learning focus:<\/strong> CI\/CD, DevOps tooling, cloud DevOps practices (including Google Cloud)<br\/>\n&#8211; <strong>Mode:<\/strong> Check website<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.devopsschool.com\/<\/p>\n\n\n\n<p>2) <strong>ScmGalaxy.com<\/strong><br\/>\n&#8211; <strong>Suitable audience:<\/strong> Beginners to intermediate DevOps learners<br\/>\n&#8211; <strong>Likely learning focus:<\/strong> SCM, CI\/CD concepts, DevOps fundamentals and tooling<br\/>\n&#8211; <strong>Mode:<\/strong> Check website<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.scmgalaxy.com\/<\/p>\n\n\n\n<p>3) <strong>CLoudOpsNow.in<\/strong><br\/>\n&#8211; <strong>Suitable audience:<\/strong> Cloud operations and DevOps practitioners<br\/>\n&#8211; <strong>Likely learning focus:<\/strong> Cloud operations, automation, DevOps\/CloudOps practices<br\/>\n&#8211; <strong>Mode:<\/strong> Check website<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.cloudopsnow.in\/<\/p>\n\n\n\n<p>4) <strong>SreSchool.com<\/strong><br\/>\n&#8211; <strong>Suitable audience:<\/strong> SREs, reliability engineers, operations teams<br\/>\n&#8211; <strong>Likely learning focus:<\/strong> SRE practices, reliability engineering, observability, incident response<br\/>\n&#8211; <strong>Mode:<\/strong> Check website<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.sreschool.com\/<\/p>\n\n\n\n<p>5) <strong>AiOpsSchool.com<\/strong><br\/>\n&#8211; <strong>Suitable audience:<\/strong> Operations teams exploring AIOps concepts<br\/>\n&#8211; <strong>Likely learning focus:<\/strong> AIOps, monitoring\/automation practices, operations analytics<br\/>\n&#8211; <strong>Mode:<\/strong> Check website<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.aiopsschool.com\/<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<p>These are listed as training resources\/platforms as requested. Verify current offerings and credentials directly on each site.<\/p>\n\n\n\n<p>1) <strong>RajeshKumar.xyz<\/strong><br\/>\n&#8211; <strong>Likely specialization:<\/strong> DevOps\/Cloud training content (verify current topics)<br\/>\n&#8211; <strong>Suitable audience:<\/strong> DevOps learners and practitioners<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/rajeshkumar.xyz\/<\/p>\n\n\n\n<p>2) <strong>devopstrainer.in<\/strong><br\/>\n&#8211; <strong>Likely specialization:<\/strong> DevOps training programs (verify syllabus)<br\/>\n&#8211; <strong>Suitable audience:<\/strong> Beginners to working DevOps engineers<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.devopstrainer.in\/<\/p>\n\n\n\n<p>3) <strong>devopsfreelancer.com<\/strong><br\/>\n&#8211; <strong>Likely specialization:<\/strong> DevOps consulting\/training resources (verify services offered)<br\/>\n&#8211; <strong>Suitable audience:<\/strong> Teams\/individuals looking for DevOps help<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.devopsfreelancer.com\/<\/p>\n\n\n\n<p>4) <strong>devopssupport.in<\/strong><br\/>\n&#8211; <strong>Likely specialization:<\/strong> DevOps support and training resources (verify offerings)<br\/>\n&#8211; <strong>Suitable audience:<\/strong> Operations\/DevOps teams needing hands-on support<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.devopssupport.in\/<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<p>Listed neutrally and factually as requested; verify capabilities and references directly with each firm.<\/p>\n\n\n\n<p>1) <strong>cotocus.com<\/strong><br\/>\n&#8211; <strong>Likely service area:<\/strong> Cloud\/DevOps consulting (verify exact offerings)<br\/>\n&#8211; <strong>Where they may help:<\/strong> CI\/CD implementation, cloud architecture, migration planning<br\/>\n&#8211; <strong>Consulting use case examples:<\/strong><br\/>\n  &#8211; Designing Cloud Build pipelines and IAM model<br\/>\n  &#8211; Artifact Registry and Cloud Run deployment automation<br\/>\n  &#8211; Standardizing build templates across teams<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/cotocus.com\/<\/p>\n\n\n\n<p>2) <strong>DevOpsSchool.com<\/strong><br\/>\n&#8211; <strong>Likely service area:<\/strong> DevOps consulting and enablement (verify exact offerings)<br\/>\n&#8211; <strong>Where they may help:<\/strong> CI\/CD platform setup, DevOps transformation, training + implementation<br\/>\n&#8211; <strong>Consulting use case examples:<\/strong><br\/>\n  &#8211; Building organization-wide Cloud Build standards<br\/>\n  &#8211; Implementing secure deployment workflows to Cloud Run\/GKE<br\/>\n  &#8211; Governance, logging, and cost controls for build platforms<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.devopsschool.com\/<\/p>\n\n\n\n<p>3) <strong>DEVOPSCONSULTING.IN<\/strong><br\/>\n&#8211; <strong>Likely service area:<\/strong> DevOps consulting services (verify exact offerings)<br\/>\n&#8211; <strong>Where they may help:<\/strong> CI\/CD pipeline modernization, automation, operational best practices<br\/>\n&#8211; <strong>Consulting use case examples:<\/strong><br\/>\n  &#8211; Migrating from Jenkins to Cloud Build<br\/>\n  &#8211; Implementing private worker pools for restricted networking<br\/>\n  &#8211; Hardening IAM and secrets management for build pipelines<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.devopsconsulting.in\/<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Cloud Build<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Git fundamentals (branches, PRs, tags)<\/li>\n<li>CI\/CD concepts (pipelines, artifacts, environments)<\/li>\n<li>Containers and Docker basics (Dockerfile, layers, tags)<\/li>\n<li>Google Cloud basics:<\/li>\n<li>Projects, IAM, service accounts<\/li>\n<li>Artifact Registry fundamentals<\/li>\n<li>Cloud Logging basics<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Cloud Build<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Deployment orchestration:<\/li>\n<li>Cloud Run release strategies<\/li>\n<li>Cloud Deploy (for staged promotion)<\/li>\n<li>Security for supply chain:<\/li>\n<li>Provenance concepts, artifact signing\/attestation patterns (verify current Google Cloud toolchain)<\/li>\n<li>Vulnerability scanning workflows (Artifact Registry scanning and\/or external scanners)<\/li>\n<li>Platform engineering:<\/li>\n<li>Standard pipeline templates<\/li>\n<li>Policy-as-code and guardrails<\/li>\n<li>Observability:<\/li>\n<li>Log-based metrics for build failure rates<\/li>\n<li>SLOs for deployment frequency and MTTR<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Platform Engineer \/ Build &amp; Release Engineer<\/li>\n<li>Cloud Engineer \/ Solutions Engineer<\/li>\n<li>Application developer working in cloud-native environments<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud certifications don\u2019t certify \u201cCloud Build only,\u201d but Cloud Build knowledge is useful for:<\/li>\n<li>Associate Cloud Engineer<\/li>\n<li>Professional Cloud DevOps Engineer<\/li>\n<li>Professional Cloud Developer<br\/>\nVerify current certification titles and exam guides: https:\/\/cloud.google.com\/learn\/certification<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Add a PR validation pipeline that runs unit tests and lints only.<\/li>\n<li>Build multiple services from a monorepo and push images with consistent tags.<\/li>\n<li>Implement a \u201crelease build\u201d triggered by Git tag that deploys to a staging Cloud Run service.<\/li>\n<li>Add Secret Manager integration for a private package registry token.<\/li>\n<li>Implement Artifact Registry cleanup policies and measure cost impact over time.<\/li>\n<li>Build with a private worker pool to access a private dependency endpoint.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Artifact Registry<\/strong>: Google Cloud service to store and manage artifacts such as container images and language packages.<\/li>\n<li><strong>Builder<\/strong>: A container image used as a Cloud Build step runtime (e.g., Docker builder, gcloud builder).<\/li>\n<li><strong>Build<\/strong>: A single execution in Cloud Build defined by steps and options, producing logs and optional artifacts.<\/li>\n<li><strong>Build config<\/strong>: <code>cloudbuild.yaml<\/code>\/<code>cloudbuild.json<\/code> defining steps, substitutions, artifacts, and options.<\/li>\n<li><strong>CI (Continuous Integration)<\/strong>: Automatically building\/testing code changes frequently.<\/li>\n<li><strong>CD (Continuous Delivery\/Deployment)<\/strong>: Releasing artifacts into environments via automated workflows.<\/li>\n<li><strong>Cloud Logging<\/strong>: Google Cloud\u2019s managed logging service where Cloud Build logs commonly land.<\/li>\n<li><strong>Cloud Run<\/strong>: Managed serverless container runtime on Google Cloud.<\/li>\n<li><strong>IAM<\/strong>: Identity and Access Management; controls permissions for users and service accounts.<\/li>\n<li><strong>Private worker pool (private pool)<\/strong>: Cloud Build feature to execute builds on workers connected to a customer VPC.<\/li>\n<li><strong>Service account<\/strong>: A non-human identity used by workloads (including Cloud Build) to access Google Cloud APIs.<\/li>\n<li><strong>Substitutions<\/strong>: Variables injected into builds (e.g., <code>_REGION<\/code>) to parameterize configs.<\/li>\n<li><strong>Trigger<\/strong>: Cloud Build configuration that starts builds automatically on events (e.g., source changes).<\/li>\n<li><strong>Immutable tag<\/strong>: A tag that uniquely identifies a specific artifact version (e.g., commit SHA).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Cloud Build is Google Cloud\u2019s managed build service for <strong>Application development<\/strong> workflows: it runs container-based build steps to test code, build artifacts (especially container images), and publish them to destinations like Artifact Registry. It matters because it reduces CI infrastructure overhead while improving repeatability, auditability, and integration with Google Cloud IAM, logging, and deployment targets.<\/p>\n\n\n\n<p>From an architecture perspective, Cloud Build commonly sits between your source system and Artifact Registry, and can optionally deploy to Cloud Run or GKE. Cost is primarily driven by build execution time\/resources, private pool usage (if used), and indirect costs like Artifact Registry storage and Cloud Logging ingestion\u2014so controlling build frequency, artifact retention, and log volume is key.<\/p>\n\n\n\n<p>Use Cloud Build when you want a managed, Google Cloud-native build platform with strong IAM and ecosystem integration. For your next step, deepen skills in Artifact Registry governance, Cloud Run deployment strategies, and (for production) staged promotion with Cloud Deploy and security hardening with least-privilege service accounts and secrets management.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Application development<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[54,51],"tags":[],"class_list":["post-591","post","type-post","status-publish","format-standard","hentry","category-application-development","category-google-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/591","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=591"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/591\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=591"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=591"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=591"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}