Google Associate Cloud Engineer (ACE) — Questions 226–300

The Cloud Billing Reports page provides a native console view of cost data and includes filtering by labels such as 'department'. Once you select the appropriate time range and filter by the 'department' label, the report dynamically groups costs by that label, giving you the required department-level breakdown instantly and without any additional configuration. This is the correct and most direct tool for this task.

CMEK with Cloud KMS is the correct choice because it lets your security team directly manage the full lifecycle of the encryption key — creating it in a dedicated key ring, rotating it on a schedule, setting IAM permissions for who can use or manage it, and most importantly disabling or destroying it. Disabling the key immediately blocks all access to data encrypted under it (cryptographic shredding) without waiting for storage deletion, and every use of the key is recorded in Cloud Audit Logs. This gives auditors a clear, independent chain of custody over the encryption material, which satisfies internal security requirements that Google-managed keys cannot.

Setting memory requests (and limits equal to requests) for every pod converts them from BestEffort or Burstable QoS to Guaranteed QoS, which places them last in the kubelet eviction order when memory pressure occurs. Requests also inform the scheduler, allowing it to place pods on nodes based on actual memory footprint, reducing the chance of overcommitting a node and triggering pressure in the first place. This directly fixes the root cause because it ensures every pod signals its memory needs and gets the appropriate eviction priority.

Regional persistent disks are block storage volumes that synchronously replicate data across two zones within a region, providing a multi-zone failure domain while maintaining high performance and low latency. They attach directly to Compute Engine VMs as boot or data disks, ensuring durable, consistent storage for stateful applications. This combination of performance and zone-redundant replication makes them the ideal choice for a stateful app that needs both high IOPS and disaster recovery without relying on manual snapshot restoration.

This is correct because the standard event-driven pattern is to create a Pub/Sub topic, enable bucket notifications for OBJECT_FINALIZE events, and use a Cloud Function to call Cloud DLP's content inspection/de-identification API. The function applies an InspectConfig with the US_SOCIAL_SECURITY_NUMBER infoType and a DeidentifyConfig with a redaction transformation, then writes the redacted object, optionally deleting or quarantining the original. This runs synchronously upon object creation, ensuring the file is not publicly readable until PII is removed.

This command is correct because it explicitly provides the required function name (`my-function`), specifies the Node.js 16 runtime, sets `--trigger-http` to create an HTTP-triggered Cloud Function, names the entry point (`helloHttp`) that matches the exported function in your source code, and pins the region (`us-central1`) to avoid ambiguity. In Cloud Functions, `--trigger-http` creates a public HTTPS endpoint and deploys the function to the specified location, making this the complete and valid invocation.

This is the correct prerequisite for enabling CMEK on a Cloud SQL instance. You must create a key ring and a crypto key in Cloud KMS, then grant the Cloud SQL service account (e.g., service-<project>@gcp-sa-cloudsql.iam.gserviceaccount.com) the cloudkms.cryptoKeyEncrypterDecrypter role. That IAM binding lets Cloud SQL call Cloud KMS to encrypt and decrypt the data encryption keys used to protect the instance.

Adding the script to the instance template using the metadata key 'startup-script' is the recommended, automated approach because Compute Engine stores the metadata in the instance template and executes the script on every VM boot. The MIG automatically applies this metadata to all instances it creates, including during autoscaling, rolling updates, and instance recreation after a failure. This guarantees the configuration is consistently applied without manual intervention, and the script can be updated by editing the template and rolling out a new version of the MIG.

This is the correct approach because BigQuery must already exist as a dataset for the log sink to write into, and the sink's underlying writer identity (the service account) needs the BigQuery Data Editor role (roles/bigquery.dataEditor) on that dataset to create tables and insert log entries. You first create the dataset, then configure the log sink with BigQuery as its destination, and after the sink is created you copy its service account ID and grant that service account the required IAM role. Without that grant, the sink will fail with permission errors when trying to deliver logs to BigQuery.

Cloud SQL with a regional (HA) configuration is the correct choice because it provides a fully managed relational database with automatic failover to a standby instance in a different zone within the same region. Data is synchronously replicated to the standby, so if the primary zone experiences an outage, Google Cloud promotes the standby with minimal disruption and no manual intervention. This gives the legacy monolithic application the ACID transactions, relational queries, and high availability it needs, at a cost and complexity level appropriate for moderate workloads.

A hierarchical firewall policy applied at the organization level with a deny rule for ingress from 0.0.0.0/0 is the correct preventive control. Hierarchical firewall policies are evaluated before VPC firewall rules, and a deny rule in such a policy takes precedence over any project-level allow rule, regardless of that allow rule's priority. By setting the policy's association scope to the organization and giving the deny rule a sufficiently high precedence, all inbound traffic from the public internet is blocked across every project in the organization, and no project administrator can override it with a per-project firewall rule.

A Serverless VPC Access connector bridges the Cloud Function's managed execution environment to your VPC network, allowing outbound requests over RFC 1918 private addresses. Attaching it to the function lets it reach the Cloud SQL instance's private IP without ever exposing a public endpoint, satisfying both connectivity and isolation. This is the only option that preserves the 'private IP only' security requirement.

Cloud Run is a serverless container platform that automatically provisions instances based on incoming requests, and because each container instance can serve multiple concurrent requests (based on the concurrency setting), it can handle 50,000 RPS with a relatively small number of instances. With max-instances configured, you control the upper bound, receiving 429 errors if exceeded, but the default scaling can spin up thousands of instances in seconds to absorb spikes. When no traffic arrives at night, Cloud Run scales to zero instances, so you pay only for requests, making it the most cost-effective and responsive choice.

Cloud Run scales to zero and charges per request, ideal for unpredictable traffic.

This Organization Policy constraint on Compute Engine restricts the service accounts that can be attached to newly created VM instances. It is the correct control because the requirement is to ensure all instances run under a specific identity: when you configure constraints/compute.setServiceAccount with an allowlist of permitted service account IDs, any attempt to create an instance with a different service account is rejected. This prevents a developer from accidentally or intentionally launching a workload as a privileged service account.

roles/logging.logWriter is the predefined IAM role that contains the logging.logEntries.create permission, which is exactly what a Cloud Function needs to write log entries to Cloud Logging. Unlike broader roles, it does not include permissions to delete logs, manage log sinks, or modify log-based metrics, making it the least-privilege choice. Assigning this role to the function’s runtime service account allows both the Cloud Logging API and client libraries to write structured log entries on the function’s behalf.

This rule is correct because it pairs a source range of 10.0.1.0/24—exactly matching subnet-a—with a target tag, such as 'https-server', that is applied only to the specific instance in subnet-b. The VPC firewall rule then evaluates the source IP of the incoming packet against the allowed CIDR and the destination instance's effective firewall tags to determine whether to permit TCP 443. Since both conditions are tightly scoped, the rule enforces the intended access: only instances in subnet-a can reach that one HTTPS server, and all other traffic is implicitly denied.

The gcp.resourceLocations organization policy constraint is a list constraint that defines the exact set of Google Cloud locations where new resources, including Compute Engine instances, may be created. Setting it to allow only us-central1 and europe-west1 at the organization or folder level makes non-compliance impossible at creation time, since the API call itself is rejected. This is a preventive, centralized governance mechanism that is inheritable across projects, making it the correct solution for enforcing geographic restrictions.

Workflow templates allow you to define a cluster configuration and job list, then instantiate it on a schedule via Cloud Scheduler or Dataproc's scheduled deletion. The template creates an ephemeral cluster at job start, runs the Spark job, and deletes the cluster after completion, ensuring you pay only for the duration of the job. This integrates natively with Cloud Scheduler and manages cluster lifecycle automatically.

Private Google Access is a subnet-level setting that already routes traffic from VM instances with only internal IP addresses to Google APIs and services over Google's internal network. When this is enabled on the subnet, DNS resolution for googleapis.com automatically maps to Google's internal IP ranges, so the existing VPC routing handles API calls without any extra networking components. Therefore, no additional configuration is required.

`twine upload` is the standard utility for publishing Python distribution packages (wheels and sdist archives) to a package index, and Artifact Registry's Python repositories implement the PyPI upload protocol. When invoked with the registry's repository URL as the `--repository-url` parameter and authenticated via Google Cloud credentials (e.g., a service account key or `gcloud auth login`), twine securely sends the package files to the correct format-specific endpoint. This is the only officially supported way to push Python packages into Artifact Registry, as it properly handles the package metadata and multipart upload that the PyPI protocol requires. Using twine ensures compatibility with the repository's authentication and validation mechanisms.

Setting the activation policy to ON_DEMAND tells Cloud SQL to shut down the instance when it has had no connections for a configurable idle period (default 15 minutes) and to start it automatically when a new connection arrives. While stopped, you are billed only for persistent storage and static IP allocation, not for vCPUs or memory, which is the dominant cost for intermittent workloads. This policy is ideal for development and test environments, but it is disabled for high-availability configurations because failover requires the instance to be always on. It also introduces a cold-start delay on every reconnect.

Applying a higher PriorityClass to web service pods and placing batch jobs on a separate, tainted node pool is the architecturally correct solution. Node taints prevent batch pods from being scheduled onto web-service nodes (unless they tolerate the taint), providing hard isolation, while PriorityClass with preemption guarantees that if a web pod ever needs to be scheduled on a shared node, it will evict lower-priority batch pods. Together, these mechanisms ensure batch workloads cannot throttle web pods and that web traffic gets uninterrupted CPU resources.

Correct.

For a peer VPN device that has only one public IP address, HA VPN supports using just one of its two interfaces: you create one tunnel from that interface and leave the second interface disabled or without a tunnel. This preserves the HA VPN gateway object and allows the existing Cloud Router/BGP session to operate over the single tunnel, matching the on-premises endpoint's capability. It is the documented configuration when the peer lacks the second IP needed for a fully redundant HA VPN pair.

Cloud Run is a fully managed serverless platform that executes a container in response to HTTP requests and automatically scales the number of instances to zero when no traffic is arriving. Since you pay only for vCPU and memory during request processing, rounded up to 100ms increments, an idle service incurs no cost. This zero-idle scaling makes Cloud Run the most direct way to run a containerized web application with complete cost savings during inactivity.

Running 'gcloud run deploy my-service --image gcr.io/my-project/my-app:v2' is the correct way to update a Cloud Run service's container image. The deploy command prepares a new immutable revision with the specified image, makes it the latest revision, and automatically routes traffic to it according to your service's traffic policy. Existing revisions are preserved in the revision history, enabling immediate rollback via 'gcloud run services update-traffic' if the new revision misbehaves.

Preemptible VMs are Compute Engine instances that are up to 80% cheaper than standard VMs and are ideal for fault-tolerant, batch workloads. They can be terminated by Google at any time within their maximum runtime of 24 hours, so the job must be checkpointed or designed to restart gracefully. Since the batch job runs daily and is inherently tolerant of interruption, using preemptible VMs maximizes cost savings without sacrificing correctness, making this the most cost-effective choice.

Creating a persistent disk snapshot with `gcloud compute disks snapshot` captures the exact state of the disk at a point in time, including the boot sector, partition table, and all system files. For best consistency, you should stop the VM before taking the snapshot to flush caches and avoid changes during the operation, though `--guest-flush` (where available) can coordinate with the guest OS. Snapshots are stored incrementally in Cloud Storage and can be used to create a new disk or VM, making them a reliable backup mechanism.

A Service of type LoadBalancer in GKE creates an external passthrough Network Load Balancer in Google Cloud, provisioning an external forwarding rule with a stable public IP address from a regional pool. This IP remains fixed for the lifetime of the Service unless the Service is deleted or a reserved static IP is explicitly configured, making it the correct choice for a microservice that needs a durable public endpoint without additional configuration.

These two org policy constraints enforce UBLA and region restrictions declaratively at creation time — no buckets outside the policy are ever created.

Workload Identity lets each Kubernetes ServiceAccount map to a dedicated GCP IAM ServiceAccount, so Pods authenticate through the GKE metadata server using short-lived OAuth2 tokens. This completely removes the need for static JSON key files, eliminating manual rotation and key-leak risk. It also enforces least privilege because each workload gets only the IAM permissions bound to its own service account. Enabling it requires the cluster, node pools, and the metadata server configuration, but it's the recommended modern pattern.

Defining all three steps in a single `steps` list is the idiomatic Cloud Build approach because each step runs as its own container sequentially, in the order they appear. The build automatically stops at the first step that exits with a non-zero status, so a failing test prevents the build and push steps from ever executing. This implicit sequential ordering and fail-fast behavior exactly enforces the test-before-build-before-push dependency without any extra configuration.

Archive is the cheapest, designed for data accessed less than once a year.

terraform import explicitly binds an existing GCP resource to a specified resource address in Terraform state, using the syntax terraform import <address> <resource_id>. After import, Terraform considers the resource as managed, but you must still write matching configuration; otherwise a subsequent plan will show changes. This is the only direct way to bring an out-of-band resource under Terraform management.

This predefined role contains only read permissions for Compute Engine resources, including instances, disks, images, snapshots, instance templates, and usage metrics, and it allows you to see them in the Cloud Console without any write or administrative actions. It precisely matches the contractor's access need and nothing more, upholding the principle of least privilege. As the correct answer, it is the best fit for granting read-only access to Compute Engine resources only.

Cloud Functions (2nd gen) is a fully managed, event-driven compute service that can be triggered directly by Pub/Sub messages via Eventarc. It scales automatically from zero to thousands of concurrent invocations and bills only for the time your code runs, so there is no idle capacity or cluster infrastructure to manage. This makes it the most cost-effective and operationally simple choice for processing sporadic events.

Cloud Trace is the correct choice because it captures end-to-end request latency as distributed traces, recording each span with its duration and parent-child relationships across services. This lets you follow a single user request through the entire service chain and identify exactly which downstream call added the most delay, rather than merely showing aggregate trends or isolated logs.

Dedicated Interconnect provides a private, physical 10 Gbps (or 100 Gbps) connection from your on-premises network to Google at a Google edge co-location facility. Traffic traverses only Google's global network and never the public internet, which directly satisfies the compliance requirement. This option also comes with a 99.9% uptime SLA, making it the most robust and compliant choice for high-bandwidth, low-latency connectivity.

Cloud Scheduler can authenticate HTTP targets using OIDC by automatically generating a short-lived Google-issued identity token for a configured service account. That token is placed in the Authorization header as 'Bearer <token>' for each scheduled request. The service account must be granted the roles/run.invoker role on the target Cloud Run service so that the token is accepted. This is the recommended pattern because the token is ephemeral, automatically rotated, and tied to a specific service, making it both secure and auditable.

Cloud Trace provides distributed tracing with per-span and per-service latency breakdowns, capturing the full path of a message as it flows through Pub/Sub and downstream services. Its waterfall view and latency distributions reveal exactly which step—from publish to processing—contributes the most delay. It is the only tool among these options specifically designed to analyze per-step latency in a distributed, asynchronous pipeline.

Checking the subscription's backlog, either in the Pub/Sub console or via the `gcloud pubsub subscriptions describe` command, gives a direct numeric measurement of how many messages are unacknowledged and waiting to be redelivered. A consistently growing backlog relative to the publish rate indicates the subscriber cannot keep up with the incoming flow. This is the first diagnostic step because it confirms whether the bottleneck is on the delivery side or the processing side without instrumenting any application code.

CPU utilization metrics drive the Horizontal Pod Autoscaler's scaling decisions. By default, HPA reads the average CPU utilization across all pods in a target Deployment, comparing it against the target percentage you set relative to each pod's CPU request. This is the most common and default metric type, requiring pods to have explicit `resources.requests.cpu` values. Custom and external metrics can be used, but CPU utilization is the built-in, standard input for autoscaling.

VPC Flow Logs, when enabled on a subnet, sample and collect metadata about every network flow that touches a VM interface in that subnet, including source/destination IP and port, protocol, bytes sent/received, and timing. These flow records are ingested into Cloud Logging and can be exported to BigQuery or Pub/Sub for anomaly detection, network forensics, or audit purposes. Because they cover all internal and external traffic regardless of protocol, they are the correct choice for connection-level visibility without capturing payloads.

The retention policy on the Cloud Storage bucket prevents objects from being deleted or overwritten for a specified duration, and object versioning preserves every version of each object, so even if an object is deleted or replaced, an immutable prior version remains. This is critical for compliance because audit logs must be tamper-proof and available for a multi-year period. However, this step alone does not capture logs; it secures the destination bucket where the log sink delivers exported log entries.

Deleted Google Cloud projects are not removed instantly; instead, they enter a soft-delete state for exactly 30 days. During this window, you can restore the project by running `gcloud projects undelete [PROJECT_ID]` or by using the Cloud Console's Resource Manager page. After 30 days, the project and its underlying resources are permanently purged and cannot be recovered. Note that the project ID must still be available and you need appropriate IAM permissions to perform the undelete.

Cloud Armor security policies attached to the external HTTP(S) load balancer deliver both volumetric DDoS mitigation at Google's global edge and layer 7 WAF rules, including preconfigured OWASP rules that detect and block SQLi payloads. Because it operates at the edge and inspects traffic before it reaches backends, it can filter attack traffic close to the source while allowing legitimate requests. This single service directly addresses both the DDoS flood and the SQL injection attempts described in the scenario.

Setting `parallelism: 10` and `completions: 10` in a Job spec is exactly the right way to run 10 workers in parallel while ensuring the Job is considered complete only after all 10 Pods have succeeded. `parallelism` controls the maximum number of Pods allowed to run at the same time, and `completions` tells the Job controller how many successful Pod runs are required overall. This is the standard configuration for a deterministic parallel batch job.

Use pg_stat_activity to identify the specific backend PIDs running the long table scans, then execute SELECT pg_terminate_backend(pid) to kill only those queries and restores the CPU headroom instantly without affecting other sessions. After that, create indexes on the columns used in the WHERE and JOIN clauses — preferably with CREATE INDEX CONCURRENTLY on PostgreSQL to avoid locking writes — so the optimiser can use Index Scan instead of Seq Scan, fixing the root cause. This combination yields immediate relief and a sustainable prevention of recurrence.

This is the correct command. `gcloud projects get-iam-policy` invokes the Cloud Resource Manager `getIamPolicy` API for the specified project, and the `--format json` flag requests the output as a structured JSON object containing the policy's `etag`, `version`, and `bindings`. It is the standard way to view all project-level IAM bindings.

This is the correct command. It uses the 'gcloud projects get-iam-policy' subcommand to retrieve the IAM policy for the specified project ID ('my-project') and sets the output format to JSON via '--format json'. The command returns the Policy object containing bindings, roles, members, etag, and version, all serialized in the requested JSON structure.

Granting roles/compute.securityAdmin at the folder level is the most precise solution because this role includes the compute.firewalls.create, compute.firewalls.update, and compute.firewalls.delete permissions needed to manage firewall rules, but does not include broader permissions to manage instances, networks, or IAM. IAM policies at the folder level are inherited by all projects and resources within that folder, so this single binding covers every descendant project, including newly created ones. This follows least privilege by granting exactly the permissions needed for firewall rule management and nothing extra.

Secret Manager is the dedicated GCP service for securely storing secrets such as database passwords, API keys, and TLS certificates. It provides automatic encryption at rest and in transit, granular IAM-permission binding, versioning, and audit logging, enabling applications to retrieve secrets on demand via API without embedding them in code. As a fully managed and centralized secret store, it is purpose-built to safeguard database credentials in compliance with security best practices.

Admin Activity audit logs are enabled by default for every Google Cloud project and record all IAM policy changes, including modifications to roles, bindings, and service account keys. To see who changed permissions, you can go directly to the Logs Explorer and query protoPayload.methodName=SetIamPolicy without creating any sinks or enabling additional features. This is the only option that directly answers the question with zero configuration effort.

gcloud init is the correct command because it performs a complete guided initialization of the local gcloud environment: it authenticates using either a user account or service account, sets a default project, and optionally configures compute/region and compute/zone properties in a new or existing configuration. It also runs an initial diagnostic to verify the installation and, if needed, can re-initialize an existing configuration. This one command provides the foundational project and location context that other gcloud commands depend on.

Before a GCP project can be deleted, its billing account attachment must be removed by disabling billing or unlinking the billing account. GCP will reject the deletion if the project is still linked to an active Cloud Billing account, returning an error such as 'Project is linked to a billing account'. You must disable the project's billing association first, then retry the deletion. This is the typical failure after creating a new project because billing is enabled by default.

The instance does not have a public IP address. The `gcloud compute instances describe` output displays the `networkInterfaces` section without any `accessConfigs`, which is where an external NAT IP would be defined. Without an entry such as `natIP: 34.123.45.67`, the instance has no public IPv4 address, and therefore no direct path for inbound or outbound internet traffic.

Custom domain mapping on Cloud Run registers the domain and provisions a Google-managed TLS certificate so the domain points to the service's default URL. This is a mandatory step to expose the application at the customer's chosen domain. While it handles the domain mapping, it does not by itself provide multi-region low latency; that requires a global load balancer with multiple regional backends.

Cloud Billing Budgets is the purpose-built service for setting spend limits on a billing account or project, defining threshold percentages (e.g., 50%, 90%, 100%), and sending alerts via email or Pub/Sub when actual or forecasted costs exceed those thresholds. It integrates directly with Billing Account and can trigger automated responses like disabling resources or sending notifications, making it the correct tool.

Configuring the Cloud Run service with `--add-cloudsql-instances` is the native, recommended integration for Cloud SQL. This flag instructs Cloud Run to start the Cloud SQL Auth Proxy within the instance, creating a Unix socket at `/cloudsql/<INSTANCE_CONNECTION_NAME>` and using the service account to establish a secure TLS connection. It avoids managing proxy deployments, certificates, and public IP exposure while providing IAM-based authentication. This approach works for both public and private IP instances.

This pairing correctly separates concerns: roles/compute.snapshotAdmin on the source project includes compute.snapshots.create and compute.disks.get permissions, allowing the service account to initiate a snapshot from the persistent disk. Meanwhile, roles/storage.objectAdmin on the target bucket permits the service account to write the snapshot image as an object into that Cloud Storage bucket. This is the standard pattern for cross-project snapshotting, because the snapshot is staged as an object in the designated bucket.

In Pub/Sub push delivery, the ack deadline defines how long the service waits for the subscriber to acknowledge. If the Cloud Function runs longer than the subscription's ack deadline (commonly 10 seconds by default), Pub/Sub redelivers the message to another instance before processing finishes. Configure the subscription's ack deadline to a value greater than 25 seconds—for example, 60 seconds—so the function can complete and return 200 OK to acknowledge before any redelivery.

Service projects must be attached to the host project to use shared resources.

Inbound HTTP packets have destination TCP port 80 and source IPs in 0.0.0.0/0, which exactly matches the custom ingress allow rule (protocol tcp, ports 80, priority 1000, applied to the instance's network tag). Because priority 1000 is lower than the deny-all rule's 2000, the allow rule is evaluated first and matches, so HTTP is permitted before the deny rule is ever considered. GCP firewall rules are stateful as well, so the return traffic for these HTTP connections is automatically allowed, making HTTP traffic from the internet successful.

Database Migration Service (DMS) uses continuous MySQL binlog replication to synchronize your on-premises source with Cloud SQL, enabling near-zero downtime cutover. It automatically manages replication health, VPC connectivity, and can fail back to the source if needed, making it the only option that meets the requirement of minimal downtime and a managed destination.

Configuring two budget alerts at 80% and 100% satisfies the requirement precisely: the 80% threshold warns you that costs are approaching the limit while there is still time to act, and the 100% threshold notifies you the moment the budget is fully consumed. Google Cloud's budget feature allows multiple alert thresholds on the same budget, each published to your selected notification channels. This approach avoids alert fatigue and covers both proactive and reactive notification needs.

Cloud Run executes stateless containers on a fully managed platform, where each instance only receives compute billing while actually processing a request and the service can scale down to zero when no traffic arrives. It automatically provisions instances based on concurrency and can start many instances to handle bursts, with optional min instances for latency-sensitive workloads. A containerized web application is an ideal fit because Cloud Run accepts any container image that listens on a port, and integrates directly with Cloud Build and Artifact Registry.

Cloud Build Triggers are the native, fully managed CI/CD solution on Google Cloud. Configuring a trigger on the main branch means every push automatically executes a pipeline defined in cloudbuild.yaml, which can include steps for unit tests, container image building with Kaniko or Buildpacks, pushing to Artifact Registry, and deploying to a GKE cluster using the kubectl or gke-deploy builder. This is exactly the intended use case, with built-in integration, logging, and minimal operational overhead.

The correct answer is that a linked billing account prevents project deletion. Google Cloud requires you to disable billing for a project before it can be deleted, because deletion finalizes cost responsibility and prevents accidental ongoing charges. The console will display an error such as 'Billing must be disabled' if the project is still linked to a billing account. You must detach the billing account or disable the project's billing, then initiate the deletion process.

Workload Identity is the recommended GKE authentication mechanism because it binds a Kubernetes Service Account to a Google Service Account via the `iam.gke.io/gcp-service-account` annotation. Pods automatically receive short-lived OAuth 2.0 access tokens from the GKE metadata server, eliminating the need to create, store, or rotate any service account key files. Since the mapped Google Service Account holds only `roles/cloudtranslate.user`, access is strictly scoped to the Translation API for that workload, satisfying least privilege. The node pool's service account only needs `roles/iam.workloadIdentityUser` to enable impersonation, so node-level permissions stay minimal.

max-unavailable: 2 limits simultaneous unavailable nodes to 2, meeting the requirement. max-surge: 0 means no extra nodes are provisioned (workloads are rescheduled as nodes drain sequentially in pairs).

Instance metadata is a key-value store exposed by the metadata server to every VM, and it is the recommended way to pass configuration parameters to preemptible VMs without baking them into the image. Because preemptible VMs can be recreated at any time, metadata lets the same image serve many different configurations; startup scripts or agents can read those values at boot to adapt the workload. This keeps the image generic and enables dynamic, per-instance configuration even when thousands of ephemeral VMs are launched from one template.

This is the exact HA VPN architecture: one regional HA VPN gateway exposes two external IP addresses (called interfaces) in the same region, and each interface forms its own IPsec tunnel to a different on-premises device. The two tunnels run as an active/active or active/standby pair using BGP dynamic routing, so if one on-premises device or tunnel fails, the Cloud Router can withdraw routes and send traffic through the surviving tunnel. This configuration is required to meet the 99.99% availability SLA for Cloud VPN.