Practice Test #2

A custom mocking framework is risky because it is very hard to accurately reproduce Pub/Sub semantics (ordering keys, redelivery, ack deadlines, flow control, and concurrency effects). Such mocks often diverge from real behavior, creating tests that pass but fail in production. It also increases maintenance burden and does not align with best practices for testing managed services when an official emulator exists.

Creating a dedicated topic and subscription per tester can reduce interference, but it adds operational overhead (resource creation/cleanup, IAM, quotas) and can still be flaky due to real service dependencies. It also violates the “zero additional GCP cost” requirement because Pub/Sub usage (publish/deliver operations, storage) is billable, and scaling this across many CI runs can become expensive.

Subscription filters can isolate messages by tester_id, but they do not eliminate cost or external dependency. You still pay for publishing and delivery attempts, and filters add complexity (ensuring every message has correct attributes, managing filter expressions). Filters also don’t fully prevent flakiness from shared infrastructure, parallel test contention, or transient Pub/Sub service behavior in CI.

Access-Control-Allow-Origin: * allows any website origin to make cross-origin requests and read responses (subject to other CORS rules). This directly violates the requirement to restrict submissions to only https://dashboard.acme.io. While it can be tempting for simplicity and may reduce CORS troubleshooting, it is not compliant with the stated restriction and is generally discouraged for sensitive ingestion endpoints.

Access-Control-Allow-Origin does not support wildcard patterns like https://*.acme.io. The CORS spec requires either a single explicit origin, the literal wildcard *, or dynamically echoing back the request’s Origin when it is in an allowlist. Therefore this header value would not work as intended in browsers and would likely cause CORS failures, making it both incorrect and unreliable for compliance.

Access-Control-Allow-Origin: https://ingest.acme-data.io would only allow pages whose origin is the ingestion domain itself to make cross-origin requests. But the calling origin is https://dashboard.acme.io, so the browser would still block the request. This option confuses the resource’s host (where the API runs) with the requesting origin (where the JavaScript/WebView content is served from).

Incorrect. Kubernetes Jobs are for finite, run-to-completion tasks, not continuous health monitoring and lifecycle management of a long-running Deployment. A separate Job cannot directly mark a specific Pod/container unhealthy in the kubelet sense, nor reliably coordinate graceful termination on probe failures. This approach adds complexity and does not meet the probe semantics (period/timeout/failureThreshold) required by the question.

Incorrect. postStart is not a health check mechanism and does not provide periodic checks, timeouts, or failure thresholds. It runs once at container start. Also, Kubernetes cannot conditionally run preStop “only if the container is failing”; preStop runs whenever the container is terminated (for restarts, rollouts, node drains). This option fails the requirement for continuous 10-second health verification.

Incorrect. An initContainer can validate Pub/Sub connectivity only before the main container starts; it cannot continuously verify connectivity every 10 seconds during runtime. While preStop is the right place for /app/shutdown.sh, the option’s health-check mechanism does not satisfy the ongoing probe requirements (periodSeconds/timeoutSeconds/failureThreshold) and would not detect mid-run connectivity loss.

Waiting relies on probability, not certainty. With a 10% sampling rate, any single request has a 90% chance of not being traced, and time does not change that for a specific one-off curl. This does not meet the requirement to guarantee tracing for one specific request and is a poor operational practice for validation because it is nondeterministic.

Repeatedly sending requests increases the likelihood that at least one request is sampled, but it still cannot guarantee that the specific test request you care about is captured. It also adds unnecessary traffic, can skew metrics, and may incur extra cost. For exam scenarios emphasizing determinism and minimal impact, brute-force retry is not the right approach.

The Cloud Trace API can write spans or annotate traces, but it does not retroactively force an unsampled request to be captured end-to-end. Sampling decisions typically occur at trace creation time in the instrumentation/SDK. Custom attributes enrich existing spans; they don’t override the sampler or ensure that a request becomes traced when it otherwise would be dropped.

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.