Google Associate Cloud Engineer (ACE) — Questions 1–75

Why this answer

How to eliminate wrong answers

Option A is wrong because a CronJob runs on a schedule, not as a prerequisite for Pod startup, and cannot guarantee completion before application pods start. Option C is wrong because a readiness probe only checks if a pod is ready to serve traffic; it does not run scripts before the main container starts, and running a migration in a probe would be unreliable and could cause probe failures. Option D is wrong because a Kubernetes Job runs independently of a Deployment; the Deployment does not automatically wait for a Job to complete unless custom orchestration (e.g., using a hook or manual sequencing) is implemented, which is not a built-in feature.

Why this answer

How to eliminate wrong answers

Option A is wrong because Kubernetes Services do not queue or buffer traffic; they rely on real-time endpoint discovery via the EndpointSlice controller, and with zero endpoints, packets are either rejected or blackholed. Option C is wrong because GKE does not automatically restore a Deployment’s replica count; the user explicitly set `--replicas=0`, and Kubernetes respects that desired state without any built-in high-availability override. Option D is wrong because scaling to 0 immediately terminates Pods; the Deployment is not paused, and Pods do not continue running — `kubectl scale` directly modifies the `spec.replicas` field, triggering a rollout that deletes all Pods.

Why this answer

How to eliminate wrong answers

Option A is wrong because Cloud Armor is a web application firewall (WAF) that protects HTTP/HTTPS traffic at the Google Cloud Armor edge, not SSH traffic at the VM level; it cannot filter SSH connections. Option B is wrong because Cloud NAT provides outbound internet access for private VMs via source network address translation, but it does not control inbound SSH access or restrict source IPs. Option D is wrong because Identity-Aware Proxy (IAP) TCP forwarding enables SSH access without public IPs by tunneling through IAP, but it does not restrict access to approved IP ranges; instead, it uses identity and context-based access, not source IP filtering.

Why this answer

How to eliminate wrong answers

Option A is wrong because a VPC firewall rule would block traffic at the network layer, but the question states the VM is still running and the application has crashed—firewall rules do not detect application crashes. Option C is wrong because Cloud Armor security policies filter traffic based on IP addresses, geographic regions, or layer 7 attributes, not based on the health of the application process on a VM. Option D is wrong because the instance group autoscaling policy reacts to overall load metrics (e.g., CPU utilization, requests per second) and may replace unhealthy instances, but it does not directly prevent the load balancer from sending traffic to a crashed instance—that is the health check's role.

Why this answer

How to eliminate wrong answers

Option A (Nearline Storage) is wrong because it is optimized for data accessed less than once a month, not once a year, and has a 30-day minimum storage duration, making it more expensive for 7-year retention. Option B (Regional persistent disk) is wrong because it is a block storage solution for high-performance compute instances, not designed for archival log storage, and would be prohibitively expensive for 50 TB of rarely accessed data. Option D (Coldline Storage) is wrong because it is designed for data accessed less than once a quarter (90-day minimum storage duration), which is more frequent than once a year, and its storage cost is higher than Archive Storage.

Why this answer

How to eliminate wrong answers

Option A is wrong because VPC Flow Logs only capture metadata about network flows (source, destination, ports, packets) and cannot inspect payload content to determine if TLS is used; they cannot enforce encryption or block traffic. Option B is wrong because restarting pods does not change the underlying Istio configuration or sidecar behavior; if the sidecar is already injected and mTLS is in STRICT mode, a restart will not fix a misconfiguration or a bypass scenario. Option D is wrong because the Istio add-on for GKE node pools is a legacy feature that installs Istio system components; it does not control per-pod mTLS enforcement or fix the issue of pods communicating without TLS when sidecars are already present.

Why this answer

How to eliminate wrong answers

Option A is wrong because VPC Service Controls are a security perimeter mechanism that prevents data exfiltration, not a connectivity method for Cloud Run to reach VPC resources. Option C is wrong because assigning external IPs to Cloud SQL and Memorystore would expose them to the public internet, violating the requirement for no public IP connectivity and introducing security risks. Option D is wrong because Cloud Run does not automatically connect to VPC resources; it runs in a Google-managed network and requires explicit configuration (e.g., Serverless VPC Access or Direct VPC) to access private VPC resources.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because auto-repair is designed to be fully automated; it does not wait for manual intervention—it triggers the repair process after the 10-minute 'NotReady' threshold. Option C is wrong because GKE does not permanently terminate the node; it recreates the node using the same instance template, and the node pool's minimum size is irrelevant to the repair action (the node is replaced, not permanently removed). Option D is wrong because GKE does not leave the unresponsive node running; it drains the node and then recreates it, fully replacing the unhealthy node.

Why this answer

How to eliminate wrong answers

Option A is wrong because N2-standard machines are general-purpose and lack the high-bandwidth GPU interconnect (e.g., NVLink) needed for efficient GPU-bound training; attaching a custom GPU as an on-demand VM incurs higher cost without interruption tolerance benefits. Option C is wrong because E2-highcpu Spot VMs are CPU-optimized and do not support attached GPUs, so they cannot provide GPU access at all, let alone maximize it. Option D is wrong because C3 on-demand VMs are compute-optimized for CPU-intensive tasks, not GPU-bound workloads, and on-demand pricing is significantly higher than Spot, failing the 'lowest cost' requirement.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because it places Folder above Organization, but the Organization is the top-level node in the hierarchy, not a Folder. Option C is wrong because it reverses the order, placing Project above Folder and Organization, whereas Projects are always children of Folders or the Organization. Option D is wrong because it places Project above Folder, but Folders are a higher-level grouping mechanism that can contain multiple projects, so the correct order is Organization → Folder → Project → Resources.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because materialized views precompute and store query results, which can speed up repeated queries but do not optimize the underlying data layout for arbitrary filters on 'customer_id' and 'region'; they also incur storage costs and maintenance complexity. Option C is wrong because creating views for each combination of filters does not reduce the amount of data scanned—views are just saved queries and do not change how BigQuery reads the underlying table; this approach would be impractical and offer no performance benefit. Option D is wrong because changing partitioning to ingestion time (e.g., _PARTITIONTIME) would not improve query performance for filters on 'customer_id' and 'region'; it would only change how partitions are defined, and since queries already filter on 'order_date', the current partitioning is appropriate—ingestion time partitioning is typically used when no natural date column exists.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because `sql.restrictPublicIp` is not a list constraint; list constraints use `deniedValues` or `allowedValues` lists for resources like allowed external IPs, but this constraint is boolean. Option C is wrong because custom constraints require a CEL expression and are used for policies not covered by built-in constraints, but `sql.restrictPublicIp` is a built-in boolean constraint, so no custom definition is needed. Option D is wrong because adding `0.0.0.0/0` to `deniedValues` is a list constraint approach for VPC firewall rules or similar, not for Cloud SQL public IP restriction, and the constraint type is boolean, not list.

Why this answer

How to eliminate wrong answers

Option A is wrong because while gcloud commands can create a project and link billing, a script is imperative and less reproducible than declarative IaC; it also lacks built-in state management and drift detection, making it error-prone for sensitive workloads. Option C is wrong because manually creating the project via Cloud Console and documenting steps in a runbook is not automated and introduces human error, violating the reproducibility requirement. Option D is wrong because Cloud Deployment Manager, while capable of IaC, is a Google-specific tool that is less portable and has a smaller community compared to Terraform; it also requires Python templates, adding complexity without the multi-cloud benefits of Terraform.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because Cloud Functions and Cloud Tasks are serverless compute and task orchestration services, not designed for metric collection or threshold-based alerting; they lack native monitoring of CPU utilization. Option B is wrong because Cloud Audit Logs record administrative actions and access events, not system metrics like CPU utilization, and Cloud Storage is an object store with no alerting capability for real-time metrics. Option D is wrong because Cloud Logging ingests log data, not time-series metrics, and Cloud Functions alone cannot evaluate metric thresholds over a sliding window; the alerting logic must be handled by Cloud Monitoring's alerting policies.

Why this answer

How to eliminate wrong answers

Option A is wrong because Cloud VPN creates an encrypted tunnel to an on-premises network or another cloud, not to the public internet; it does not provide outbound internet access for private VMs. Option C is wrong because a VPC firewall rule allowing egress to 0.0.0.0/0 only permits traffic to leave the VPC, but without a public IP or NAT, the VMs have no routable source IP for internet responses to return, so outbound traffic fails. Option D is wrong because an internal load balancer operates within the VPC and does not provide internet routing; it distributes traffic among backend VMs but cannot translate private IPs to public ones for outbound internet access.

Why this answer

How to eliminate wrong answers

Option A is wrong because a startup script runs only when the instance boots, but it cannot detect termination events or trigger a restart; it would require an external monitoring system to restart the VM, which is not a built-in Compute Engine feature. Option B is wrong because the 'On host maintenance' policy (Migrate VM instance) controls behavior during host maintenance events (e.g., live migration), not automatic restart after unexpected termination. Option D is wrong because firewall rules for health check traffic are used by load balancers to determine instance health, but they do not cause an instance to restart; they only allow or deny traffic.

Why this answer

How to eliminate wrong answers

Option A is wrong because relying on manual enablement by database administrators is error-prone and violates the 'no exceptions' mandate; it does not enforce the policy programmatically. Option B is wrong because Security Command Center can only detect and alert on non-compliant instances after they are created, but it cannot prevent creation or enforce SSL; this is a detective control, not a preventive one. Option C is wrong because Cloud Monitoring alerts and Cloud Functions auto-remediation are reactive and can have a delay, allowing non-compliant instances to exist temporarily; they also cannot block the initial creation of an instance without SSL.

Why this answer

How to eliminate wrong answers

Option B is wrong because `gcloud run services update` with `--tag` does not exist; the `--tag` flag is used with `gcloud run deploy` to assign a traffic tag, not to specify an image version. Option C is wrong because `docker push` only uploads the image to the registry; it does not trigger a Cloud Run deployment, and there is no automatic 'auto-deploy' mechanism unless a Cloud Build trigger is configured separately. Option D is wrong because `--image app:v2.0` is a relative reference that omits the full registry path (`us-central1-docker.pkg.dev/my-project/my-repo/`), which Cloud Run requires to locate the image in Artifact Registry; without the full URI, the command will fail or pull from the wrong source.

Why this answer

How to eliminate wrong answers

Option A is wrong because moving the bucket to a multi-region bucket in Asia does not solve the latency problem for users outside Asia; it only shifts the origin location, and multi-region buckets still serve from a single geographic set of regions, not from edge caches. Option C is wrong because replicating the bucket to multiple regions using storage transfer creates separate copies of data, but the load balancer would still need to route requests to the nearest bucket, which requires additional configuration (e.g., multi-region backend buckets or DNS-based routing) and does not provide the automatic edge caching benefits of Cloud CDN. Option D is wrong because Cloud Interconnect provides dedicated private connectivity between on-premises networks and Google Cloud, not between end users and Google Cloud; it does not improve latency for general internet users in Asia accessing a public web application.

Why this answer

How to eliminate wrong answers

Option A is wrong because `google_project_iam_binding` manages IAM roles and permissions, not API enablement; the `serviceusage.services.enable` permission controls who can enable APIs, but the resource itself does not enable them. Option C is wrong because `google_service_account` creates and manages service accounts, and there is no `enabled_services` block in that resource — API enablement is unrelated to service account configuration. Option D is wrong because `google_project` does not have a `services` argument; API enablement is handled by the separate `google_project_service` resource, and listing services in the project resource would be invalid syntax.

Why this answer

How to eliminate wrong answers

Option A is wrong because enabling automatic storage increase only prevents out-of-disk errors by expanding storage, it does not offload read queries or reduce CPU/memory load from reads. Option B is wrong because increasing the machine type of the primary instance scales up the primary itself but does not offload read traffic; it may temporarily improve performance but does not distribute the read load. Option D is wrong because changing to private IP only affects network connectivity and security, not read query distribution or load reduction.

Why this answer

How to eliminate wrong answers

Option A is wrong because a Global external Application Load Balancer is inherently internet-facing, and while Cloud Armor can block non-VPN IPs, the load balancer itself still has a public IP and is exposed to the internet, violating the requirement that APIs should not be reachable from the public internet. Option C is wrong because a ClusterIP Service is only reachable within the same Kubernetes cluster (not from on-premises systems via VPN) and does not support external IP range allowlisting; it has no external IP at all. Option D is wrong because a NodePort Service exposes the application on a high port on every node's external IP, and while VPC firewall rules can restrict access to VPN IP ranges, the service is still bound to the node's public IP addresses, making it reachable from the internet if the firewall is misconfigured or bypassed, and it does not provide Layer 7 load balancing.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because rotating keys every 90 days does not address the fundamental risk of storing static credentials on laptops; the keys remain exfiltratable between rotations and still represent a persistent attack surface. Option B is wrong because encrypting the JSON key files with Cloud KMS does not remove the static credential from the laptop; the encrypted file still contains the key material that can be decrypted by anyone with access to the encryption key, and the distribution process remains a risk. Option D is wrong because storing the key files in Secret Manager and retrieving them at startup still requires the application to possess a long-lived static credential (the JSON key) at runtime, which can be exfiltrated from memory or disk; the goal is to eliminate the static key entirely, not just move its storage location.

Why this answer

How to eliminate wrong answers

Option A is wrong because VPC firewall rules control network traffic at layers 3 and 4 (IP/port), not application-layer operations like container image pulls; they cannot inspect the registry URL in a pull request. Option C is wrong because Cloud Armor is a web application firewall (WAF) that protects against HTTP/S attacks, not a mechanism to restrict container image sources; it operates at the edge, not on GKE node-to-registry traffic. Option D is wrong because manual review is a procedural control, not a GCP technical control; it is error-prone, unscalable, and does not provide automated enforcement at deployment time.

Why this answer

How to eliminate wrong answers

Option B is wrong because revoking all IAM roles from the node's service account would block ALL pods on that node from accessing GCP APIs, not just the restricted team's pods. Option C is wrong because setting `automountServiceAccountToken: false` only prevents the Kubernetes API service account token from being mounted into the pod; it does not affect the pod's ability to reach the Compute Engine metadata server to obtain the node's service account credentials. Option D is wrong because a ResourceQuota limits resource consumption (CPU, memory, etc.) and cannot restrict network access to specific IP addresses or APIs.

Why this answer

How to eliminate wrong answers

Option A is wrong because stopping the VM is unnecessary for a live resize and introduces downtime; also, taking the snapshot after resizing would capture the resized disk, not the original state for safety. Option C is wrong because `gcloud compute instances set-disk-auto-delete` controls whether a disk is deleted when the instance is deleted, not disk resizing or expansion. Option D is wrong because creating a new disk and using rsync is a valid migration approach but is not the correct sequence for resizing an existing boot disk online as specified in the question.

Why this answer

How to eliminate wrong answers

Option A is wrong because `gcloud compute instances update` does not support an `--add-label` flag; the correct subcommand for adding labels is `add-labels`. Option C is wrong because `gcloud label add` is not a valid gcloud command; labels are managed through resource-specific commands like `gcloud compute instances add-labels`. Option D is wrong because `gcloud compute instances set-labels` replaces all existing labels on the VM with the specified labels, rather than adding a single label to the existing set, which would remove any other labels already applied.

Why this answer

How to eliminate wrong answers

Option A is wrong because switching regions does not enable the required API; the error is about API access, not regional availability. Option C is wrong because `gcloud auth login` authenticates the user but does not enable the API; the API must be enabled at the project level regardless of authentication. Option D is wrong because increasing the project quota addresses resource limits, not the fundamental requirement of having the API enabled; the API must be enabled before any quota increase would be relevant.

Why this answer

How to eliminate wrong answers

Option A is wrong because Cloud Firestore in Datastore mode is a document/NoSQL database with eventual consistency and higher read latency (typically tens of milliseconds), not microsecond-level, and it is optimized for mobile/web apps with real-time sync, not for high-throughput key-value access with strict latency requirements. Option C is wrong because Cloud SQL (PostgreSQL) is a relational database with ACID transactions but cannot achieve microsecond read latency due to disk-based storage and SQL overhead, and it is not horizontally scalable (requires manual sharding or read replicas). Option D is wrong because Cloud Memorystore (Redis) is an in-memory cache that provides microsecond latency but does not guarantee data persistence beyond 30 days without activity; Redis data can be evicted or lost on node failure unless configured with persistence (AOF/RDB), which adds latency and complexity, and it is not designed as a durable primary store for long-term survival.

Why this answer

How to eliminate wrong answers

Why this answer

How to eliminate wrong answers

Option A is wrong because `gsutil cp` copies objects, which would create new objects with the Nearline storage class but leave the original objects unchanged, resulting in duplicate objects and unnecessary costs. Option C is wrong because `gsutil setmeta` is used to set custom metadata on objects, not to change the storage class; the `-s` flag is not valid for this command. Option D is wrong because `gsutil mv` moves objects, which effectively copies and then deletes the original, incurring restoration fees if the original is in a cold storage class like Nearline, and it does not change the storage class of the existing object in place.

Why this answer

How to eliminate wrong answers

Option A is wrong because Cloud Trace is a distributed tracing tool for request latency analysis, not JVM memory profiling; it cannot show garbage collection or heap allocation data. Option C is wrong because Cloud Monitoring with JVM MBeans via the Ops Agent provides metric-based memory usage (e.g., heap usage) but lacks the detailed allocation profiling and GC cycle breakdown that Cloud Profiler's heap profiling offers. Option D is wrong because Error Reporting only aggregates application errors like OutOfMemoryError; it does not provide proactive profiling of memory allocation or garbage collection behavior over time.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because even if the health check path is incorrect, the VM would not be immediately recreated; instead, the health check would consistently fail, but the MIG would not enter a restart loop unless the application eventually becomes healthy after a restart, which is not the case here. Option C is wrong because autohealing and autoscaling are fully compatible in Google Cloud MIGs; they serve different purposes (health-based repair vs. load-based scaling) and can be used together without conflict. Option D is wrong because MIGs fully support HTTP health checks; TCP checks are an alternative but not a requirement, and the issue described is unrelated to the health check protocol.

Why this answer

How to eliminate wrong answers

Option A is wrong because selecting the closest larger predefined N2 machine type would result in over-provisioning resources, leading to unnecessary costs and potential performance inefficiencies. Option C is wrong because splitting the workload across multiple smaller VMs introduces complexity, coordination overhead, and may not be feasible for workloads that require a single large memory address space or high vCPU count. Option D is wrong because Google Cloud does not create new predefined machine types on demand for individual requests; custom machine types are the designed solution for such scenarios.

Why this answer

How to eliminate wrong answers

Option A is wrong because service accounts are intended for applications and automated workloads, not for human users; sharing a key file violates security best practices and does not provide proper identity-based access control. Option C is wrong because creating a new project for the engineer is unnecessary and wasteful; the engineer should be added to an existing project, and personal Gmail accounts are not part of the corporate Google Workspace domain, so they cannot be managed centrally. Option D is wrong because API keys are used to authenticate calls to GCP APIs for applications, not to grant human users access to the GCP Console or project resources; they lack identity context and cannot enforce IAM roles.

Why this answer

How to eliminate wrong answers

Option A is wrong because Cloud Spanner offers strong consistency across regions, not eventual consistency, and its global synchronous replication adds latency and cost that are unnecessary for a system that tolerates eventual consistency. Option C is wrong because Cloud SQL is a regional database that does not scale globally or support cross-region replication for eventual consistency, and VPC peering does not create a single global network for low-latency intra-region communication. Option D is wrong because Cloud Datastore (Firestore in Datastore mode) is a regional NoSQL database that does not natively support global scaling with eventual consistency across regions, and Shared VPC is designed for multi-project networking within an organization, not for global low-latency communication.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because a VPC firewall rule blocks traffic at the network layer, not the creation of VMs with external IPs; developers could still assign an external IP to a VM, and the firewall rule would only block outbound internet traffic after the VM is created. Option C is wrong because removing the `compute.instanceAdmin` role would prevent developers from creating any VMs at all, not just those with external IPs, and it does not selectively restrict external IP assignment. Option D is wrong because configuring the default VPC network to use internal-only routes does not prevent a developer from explicitly assigning an external IP when creating a VM; it only affects routing, not the IP assignment itself.

Why this answer

How to eliminate wrong answers

Option A is wrong because `kubectl create -f api-deployment.yaml` will fail with an error if the Deployment already exists, as it only creates new resources and does not support updates. Option B is wrong because `kubectl run api-deployment.yaml` is not a valid command; `kubectl run` is used to create a Pod or Deployment from an image, not from a YAML file. Option D is wrong because `kubectl deploy -f api-deployment.yaml` is not a valid kubectl subcommand; the correct verb for updating existing resources is `apply`, not `deploy`.

Why this answer

How to eliminate wrong answers

Option A is wrong because alerting policies are designed for threshold-based notifications, not for displaying real-time metric data on a dashboard; pinning alerts to a shared page does not create a visual dashboard with time-series charts. Option C is wrong because while BigQuery metrics export can feed Looker Studio, this adds unnecessary complexity and latency, and is not the native Cloud Monitoring feature for a single-screen overview. Option D is wrong because Cloud Logging is for log data, not numeric metrics like request count or latency; log-based dashboards cannot natively chart metric time-series such as p99 latency or CPU utilization.

Why this answer

How to eliminate wrong answers

Option A is wrong because deleting the VM removes the instance and its attached persistent disks by default, which would destroy the disk data unless a snapshot or disk backup was taken beforehand. Option C is wrong because while snapshotting the disk and deleting the VM does preserve the data, it introduces unnecessary complexity and additional snapshot storage costs; stopping the VM is simpler and directly meets the goal without extra steps. Option D is wrong because resizing to a smaller machine type reduces but does not eliminate compute charges, and the VM would still be running unused, wasting resources; the goal is to stop compute charges entirely.

Why this answer

How to eliminate wrong answers

Option A is wrong because Network Service Tiers (Premium vs Standard) control the quality of network transit and egress pricing, not the isolation or sharing of VPC resources like Cloud NAT or firewall rules. Option C is wrong because VPC Network Peering connects separate VPCs but does not allow them to share a single Cloud NAT or a common set of firewall rules; each VPC would need its own NAT and firewall configuration. Option D is wrong because a single VPC with per-team firewall rules does not provide the separate, isolated environments (e.g., separate projects or VPCs) that the question requires; it only offers logical isolation within one network, which is insufficient for true environment separation.

Why this answer

How to eliminate wrong answers

Option A is wrong because Cloud Shell does not automatically save all files to Cloud Storage; only the $HOME directory is backed by persistent storage, and users must explicitly copy files elsewhere if they want them saved. Option C is wrong because Cloud Shell uses Cloud Storage (specifically a persistent disk mounted as the home directory), not Firestore, which is a NoSQL document database and not used for file storage in this context. Option D is wrong because files outside $HOME are not deleted after a fixed 24-hour period; they are removed when the Cloud Shell container is recycled or the session ends, which can happen sooner than 24 hours depending on inactivity or manual restart.

Why this answer

How to eliminate wrong answers

Option A is wrong because storing a password as a plain-text environment variable exposes it in the Cloud Run console, logs, and any process that can read environment variables, violating the principle of least privilege and secure secret management. Option B is wrong because Cloud Storage buckets are designed for object storage, not secret management; they lack built-in encryption key rotation, audit logging for secret access, and fine-grained access control specific to secrets, and storing a password there would require additional complexity to secure it. Option D is wrong because baking secrets into a container image at build time embeds them in the image layers, making them accessible to anyone with image pull access and preventing rotation without rebuilding and redeploying the image.

Why this answer

How to eliminate wrong answers

Option A is wrong because `gcloud environments` is not a real gcloud feature; the correct mechanism for managing multiple sets of properties is `gcloud config configurations`, not a built-in workspace manager. Option C is wrong because maintaining separate gcloud installations for each project is unnecessary and inefficient; gcloud is designed to handle multiple projects and accounts within a single installation using configurations. Option D is wrong because gcloud does not automatically read a `.gcloudrc` file from project directories; it uses the active configuration (or the default configuration) and does not support per-directory property files.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because disabling autohealing entirely removes the ability to recover from genuine failures during the update, leaving the MIG vulnerable to stuck deployments without automatic recovery. Option C is wrong because switching to a canary update does not address the root cause—the health check timing—and can still result in a deployment loop if the new version is slow to start. Option D is wrong because reducing the health check interval and timeout would make the problem worse by evaluating health more aggressively, increasing the likelihood of premature unhealthy detection and loop amplification.

Why this answer

How to eliminate wrong answers

Option A is wrong because `gcloud service-accounts list` is not a valid gcloud command; the correct command structure requires the `iam` group before `service-accounts`. Option B is wrong because `gcloud iam list service-accounts` uses an incorrect subcommand order — the verb `list` must come after the resource type `service-accounts`, not before. Option D is wrong because `gcloud projects list-service-accounts` does not exist; the `gcloud projects` command group is for managing project metadata, not for listing service accounts.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because App Engine Flexible Environment runs containers on managed VMs that cannot scale to zero; it requires at least one instance to be running at all times, incurring costs even when idle. Option C is wrong because Compute Engine with managed instance groups requires at least one running VM instance to serve traffic; while you can configure autoscaling to a minimum of one, it cannot scale to zero instances, and you pay for the underlying VMs regardless of request volume. Option D is wrong because Google Kubernetes Engine (GKE) with Autopilot or Standard mode requires at least one node to run pods; even with cluster autoscaling, you cannot scale to zero nodes, and you incur costs for the node infrastructure even when no requests are being processed.

Why this answer

How to eliminate wrong answers

Option A is wrong because Security Command Center (SCC) does not automatically audit service account key age; it focuses on vulnerability and threat detection, not asset inventory of key creation dates. Option C is wrong because Cloud Monitoring metrics do not expose service account key creation dates; metrics are for performance and usage, not IAM resource metadata. Option D is wrong because manually checking each service account in each project's IAM & Admin page is not a tool and is impractical for an organization-wide inventory, violating the requirement for an automated, scalable solution.

Why this answer

How to eliminate wrong answers

Option A is wrong because Cloud SQL instances can connect to Compute Engine instances across regions within the same VPC network using private IP, as long as VPC peering is configured; region mismatch is not a direct cause of connectivity failure. Option B is wrong because a Compute Engine instance does not need an external IP address to connect to Cloud SQL via private IP; private connectivity relies on internal routing and VPC peering, not external IPs. Option D is wrong because firewall rules for ingress on port 3306 are relevant for public IP connections or when using the Cloud SQL proxy, but for private IP connections within a peered VPC, the default firewall rules allow internal traffic; the issue is routing, not firewall filtering.

Why this answer

How to eliminate wrong answers

Option A is wrong because Cloud SQL with synchronous read replicas is not globally distributed; it is a single-region service with read replicas that do not support writes, and it cannot scale to thousands of writes per second without downtime for maintenance. Option B is wrong because Cloud Bigtable is a NoSQL wide-column database that does not support SQL transactions or strong consistency across regions; it is designed for high-throughput analytical workloads, not transactional SQL. Option C is wrong because Cloud Firestore is a NoSQL document database that does not support SQL transactions; it provides strong consistency only within a single region and cannot handle thousands of writes per second globally with SQL semantics.

Why this answer

How to eliminate wrong answers

Option B is wrong because insufficient CPU/memory on the node or high resource requests cause `Pending` or `OutOfcpu`/`OutOfmemory` states, not `ImagePullBackOff`; the image pull itself is not affected by resource constraints. Option C is wrong because a failing liveness probe causes container restarts (CrashLoopBackOff) or pod termination, but does not affect the image pull process; `ImagePullBackOff` occurs before the container even starts. Option D is wrong because a failing entrypoint command causes the container to exit immediately after starting (CrashLoopBackOff), not an image pull failure; the image pull completes successfully before the entrypoint runs.

Why this answer

How to eliminate wrong answers

Option A is wrong because shared-core machine types (e.g., e2-micro) can cause CPU throttling under sustained load, but the symptom would be high CPU credit exhaustion and visible CPU throttling, not consistently low CPU utilization. Option B is wrong because if the machine type were too small, CPU utilization would be high (near 100%) as the job struggles to complete, not below 20%. Option D is wrong because a persistent disk in a different zone than the VM is not supported; Compute Engine requires the disk to be in the same zone as the VM, so this configuration would cause an immediate launch failure, not a gradual performance degradation.

Why this answer

How to eliminate wrong answers

Option A is wrong because IAM deny policies can restrict specific operations but they operate at the IAM level and cannot override valid permissions granted to a user; they also do not provide a network-level data exfiltration control that prevents copying results across projects. Option C is wrong because an organization policy preventing resource creation outside specific projects only controls where new resources can be created, not the movement of existing data or query results between projects. Option D is wrong because Cloud Armor is a web application firewall that protects HTTP(S) traffic, not BigQuery API calls, and it cannot block outbound API requests to BigQuery in other projects.

Why this answer

How to eliminate wrong answers

Option A is wrong because Cloud SQL Editor (roles/cloudsql.editor) includes permissions to create, update, and delete Cloud SQL instances, which exceeds the required read-only access. Option B is wrong because Cloud SQL Client (roles/cloudsql.client) primarily grants permissions to connect to Cloud SQL instances (e.g., using the Cloud SQL Proxy or client libraries) but does not include the ability to view instance metadata or connection strings in the console. Option D is wrong because Project Viewer (roles/viewer) provides read-only access to all resources in the project, which is overly broad and not scoped specifically to Cloud SQL; it also does not grant the precise permissions needed for viewing Cloud SQL instance details and connection strings.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because hardcoding values in `args` makes the pipeline environment-specific, requiring manual edits for each environment and violating the principle of configuration externalization. Option C is wrong because Cloud Secret Manager is designed for sensitive data (e.g., API keys, passwords), not for non-sensitive environment variables like `PROJECT_ID`, `REGION`, or `IMAGE_TAG`; retrieving secrets in every build step adds unnecessary latency and complexity. Option D is wrong because a `.env` file committed to the repository exposes environment-specific values in version control, creating security risks and maintenance overhead, and Cloud Build does not natively source `.env` files without custom scripting.

Why this answer

How to eliminate wrong answers

Option A is wrong because session duration limits apply to the maximum time a service account can use a token before re-authentication, not to the overall validity of the IAM role binding; they do not expire the permission itself after 90 days. Option C is wrong because manually revoking access is error-prone, not automated, and violates the requirement for automatic expiration; it is not an IAM feature. Option D is wrong because deleting a service account does not automatically remove its IAM role bindings (orphaned bindings remain), and Cloud Scheduler cannot delete a service account without additional custom logic; this approach is unnecessarily complex and not a built-in IAM feature.

Why this answer

How to eliminate wrong answers

Option A is wrong because Data Access logs do not record authentication events; those are captured by Admin Activity logs (for IAM policy changes) and System Event logs (for GCP actions). Option C is wrong because VM instance creation and deletion are recorded by Admin Activity logs, not Data Access logs, and they are enabled by default for free. Option D is wrong because Data Access logs are not experimental—they are GA—and they do not provide real-time threat detection; that is the role of services like Security Command Center or Event Threat Detection.

Why this answer

How to eliminate wrong answers

Option A is wrong because labels are key-value metadata used for resource organization and cost tracking, but they do not support inheritance of IAM policies across projects. Option B is wrong because resource tags (now called 'tags' in GCP) are used for conditional policy enforcement and network firewall rules, not for hierarchical grouping with IAM policy inheritance. Option D is wrong because a Shared VPC host project allows multiple service projects to share a common VPC network, but it does not group projects for IAM policy inheritance across unrelated projects; it only provides network-level isolation and sharing.

Why this answer

How to eliminate wrong answers

Option A is wrong because Cloud Monitoring's request_latencies metric is a distribution (e.g., histogram) that shows aggregated percentiles like P99, not individual request latencies. Option C is wrong because Cloud Logging does not natively include a 'duration' field for HTTP requests unless you explicitly log it; even then, filtering for >3s would show all requests exceeding that threshold, not the slowest ones sorted by latency. Option D is wrong because Cloud Profiler samples function call stacks and CPU/memory usage, not per-request latency data; it identifies slow functions, not slow individual requests.

Why this answer

How to eliminate wrong answers

Option A is wrong because `gcloud projects switch` is not a valid gcloud command; the correct verb for switching context is `config set`, not a subcommand under `projects`. Option C is wrong because `gcloud auth set-project` does not exist; authentication and project configuration are separate concerns — `gcloud auth` handles credentials, not project settings. Option D is wrong because `gcloud init --project=[PROJECT_ID]` would reinitialize the entire configuration, which is unnecessary and slower than simply updating the project property; it also overwrites other settings like region and zone, which the developer likely wants to preserve.

Why this answer

How to eliminate wrong answers

Option A is wrong because Cloud Debugger is used for inspecting application state (variables, stack traces) at a specific point in time without stopping the service, but it does not collect or aggregate CPU usage data over time to identify hotspots. Option B is wrong because Cloud Trace focuses on latency analysis of requests and spans, measuring how long operations take, not CPU consumption; it can show slow operations but cannot attribute CPU usage to specific functions. Option D is wrong because Cloud Monitoring custom dashboards display metrics like CPU utilization at the instance or container level, but they cannot drill down into function-level CPU hotspots within the application code.

Why this answer

How to eliminate wrong answers

Option A is wrong because Audit Logs is used to view and configure audit logs for tracking admin activity, data access, and system events, not for creating or managing IAM roles. Option C is wrong because Organization Policies are used to set constraints on Google Cloud resources at the organization, folder, or project level (e.g., restricting resource locations or disabling service creation), not for defining IAM roles. Option D is wrong because Service Accounts is the page for managing service account identities and their keys, not for creating or managing IAM roles.

Why this answer

How to eliminate wrong answers

Option A is wrong because it incorrectly assumes that a more specific rule 'takes precedence' over a broader allow rule; in GCP, all matching allow rules are applied, and the more specific rule does not block the broader rule from allowing other traffic. Option C is wrong because it falsely claims that deny rules override allow rules by default; GCP firewall rules are implicitly permissive—if no deny rule matches, traffic is allowed, and there are no deny rules in this scenario. Option D is wrong because it suggests that the priority 1000 rule overrides the priority 999 rule; priority only determines the order of evaluation for conflicting rules (e.g., an allow vs. a deny), but both are allow rules, so both apply to their respective matching traffic.