Google Associate Cloud Engineer (ACE) — Questions 526–600

A custom role lets you assemble an exact allowlist of permissions, such as compute.instances.create, start, and stop, while deliberately omitting compute.instances.delete. This satisfies the developer requirement to create and manage instances without granting the destructive capability to terminate them, enforcing least privilege. Because permissions map directly to specific API methods, you can precisely exclude deletion without losing any other management functionality.

Cloud Tasks decouples the direct invocation path by enqueuing messages that are asynchronously delivered to your function, providing built-in retries with configurable deadlines, exponential backoff, and rate limiting that prevent overload and handle transient failures. This decoupling means the caller's success is not dependent on the function being immediately available, and tasks are queued persistently so no request is lost if the function is temporarily unavailable. It also smooths burst traffic, which is a core reliability practice.

Cloud Build's availableSecrets.secretManager field is the recommended way to reference a Secret Manager secret at build time. The secret value is fetched by Cloud Build using the build service account's IAM permissions and injected as an environment variable only into the specific build step that declares it, so it never appears in the source repository. Because the value is not written to the build config or log, this approach protects the API key while keeping the build reproducible and auditable.

This command correctly uses gcloud sql instances create with the supported database version MYSQL_8_0, the properly prefixed tier db-n1-standard-2, the target region us-central1, and the --root-password flag to set the initial root password. These are all valid and required parameters for provisioning a Cloud SQL for MySQL 8.0 instance from the command line.

Admin Activity logs record every API call that creates, modifies, or deletes a resource, including governance changes such as IAM bindings, while Data Access logs capture DATA_READ and DATA_WRITE calls that read or change data, and include the request payload. Together they cover both the control-plane and data-plane aspects of all employee API calls, which is exactly what the scenario requires for complete audit coverage.

Configuring partition expiration directly on a date-partitioned table is correct because BigQuery automatically deletes entire partitions whose partition boundary is older than the configured number of days, without any user-initiated queries or jobs. For example, setting partition expiration to 180 days makes BigQuery drop any daily partition whose date is more than 180 days in the past, effectively retaining the most recent 180 days of rolling data. This is the most efficient, low-cost, and fully managed approach, as it uses no query slots and requires no scheduler, making it ideal for time-series and log data.

Google automatically applies encryption to all VM-to-VM traffic in transit within its network using the cryptographic capabilities built into Google's physical network infrastructure. This includes traffic between GKE nodes in the same cluster or across clusters, whether they are in the same zone or different regions. No configuration or key management is required from the customer, and this protection is independent of application-level protocols like TLS.

roles/logging.viewer is the predefined role for read-only access to Cloud Logging data. It includes permissions such as logging.logEntries.list, logging.logEntries.get, and logging.logs.list, which are required to view audit logs in the Logs Explorer. This role cannot modify log sinks or delete logs, providing the least-privileged access to view audit logs.

A managed instance group (MIG) with instances distributed across multiple zones directly mitigates preemption by ensuring that a single zone's preemption event doesn't wipe out the entire batch capacity; MIGs also provide automatic instance replacement via health checks and instance re-creation. Enabling autoscaling lets the group scale the number of preemptible VMs based on job demand or queue depth, and you can even configure the MIG to use preemptible VMs as the default while maintaining a buffer of on-demand instances if needed. This combination creates a resilient, self-healing architecture that tolerates preemption events and keeps the batch job making progress, which is exactly what the question requires.

Data Access audit logs for Cloud Storage capture object-level read (e.g., object.get) and write (e.g., object.create) API calls, including the principal, source IP, timestamp, and the specific resource accessed. Because Data Access audit logs are disabled by default, they must be explicitly enabled in the project's IAM audit config to satisfy security auditing requirements.

Admin Activity audit logs record all API calls that modify configuration or metadata of resources, including IAM policy changes. In Cloud Logging, they are enabled by default and retained for 400 days. Since setting an IAM policy (e.g., projects.setIamPolicy) is a configuration-modifying operation, it's captured here. That's why this is the correct choice.

An organization policy with a custom constraint is the correct answer because it can enforce resource naming patterns at the resource creation step. By defining a custom constraint with a CEL condition that checks the resource name against a regex (for example, `resource.name.matches('^[a-z]+[-][0-9]+$')`), the policy rejects any project that does not conform. This policy applies hierarchically across all projects under the organization, making it a proactive, centralized, and enforceable naming governance control.

BigQuery is Google Cloud's serverless, highly scalable data warehouse optimized for analytical queries on massive datasets. It separates storage from compute, uses columnar storage and a distributed query engine, and offers pay-per-query pricing, so you only pay for the data scanned. With features like partitioning, clustering, and BI Engine, it is the ideal choice for complex analytical workloads without managing infrastructure.

A signed URL is a URL that includes an expiration timestamp, a signature, and a signature algorithm, generated using your service account's private key; when accessed, Cloud Storage verifies the signature and grants access only to the specific object path embedded in the URL. This is the correct choice because it gives the partner temporary, revocable access to exactly the identified files without modifying IAM policies or making data public. The signature is cryptographically tied to the object name, bucket, and expiration, so the URL cannot be altered to access other objects.

Cloud Shell automatically mounts a persistent home directory at ~ on a small but durable disk that is attached to your user profile across sessions. Any files, Bash scripts, or gcloud configuration files you place in ~ remain available even when the underlying VM is replaced. This is the intended and simplest way to preserve your work in Cloud Shell, and it also houses the .config directories used by gcloud.

StatefulSets are designed for applications that need stable network identities and dedicated persistent storage for each replica. The volumeClaimTemplates field causes Kubernetes to generate a unique PVC for every pod, which binds to a persistent disk that remains even after the pod is terminated. When a StatefulSet pod is rescheduled, it reattaches to the same PVC, ensuring data persists and remains exclusively associated with that pod.

Setting min-instances to a value greater than 0, such as 1, instructs Cloud Run to keep at least one instance always running and fully initialized, so baseline traffic never experiences the latency penalty of a cold start. This pre-warmed instance is ready to serve immediately, eliminating the delay caused by pulling a container image and booting the runtime. Note that this approach incurs billing even when there is no traffic, and it only removes cold starts for the first instance; a sudden burst beyond that instance's concurrency can still trigger new cold starts.

Horizontal Pod Autoscaler (HPA) continuously observes the average CPU utilization of the pods in a Deployment (via metrics-server) and automatically adjusts the `replicas` field to keep utilization near the configured target, e.g., 70%. This directly fulfills the stated need to scale the application based on load — when CPU usage rises, HPA adds pods; when it drops, HPA removes excess pods. Note that HPA is about pod-level elasticity and does not by itself provide zone resilience; to meet the production requirement fully, you would combine HPA with a regional multi-zone cluster so that scaled-out pods can be scheduled across failure domains.

Cloud Pub/Sub's fan-out model is exactly this scenario: the payment service publishes each business event once to a single topic, and then each downstream service creates its own subscription to that same topic. Pub/Sub delivers every message to every subscription independently, with each subscription maintaining its own acknowledgment state, so consumers can process different views of the same event without coordinating with one another or with the publisher. This provides at-least-once delivery, independent retries, and horizontal scaling per service, which is why it's the correct decoupled pattern.

HorizontalPodAutoscaler continuously monitors a selected metric, typically CPU utilization, and reconciles the 'replicas' field of a Deployment or ReplicaSet to the number needed to meet the target. When average CPU exceeds the configured threshold, HPA increases replica count; when demand drops, it decreases pods to help control cost. This is precisely the behavior required to scale a containerized web application horizontally based on workload pressure.

HSM protection level keys are generated and stored inside FIPS 140-2 Level 3 HSMs. They are non-exportable by design. CMEK with Cloud KMS HSM keys gives your team control while meeting HSM and non-exportability requirements.

A BigQuery federated query with an external table definition lets you query data that remains in Cloud Storage without loading it into BigQuery's managed storage. You define an external table pointing at files in GCS (CSV, JSON, Avro, Parquet, etc.) with optional schema auto-detection, and the query engine reads the source natively at query time. This matches a one-time analysis by eliminating the load job, copying no data, and charging only for the bytes scanned during execution.

A Cloud Router alone is only a BGP session manager; it does not perform address translation by itself. To enable NAT on a VPC, you must explicitly create a Cloud NAT gateway and attach it to the Cloud Router for a given region and subnetwork, which then maps private IPs to a pool of external IPs. Without that gateway, outbound packets from private instances are dropped when they try to reach the internet, regardless of routing.

This command creates a regional GKE cluster in the us-central1 region, using --region rather than --zone. The --num-nodes=3 flag sets three e2-medium nodes in the cluster, and the regional scope means the control plane is replicated across the zones in us-central1, providing higher availability. This is the only option that correctly combines the required node specification with a regional location.

Creating a regional route in us-central1 with the on-premises CIDR as the destination and the Cloud VPN tunnel as the next hop is the standard way to direct that traffic through the desired tunnel. Because the VPN tunnel is a regional resource in us-central1, the route must be created in that same region. Additionally, a firewall rule must allow the traffic from the source VPC subnets to the on-premises range, otherwise the packets are dropped even with a valid route.

PSC (Private Service Connect) provisions a forwarding rule in your VPC that allocates an internal IP address as an endpoint for the managed service, such as Cloud SQL. All traffic sent to that internal IP is routed over Google's internal network directly to the service's backends, without traversing the public internet, a VPN, or a NAT gateway. This provides private, low-latency connectivity while keeping the resource entirely within your VPC's IP space.

The HTTP(S) Load Balancer is a correct component because it provides a single anycast IP address that distributes incoming traffic across the backend Compute Engine instances in the managed instance group. It also performs health checks on those instances and automatically routes traffic only to healthy VMs, which is essential for a highly available application and is the standard external entry point for a MIG-based deployment.

The access scopes configured on the instance determine the OAuth token's capabilities and are enforced in addition to IAM. In the exhibit, the scope is devstorage.read_only, so the token can only perform read operations on Cloud Storage, even if the service account has a write-capable IAM role like storage.objectAdmin. Because GCS writes use the token's scopes, the API call fails with a scope error before IAM is evaluated. To allow writes, you must either update the instance's access scopes or restart with the correct scope.

Enabling OS Login at the project or instance level, then assigning IAM roles such as roles/compute.osLogin or roles/compute.osAdminLogin to users, is the recommended pattern for SSH access. OS Login links the Linux account on the instance to the user's Google identity, automatically provisions a temporary SSH key when the user runs gcloud compute ssh, and allows instant revocation simply by removing the IAM policy binding.

Exporting detailed billing data to BigQuery is the correct approach because it automatically creates and maintains tables like `gcp_billing_export_v1` within your project's BigQuery dataset. Every project that shares the billing account is included, and you can immediately run SQL queries to analyze costs by project, service, SKU, or label, as well as build dashboards and scheduled queries. This export is the official Google-recommended method for centrally managing and analyzing billing information across an organization.

Running a CDN cache invalidation is the correct and intended way to immediately refresh stale content. Use the gcloud command `gcloud compute url-maps invalidate-cdn-cache [URL_MAP] --path=[PATH_PATTERN]` to purge all matching cached objects from Cloud CDN's edge caches. After invalidation, the next request for that path is forwarded to the Cloud Storage origin, which returns the fresh content and repopulates the cache. This approach is non-destructive, immediate, and highly targeted, allowing you to refresh only the URLs that changed while preserving cached responses for all other paths. Keep in mind that invalidation propagates across edge locations in a few seconds, so it is the best choice when time-sensitive content must be updated without origin disruption or unnecessary cost.

A 3-year committed use discount (CUD) on N2 VMs provides up to a 57% discount off on-demand pricing, the highest discount Google Cloud offers for this machine family. Since the workload is stable and must run continuously, the long-term commitment carries little risk and maximizes cost savings. This makes the 3-year CUD the most cost-effective choice among the options presented.

After purchasing a capacity commitment, you must create a reservation and then create an assignment that associates that reservation with specific projects (or folders/organizations). Once the assignment is in place, query jobs issued from those assigned projects consume the reserved slots, and their usage is billed at the flat-rate, on-demand pricing no longer applies.

A metric threshold alert continuously evaluates a time-series metric (e.g., error rate, request latency, or CPU utilization) against a user-defined threshold, such as 'error rate > 5% for 5 minutes', and immediately triggers a notification when the condition is met. This is precisely the right tool for an SRE who needs to be notified when application error rates exceed an acceptable level, because it supports real-time aggregation, sliding windows, and alerting policies with multiple notification channels. It is the correct answer.

Cloud Run is a managed serverless container platform that executes your container image on demand, automatically scaling instances from zero to thousands based on incoming HTTP traffic and billing only for resources used during request processing. It is purpose-built for stateless HTTP workloads and supports common features like health checks, environment variables, secrets, and gRPC, all without requiring you to provision or manage any servers. For a containerized web application, this directly satisfies the requirement with minimal operational effort and can scale to zero when idle.

This command explicitly associates a specified project with a specified billing account. It is the standard gcloud operation for setting up the billing relationship after project creation, enabling the project to consume paid services. The command requires both the project ID and the billing account ID as arguments, and it performs an API call to the Cloud Billing API. Once run, the project's billing is active and can be used for resource consumption.

Resource Manager Tags are hierarchical key-value pairs that can be attached to projects, folders, and individual resources such as Compute Engine instances. When a tag with key 'environment' and value 'production' is attached, it becomes visible in IAM policy binding conditions through the `resource.getTagKeys()` and `resource.getTagValue()` functions, enabling attribute-based access control. This approach is declarative, preventive, and evaluated at every API request, so it correctly fulfills the requirement to allow access only to production resources.

Workload Identity Federation lets GitHub Actions present its native OIDC token to a Workload Identity Pool provider; the Security Token Service exchanges it for a short-lived Google-issued access token. The workflow then impersonates a service account via IAM bindings without ever creating or storing a service account key file. Conditional attribute mappings can restrict which repositories, branches, or jobs are allowed to impersonate the identity.

Adding a content match with a regular expression is the direct way to verify a specific string pattern in the HTTPS response body. Cloud Monitoring uptime checks accept both substring and regex content matches, allowing you to assert that the page contains a particular marker or dynamic token. This confirms the endpoint is serving expected application content, not just a reachable server.

Cloud NAT is designed to provide source network address translation for private instances that do not have external IP addresses. If an instance is assigned an external IP, even an ephemeral one, its outbound traffic will use that IP as the source address, completely bypassing Cloud NAT. Therefore, the observation that traffic is 'not being NATed' is exactly what would happen when instances have external IPs, not a sign of NAT misconfiguration.

The compute.viewer role provides read-only permissions for Compute Engine resources, including compute.instances.get, compute.instances.list, and similar operations. The IAM condition resource.labels.environment == "production" restricts the resource's access to only those instances carrying that exact label. This combination precisely meets the administrator's requirement: the service account can view production instances but cannot modify or delete them. The condition is evaluated at access time against the instance's labels, so unlabeled or differently labeled instances are excluded.

Upgrading the cluster's control plane with `gcloud container clusters upgrade` is the correct first step because GKE enforces a maximum version skew between the control plane and node pools—typically one minor version. The control plane must be on the target version before node pools can be upgraded, and this command without a `--node-pool` flag updates only the control plane. This ensures the Kubernetes API server and scheduler are consistent with the target version, reducing the risk of API deprecations or incompatibility. It is the only supported way to perform an in-place control plane upgrade while preserving cluster identity and state.

The command `gcloud iam list-grantable-roles //cloudresourcemanager.googleapis.com/projects/PROJECT_ID` takes a canonical resource name and calls the IAM API's listGrantableRoles method, which returns every role—predefined and custom—that can be placed on that resource's IAM policy. For a project, the required canonical form is the Cloud Resource Manager resource name, prefixed with the service name. This is the only option that directly lists the full set of grantable roles for the project, making it the correct answer.

This is the correct command because it queries the Metrics Server API, which aggregates metrics from kubelets on each node and reports current CPU and memory usage, including percentages of allocatable capacity. It provides a concise per-node summary directly in the terminal, making it the fastest native CLI way to assess live node utilization in the cluster.

roles/compute.viewer is the correct predefined IAM role for a read-only security auditor because it grants only list and get permissions for all Compute Engine resources, including instances, disks, snapshots, images, and instance metadata. It does not include any mutating operations such as start, stop, delete, or modify, nor does it allow changes to IAM policy. This role satisfies the auditor's requirement to inspect the environment without risking unintended changes.

Cloud SQL supports online storage increases without an instance restart or downtime. Running `gcloud sql instances patch [INSTANCE_NAME] --storage-size=[NEW_SIZE]` modifies the persistent disk capacity in place, and the instance continues serving reads and writes during the operation. This directly resolves the immediate capacity alarm for a production database, making it the correct first response among the options.

Cloud Spanner is a fully managed relational database that synchronously replicates data across regions, using TrueTime and Paxos to deliver external consistency for reads and writes. A multi-region configuration can be placed in the three required continents, allowing strongly consistent transactions to commit with lower latency than a single primary and letting local read replicas serve fresh data. It supports ANSI SQL and ACID transactions, so the existing e-commerce application can keep its relational schema.

A counter metric is the correct log-based metric type for this use case, because it increments by one for every log entry that matches the specified filter, such as severity=ERROR. This gives the total number of error logs over the selected time window, which is exactly what the team wants to track. In Cloud Logging, you define a counter-based log metric with a filter and then use it in Monitoring charts or alerts.

Cloud Run Domain Mappings and a Global Load Balancer with a Serverless NEG are both valid, production-ready approaches. Domain Mappings offer the simplest path for a single service: you verify the domain, and Cloud Run automatically provisions a Google-managed TLS certificate. The load balancer approach is better when you need advanced routing, multi-region failover, or CDN/WAF features; a Serverless NEG allows the global external Application Load Balancer to direct traffic to your Cloud Run service. Choose based on whether you need basic custom-domain support or full-fledged edge routing.

Correct: `gcloud organizations list` calls the `resourcemanager.organizations.list` API, which returns only organizations where the caller has permission such as `resourcemanager.organizations.get`. The Organization Viewer role includes this permission, and without it the command exits successfully but shows no rows. An organization admin must grant the user an appropriate IAM role at the organization node for the organization to become visible.

Correct: Deleting default rules removes internet ingress and the default allow-all-internal rule. New rule restricts internal communication to port 443.

Cloud Scheduler is Google Cloud's fully managed cron service, designed specifically to fire off a single HTTP request on a fixed schedule. With a JSON payload and optional OIDC authentication, it can invoke your backup endpoint at 2 AM UTC daily with zero additional infrastructure to manage. It also offers built-in retries and execution logs, but for a simple scheduled HTTP call, no other service or custom code is required — making it the minimal, correct choice.

Coldline is designed for data accessed no more than once per quarter, exactly matching the stated requirement. It offers a low storage cost to minimize spend on long-term retention, with a 90-day minimum storage duration that aligns well with quarterly access. Although retrieval fees are higher than Standard or Nearline, the infrequent access makes Coldline the most cost-effective choice here.

CSEK requires the customer to supply the encryption key with every API request. GCP uses the key transiently and never stores it — Google cannot access data without the customer providing the key each time.

Cloud Storage is a fully supported Terraform remote backend for Google Cloud. When you configure a GCS bucket as a backend, Terraform stores the state file in the bucket, which lets multiple team members access the same state. The backend automatically uses an object lock to prevent concurrent writes, and you can enable bucket versioning to keep a history of state changes, which is essential for rollback and recovery. Additionally, the bucket can be secured with IAM policies, encryption at rest, and access logging.

The gcs backend stores Terraform state in a Cloud Storage bucket, which automatically enables state locking via the bucket's object semantics. While one apply is running, a lock is held so a second 'terraform apply' fails with a lock error, preventing concurrent destructive changes. Enabling versioning on the bucket preserves prior state generations, giving you a rollback path if a state update is corrupted or incorrect.

This load balancer can route to multiple backends across regions and terminate SSL.

A single Cloud SQL instance with a separate schema (database) per customer gives each tenant its own isolated set of tables while sharing the underlying compute and storage resources. Because schemas are logical constructs, a customer can be provisioned in sub-minute time via API calls (e.g., using the Cloud SQL Admin API or Terraform) without restarting the instance or creating a new instance. This design strikes a practical balance: tenant data is separated at the query layer, so a cross-schema error is far less likely than with a shared table, while costs and operational effort stay manageable because you run and maintain only one instance and its connection endpoints.

Cloud Memorystore for Redis is a fully managed in-memory data store that delivers sub-millisecond latency, making it ideal for real-time game session state. Its native key expiration (TTL) automatically clears stale sessions, and the Redis data structure server supports complex session objects such as hashes or sorted sets. Unlike persistent databases, Memorystore is designed for high-throughput, low-latency read/write workloads with occasional data loss tolerated, perfectly matching ephemeral state requirements.

Kustomize organizes Kubernetes manifests as a shared base and environment-specific overlays. The base contains common full resource definitions (Deployment, Service, ConfigMap), while each overlay—for example, dev, staging, or production—contains only the differences to apply, such as the image tag, replica count, or a ConfigMap value. These differences are expressed as patches in the overlay's kustomization.yaml, and running `kubectl apply -k` reads the overlay, fetches the base, and merges them to produce the final, environment-specific manifests.

This is the correct command because autoscaling is a node-pool-level feature. It uses `gcloud container node-pools update`, points at the specific pool with `--cluster=my-cluster`, and enables the Cluster Autoscaler with the valid `--enable-autoscaling` flag. The `--min-nodes 1 --max-nodes 10` range constrains the pool size, and `--region us-central1` correctly specifies the regional control plane where the cluster lives.

Resizing the node pool with `gcloud container clusters resize CLUSTER --node-pool=POOL --num-nodes=N` immediately adds worker nodes, increasing the cluster's total allocatable CPU and memory so that Pending Pods can be scheduled. On GKE, if cluster autoscaler is enabled, it already performs this action automatically; manually resizing is the deterministic fallback. Resizing is non-disruptive and does not terminate existing Pods, making it the ideal solution.

Google Groups can be used as an IAM principal, and roles granted to the group apply to every member automatically. When team members are added to or removed from the group in the Google Admin console or Cloud Identity, their Google Cloud permissions update without anyone having to edit IAM policies directly. This centralizes membership management and avoids per-user service account key handling. It is the recommended pattern for human teams because it couples IAM role grants to an identity directory that already reflects the organization's structure.

Google-managed certificates automatically handle both provisioning and renewal, so you never have to manually track expiration dates or replace certificates. After you configure the certificate on an HTTPS target proxy, Google Cloud's certificate manager regularly checks the certificate's validity and renews it approximately 30 days before expiration, provided the domain's DNS record still points to the load balancer. This automation is the key advantage because it prevents outages caused by expired certificates.

Immediately deleting or disabling the service account key in the Cloud Console or with gcloud revokes the credential at the source, making it invalid for all OAuth token requests regardless of who possesses it. This is the highest-priority action because it stops ongoing unauthorized access in seconds and does not depend on how widely the key was distributed. After this containment step, you can investigate the exposure, rotate remaining keys, and audit usage logs without an active threat.

Organization policies — The Organization Policy service is the correct mechanism for centrally governing multiple projects. It applies constraints like `compute.vmExternalIpAccess` or `iam.disableServiceAccountKeyCreation` at the organization, folder, or project level, and these constraints are inherited by all descendant resources. This provides a hierarchy-wide, enforceable governance layer that either permits or denies certain API calls before they execute. It directly meets the requirement to manage and enforce rules across all projects in the organization.

Creating one budget per project and setting the 'Scoped to' field to that project is the correct, efficient approach. In the Google Cloud console, budgets are created at the billing account level but can be scoped to a specific project, which allows the budget amount and alert thresholds to apply exclusively to that project's costs. This directly enables per-department tracking if each department maps to a project, and it provides native budget alert notifications, exactly as required.

Custom mode VPC is the correct choice because it begins with no subnets and lets the engineer explicitly define each subnet's IP CIDR range and region. This provides full control over the address space, including private or publicly routable blocks, to avoid conflicts and meet design requirements. For a task that requires setting custom subnet IP ranges per region, this mode is the only way to do so natively.

When the relevant API is disabled in the project, any request using a service account or user credential fails with a message indicating either 'API has not been used' or that the endpoint cannot be reached. Google Cloud requires an API to be enabled per project before its methods are callable, regardless of the caller's IAM roles. Enabling the API via gcloud services enable or the Cloud Console resolves the error and does not require changing IAM roles.

Cloud Billing budgets natively support multiple alert thresholds, so you can set percentage thresholds at 80% and 100% of your budget amount. When actual spending crosses each threshold, Cloud Billing automatically sends email notifications to the configured recipients, and can also publish to Pub/Sub for programmatic handling. This is the simplest and most reliable method because it requires no custom code, no external services, and no additional monitoring setup.

Preemptible VMs cost up to 60–80% less than standard on-demand VMs and are explicitly designed for fault-tolerant, batch workloads that can be interrupted. Compute Engine can terminate a preemptible VM at any time, but it will always run for at least 30 seconds, and the job should be coded to handle early termination by persisting progress to durable storage. Because this nightly batch job is by nature interruptible and short-lived, preemptible VMs are the cost-optimal choice and align with Google's best practices for batch processing.

bq load is the correct BigQuery CLI command to initiate a batch load job from Cloud Storage. It creates a load job that reads the CSV file at the given URI, parses it according to the specified --source_format, and writes rows into the target table (mydataset.mytable), which can be appended to or replace. This is the standard, idempotent way to bulk-load CSV data into BigQuery.

Cloud Storage Object Lifecycle Management lets you define rules at the bucket level, for example an action to set the storage class to Coldline when `age` is 90 days, and a delete action when `age` is 365 days. These rules are evaluated asynchronously by Google Cloud for all current and future objects, so you get automatic, fully managed transition and deletion behavior without any external triggers. This is the intended mechanism for exactly this requirement, and it is both simpler and more reliable than any custom event-driven or scheduler-based solution.

With Shared VPC (XPN), the shared services project acts as the host, owning the VPC networks and subnets that service projects' VMs consume. The host project's network admin has centralized visibility and control over routing, firewall policies (including hierarchical firewall rules), and subnet allocation, while service project owners can deploy VMs without managing network infrastructure. This is the recommended pattern when multiple projects need to consume common services over private IPs because it enforces consistent governance, simplifies auditing, and scales without adding peering or VPN links per project.