Google Associate Cloud Engineer (ACE) — Questions 676–750

This command correctly retrieves the IAM policy for the specified GCP project, including all role bindings for members at the project level. The --format json flag ensures the output is machine-readable JSON, which is useful for automation or programmatic inspection. It is the standard gcloud command for viewing project-level IAM policies.

This is the correct operational behavior. After rotating the key version in Cloud KMS, you must restart the Cloud SQL instance using the console, gcloud command, or API so that it recognizes the new key version as the encryption key for upcoming writes. The restart is required because the instance caches the old key version in memory, and the new version is only picked up during instance startup. This allows existing data to still be decrypted with the prior version while new encrypted data uses the updated version.

This is the correct filter because Cloud Run automatically converts JSON-formatted lines written to stdout/stderr into structured LogEntry objects whose contents populate jsonPayload. Using jsonPayload.user_id="12345" directly compares the value of the user_id field inside that JSON object, giving a precise, indexed lookup. It follows Cloud Logging's filter syntax and avoids text scanning or guessing at metadata.

Cloud SQL with High Availability (HA) configuration is the correct choice because it automatically provisions a standby instance in a different zone within the same region and uses synchronous replication to keep it current. When the primary fails, Cloud SQL detects the outage and automatically promotes the standby, typically within seconds, and the public IP address remains the same so existing applications can reconnect without code changes. This gives you a simple, managed, zone-redundant solution that meets the requirement for automatic failover with no application-level logic.

The default VPC network ships with the `default-allow-ssh` ingress rule, which permits TCP port 22 from 0.0.0.0/0 and overrides the absence of custom rules. Deleting it removes the only path allowing SSH, satisfying the requirement that inbound traffic be limited to ports 80 and 443.

Deploying with `--no-allow-unauthenticated` enforces that only authenticated requests carrying a valid OIDC token are accepted by the Cloud Run service. When the Pub/Sub subscription is configured with a service account that has the `roles/run.invoker` role on the service, Pub/Sub uses that identity to mint an OIDC token with the correct audience, and Cloud Run recognizes the token as authorized. This is the recommended secure pattern for triggering Cloud Run from Pub/Sub.

The resource google_project_iam_member defines its IAM principal using a singular 'member' argument, whereas the plural 'members' argument is only valid on google_project_iam_binding (which manages a full set of members for a specific role). Terraform's schema validation for the google_project_iam_member resource does not recognize 'members' and therefore raises an 'unexpected argument' error during the plan. To fix this, change the argument key from 'members' to 'member', ensuring the configuration matches the resource's expected singular attribute for assigning one principal to a project role.

An organization policy with the constraints/gcp-resource-locations constraint defines an explicit allowlist of regions where resources can be created. When set at the organization, folder, or project level, it is enforced synchronously at resource creation time, and any API request targeting a location outside the allowlist is rejected with an error. This is the intended, preventative control for enforcing data residency or regulatory location requirements across Google Cloud.

Sustained use discounts are applied automatically when a VM runs for more than 25% of a billing month (approximately 186 hours), without requiring any upfront commitment or configuration. For a VM running 12 hours daily, monthly usage is roughly 360 hours, so the discount kicks in automatically after the threshold is crossed, reducing the bill by up to 20-30% based on the on-demand price — exactly the kind of predictable, usage-based discount this team can estimate.

A JSON key file downloaded for the service account is a valid authentication method because it contains the private key associated with the service account's identity. Applications can load this file via the GOOGLE_APPLICATION_CREDENTIALS environment variable or directly in client libraries (e.g., service_account.Credentials.from_service_account_file). This enables the application to sign requests and obtain OAuth2 access tokens that prove it is acting as that service account, making it suitable for server-to-server authentication.

The Service Account API's keys.create method supports user-managed keys with a validBeforeTime (expiration) field, allowing you to set an exact expiration timestamp at creation time. When a key reaches that time, it becomes invalid, effectively forcing a controlled lifespan and enforcing rotation via a key refresh process. This is a native Google Cloud mechanism for key rotation that does not require external automation, making it a correct approach.

This is the correct service-level command for a precise traffic split between two existing revisions. It specifies both revisions explicitly, so Cloud Run routes exactly 10% of requests to rev2 and 90% to rev1; percentages must sum to 100 and should be entered as bare integers (no '%' sign). Because it uses `--to-revisions` on `update-traffic`, it works for rollbacks and gradual shifts without creating a new revision.

This is the correct way to open an interactive shell inside the `api-pod-7d4f9` Pod. `-i` keeps STDIN open so you can type commands, `-t` allocates a pseudo-TTY for a proper terminal session, and `-n production` selects the namespace where the Pod lives. The `-- /bin/bash` specifies the command to run inside the first container of the Pod, and because most application images include bash, this gives you an interactive bash shell. If bash were not installed, you could substitute `/bin/sh` or another available shell.

The primary purpose of gcloud init is to bootstrap the gcloud command-line tool by creating a new configuration, authenticating with your Google account or service account, and setting properties like the default project, region, and zone. It is the standard first step when installing or reinstalling the gcloud SDK on a new machine or for setting up an isolated environment.

Creating multiple named configurations with gcloud config configurations create and activating them via gcloud config configurations activate is the officially recommended pattern for frequent context switching. Each configuration stores its own project, account, region, and other properties, so you can define a distinct environment for every GCP project or workflow. Activation is instantaneous and deterministic, and you can even use the --configuration flag to run a single command in a non-default configuration without changing your active context, enabling safe automation and parallel work.

Enabling the gcr.io compatibility redirect in the Artifact Registry project settings maps the legacy gcr.io hostname to the corresponding Artifact Registry repository, so existing container commands like docker pull gcr.io/my-project/my-image continue to work without immediate script changes. This is the intended migration path because it lets you incrementally move workloads from Container Registry to Artifact Registry while preserving CI/CD pipeline behavior. Without this setting, gcr.io URLs continue to hit the deprecated Container Registry service instead of the new repository, risking breakage when Container Registry is decommissioned.

Cloud Identity is the correct choice because it is Google's Identity-as-a-Service (IDaaS) solution that centrally manages user accounts, groups, and security policies for a project. It provides features like two-step verification (2SV), single sign-on (SSO), and session management, which directly enforce authentication security for IAM users. As the identity provider for Cloud Platform, it ensures that only properly authenticated and policy-compliant users can access project resources.

The `oldest_unacked_message_age` metric, available in Cloud Monitoring under `pubsub.googleapis.com/subscription/oldest_unacked_message_age`, is a gauge metric that reports, per subscription, the age of the oldest message that has not yet been acknowledged. A high or increasing value directly indicates that the subscriber is not keeping up with the message flow, representing a growing backlog. This is the standard and most direct way to detect consumer lag in Cloud Pub/Sub, making it the correct diagnostic tool for the scenario.

Attaching a service account to the VM and assigning it the Storage Object Viewer role is the correct approach because it gives the instance a dedicated machine identity with least-privilege access to read objects. The application can automatically obtain OAuth tokens from the instance metadata server without needing to store any credentials locally. This works seamlessly with the Cloud Storage client libraries, which automatically pick up the attached service account's credentials. It also ensures rotation and revocation are managed by Google Cloud, not by application code.

Immediately returning an acknowledgment after publishing the job to Cloud Pub/Sub gives the user a fast response while decoupling API availability from transcoding latency. Cloud Pub/Sub durably buffers the messages, so a burst of uploads doesn't cause lost work or API saturation. Autoscaling Compute Engine or Cloud Run workers pull messages at their own pace and perform transcoding independently, making the pipeline elastic and burst-tolerant. This is the canonical asynchronous, event-driven media-processing pattern on Google Cloud.

Without memory requests, Pods are classified BestEffort, so the kubelet evicts them first under node memory pressure. Declaring explicit memory requests makes each Pod Burstable or Guaranteed, giving the scheduler accurate placement data and the kubelet a defined eviction ranking.

Predefined WAF rules at Cloud Armor's layer 7 evaluate request payloads against signatures for SQL injection and cross-site scripting. This satisfies the stem's requirement to block common web attacks, which IP-based allow rules alone cannot inspect or mitigate.

gcloud app deploy is the correct command to deploy an App Engine Standard application. It reads the app.yaml from the current directory, packages the source code, uploads it, and creates or updates the service version while routing traffic to the new deployment.

Cloud Run (multi-region) and Cloud Spanner (multi-region) together provide a truly global, automatically failing-over architecture. Spanner uses synchronous replication across multiple regions with the Paxos protocol, providing both strong consistency and automatic failover without manual intervention, unlike Cloud SQL. Cloud Run multi-region services automatically route traffic to the nearest healthy region, and when paired with Spanner's multi-region configuration, the entire application stack becomes resilient to both zonal and regional outages. This combination satisfies the low-latency, global distribution, and relational requirements of the multi-tier application.

The `roles/secretmanager.admin` role includes the `secretmanager.secrets.create` permission required for adding a new secret via the Cloud Console, gcloud CLI, or Secret Manager API. It also grants full management of versions, IAM policies, and deletion, so it is the predefined role that reliably supports all CI/CD operations that need to provision and rotate secrets.

VPC firewall rules are stateful and evaluated in priority order, with an implicit deny-all ingress rule at priority 65535 that blocks any inbound traffic not explicitly allowed. An allow rule for tcp:443 from 0.0.0.0/0 targeting the 'web-server' tag explicitly permits HTTPS while all other ports remain implicitly denied, so no explicit deny rule is necessary. This single rule is sufficient because GCP's firewall model defaults to deny when no match exists.

kubectl top pods -n production is the correct way to inspect actual resource consumption because it directly queries the metrics-server, which aggregates per-pod CPU and memory usage from each node's kubelet and cAdvisor. The command renders a table with columns for CPU (cores) and memory (MiB) along with the container breakdown, filtered to the production namespace. It provides a near-real-time snapshot of utilization, not just configured requests or limits, and is the standard CLI tool for verifying which pods are consuming the most resources.

Using `severity >= "ERROR"` correctly matches all log entries with severity level ERROR or higher (CRITICAL, ALERT, EMERGENCY) across all resource types, which is the intended scope. The time range is not part of the filter; you set the range (e.g., last 24 hours) via the time picker in the Cloud Console, which is a best practice. This filter is precise and avoids unnecessary restrictions on log streams or resource types.

gcloud services enable compute.googleapis.com is the correct command to enable the Compute Engine API for a project. The gcloud services enable command accepts the fully qualified service name (compute.googleapis.com) and provisions access for the project, making it available for use with gcloud compute commands, API calls, and console operations. This is the standard, documented way to turn on a Google API in a project.

Object Lifecycle Management is a native Cloud Storage feature that lets you define rules to automatically delete or transition objects based on conditions like age. A rule with action 'Delete' and condition 'Age: 30 days' will remove objects that are at least 30 days old. This directly satisfies the developer's requirement for scheduled deletion, making it the correct choice.

Private Google Access on the subnet is the correct configuration to enable VMs without external IPs to reach Google APIs and services. When enabled, the subnet's VMs can send traffic to Google's public API IPs, which are then routed internally through the VPC's default route and into Google's network without ever needing an external IP. This is a subnet-level Boolean flag that must be turned on for each subnet where you want the capability; it applies to the entire subnet and works with the standard default route. Enabling this is the direct, documented mechanism that satisfies the security engineer's requirement.

Cloud DNS peering is the intended solution: you configure a DNS peering zone in the new VPC that targets the source VPC's private zone, and the new VPC's resolver forwards queries for that zone to the source VPC's Cloud DNS. This creates a unidirectional resolution path, so if you need bidirectional resolution you must create a separate peering zone in the opposite direction. The peering works even without VPC peering because the query is handled by the Cloud DNS infrastructure, not by network routing. It preserves the private zone's visibility scope and requires only the appropriate DNS peering IAM permissions.

Access scopes define the maximum set of APIs an instance can call, while IAM roles determine the actual permissions. By setting scopes to only the required APIs and granting minimal IAM roles, the instance is restricted to exactly the needed APIs. This enforces defense in depth and meets the requirement of limiting access to a specific set.

Rule B has a priority of 500, which is numerically lower than Rule A's priority of 1000, so GCP evaluates Rule B first. Because Rule B's action is to deny and the traffic matches its conditions, that denial is the final decision. Rule A is not evaluated, so the traffic is denied as expected.

The Viewer role provides read-only access to all resources within a project, excluding sensitive data and IAM policies. It allows auditors to view resources without the ability to modify them. This role is appropriate for granting broad read access while preventing changes, and it does not include permissions to alter IAM policies.

The correct approach is to define a filter expression in Cloud Logging that matches the error logs (e.g., severity=ERROR or specific text), then use that filter to create a logs-based metric. The metric counter increments for every matching log entry, and the filter becomes the metric's definition, allowing you to alert on the count over time.

The Global external Application Load Load Balancer is built on Google's global anycast infrastructure, using a single global IP address that accepts HTTPS traffic at Google's edge points around the world. It then routes requests over Google's private backbone to the nearest healthy backend, regardless of the backend's region, enabling a true global load-balancing. This makes it the only option that satisfies the dual requirements of HTTP/HTTPS content delivery and multi-region global routing.

Correct: --concurrency controls the maximum number of simultaneous requests that each container instance can process at the same time. With a spike, setting it to 10 means an instance will accept only 10 in-flight requests and Cloud Run will automatically spin up additional instances to handle the remaining traffic, preventing any single instance from being overwhelmed. It directly manages per-instance load rather than total capacity or request duration.

A managed instance group (MIG) automatically creates and manages instances based on an instance template. It supports autohealing by recreating instances that fail health checks, and it can autoscale based on CPU utilization or other metrics. This directly meets the requirement for automatic repair and scaling, making it the correct choice for the stateless web application.

Creating a cross-region read replica in europe-west1 is correct because Cloud SQL supports read-only replicas in a different region, using asynchronous replication to serve queries close to the users. This reduces read latency for European users while keeping writes on the primary instance. The replica can also be manually promoted to a standalone primary for disaster recovery, but it does not require an HA configuration or additional on-premises infrastructure.

Cloud NAT lets instances without external IP addresses initiate outbound connections to the internet for updates and patches, while remaining unreachable from inbound internet traffic. This satisfies the requirement for private instances to obtain updates without exposing them publicly.

This is the correct command because GKE exposes node-pool-level autoscaling through the container API. Running `gcloud container node-pools update NODE_POOL --cluster=CLUSTER --enable-autoscaling --min-nodes=MIN --max-nodes=MAX` turns on the cluster autoscaler for that specific node pool, allowing GKE to add or remove nodes within the configured limits based on resource demand. The command can also be used later to adjust min/max limits or disable autoscaling on existing node pools.

The correct command to enable the Kubernetes Engine API is `gcloud services enable container.googleapis.com`. This calls the Service Usage API to activate the service in the current Google Cloud project, making it possible to later create and manage GKE clusters. Enabling the API is a prerequisite that also links the service to the project's billing account; until this is done, any GKE resource creation will fail with an error indicating the API is disabled.

A managed instance group with an autoscaling policy satisfies the CPU-based scaling requirement: the MIG maintains identical Compute Engine instances, while the autoscaling policy adds or removes instances when average CPU utilisation crosses the configured target. The load balancer then distributes traffic across the group's instances.

A signed URL is a time-limited, cryptographically authenticated URL that Cloud Storage generates for a specific object and HTTP method (e.g., GET). It is created by signing the object path, a validity window, and an expiration timestamp with a service account's private key. The vendor receives the URL, requires no GCP account or credentials, and access is automatically invalidated after the 48-hour expiry, making it the correct tool for temporary, controlled sharing.

Cloud NAT, configured through a Cloud Router, provides managed outbound internet connectivity to private Compute Engine instances without assigning them external IP addresses. It uses the Cloud Router to dynamically exchange routing information with the VPC network, allowing instances with internal IPs to initiate connections to the internet while remaining unreachable from outside. This is the recommended, highly available, and serverless solution because Cloud NAT automatically scales to handle thousands of instances and does not require manual patching or failover configuration.

kubectl describe pod is the correct diagnostic command because it produces a categorized, human-readable report: Pod conditions, init-container and container states (including last terminated reason and exit code), resource requests and limits, QoS class, probe configuration, tolerations, volumes, and a dedicated Events section. That Events section is usually the fastest way to identify why a Pod cannot start—for example, image pull failures, unschedulable nodes, or liveness probe failures—making it the go-to first step in troubleshooting.

Granting the roles/secretmanager.secretAccessor role to the Compute Engine default service account is the correct approach because it gives the instance's identity the minimum permission needed to access secret versions. The instance authenticates through the metadata server, so no long-lived keys are stored on the instance. This makes it the most secure and operationally simple method, and it aligns with Google's recommended practice of using IAM roles on service accounts rather than embedding credentials.

Shared VPC lets a host project export its subnets to service projects, so teams create resources in their own projects while network administration stays centralised. This directly satisfies the stem's requirement for one shared network hosting common services, with per-project resources connecting to it.

This command, `gcloud projects describe my-startup-prod`, queries the Cloud Resource Manager API and returns the project's metadata, including its `projectNumber` field, which is the unique numeric identifier assigned by Google Cloud. Unlike other methods that may be ambiguous or incorrect, this approach works regardless of the project ID's format and is the documented way to retrieve a project number from the CLI. The output also shows the project ID, name, and lifecycle state for confirmation.

Labels are key-value pairs applied to GCP resources, letting you attribute spend to both department and project dimensions and filter billing reports accordingly. They satisfy the requirement to categorise costs across multiple projects, unlike billing accounts or folders, which cannot carry arbitrary cost-tracking metadata.

A Managed Instance Group (MIG) built from the VM, combined with an HTTP(S) load balancer, delivers horizontal scaling by launching additional identical VM instances on demand. The autoscaler monitors metrics like CPU utilization or request rate and adjusts instance count, while the load balancer distributes traffic evenly and performs health checks. This approach is elastic, fault-tolerant, and the standard pattern for stateless, scalable web workloads.

roles/bigquery.dataEditor is the correct choice because it provides the necessary permissions for a data analyst to run queries, including bigquery.jobs.create to execute query jobs and bigquery.tables.getData to read table contents. It also allows creating and updating tables within datasets, striking the right balance between access and control. Unlike broader roles, it does not grant dataset-level deletion or permission management, aligning with the principle of least privilege for a typical analyst use case.

Object Lifecycle Management (OLM) is the native, serverless solution for this exact scenario. You can define a rule with a `SetStorageClass` action to transition objects to Nearline 7 days after creation, and a separate `Delete` action to permanently remove them after 30 days. Both actions live in the same bucket's lifecycle configuration, so no custom code, scheduler, or manual intervention is needed, and Google Cloud executes the rules automatically.

Dataflow's Beam runner leverages the Pub/Sub I/O source that checkpoints its read position and assigns each message a unique ID when it is pulled; on replay, the runner deduplicates message IDs so that the pipeline processes each message exactly once even if Pub/Sub redelivers. This is a built-in, distributed, and managed capability of Dataflow, enabling exactly-once semantics without custom application code. It also supports autoscaling and checkpointing with Apache Beam's stateful processing. Therefore, it is the correct choice for a managed exactly-once processing guarantee.

Cloud Monitoring includes native uptime checks that actively send HTTPS GET requests to the external endpoint from multiple global locations, verifying that the service is reachable and that expected HTTP status codes are returned. You can set response-time thresholds and alerting policies on these checks to trigger notifications when the endpoint fails or becomes slow. This makes it the correct service for monitoring endpoint availability rather than merely analyzing its internal behavior.

A connection pooler like PgBouncer sits between the microservices and Cloud SQL, multiplexing many client connections over a small set of persistent database connections using transaction-level pooling. For example, thousands of microservice connections can be served by just tens of actual PostgreSQL connections, keeping the database well under max_connections and reducing per-connection memory overhead. This directly addresses the root cause of connection proliferation and is the correct fix because it lowers the true connection count Cloud SQL must manage.

Stopping the instance is the correct approach because it triggers a clean guest OS shutdown, allowing filesystem caches to be flushed and applications to close files gracefully. After the instance is in the `TERMINATED` state, the persistent disk is quiescent, and running `gcloud compute disks snapshot` captures a point-in-time image that is both crash-consistent and application-consistent for most setups. Once the snapshot completes, you can restart the instance with `gcloud compute instances start` and resume operations with confidence that the snapshot reflects a known-good state.

Folders are correct because they serve as intermediate grouping nodes within the resource hierarchy, sitting directly below an Organization and above Projects. They allow you to group teams, products, or departments and apply IAM policies and organization policies at that group level, which are inherited by all contained projects. Folders can also nest other folders, enabling multi-level administrative boundaries that align with corporate structure.

The compute.setServiceAccount organization policy constraint lets administrators define a list of allowed service account emails that can be used when creating Compute Engine instances or changing an instance's service account. When a user attempts to create an instance with a service account outside this list, the request is denied by the policy enforcement point. This directly enforces the requirement that only the authorized service account is used, making it the correct answer.

This is the expected behavior for a GKE node pool upgrade configured with maxSurge: 1 and maxUnavailable: 0. GKE first provisions an extra node (the surge node) from the new node image, waits until it is Ready, then cordons and drains one old node, rescheduling its pods to the new node. Only after the old node is empty is it deleted, and the process repeats for each node — so no old node is taken offline before a replacement is available, yielding zero downtime.

Cloud Monitoring ingests service-level metrics such as request count, latency, and error rate from GKE, Compute Engine, and App Engine, and can display them in dashboards with percentile aggregations. You can create alerting policies and SLOs to detect when one service's latency breaches a threshold. This metric-centric view identifies which service is slow and when, but does not give the end-to-end span journey through each internal call — that is Cloud Trace's role.

This command correctly creates a Google-managed SSL certificate for the domain 'example.com'. The --domains flag tells the Cloud API to request a managed certificate, which Google will automatically obtain and renew without requiring you to upload a private key. Note that for a global external load balancer, you should also include --global, but the essential syntax for a managed certificate is exactly this.

Attaching the service account via the --service-account flag at instance creation is the correct approach because it binds the identity to the VM and makes credentials available through the metadata server. Code running on the instance can fetch OAuth 2.0 tokens from the metadata endpoint (http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token) and act on behalf of the service account. This avoids managing key files and ensures that IAM permissions are automatically applied to the instance.

Enabling sticky sessions (session affinity) on the existing load balancer forces all requests from a given user to be directed to the same backend instance. However, the session data is still stored in that instance's local memory, so the affinity is only as durable as the instance itself. When the instance is restarted for patching, fails a health check, or is removed during a scale-in event, the load balancer reroutes traffic to a different instance that has no copy of the original session, causing the user to lose their cart or login. Sticky sessions merely tie the client to a VM; they do not replicate or persist the session state across the instance lifecycle.

Cloud Functions billing is consumption-based, charging for three dimensions: the number of invocations, compute time measured in GB-seconds (memory in GB multiplied by execution duration in seconds), and outbound network egress. The monthly free tier (2M invocations, 400K GB-seconds, and 5 GB network egress) is subtracted before per-unit rates apply. With 150M invocations and 7.5M GB-seconds, you would estimate cost by calculating usage above the free tier for each dimension and multiplying by the applicable regional price, making this the only correct approach.

RollingUpdate is the default strategy for Kubernetes Deployments, progressively replacing old Pods with new ones while keeping a minimum number of Pods available at all times. It uses configurable parameters such as maxUnavailable and maxSurge to control how many Pods can be taken down or created beyond the desired replica count, allowing zero-downtime updates without any additional manifests. Since the Deployment controller manages the entire rollout automatically, it is the simplest and most direct way to achieve continuous availability.

Connectivity Tests in Network Intelligence Center perform a simulated hop-by-hop analysis of a packet’s path from a VM to an on-premises IP, dynamically evaluating all applicable VPC firewall rules, routes, Cloud VPN tunnels, and Cloud Interconnect VLAN attachments. This allows the test to pinpoint the exact rule or route that is blocking traffic, such as an egress firewall rule denying traffic to the on-premises CIDR or a missing BGP route advertisement. Unlike simple reachability checks, Connectivity Tests do not require actual traffic or agent installations, making them safe and non-invasive for production troubleshooting.

Enabling the Cloud SQL Admin API via APIs & Services > Library is the correct solution because this error directly indicates that sqladmin.googleapis.com has not been enabled in the project. In the Google Cloud Console, you navigate to APIs & Services > Library, search for 'Cloud SQL Admin API', and click Enable, which turns on the service for that project. The equivalent command-line approach is `gcloud services enable sqladmin.googleapis.com`, and once the API is enabled, the previously failing operation will succeed without any further IAM or quota changes.

Use an organization policy with the constraints/serviceusage.services constraint on the organization, folder, or project to define an allowlist of Google API service names, such as compute.googleapis.com and storage.googleapis.com. This policy is enforced at access time and inherited hierarchically, so no project-level IAM change can bypass the allowed set. It is the proper guardrail to ensure that only approved APIs can be enabled across a new project, regardless of who holds IAM permissions.