Practice Test #3

Cloud SQL (PostgreSQL) is a managed relational database but still requires schema management and careful capacity planning. Weekly schema migrations and downtime risk are exactly the pain points described. At 45,000 writes/second, a single instance will not suffice; scaling typically requires read replicas (not for writes) or application-level sharding, increasing operational overhead. It also doesn’t naturally support highly variable per-user records without frequent migrations.

Cloud Storage is an object store for blobs (files) with very high durability and throughput, but it is not a database optimized for low-latency key-based reads/writes with per-user transactional consistency. You could store per-user JSON objects, but you’d lose efficient querying, atomic updates across multiple related items, and database-like concurrency controls. It’s better for raw telemetry archives, exports, or batch analytics inputs.

Cloud Spanner provides horizontally scalable relational SQL with strong consistency and high availability, and it can handle very high write throughput. However, it is schema-based and best when you need relational modeling, SQL joins, and cross-row/table transactions at scale. The scenario explicitly wants to avoid rigid schemas and frequent migrations, and only needs per-user transactional consistency with simple key-based reads—making Spanner unnecessarily complex and costly.

Incorrect. If the VM is stuck in “Starting” and repeatedly rebooting, the OS likely never reaches a stable multi-user state where sshd is running and accepting logins. Changing the Linux username does not address bootloader/kernel/filesystem failures. SSH troubleshooting is appropriate when the instance is RUNNING and serial console indicates the OS booted successfully.

Incorrect. VPC firewall rules and routes affect network connectivity to/from an instance, but they do not prevent the guest OS from booting. A VM can fully boot even with no network access. The symptom described (serial console shows repeated boot attempts and the instance remains in Starting) points to disk/OS boot issues rather than routing or firewall configuration.

Incorrect. Dropped network traffic (firewall/policy) can explain inability to SSH or reach the application, but it does not explain repeated boot attempts shown in the serial console or a VM stuck in “Starting.” Network policies operate after the OS boots and the NIC is configured; they do not typically cause kernel/init failures or reboot loops.

Cloud Functions is serverless and can autoscale, but it is primarily event/function oriented and historically constrained around runtimes and packaging. Even with newer container support, the question explicitly frames a containerized microservice with native .so libraries and OpenSSL 1.1 build requirements, which is a more natural fit for Cloud Run’s “run any container” model and HTTP service semantics (port 8080, request routing, concurrency controls).

A Container-Optimized OS VM on Compute Engine can run containers, but it still requires provisioning and managing VMs (patching strategy, instance groups, autoscaling configuration, OS lifecycle, monitoring, and capacity planning). It also will not naturally scale to zero without additional orchestration and would typically have slower operational iteration than Cloud Run. This violates the “does not want to manage servers” requirement.

GKE is powerful for container orchestration, but it introduces cluster management overhead (node pools, upgrades, patching, scaling, networking policies), even in Autopilot mode. While GKE can autoscale, scaling to zero for an HTTP service and achieving consistently low cold starts is more complex and typically involves Knative/KEDA patterns. The question explicitly asks to avoid managing clusters, making Cloud Run the better match.

Google Cloud Armor is a security enforcement service (WAF and DDoS protection) for applications behind Cloud Load Balancing. It helps mitigate threats using preconfigured WAF rules (e.g., OWASP CRS), custom rules, and rate limiting. However, it does not crawl your site or generate a vulnerability findings report from active scanning. It’s for prevention and mitigation, not discovery/assessment.

Cloud Debugger (part of Cloud Operations) helps inspect application state in production by capturing snapshots and adding logpoints without stopping the app. It is used for troubleshooting and debugging code issues, not for security scanning. It does not crawl web pages, test for XSS, or report vulnerable client-side libraries.

Error Reporting aggregates and groups application errors/exceptions and provides notifications and dashboards to help developers prioritize fixes. It is valuable for reliability and debugging production issues, but it does not perform web vulnerability scanning, does not crawl pages, and will not assess XSS exposure or vulnerable client-side libraries.

Google API Client Libraries are more generic and often oriented around REST/HTTP with discovery-based APIs. While they can authenticate with ADC, they typically require more manual configuration to achieve the same retry, deadline, and connection reuse behavior as the purpose-built Cloud Client Libraries. For Firestore performance-sensitive workloads, they add unnecessary boilerplate and may not deliver optimal latency characteristics.

A custom gRPC client could theoretically achieve high performance, but it significantly increases implementation complexity and risk. You would need to correctly implement authentication (ADC token plumbing), retries with proper idempotency semantics, deadlines, channel pooling, and error handling. This contradicts the requirement to minimize boilerplate and is not the recommended approach for exam scenarios unless a feature is unavailable in official libraries.

A third-party HTTP client library would require you to manually implement Firestore’s API calls, authentication, retries/backoff, deadlines, and connection pooling. It is easy to get retry behavior wrong (e.g., retrying non-idempotent writes) and to miss Google’s recommended client configurations. This option increases boilerplate and operational risk and is unlikely to be the best path to consistent low-latency writes.

Incorrect. Binary Authorization policies are evaluated at deployment time by the cluster’s admission controller; you don’t practically “exempt images not deployed to prod” because the same image could be deployed to any cluster. The requirement is cluster-specific enforcement, not image-specific exemptions. The correct approach is to scope the rule to the prod cluster via clusterAdmissionRules.

Incorrect. Vulnerability scanning and tagging images as untrusted is not the same as cryptographic signing/attestation enforcement. Scanning can inform risk decisions, but by itself it does not block deployments to GKE. To enforce “only signed by release attestor,” you need Binary Authorization with an attestor and an admission policy, not just Artifact Registry scanning metadata.

Incorrect. A Cloud Functions-based gate in the build pipeline is not the recommended control for cluster admission, and it doesn’t guarantee enforcement if someone deploys an image from another pipeline or registry path. The requirement is deploy-time enforcement on the prod cluster. Binary Authorization provides centralized, auditable, cluster-enforced policy independent of how images were built or stored.

Incorrect. Adding console.log before/after every function call is extremely intrusive: it adds synchronous/async overhead, increases CPU usage, and can significantly increase latency and log volume/cost at 800 RPS. It also creates noisy data and operational risk in production. This violates the requirement for minimal overhead (<1% CPU) and “without adding significant latency.”

Incorrect. Aggregating request logs and computing handler durations can identify slow requests, but it cannot reliably attribute CPU cycles or heap usage to specific functions. Latency can be dominated by I/O waits, network calls, or downstream dependencies. Additionally, request logs typically don’t provide function-level granularity, and inferring CPU hotspots from timestamps is imprecise and misleading.

Incorrect. OpenTelemetry + Cloud Trace is excellent for distributed tracing and identifying high-latency spans across services, but it is not a CPU/heap profiler. Tracing shows where time is spent (including waiting), not which functions consume CPU cycles or allocate heap. Also, high-cardinality tracing at 800 RPS can add overhead unless carefully sampled, and still won’t produce flame graphs for CPU/heap.

Running the Cloud SQL Auth Proxy as a background service can improve reliability and startup behavior, but it does not change network reachability. The timeout to 10.20.3.5 is caused by lack of L3 routing between analytics-vpc and db-vpc, not by how the proxy process is managed. Even as a daemon, the proxy still cannot reach a private IP in another VPC without peering/VPN/Interconnect.

The scenario already states the proxy is started with --private-ip. That flag only instructs the proxy to connect to the instance’s private address instead of the public one. It does not create connectivity between VPCs. If the client VM cannot route to 10.20.0.0/16, using --private-ip will simply result in timeouts, exactly as observed.

The Cloud SQL Client IAM role is required for the Auth Proxy to obtain credentials and connect to Cloud SQL, but the evidence shows public IP connections already succeed, indicating IAM is likely correct. IAM permissions do not affect VPC routing to a private IP. Without peering (or VPN/Interconnect), the VM still cannot reach 10.20.3.5, so granting roles will not resolve the timeout.

Incorrect. Deploying a new revision in the existing production project and using traffic splitting does not provide full isolation. IAM, networking, quotas, and potentially data access remain shared with production, and misconfiguration can send traffic to production. Even if you route test traffic to a new revision, you still risk interacting with production dependencies and violate the “separate project” requirement.

Partially viable but not best. gcloud commands can create a project and deploy Cloud Run, but this is imperative automation that tends to be harder to maintain, less reusable, and more prone to configuration drift than Terraform. As requirements evolve (IAM bindings, API enablement, org policies, networking), scripts become brittle. The question asks for least ongoing effort, which favors Terraform-based IaC.

Incorrect. Like option B, this keeps everything in the production project and relies on traffic splitting. It fails the explicit requirement for a separate project and increases risk of accidental production impact. It also doesn’t guarantee “without sending any traffic to production,” because shared routing/configuration mistakes or shared backends could still affect production systems.