Google ACE: Deployment, Configuration and Automation — Study Guide

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Part of the Google Associate Cloud Engineer — Study Guide. Practice with verified answers in the Google exam hub, or take timed practice tests on ExamRoll.io.

Overview

Deployment, configuration, and automation on Google Cloud center on repeatable, auditable, and safe change delivery. Sound practice relies on infrastructure as code (IaC), declarative templates, immutable artifacts, and standardized pipelines. Operational excellence comes from designing for idempotency, previewing changes, enforcing policy, and planning controlled rollouts with clear rollback paths. The following sections provide practical patterns, command examples, and the reasoning behind design choices, including common pitfalls and trade-offs.

Infrastructure as Code and Configuration Foundations

Principles:

Declarative templates describe desired end state; tooling reconciles actual state to match. This improves idempotency, repeatability, and auditability.
Immutable infrastructure deploys new instances or revisions rather than modifying in place, simplifying rollback and reducing drift.
Separation of concerns: parameterize environment-specific values while reusing shared modules or templates.

Terraform on Google Cloud:

Configuration: HCL files define resources, variables, and outputs. Use modules to encapsulate VPCs, service accounts, or GKE clusters; publish shared modules internally to standardize patterns.
State: Keep state remote and versioned. Use a Cloud Storage backend with object versioning and bucket retention as appropriate.
- Example backend block: terraform { backend “gcs” { bucket = “tf-state-prod” prefix = “envs/prod” } }
- Failure modes: local state or unversioned buckets risk data loss and concurrent writes. Enforce least-privilege access to the state bucket; prefer short-lived credentials and service account impersonation over keys.
Plans and applies: terraform plan provides a preview; gate applies in CI/CD with human approval for production. Use -target sparingly; frequent targeting increases drift risk.
Modules: version modules semantically; pin versions to avoid unplanned changes. Validate with terraform validate and policy checks before apply.
Imports and drift: terraform import brings existing resources under management; follow with careful state review. Detect drift by running terraform plan regularly.
Remote execution: run Terraform in Cloud Build or Cloud Run jobs with Workload Identity Federation to avoid service account keys. Cache providers to reduce build time.

Deployment Manager:

While many teams standardize on Terraform, you may encounter Deployment Manager. Update a deployment without downtime by updating the config: gcloud deployment-manager deployments update my-deployment –config=config.yaml

Configuration standards:

Naming: apply consistent, parseable names with env, region, purpose, and sequence, e.g., vpc-prod-usw1-core.
Labels: attach labels such as env, cost_center, owner, and app to all resources; enforce via policy or validation.
Tags: use network tags to scope firewall rules; avoid overloading tags for identity or ownership (labels are better).
Metadata: leverage instance metadata for startup scripts and configuration; prefer metadata with checksum or version flags to control re-runs. Avoid placing secrets in metadata; use Secret Manager.

APIs, service enablement, quotas, and service accounts:

Enable required services early in automation: gcloud services enable compute.googleapis.com container.googleapis.com
Validate quota headroom during planning; scale tests should include quota checks to avoid throttling.
Use dedicated service accounts per workload and environment; grant least-privilege IAM roles at the narrowest scope. Prefer group membership for human access and service account impersonation for automation.

Delivery Pipelines and Artifact Promotion

Cloud Build:

Define Cloud Build steps to build, test, and package artifacts. Use substitutions for dynamic values and use Secret Manager for credentials.
Trigger builds from source changes; isolate build service accounts by repository or environment and grant only needed permissions.
Cache Docker layers and language dependencies to reduce build times. Watch concurrent build limits and ephemeral worker quotas.

Artifact promotion:

Store container images or language packages in Artifact Registry. Promote by:
- Re-tagging immutable digests for env (e.g., :qa, :prod) or
- Copying artifacts to an environment-specific repository.
Trade-offs: single repo with tags simplifies discovery but requires strict governance; per-environment repos strengthen isolation and policy enforcement.

Cloud Deploy:

Model a delivery pipeline with ordered targets (e.g., dev → qa → prod). Releases reference a specific artifact digest and deployment manifest.
For GKE and Cloud Run, Cloud Deploy uses Skaffold configurations to render and apply manifests. Configure approvals, verifications, and gates.
Rollout and rollback:
- Canary with incremental traffic shifting reduces blast radius.
- Blue/green enables fast cutover and rollback at the cost of extra capacity.
- Roll back by pinning to the last good release; avoid in-place fixes that create drift.
Failure modes: mismatched cluster permissions, missing APIs, and manifest schema errors. Detect early by rendering manifests during build and validating against cluster policies.

Safe change planning:

Require preview (plan or render), automated tests, policy validation, and human approval for production.
For Compute Engine managed instance groups, tune update policy maxSurge/maxUnavailable and health check settings to avoid overprovisioning when app readiness is slow.

Command-Line Operations and Environment Management

Cloud Shell and gcloud configurations:

Cloud Shell provides a managed admin environment with pre-authenticated gcloud and a persistent home directory.
Use named configurations to switch accounts, projects, and regions quickly: gcloud config configurations create prod gcloud config set project my-prod gcloud config set compute/region us-central1 gcloud config set compute/zone us-central1-a gcloud config configurations activate prod
Inspect active config with gcloud config list. For GKE, acquire credentials: gcloud container clusters get-credentials my-cluster –region us-central1

Compute command patterns:

Create VM with a reserved internal IP: gcloud compute addresses create license-ip –region=us-central1 –subnet=default –addresses=10.0.3.21 gcloud compute instances create license-server –zone=us-central1-a –subnet=default –private-network-ip=10.0.3.21 –tags=license
Create a custom VPC, subnet, and firewall rule: gcloud compute networks create core –subnet-mode=custom gcloud compute networks subnets create core-us –network=core –range=10.0.0.0/20 –region=us-central1 gcloud compute firewall-rules create allow-https –network=core –allow=tcp:443 –target-tags=web

IAM patterns:

Grant a role at project scope: gcloud projects add-iam-policy-binding my-project –member=group:ops@example.com –role=roles/logging.viewer
Copy custom roles across projects: gcloud iam roles copy myCustomRole –source=my-dev –destination=my-prod

Storage patterns:

Create a bucket and upload objects: gcloud storage buckets create gs://backups-prod –location=us-central1 –class=coldline –uniform-bucket-level-access gcloud storage cp ./backup.tar.gz gs://backups-prod/
Configure lifecycle via file and apply with gcloud storage buckets update –lifecycle-file=policy.json

API enablement and verification:

Enable Pub/Sub for an app: gcloud services enable pubsub.googleapis.com
List enabled services: gcloud services list –enabled

Governance, Drift, and Automation

Configuration drift and policy enforcement:

Detect drift by running terraform plan on a schedule; fail builds on unexpected changes.
Enforce organization policy constraints (e.g., restrict external IPs) and validate resource configs with policy-as-code before apply.
For Kubernetes, use Config Sync and Policy Controller to continuously reconcile and gate noncompliant changes.
Auditability: rely on Admin Activity and Data Access logs; route to BigQuery for analysis. Use Cloud Asset Inventory for point-in-time and time-travel state queries.

Quotas and limits:

Inspect quotas per region and project; plan headroom for autoscaling and rollouts: gcloud compute regions describe us-central1 –format=“yaml(quotas)”
Request increases ahead of planned growth or large rollouts.

Automated operational tasks:

Cloud Scheduler triggers HTTP endpoints, Pub/Sub topics, or Workflows on a cron schedule. Ensure idempotent handlers; configure retries and dead-letter topics.
Workflows orchestrate multi-step automation across Google APIs with retries, parallel steps, and compensation logic.
Cloud Run jobs execute containerized batch or administrative tasks on demand or via Scheduler. Prefer jobs for one-off or iterative workloads; use minimum permissions on the job’s service account.

Rollout safety and observability:

Bake health checks and readiness probes into services. For MIGs with slow startup, increase initial delay to prevent premature scaling actions.
Collect deployment metrics and error budgets; pause or auto-abort rollouts when SLOs degrade.

Practical Problem Scenario

Altostrat Media needs to standardize multi-environment deployments for a GKE-based service while eliminating configuration drift and ensuring rapid rollback. They also must reserve a fixed internal IP for a legacy license server without reconfiguring the application.

Create foundational Terraform modules and remote state

Implement modules for VPC, subnets, GKE, service accounts, and firewall rules. Configure a Cloud Storage backend with versioning and a retention policy for the state bucket.
Rationale: Modularization promotes reuse and consistency; remote, versioned state enables collaboration, recoverability, and locking.

Enable required services and establish least-privilege automation identities

Enable compute.googleapis.com, container.googleapis.com, clouddeploy.googleapis.com, artifactregistry.googleapis.com.
Create per-environment service accounts for Terraform, Cloud Build, and Cloud Deploy; grant minimal roles (e.g., roles/container.admin to deployers, not builders).
Rationale: Pre-enablement and role scoping reduce deployment failures and limit blast radius.

Provision networking and reserve the legacy IP

With Terraform, create a custom VPC, regional subnets, and firewall rules based on network tags.
Reserve the internal IP: gcloud compute addresses create license-ip –region=us-central1 –subnet=core-us –addresses=10.0.3.21
Rationale: Declarative networking ensures repeatability; reserving the IP preserves application assumptions.

Build artifacts with Cloud Build and publish to Artifact Registry

Define cloudbuild.yaml to run tests, build the container, scan, and push an immutable digest to Artifact Registry.
Rationale: Immutable, scanned artifacts are the basis for safe promotions and provenance.

Configure Cloud Deploy pipeline with dev → qa → prod targets

Define a delivery pipeline and targets; reference Skaffold config to render manifests. Require manual approval for prod and configure verifications.
Rationale: Structured promotion enforces controls; per-target policies avoid accidental prod deployment.

Roll out GKE updates with canary strategy and health gates

Use a canary rollout policy to shift 10%, then 50%, then 100% traffic, contingent on SLO and error-rate checks.
Rationale: Progressive delivery reduces risk and provides natural rollback points.

Eliminate drift with scheduled plans and policy checks

Nightly job runs terraform plan and a policy-as-code validator; alerts on unexpected diffs or violations.
Rationale: Early detection prevents drift from accumulating and breaking future applies.

Operationalize the license server VM with the reserved IP

Create the VM bound to the reserved address and proper tags: gcloud compute instances create license-server –zone=us-central1-a –subnet=core-us –private-network-ip=10.0.3.21 –tags=license
Rationale: Ensures reachability without changing the application; tags keep firewall rules narrowly scoped.

Automate recurring tasks with Scheduler, Workflows, and jobs

Cloud Scheduler triggers a Workflow to rotate service account keys where unavoidable and to launch a Cloud Run job for weekly database vacuum tasks.
Rationale: Centralized scheduling plus orchestration yields reliability and observability with retries and compensation.

Plan rollbacks and validate readiness thresholds

Define rollback playbooks to re-promote the last good release. Tune readiness probes and, for any MIG-based workloads, increase initial health check delays to match app warm-up.
Rationale: Preplanned rollback and tuned health checks prevent cascading failures and overprovisioning during incidents.

This approach aligns immutable artifacts, declarative infra, gated promotions, and least-privilege automation to deliver safe, auditable, and repeatable operations on Google Cloud.

← Storage · All domains · Monitoring →

Practice these questions → · Timed practice on ExamRoll.io →