Last reviewed: May 2026
A scannable reference of architectural patterns the ACE exam tests. Read top-to-bottom, or jump to a section.
Centralize billing and policy enforcement while granting business units administrative autonomy.
Use an Organization node with Folders for each business unit. Create projects within folders. Link all projects to a single Billing Account.
Why: Folders provide administrative boundaries and policy inheritance. A single billing account centralizes cost management and allows for organization-wide discounts.
Notify finance when project spending reaches certain percentages of a budget.
In Cloud Billing, create a Budget for the project. Set multiple alert threshold rules (e.g., 50%, 90%, 100%) that send notifications to a Pub/Sub topic or email.
Why: Budgets are for alerting, not for stopping spend. To automatically cap spending, a Pub/Sub notification must trigger a Cloud Function to disable billing or shut down resources.
Analyze granular, resource-level cloud costs and track spending by cost center.
Enable detailed billing export to a BigQuery dataset. Apply labels (e.g., `cost-center: "finance"`) to resources. Query the BigQuery table and group by labels for analysis.
Why: Billing export to BigQuery provides the most detailed cost data, including labels, which is essential for custom chargeback and showback models.
Enforce security and configuration standards across all projects in an organization (e.g., restrict resource locations, require uniform bucket access, disable public IPs).
Apply Organization Policy constraints at the Organization or Folder level. Examples: `gcp.resourceLocations` for data residency, `storage.uniformBucketLevelAccess` for GCS security, `compute.vmExternalIpAccess` to prevent public IPs.
Why: Organization policies are inherited and provide preventative control, blocking non-compliant actions before they occur. This is more effective than reactive auditing.
Prevent the accidental deletion of a critical production project.
Place a lien on the project using `gcloud alpha resource-manager liens create`.
Why: A lien is a property that blocks the deletion of a project. It must be explicitly removed by a user with the `resourcemanager.lienModifier` role before the project can be deleted.
Efficiently switch between different projects and user accounts when using the gcloud CLI.
Use `gcloud config configurations create` to create named configurations for each project/account. Switch between them using `gcloud config configurations activate [CONFIG_NAME]`.
Why: Configurations store settings like project, account, region, and zone, avoiding the need to specify them with every command.
Run a stateless, containerized HTTP microservice with variable traffic, minimizing operational overhead and cost.
Deploy the container to Cloud Run.
Why: Cloud Run is fully managed, scales to zero (eliminating cost for idle periods), and scales automatically based on incoming requests. It is ideal for stateless web services.
Run a fault-tolerant, time-flexible batch processing job at the lowest possible cost.
Use Spot VMs (formerly Preemptible VMs) in a Managed Instance Group.
Why: Spot VMs offer up to a 91% discount compared to on-demand pricing. They are suitable for workloads that can be stopped and restarted, like many batch processing jobs.
Deploy a web application that requires high availability (e.g., 99.9%) and autoscaling.
Use a Regional Managed Instance Group (MIG) with an autoscaling policy, deployed behind a Global External HTTP(S) Load Balancer.
Why: A regional MIG automatically distributes instances across multiple zones for fault tolerance. Autoscaling adjusts capacity to meet demand, and the load balancer provides a single entry point.
Store data that is frequently accessed for 30 days, then infrequently for a year, then archived.
Store in a Cloud Storage Standard class bucket. Create a lifecycle rule to transition objects to Nearline/Coldline after 30 days and to Archive after 365 days.
Why: Lifecycle rules automate cost optimization by moving data to cheaper storage classes based on age or other conditions, without manual intervention.
A globally distributed application requires a relational database with horizontal scalability and strong consistency.
Use Cloud Spanner.
Why: Cloud Spanner is the only service that provides a globally distributed, strongly consistent, relational database with SQL support. Cloud SQL is regional.
An application requires a managed PostgreSQL or MySQL database with a 99.95% availability SLA and automatic failover.
Use Cloud SQL with the High Availability (HA) configuration enabled.
Why: The HA configuration creates a primary instance and a standby instance in a different zone. Data is synchronously replicated, and failover is automatic.
Design a VPC for a 3-tier application (web, app, db) where the database tier must not be accessible from the internet.
Create a custom-mode VPC with a separate subnet for each tier. Provision the database instances with only private IP addresses in their dedicated subnet.
Why: Isolating tiers in separate subnets allows for granular firewall rules. Omitting external IPs on database instances is the most direct way to prevent internet access.
Deploy a stateful application (e.g., a database) on GKE that requires stable network identifiers and persistent storage.
Use a StatefulSet with a PersistentVolumeClaim template.
Why: StatefulSets are designed for stateful workloads, providing stable hostnames (e.g., `pod-0`, `pod-1`) and automatically provisioning a unique PersistentVolume for each replica.
A latency-sensitive Cloud Run service must avoid cold starts during traffic spikes.
Deploy the service with the `--min-instances` flag set to 1 or higher.
Why: Setting minimum instances keeps a specified number of containers "warm" and ready to serve requests, eliminating the latency associated with starting a new container.
Execute a serverless function automatically whenever a new file is uploaded to a Cloud Storage bucket.
Deploy a Cloud Function (2nd Gen) with an Eventarc trigger for the `google.cloud.storage.object.v1.finalized` event on the specified bucket.
Why: Eventarc provides a unified, event-driven architecture. The GCS trigger is the standard, managed way to connect storage events to serverless compute without polling.
Deploy a new version of an App Engine application for testing without immediately sending production traffic to it.
Deploy the new version using `gcloud app deploy --no-promote`.
Why: The `--no-promote` flag creates the new version but does not shift any traffic to it. You can then test it using its version-specific URL and migrate traffic manually when ready.
Create a global HTTP(S) load balancer for a web application running on Compute Engine instances.
Create these components in order: Instance Group (with VMs), Health Check, Backend Service (pointing to IG and HC), URL Map, Target HTTP(S) Proxy, and a Global Forwarding Rule (with a public IP).
Why: This sequence correctly builds the load balancer from the backend (instances) to the frontend (forwarding rule). Each component serves a specific purpose in routing and health checking.
A team needs to manage Terraform state collaboratively, ensuring security and preventing concurrent modifications.
Use a Cloud Storage bucket as the Terraform backend. Enable object versioning for history and recovery. State locking is handled automatically by the GCS backend.
Why: A remote GCS backend is the standard for team collaboration on GCP. It provides locking to prevent state corruption and versioning for rollback capabilities.
Receive a notification when CPU utilization on any VM in a group exceeds 80% for a sustained period (e.g., 5 minutes).
In Cloud Monitoring, create an Alerting Policy. Set the condition to `Metric: CPU utilization > 80%` for `Duration: 5 minutes`. Configure a notification channel (e.g., email, PagerDuty).
Why: Cloud Monitoring is the native service for creating metric-based alerts. The duration condition is crucial to avoid "flapping" alerts from brief, normal spikes in utilization.
Retain specific audit logs for 7 years for compliance, while keeping other logs for 30 days.
Create a log sink with a filter for the audit logs. Configure the sink to export to a Cloud Storage bucket. Apply a 7-year retention policy on the bucket.
Why: Cloud Logging has a limited retention period (max 400 days for Admin Activity). Sinks are the mechanism for routing logs to long-term, cheaper storage like GCS or for analysis in BigQuery.
A GKE pod is in a `CrashLoopBackOff` state. You need to view the logs from the container just before it crashed.
Use the command `kubectl logs [POD_NAME] --previous`.
Why: When a container crashes and restarts, `kubectl logs` shows the logs of the *new* container. The `--previous` flag is essential for viewing the logs of the terminated instance to diagnose the crash.
A managed instance group must automatically replace instances that become unresponsive.
Configure a health check (e.g., HTTP, TCP) and apply it to the managed instance group's autohealing policy.
Why: The MIG periodically probes instances based on the health check. If an instance fails consecutive checks, the MIG automatically deletes and recreates it from the template, ensuring application availability.
A data corruption event occurred in a Cloud SQL database. You need to restore the database to the state it was in 5 minutes before the event.
Ensure Point-in-Time Recovery (PITR) is enabled on the instance beforehand. Perform a restore operation, specifying the exact timestamp to recover to.
Why: PITR relies on binary logging being enabled. It allows for granular recovery to any point in time within the retention window, which is critical for minimizing data loss (low RPO).
Automate daily backups of a Compute Engine persistent disk and retain them for 14 days.
Create a Resource Policy for disk snapshots. Configure a daily schedule and a 14-day retention policy. Attach this policy to the target persistent disk.
Why: Snapshot schedules are the managed, "fire-and-forget" way to automate GCE backups. This is more reliable and maintainable than using cron jobs or custom scripts.
A Compute Engine instance needs to read from a Cloud Storage bucket and write to a BigQuery table. Grant the minimum required permissions.
Create a custom service account. Grant it the `roles/storage.objectViewer` and `roles/bigquery.dataEditor` roles. Attach this service account to the instance.
Why: Using a custom service account with specific, predefined roles avoids the overly permissive nature of the default Compute Engine service account, adhering to the principle of least privilege.
Grant a user permissions to manage GCE instances but not delete them.
Create a custom IAM role. Start with the permissions from the `roles/compute.instanceAdmin.v1` role and remove the `compute.instances.delete` permission.
Why: Custom roles provide the flexibility to grant a precise set-of-permissions when predefined roles are too broad or too restrictive for a specific job function.
A developer needs to SSH into a Compute Engine instance that has no external IP address, as per security policy.
Grant the developer the `roles/iap.tunnelResourceAccessor` role. They can then connect using `gcloud compute ssh [INSTANCE_NAME] --tunnel-through-iap`.
Why: Identity-Aware Proxy (IAP) TCP forwarding provides a secure, identity-based method to access internal instances without bastion hosts, VPNs, or public IPs.
Allow inbound SSH (port 22) traffic to specific VMs from the corporate office IP range only.
Create a VPC firewall rule with `direction: INGRESS`, `action: ALLOW`, `protocol/ports: tcp:22`, `source ranges: [CORPORATE_IP_CIDR]`, and `target tags: [e.g., "allow-ssh"]`. Apply the tag to the intended VMs.
Why: Combining source ranges and target tags provides a precise and scalable way to control traffic. It restricts both *who* can connect and *what* they can connect to.
Prevent data from a sensitive BigQuery project from being copied or accessed from outside a trusted network boundary, even with valid credentials.
Configure VPC Service Controls. Create a service perimeter that includes the sensitive project and restricts the BigQuery API.
Why: VPC Service Controls create a virtual "data perimeter" that controls API-level access, providing a strong defense against data exfiltration that firewall rules cannot.
Provide a third-party application temporary, time-limited read access to a specific private object in a Cloud Storage bucket.
Generate a signed URL for the object with a short expiration time (e.g., 15 minutes) using a service account with read permissions.
Why: Signed URLs grant temporary, per-object access without requiring the third party to have a Google account or IAM permissions. It is the most secure method for this use case.
A GKE pod needs to securely access Google Cloud APIs (e.g., Pub/Sub) without storing service account keys as Kubernetes secrets.
Enable Workload Identity on the GKE cluster. Create a Google Service Account (GSA) and a Kubernetes Service Account (KSA). Bind the KSA to the GSA using an IAM policy. Configure the pod to use the KSA.
Why: Workload Identity is the recommended, keyless way for GKE applications to authenticate to Google Cloud services. It maps KSA identities to GSA identities, which is more secure than managing and rotating key files.
An organization policy requires that all data in a Cloud Storage bucket be encrypted using an encryption key that the organization controls.
Create a cryptographic key in Cloud KMS. When creating the Cloud Storage bucket, specify this key as the Customer-Managed Encryption Key (CMEK).
Why: CMEK gives you control over the key used for encryption, including rotation and revocation, while still leveraging Google's managed encryption infrastructure.
Allow employees to use their existing on-premises Active Directory credentials to access Google Cloud resources.
Configure Cloud Identity to federate with Active Directory using SAML 2.0. Users authenticate with AD, which then asserts their identity to Google Cloud for access.
Why: Federation allows for Single Sign-On (SSO) and centralizes identity management in the existing IdP (Active Directory), avoiding the need to manage a separate set of passwords in Google Cloud.
Grant an external contractor temporary access to a project, which should automatically expire after 30 days.
Add the contractor as an IAM member with the required role. Add a condition to the role binding with an expiration timestamp (`request.time < timestamp("YYYY-MM-DDTHH:MM:SSZ")`).
Why: IAM Conditions provide attribute-based access control. Time-based conditions are perfect for temporary access, as they automatically revoke permissions without manual cleanup.