Google Associate Cloud Engineer (ACE) — Questions 301–375

In Cloud IAM, allAuthenticatedUsers is a special principal that matches any identity that is authenticated with Google, which includes not only your organization's users but every Gmail account, Workspace account, and even service account in the world. Because anyone can create a Google account for free, this permission is functionally equivalent to public access — a random individual only needs a few seconds to sign up and gain the granted role. For internal or sensitive data, this exposure is unacceptable, so the security risk is severe rather than minor.

A sidecar container in the same Pod shares the network namespace with the main application container, meaning both can bind to the same localhost interface and the sidecar can transparently proxy or audit all traffic entering or leaving the Pod. This pattern is ideal for audit logging because it requires no code changes to the application and provides a complete view of the Pod's network activity, including both inbound and outbound connections, at the Pod boundary.

Partitioning the table by date allows BigQuery to use partition pruning, so queries with date range filters only read the relevant daily partitions instead of the full table. Clustering on frequently filtered columns further organizes data within each partition, enabling block-level pruning based on the cluster columns' values. Together, these features dramatically reduce the bytes scanned and the underlying I/O, directly improving query speed and reducing cost.

This command correctly configures the official Cloud SDK apt repository on a Debian or Ubuntu system by appending a sources.list entry with the signed-by parameter pointing to the imported Google signing key at /usr/share/keyrings/cloud.google.gpg. Using signed-by binds the repository to that specific key instead of trusting the global apt keyring, which is the recommended security practice. After running this, you still need to run sudo apt-get update and sudo apt-get install google-cloud-sdk, but this repository definition is the essential correct foundation for the package-manager installation method.

Editor provides create, read, update, and delete permissions on all GCP resources, but explicitly excludes IAM policy changes and billing management. This aligns exactly with the team lead's requirement to create and manage resources without managing access controls or billing. It is a primitive role that is broader than needed for many tasks, but in this scenario it matches the stated need precisely without overprivileged access.

This is the correct command to enable the Compute Engine API. `gcloud services enable compute.googleapis.com` tells the Service Usage API to enable the service in the current project. It uses the fully-qualified service name and is the standard gcloud method for this operation. After running it, you can create and manage Compute Engine instances via gcloud or the Console.

Using Serverless VPC Access to connect Cloud Run to the VPC and keeping the VM internal is the correct approach because it enables private, encrypted communication over the Google network. The connector lets Cloud Run reach the VM's internal IP address without the VM ever needing a public IP or a firewall rule for public traffic. This minimizes the attack surface and is the recommended pattern for serverless-to-VPC connectivity.

gcloud compute instances attach-disk is the correct command: it attaches an existing zonal or regional persistent disk to a specified Compute Engine instance, using --disk and optionally --device-name. It works on both running and stopped instances, and it ensures the disk becomes visible as a block device in the instance's guest OS.

A log sink with a filter and a BigQuery destination is the fully managed, native way to export logs: Cloud Logging continuously routes any newly ingested log entries that match the filter into a specified BigQuery dataset. The sink automatically creates a table with the log schema, and you can use the _PARTITIONTIME pseudo-column for time-based partitioning. This gives reliable, near-real-time export without custom code or manual intervention.

The correct way to set the default project is `gcloud config set project my-project`, which updates the active configuration's core project property. The zone must be set as `compute/zone` because it belongs to the compute section of the property hierarchy; `gcloud config set compute/zone us-central1-a` is the accepted syntax. Together these commands ensure that subsequent gcloud commands automatically use the intended project and zone, which is essential for quick CLI workflows.

Cloud Run is a fully managed serverless container platform that automatically scales in response to incoming requests, including scaling to zero when idle, so you only pay for the exact compute time consumed. It doesn't require any cluster or infrastructure management, and it can be used with Knative Serving APIs, making it the most direct fit for a stateless containerized application that needs to scale to zero.

Cloud Storage objects are encrypted with envelope encryption: a data encryption key (DEK) is generated per object and then wrapped by the Cloud KMS key. When that KMS key is destroyed, the DEK can never be unwrapped, so the ciphertext bytes in Cloud Storage remain but are mathematically unreadable. This is cryptographic erasure — effective deletion without physically deleting the stored object.

This command correctly deploys an HTTP-triggered Cloud Function: `gcloud functions deploy` creates or updates a function resource, `--runtime python39` selects the Python 3.9 execution environment, and `--trigger-http` configures an HTTPS endpoint that invokes the function on web requests. No other trigger type is needed. The command will return a URL for the deployed function.

Connection pools retain TCP sessions that were established with the original primary; when failover occurs, those sessions are forcibly terminated and remain marked as 'open' in the pool. Without validation, the pool hands out dead connections and the application sees errors immediately after failover. Configure the pool to test connections before borrowing (e.g., testOnBorrow with a lightweight SELECT 1, or initialization/eviction checks) and to create new connections automatically. Using the Cloud SQL Auth Proxy also masks this by re-establishing connections to the new primary seamlessly.

Cloud SQL HA automatically fails over to a synchronous standby in a different zone, protecting against zonal outages. A read replica, created using binary log replication, serves read-only queries like reporting without burdening the primary. Together, these features satisfy both availability and performance needs, allowing the reporting workload to run in parallel with production.

This is the correct command because it explicitly instructs Compute Engine to provision a Google-managed certificate for the specified domains. The --domains flag triggers Google's automatic certificate management lifecycle: Google Cloud obtains the certificate and handles renewals approximately 30 days before expiration, though you must verify domain ownership first. After creation, the certificate resource still needs to be attached to a target HTTPS proxy and associated with a forwarding rule before it can serve traffic.

IAM Conditions attach to a specific role binding and can include expressions using request.time, which supports date/time, day-of-week, and time-of-day comparisons such as Monday through Friday between 09:00 and 17:00. The condition narrows the binding's effect without altering the rest of the organization, folder, or project IAM policy. This approach is the recommended pattern because it is evaluated in real time by Cloud IAM, requires no external orchestration, and applies automatically to every API request that uses that binding.

This is correct because the HTTP request travels from an instance in subnet-a (source 10.0.1.0/24) to an instance in subnet-b (destination) on TCP port 80. An ingress rule on subnet-b with the source range set to 10.0.1.0/24 explicitly allows that inbound connection at the destination. In GCP, the destination subnet's ingress rules are the primary gate for allowing traffic to reach the target instance.

The gcloud storage buckets create command calls the Cloud Storage API, which verifies that the authenticated user has the storage.buckets.create permission on the project. A 'permissionDenied' error indicates a missing IAM role, such as Storage Admin (roles/storage.admin) or a custom role containing that permission. Since the request is authenticated but not authorized, this is the correct explanation.

Project Billing Manager on the specific project is correct because the role roles/billing.projectManager includes billing.projects.update, which permits linking or unlinking a billing account to precisely that project. It is scoped at the project level, so the user gains no access to other projects or to the billing account's administrative settings, satisfying least privilege.

When an origin includes a Set-Cookie header in a response, Cloud CDN's default cache mode treats that response as private and skips caching entirely. This prevents any user-specific response from being accidentally served to other users, and follows the principle that responses with cookies often contain personalized data. Unless you explicitly configure the cache mode to FORCE_CACHE_ALL or configure Cloud CDN to ignore Set-Cookie, the presence of Set-Cookie effectively disables caching for that response.

roles/iam.serviceAccountUser is the correct role because it includes the permissions iam.serviceAccounts.actAs and iam.serviceAccounts.implicitDelegation. The actAs permission allows a principal to use the service account to access resources and create resources that are owned by or signed with the service account's identity. ImplicitDelegation also permits the principal to impersonate service accounts that are arranged in a delegated chain, making this the minimal standard role for granting a service account the ability to act on behalf of another entity.

This is the correct command because n1-standard-4 is the general-purpose machine type that provides exactly 4 vCPUs and 15 GB of memory, satisfying the stated requirement. It also explicitly sets --image-family=debian-10 and --image-project=debian-cloud, which tells gcloud to use the latest active Debian 10 image from the official debian-cloud project. The command is complete and creates a reproducible Debian 10 VM with the desired vCPU count.

Uptime checks in Cloud Monitoring are the managed, intended way to verify that an external HTTP endpoint is reachable and returning expected responses from multiple locations across the globe. The check_failed metric increments each time a probe fails, and a metric-threshold alerting policy lets you define a condition—for instance, when the number of failed checks is consistently above zero over a specified period—and route it to an email notification channel. This directly implements the requirement without custom code.

This is the correct sequence: first, `gcloud iam service-accounts create` provisions the service account and generates its unique email address, which becomes the IAM member identity. Then, `gcloud projects add-iam-policy-binding` adds that service account email as a member in the project's IAM policy and grants the specified role (e.g., roles/storage.objectAdmin) for the whole project. This binds the service account as an identity to the project-level resource, which is exactly what is needed.

A ClusterIP Service is the correct choice because it provisions a stable virtual IP and an internal DNS record (e.g., backend.default.svc.cluster.local) that is resolvable only within the cluster. Frontend pods can communicate with the backend by its service name, and kube-proxy load-balances traffic to the backend pods automatically. Because the Service is not published on any node IP or external load balancer, it remains strictly internal, fully matching the requirement.

A log sink with BigQuery as the destination is the correct method: Cloud Logging's log router matches your chosen log entries and delivers them to a BigQuery dataset, where each daily collection becomes a table. You configure the destination by providing a dataset name, and the sink automatically handles batching and streaming writes. This is the officially supported, commonly used way to export logs to BigQuery for analytics.

`kubectl drain` gracefully evicts all pods from the node while respecting PodDisruptionBudgets, making the node unschedulable and empty for maintenance. The `--ignore-daemonsets` flag skips DaemonSet-managed pods, which are intended to run on every node and would otherwise block eviction, while `--delete-emptydir-data` allows deletion of pods using emptyDir volumes, which would otherwise prevent the drain from finishing. These flags together ensure the command completes cleanly on nodes with these pod types.

Correct: This rule allows the desired traffic.

The correct resolution is to submit a quota increase request for Cloud Build API metrics, such as concurrent builds or daily build time, in the project's IAM & Admin > Quotas page (or the Cloud Quotas product). Choose the specific metric that triggered the error, specify a new limit, and provide a justification; the request is then reviewed by Google Cloud. Once approved, the new limit applies to that project, resolving the quota exhaustion error.

In custom mode, you explicitly define every subnet, choosing the exact region and CIDR block, which lets you align your VPC address space with on-premises networks and avoid overlapping IP ranges that would break VPN or Interconnect peering. Unlike auto mode, which automatically creates subnets in all regions using a reserved 10.128.0.0/9 range (each with a /20), custom mode gives you the flexibility to create subnets only where needed and with appropriate sizes, preventing subnet sprawl and preserving address space for future growth. This control is essential for hybrid cloud designs that require careful CIDR planning to ensure route propagation doesn't conflict.

Cloud Run Jobs execute a container to completion in response to an explicit execution request, making them ideal for a nightly batch script. You can configure the job with a command, environment variables, a timeout (up to 24 hours or more), and the number of parallel tasks, and the job exits with a success/failure exit code. Cloud Scheduler can trigger the job via Pub/Sub or a direct API call using IAM authentication, providing a serverless cron that runs each night without maintaining an HTTP server.

App Engine Standard is the correct choice because it runs on a fully managed, sandboxed PaaS that automatically scales to zero instances when idle, eliminating compute cost between requests. Its stateless runtime instances start in under a second even from cold, which is critical for latency-sensitive or sporadically used APIs. The API's requirement of standard Python runtimes fits Standard's supported runtimes exactly, and the absence of any need for custom system packages sidesteps Standard's primary limitation.

'gcloud services enable compute.googleapis.com' is the correct command to enable the Compute Engine API for the active project. The 'gcloud services' command group interacts with the Service Usage API to manage service availability. This command uses the fully qualified service name 'compute.googleapis.com', which is required for successful enablement. You can also specify a project with the '--project' flag if the API should be enabled for a different project than the current one.

PgBouncer in transaction pooling mode multiplexes many application connections onto fewer database connections, eliminating idle-in-transaction waste and staying well below max_connections.

SSD persistent disks are built on flash-based media and deliver substantially higher IOPS, throughput, and lower latency than standard persistent disks, directly addressing an I/O-bound workload. Unlike local SSDs, they remain durable across instance lifecycle events and maintain the same persistent disk management model. Replacing standard persistent disks with SSD persistent disks is the appropriate change to remove the storage bottleneck while retaining data durability.

With maxUnavailable=1 the Deployment is allowed to take down at most one pod at a time, so at least 5 - 1 = 4 pods remain available throughout the update. With maxSurge=1 the Deployment may create at most one extra pod above the desired count, capping total simultaneous pods at 5 + 1 = 6. These two parameters exactly satisfy both the minimum-4 available and maximum-6 total constraints while keeping the rollout incremental and service available.

The `kubectl logs my-pod` command retrieves the logs of the primary container running inside the specified pod by reading the container's stdout/stderr streams. This is the direct, native Kubernetes approach for accessing application log output, and if the pod has multiple containers, you must append `-c <container>` to select a specific one. It does not require shell access or any extra tooling, making it the correct command for viewing logs.

This is the correct pattern: first, create a log-based metric in Cloud Logging that counts Cloud Run errors, for example by filtering on status codes >= 500 or severity ERROR. Then, define a Cloud Monitoring alerting policy that watches that metric and triggers when the error count crosses a threshold. Finally, attach a PagerDuty notification channel to the policy so an incident is created automatically. This approach uses fully managed services and requires no custom application code.

This is the correct preventive approach because the `billing.allowedBillingAccounts` organization policy (constraint: `constraints/billing.allowedBillingAccounts`) restricts the set of billing accounts that can be associated with a project, and it is evaluated at project creation time, not after the fact. Scoping the Project Creator role to only approved folders via IAM roles on those folders means a user can create a project only within those resource boundaries, because the permission to create a project is inherited down the hierarchy only from those folders. Together these controls ensure that any new project is created in an approved folder and must use an allowed billing account, preventing non-compliant project sprawl before it happens.

The Ops Agent is the correct solution because it is Google Cloud's unified agent for both logging and monitoring on Compute Engine. It can be configured to collect logs from system daemons, application log files, and custom pipelines, then forward them as structured log entries to Cloud Logging, while also ingesting metrics for Cloud Monitoring. It must be explicitly installed on the VM, but it is the supported, modern replacement for the separate legacy logging and monitoring agents.

Allocating 512 MB gives the function enough headroom to handle the message payload without exhausting the default 256 MB limit, and extending the timeout to 120 seconds ensures slower processing steps aren't cut off. This directly addresses both the memory-termination error and the short timeout, while keeping costs significantly lower than the 1 GB option. It is a right-sized adjustment based on the observed failure pattern.

roles/compute.instanceAdmin.v1 is a predefined IAM role specifically designed for managing Compute Engine instances without granting broader administrative power. It includes permissions to start, stop, and reset instances, as well as modify metadata and change instance settings, but it does not allow deleting instances or creating new ones. This role exactly matches the requirement of enabling a service account to start and stop instances while maintaining least privilege.

To change the machine type of a Compute Engine instance, you must first stop it, which brings it to the TERMINATED state. While stopped, the persistent disks and instance settings remain intact, but any data on local SSDs is permanently lost because local SSDs are ephemeral storage tied to the host server. After updating the machine type, you start the instance; this process is the only supported way to resize an instance's vCPU and memory.

Automated backups and point-in-time recovery (PITR) via binary logging are foundational features of Cloud SQL, available on every edition: Enterprise, Enterprise Plus, and even the legacy basic tier. The backup infrastructure ingests daily snapshots and transaction logs regardless of the instance's tier, so no premium edition or add-on is required. Because these capabilities are guaranteed baseline functionality, the correct answer is that they apply to all Cloud SQL tiers.

Automated backups in Cloud SQL are mandatory for point-in-time recovery (PITR) and for creating read replicas. Without them, you cannot perform a restore to a specific timestamp, and you lose the baseline backup needed for replica creation. They also provide a daily recovery point that protects against data loss or corruption.

This is the correct configuration because it uses the required `terraform` block with a `backend "gcs"` block, and includes both the `bucket` name (where the state file is stored) and a `prefix` (the object path within the bucket). The backend type is exactly `"gcs"`, and this syntax registers Google Cloud Storage as the remote state backend, enabling shared state and locking across the team.

This rule is correct because it explicitly restricts inbound HTTPS (TCP port 443) to source IPs within the RFC 1918 private range 192.168.0.0/16 and applies only to VM instances bearing the network tag 'web-server'. The combination of --source-ranges with a CIDR and --target-tags ensures the rule targets exactly the intended web servers and only allows traffic from the specified internal subnet, satisfying the requirement.

Cloud Monitoring automatically collects `compute.googleapis.com/instance/cpu/utilization` from every Compute Engine VM without requiring an agent, storing it as a time-series metric. You can create an alerting policy with a threshold condition, setting an aggregation (e.g., mean value across instances) and a duration (e.g., 5 minutes) to reduce noise, and attach notification channels like email or Pub/Sub. This is the native, managed, and real-time mechanism for CPU monitoring, and it integrates directly with the rest of Cloud Monitoring, including dashboards and incident escalation.

The `gcloud compute ssl-certificates create` command with the `--domains` flag provisions a Google-managed SSL certificate, which satisfies the stem’s requirement for a Google-managed certificate rather than a self-managed one. This command triggers Google’s Certificate Authority to automatically handle domain validation and renewal for `example.com`, eliminating the need for manual certificate uploads. It directly attaches to the HTTPS load balancer’s target proxy, meeting the load-balancer constraint.

`kubectl rollout undo deployment/my-app` is the built-in rollback mechanism. It instructs the Deployment controller to revert the pod template to the spec from the previous ReplicaSet revision, scaling up the old ReplicaSet and scaling down the new one. This preserves the Deployment's revision history, so you can undo again or jump to a specific revision with `--to-revision`. It is the correct, declarative way to return to a stable version without recreating the Deployment object or disrupting its managed state.

Increasing the number of subscribers (i.e., scaling out the subscriber fleet) directly raises the aggregate processing throughput of the subscription. Because the intermittent high latency is likely due to a backlog of messages accumulating faster than the current subscribers can drain, adding more subscribers allows messages to be pulled and processed in parallel, reducing the queue depth and lowering end-to-end latency. This is the correct scaling action for a latency problem caused by insufficient compute, assuming the subscribers are stateless and can process messages independently.

Folders provide logical grouping and policy inheritance.

IAM permissions are additive — not granting `iam.serviceAccountAdmin` and `resourcemanager.projectIamAdmin` naturally prevents the service account from performing those actions. Least privilege is the approach.

Folder-level IAM grants inherit to all child projects. Using a Google Group means membership changes (add/remove people) automatically update access without modifying IAM policies.

Google Cloud NetApp Volumes offers enterprise-grade managed NFS and SMB file shares built on NetApp ONTAP. It can be mounted by multiple Compute Engine instances across different zones via NFSv3 or NFSv4.1, providing high throughput and low latency along with advanced features like snapshots and clones, making it a strong choice for migrating legacy applications that require a reliable, POSIX-compliant shared file system.

`docker run` with the `-p 8080:8080` flag binds the host port to the container's port 8080, which matches Cloud Run's default expected `$PORT` value and lets the service be exercised via `localhost:8080`. Supplying the same environment variables the Cloud Run service will receive replicates its runtime configuration, so the local container behaves like the deployed revision, enabling accurate functional and integration testing before deployment.

An alerting policy with a CPU utilization threshold condition is the correct choice because it continuously evaluates the compute.googleapis.com/instance/cpu/utilization metric against the threshold you set. Once the metric exceeds the threshold for the specified duration (e.g., 5 minutes), the policy triggers a notification through the configured channel (email, SMS, webhook, etc.). This provides the real-time proactive notification that dashboards, log-based metrics, and uptime checks cannot.

OS Login links SSH access to IAM roles like `roles/compute.osLogin` or `roles/compute.osAdminLogin`. When a user is granted one of these roles, they can SSH into instances using their own identity, and revoking that role immediately removes access across all VMs without requiring metadata edits or key cleanup. This centralizes access management, simplifies revocation, and improves auditability compared to storing keys per instance.

Correct. The billing.accounts.list permission is the specific IAM permission that allows a principal to enumerate the billing accounts they can access. Including this permission in the custom role is essential and sufficient for the read-only task of listing billing accounts; without it, any API call or console view that attempts to list billing accounts will fail with a permission denied error.

This is the exact, valid CLI command for retrieving a project's IAM policy. The subcommand get-iam-policy reads the IAM policy bound to the specified project resource, and --format json renders it as a JSON array of bindings, including roles, members, and conditions. It is the correct tool for this task.

roles/iam.securityReviewer is the correct choice because it grants permission to view IAM policies (for example, 'getIamPolicy') across all resources without allowing any modifications. It also includes permissions to list and get roles, which is exactly what an external auditor needs to review access configuration. This role aligns with least privilege for a read-only audit.

A log sink in Cloud Logging's Router exports matching log entries to a destination such as BigQuery, Cloud Storage, or Pub/Sub. By configuring a sink with BigQuery as the destination and a filter that matches all logs (or empty filter), you continuously export your project's logs to a BigQuery dataset for analysis and long-term retention. This is the standard and only fully supported mechanism for exporting Cloud Logging logs to external services.

Compute Engine offers Infrastructure-as-a-Service virtual machines in which you select the OS, disk, and networking settings, allowing you to upload a disk image or reinstall the application directly. This 'lift-and-shift' approach preserves the existing architecture, libraries, and configuration with minimal or no code changes, making it the fastest and lowest-effort migration path for a monolithic application. It also provides full administrative control over the environment, letting you manage updates, security, and scaling in a familiar way.

Enabling automatic disk resizing on the node pool lets GKE monitor persistent-disk usage and grow the disk capacity in real time when utilization crosses a threshold, up to a configurable maximum. This keeps worker nodes operational during data spikes without human intervention, and because the disk only grows when needed, you avoid paying for unused space. It is the correct balance of resilience and cost management for a pipeline with variable data volume.

Cloud Trace is a distributed tracing service designed to collect latency data from Google Cloud and measure time spent in each service and API call during a request. It provides detailed per-request traces with spans that show the timing of each operation, making it the correct tool to investigate high application latency. By analyzing the waterfall view of spans, you can identify the exact component responsible for the delay across distributed services.

GCP's VPC doesn't automatically encrypt VM-to-VM traffic. mTLS at the application layer (using certificate-based authentication) is the standard method to enforce encrypted communication between services.

A LoadBalancer Service is the appropriate choice for a containerized web application that needs a stable external IP. When you create this Service on Google Kubernetes Engine, the cloud-controller-manager automatically provisions a Google Cloud (TCP/UDP) load balancer and assigns a regional static external IP address. This gives clients a stable, publicly reachable endpoint, which precisely matches the requirement for an internet-facing web application.

Deleting the compromised service account key immediately revokes the attacker's primary authentication credential, effectively cutting off their direct API access through that key. After deletion, audit Cloud Audit Logs—specifically the Data Access and Admin Activity logs—to determine whether the key was used to call any GCP APIs, identify the scope of exposure, and check for unusual patterns such as token creation or IAM changes. Then issue a new key if the workload still requires a long-lived credential, or better, eliminate static keys entirely by adopting keyless authentication such as Workload Identity Federation, which binds short-lived credentials to the workload's identity.

Associating a purpose-built service account with the instance is the Google-recommended pattern for granting cloud resources to a VM. Granting the Storage Object Viewer role (roles/storage.objectViewer) provides read-only access to objects without allowing writes or deletions, aligning with least privilege. The Compute Engine metadata server automatically supplies short-lived OAuth tokens for the service account, so no credentials are ever hard-coded or stored on disk. This integration works with the instance's default credentials and is fully auditable in Cloud Audit Logs.

A rolling update with a new instance template and a health check is the correct way to deploy a new application version without downtime: the MIG progressively creates new instances from the updated template, waits for each to pass the configured health check, and then terminates the old instances. You can control the rollout speed with parameters like maxSurge and maxUnavailable, which ensure that a certain number of old instances remain serving at all times. The health check acts as the gate — if the new version fails health checks, the rollout pauses and old instances stay in service, allowing you to roll back without a full outage. This method directly targets the application version on existing instances, unlike a full MIG replacement, because it updates the instance group in place through the MIG's native update mechanism.

Creating one budget with three threshold rules is the recommended and most efficient approach because Cloud Billing budgets natively support multiple thresholds—each can be a percentage of the budget amount and trigger an alert independently. For example, you can set actual-cost thresholds at 50%, 90%, and 100%, and optionally add forecasted-cost thresholds as well. This gives you the desired notification at each stage without duplicating budget resources.

The `gcloud run services update-traffic` command is the correct tool for modifying an existing Cloud Run service's traffic routing. By specifying `--to-revision new-revision` and `--percent 10`, you instruct the service to send 10% of incoming requests to that revision while the remaining 90% continues to the current default revision. This enables incremental canary rollouts and rollbacks without redeploying code.

The autoscaler uses the target CPU utilization (e.g., 60%) to compute desired capacity: if the group's average CPU is above target, it calculates how many VMs are needed so that average utilization drops back to that level and provisions additional instances. For example, if 5 VMs run at 80%, it targets 7 VMs (5*0.8/0.6 ≈ 6.67) to bring average CPU to ~57%. This scale-out distributes load across new instances, reducing per-VM CPU demand. The autoscaler keeps adding until the measured average falls to approximately the target.