Practice Test #2

Running JMeter locally violates the requirement for a consistent, in-region source because your home/office network and internet path introduce variability and may not sustain 8,000 RPS reliably. While exporting logs to BigQuery is good for rapid analysis, using Looker (enterprise) may not be achievable within 1 hour if not already provisioned. The biggest issue is the non–in-region, inconsistent load generation.

Compute Engine in us-central1 is a good in-region load generator choice. However, sinking logs to Cloud Storage is not ideal for rapid analysis because logs land as files that typically require additional ETL (for example, loading into BigQuery) before you can efficiently compute latency percentiles and build interactive charts. Looker Studio is fast for dashboards, but the Storage sink slows the analysis workflow.

This option has two drawbacks. First, exporting logs to Cloud Storage is better for retention/archival than fast querying, making rapid analysis harder within the 1-hour window. Second, Looker (enterprise) is usually heavier-weight to set up than Looker Studio; unless it’s already deployed and connected, it can delay dashboard publication. The in-region JMeter VM is correct, but the analytics stack is not.

A support ticket is not the right first step for code-level latency analysis. The symptoms (high p95 latency with low CPU/memory) point to application behavior or dependency latency rather than a platform outage. Exams typically expect you to use built-in observability tools (Profiler/Trace/Monitoring) to gather evidence before escalating to support.

Cloud Debugger snapshots can capture variables and stack traces at specific code locations without stopping the app, which is useful for diagnosing logic bugs. However, it does not provide aggregated performance data or identify where most wall time is spent across requests. It’s not the best tool to find latency hotspots or quantify which functions dominate p95 latency.

Adding extensive timing logs is a form of manual instrumentation and contradicts the requirement to avoid custom timing code. It also adds overhead (extra work per request), increases log volume and cost, and can distort latency measurements. While it can reveal hotspots, it is not the minimal-overhead, best-practice approach compared to Cloud Profiler.

This approach only instruments one producer path: the standard CI pipeline. The question explicitly says images may also be pushed manually from engineers' laptops and through emergency retags, so those events would not emit the custom Pub/Sub message and would be missed. Because the requirement is to trigger on every new image or tag push, this design is incomplete. It also creates coupling between one CI implementation and the scanning workflow instead of using the repository as the system of record.

This would work technically, but it is not the least engineering effort. Introducing a Cloud Function adds an extra component to deploy, secure, monitor, and maintain even though Cloud Build can already be triggered from Pub/Sub directly. In exam questions, when a native integration exists, adding a serverless bridge is usually considered unnecessary complexity. Therefore this option is less optimal than a direct Artifact Registry to Pub/Sub to Cloud Build trigger path.

A 5-minute polling interval clearly violates the requirement that the separate Cloud Build pipeline must start within 1 minute of a push. Polling also requires additional logic to track previously seen tags or digests, handle deduplication, and avoid race conditions. This increases engineering effort and operational complexity compared with event-driven notifications. Since Artifact Registry already supports event publication, polling is the wrong pattern here.

Standardizing on one language can reduce cognitive load, but it conflicts with the requirement that three consumer teams (Java, Go, Python) will integrate. Forcing a single language reduces autonomy and is rarely feasible in microservice ecosystems. It also does not guarantee backward compatibility; breaking API changes can still occur regardless of implementation language. Exams typically favor language-agnostic interface contracts over organizational mandates.

Asynchronous, event-driven communication can improve decoupling and absorb bursts, but requiring every interaction to be async is not appropriate. Many use cases need synchronous request/response (e.g., ad serving paths with 200 ms p95 SLO). Event-driven designs also introduce ordering, duplication, and schema-evolution challenges; you still need explicit contracts and versioning for events. It’s a tool, not a universal requirement.

Pre-provisioning replicas for peak (2,500 RPS) at all times is inefficient and costly, and it doesn’t address backward compatibility. On Cloud Run you typically rely on autoscaling and concurrency; on GKE you use HPA/VPA and cluster autoscaler to handle bursts. Keeping fixed peak capacity can help latency during spikes, but it’s not the priority compared to interface stability and versioning for 12-month compatibility.

Managed instance groups (MIGs) provide autoscaling and consistent VM templates, but a cURL + shell loop is not a best-practice load-testing approach for repeatable, metrics-rich tests. Coordinating 5,000 RPS with controlled ramp-up, parallel user behavior, and aggregated latency percentiles is difficult. Source IP diversity is also not guaranteed unless you explicitly design egress IP allocation; simple VM scaling alone doesn’t ensure multiple client IPs in a controlled way.

Unmanaged instance groups remove key operational best practices (no autoscaling, no self-healing, no rolling updates), making repeatable test runs harder. Like option A, cURL loops lack built-in coordination, realistic user modeling, and robust reporting/aggregation of latency and throughput metrics. It also increases operational toil and risk of inconsistent generator configuration, which conflicts with the requirement for repeatable tests and Google-recommended practices.

Cloud Shell is intended for interactive administration and has resource/session constraints, making it unsuitable for sustained 5,000 RPS bursts for minutes. Starting multiple containers “sequentially” is not a reliable scaling strategy, and Cloud Shell does not provide strong guarantees for repeatability, concurrency control, or stable source IP diversity. It also lacks the operational controls and observability integration expected in Google-recommended best practices for performance testing.