CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Google Professional Cloud Developer
Google Professional Cloud Developer

Practice Test #2

Simulez l'expérience réelle de l'examen avec 50 questions et une limite de temps de 120 minutes. Entraînez-vous avec des réponses vérifiées par IA et des explications détaillées.

50Questions120Minutes700/1000Score de réussite
Parcourir les questions d'entraînement

Propulsé par l'IA

Réponses et explications vérifiées par triple IA

Chaque réponse est vérifiée par 3 modèles d'IA de pointe pour garantir une précision maximale. Obtenez des explications détaillées par option et une analyse approfondie des questions.

GPT Pro
Claude Opus
Gemini Pro
Explications par option
Analyse approfondie des questions
Précision par consensus de 3 modèles

Questions d'entraînement

1
Question 1

During a disaster recovery drill, your workload fails over to a standby Google Cloud project in europe-west1. Within 20 seconds, a newly created and previously idle Cloud Storage bucket begins handling approximately 2100 object write requests per second and 7800 object read requests per second. As the surge continues, services calling the Cloud Storage JSON API start receiving intermittent HTTP 429 and occasional 5xx errors. You need to reduce failed responses while preserving as much throughput as possible. What should you do?

Distributing uploads across many buckets can help in some systems that have per-bucket hot-spotting constraints, but Cloud Storage generally supports very high request rates per bucket. The scenario emphasizes a newly created idle bucket and a sudden step increase, which points to ramp/throttling behavior and retry storms. Sharding adds operational complexity (naming, lifecycle, IAM, analytics) without directly addressing the spike-induced 429/5xx.

The JSON and XML APIs are different interfaces to the same Cloud Storage service. Switching APIs does not meaningfully change backend throttling behavior, quotas, or the need to handle 429/5xx correctly. You would still need proper retry and backoff logic. This option is a common trap: changing protocol rarely fixes rate limiting or transient errors caused by sudden load.

Propagating HTTP errors to end users does nothing to reduce failed responses; it simply exposes internal throttling and transient failures to customers and increases perceived downtime. Best practice is to handle 429/5xx with controlled retries, backoff, and circuit-breaking where appropriate. For DR/failover, you want graceful recovery and stable throughput, not raw error passthrough.

Client-side rate limiting with a gradual ramp-up smooths the sudden traffic spike that triggers 429 throttling and occasional 5xx. Combined with exponential backoff + jitter on retries, it prevents retry storms and allows Cloud Storage to serve a high sustained throughput with fewer errors. This is the recommended reliability pattern for Google APIs under load: control concurrency, ramp gradually after failover, and retry transient failures safely.

Analyse de la question

Core concept: This question tests Cloud Storage request-rate behavior during sudden traffic spikes, and how to design clients/services to handle throttling (HTTP 429) and transient backend errors (5xx) while maintaining high throughput. It also touches disaster recovery failover patterns where “cold” resources suddenly become hot. Why the answer is correct: A newly created, previously idle bucket can experience a rapid ramp to high QPS. When many clients simultaneously start issuing requests, Cloud Storage can respond with 429 (Too Many Requests) due to per-project/per-bucket/per-client or internal fairness limits, and occasional 5xx during overload or transient conditions. The most effective way to reduce failed responses while preserving throughput is to smooth the spike: implement client-side rate limiting with a gradual ramp-up (and pair it with exponential backoff + jitter on retries). This aligns with Google’s guidance for handling 429/5xx: back off and retry rather than continuing to hammer the service. A controlled ramp reaches a stable high throughput with fewer errors than an immediate step-function increase. Key features / best practices: Use token-bucket/leaky-bucket rate limiting per client, gradually increasing allowed QPS over tens of seconds. For retries, use exponential backoff with jitter, respect Retry-After when present, and cap max retry concurrency to avoid retry storms. Consider request batching where applicable, and ensure idempotency for writes (e.g., preconditions like ifGenerationMatch) to safely retry. This approach follows the Google Cloud Architecture Framework reliability principles: design for graceful degradation and controlled recovery during failover. Common misconceptions: It’s tempting to “shard” into many buckets (A) to increase throughput, but Cloud Storage is designed for high request rates per bucket; the issue here is the sudden ramp and client behavior, not a fundamental need for bucket sharding. Switching APIs (B) doesn’t change underlying quotas/limits. Passing errors to end users (C) doesn’t reduce failures and harms user experience. Exam tips: When you see intermittent 429 plus occasional 5xx during a sudden surge, think: throttling + transient overload. The exam expects: implement exponential backoff with jitter and smooth ramp-up (rate limiting), rather than changing APIs or adding architectural complexity like bucket sharding unless the question explicitly indicates a sustained per-bucket limit problem.

2
Question 2

Your CI pipeline runs 200 unit tests per commit for a fleet-management analytics service that consumes messages from a Cloud Pub/Sub topic named 'telemetry' using ordering keys set to vehicle_id; for each test you need to publish a sequence of 50 messages for a single vehicle_id and assert that your subscriber processes them strictly in order within the key, while keeping the tests reliable, fast, and at zero additional GCP cost; what should you do?

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.

The local Cloud Pub/Sub emulator is designed for development and testing without incurring GCP charges. It provides an isolated environment that improves reliability and speed in CI by removing network and managed-service variability. It’s the best match for “reliable, fast, and zero additional GCP cost,” while still exercising real client libraries and your subscriber’s ordering-key logic.

Analyse de la question

Core Concept: This question tests how to build reliable, fast, and cost-free automated tests for a Pub/Sub consumer that depends on message ordering keys. Pub/Sub ordering guarantees are subtle (ordering is per ordering key, requires message ordering enabled on the topic, and is enforced by the service), so tests should validate behavior without introducing flaky network/service dependencies. Why the Answer is Correct: Running unit tests against the local Cloud Pub/Sub emulator provides a deterministic, isolated environment with no GCP charges and minimal latency. It avoids shared-project interference (other CI jobs publishing to the same topic) and removes external factors like transient service throttling, IAM propagation delays, or regional network variability that can make CI tests flaky. For CI pipelines running 200 tests per commit, the emulator keeps execution fast and repeatable while still exercising your publisher/subscriber integration logic and ordering-key handling. Key Features / Best Practices: - Pub/Sub emulator runs locally (or in a CI container) and does not incur Pub/Sub usage costs. - Enables hermetic tests: each test can create its own topic/subscription names, publish the 50 messages for a single vehicle_id ordering key, and assert the subscriber processes them in order. - Aligns with Google Cloud Architecture Framework principles: reliability (repeatable tests), operational excellence (automated CI), and cost optimization (zero additional cost). - Practical approach: use unique resource names per test run to avoid cross-test contamination; keep acknowledgments and subscriber concurrency controlled to validate ordering within a key. Common Misconceptions: It’s tempting to isolate traffic in real Pub/Sub using separate topics/subscriptions or filters, but that still costs money, adds resource-management overhead, and can be flaky under parallel CI. Another trap is building custom mocks; they rarely match Pub/Sub’s real semantics (redelivery, ack deadlines, flow control, ordering behavior), leading to false confidence. Exam Tips: When a question emphasizes “reliable, fast, and zero additional GCP cost” for Pub/Sub testing, the emulator is the canonical choice. Prefer emulators for unit/integration tests in CI, and reserve real Pub/Sub for a smaller set of end-to-end tests. Also remember ordering is guaranteed only within an ordering key and depends on correct client configuration and subscriber processing patterns.

3
Question 3

You operate a telemetry collection microservice on Cloud Run that accepts HTTP POST requests with JSON metrics, averaging 50,000 requests per minute. For compliance reasons, the ingestion endpoint must be hosted on a different domain than the user-facing app. The Cloud Run service is exposed at https://ingest.acme-data.io, while the single-page web app and an embedded mobile WebView both originate from https://dashboard.acme.io. You need to add a header to the service's HTTP response so that only pages and WebViews served from https://dashboard.acme.io can submit metrics via cross-origin requests. Which response header should you add?

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).

Access-Control-Allow-Origin: https://dashboard.acme.io is the correct header because CORS decisions are based on the requesting origin, not the API’s own hostname. The browser or WebView will send an Origin header of https://dashboard.acme.io when the page is loaded from that site and attempts to POST JSON to the Cloud Run endpoint. Returning that exact origin in Access-Control-Allow-Origin tells the browser that this specific cross-origin request is permitted. This is the least-privilege configuration and matches the requirement that only pages and WebViews served from https://dashboard.acme.io can submit metrics.

Analyse de la question

Core concept: This question tests Cross-Origin Resource Sharing (CORS) for a Cloud Run HTTP service. Browsers enforce the Same-Origin Policy, so a web app at https://dashboard.acme.io cannot POST to https://ingest.acme-data.io unless the ingestion service returns appropriate CORS response headers. The key header is Access-Control-Allow-Origin, which tells the browser which origin is permitted to read the response and therefore complete the cross-origin request. Why the answer is correct: To allow only the dashboard web app (and its embedded WebView, which uses the same origin) to submit metrics via cross-origin requests, the service must explicitly allow that single origin. Setting: Access-Control-Allow-Origin: https://dashboard.acme.io restricts cross-origin access to exactly that origin. This aligns with the requirement “only pages and WebViews served from https://dashboard.acme.io.” In practice, the service should also correctly handle preflight OPTIONS requests (common for JSON POSTs) and return Access-Control-Allow-Methods and Access-Control-Allow-Headers as needed, but the question asks specifically which response header to add. Key features / best practices: CORS is enforced by browsers, not by Cloud Run itself. You implement it in your application (or via a proxy/API gateway). For high-volume ingestion (50,000 rpm), ensure OPTIONS preflight handling is efficient and consider caching preflight responses with Access-Control-Max-Age. Also note that Access-Control-Allow-Origin cannot safely use broad wildcards when credentials are involved, and it should match the requesting Origin exactly. Common misconceptions: Many assume allowing a wildcard subdomain pattern (e.g., https://*.acme.io) is valid in Access-Control-Allow-Origin; it is not. Another misconception is to set the allowed origin to the service’s own domain (ingest.acme-data.io), which does not permit dashboard.acme.io to call it. Exam tips: For “only this site can call my API from the browser,” choose a single explicit origin in Access-Control-Allow-Origin. Remember: CORS is about browser-based cross-origin requests; server-to-server calls are not blocked by CORS. Also watch for invalid wildcard patterns and the difference between “Origin” (scheme+host+port) and URL paths.

4
Question 4

You are deploying a GKE Deployment for a background worker that pulls jobs from a Cloud Pub/Sub subscription. You must include a health check that verifies the container can reach the Pub/Sub endpoint every 10 seconds, with a 2-second timeout, and mark it unhealthy after 3 consecutive failures; if the worker becomes unhealthy due to lost connectivity, the container must execute /app/shutdown.sh (which can take up to 15 seconds) to gracefully drain and checkpoint work before termination. How should you configure the Deployment?

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.

Correct. A livenessProbe can be configured to check Pub/Sub reachability every 10 seconds with a 2-second timeout and fail after 3 consecutive failures (periodSeconds=10, timeoutSeconds=2, failureThreshold=3). When liveness fails, kubelet restarts the container. A preStop lifecycle hook runs /app/shutdown.sh before termination, and terminationGracePeriodSeconds >= 15 seconds ensures the script can complete to drain/checkpoint work.

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.

Analyse de la question

Core concept: This question tests Kubernetes health checking and graceful termination behavior on GKE: using liveness probes to detect a stuck/broken container and lifecycle hooks (preStop) plus terminationGracePeriodSeconds to allow clean shutdown. Why the answer is correct: You need an active health check every 10 seconds with a 2-second timeout and to mark the container unhealthy after 3 consecutive failures. That maps directly to a livenessProbe with periodSeconds: 10, timeoutSeconds: 2, and failureThreshold: 3. When a liveness probe fails repeatedly, kubelet treats the container as unhealthy and restarts it. Before the container is terminated, Kubernetes runs the preStop lifecycle hook, which is exactly where you place /app/shutdown.sh to drain work and checkpoint state. Because the script can take up to 15 seconds, terminationGracePeriodSeconds must be set to at least 15 (and typically a bit higher to account for SIGTERM handling and hook overhead). Key features / configurations: - livenessProbe: exec/httpGet/tcpSocket that validates Pub/Sub endpoint reachability; tuned with periodSeconds=10, timeoutSeconds=2, failureThreshold=3. - lifecycle.preStop: executes /app/shutdown.sh on termination (including restarts triggered by liveness failures and rolling updates). - terminationGracePeriodSeconds: ensures the Pod is not SIGKILLed before the preStop hook and app shutdown complete. - (Best practice) Consider separating “can process” vs “should receive traffic” using readinessProbe, but the requirement explicitly says “mark it unhealthy,” which aligns with liveness. Common misconceptions: Many confuse initContainers or postStart hooks with ongoing health checks. initContainers only run once at startup and cannot enforce continuous connectivity. postStart is not a health check and failures there don’t provide the periodic, threshold-based semantics required. Also, Kubernetes does not have a built-in conditional “run preStop only if failing”; preStop runs on termination regardless of reason. Exam tips: For GKE workloads that must gracefully drain on restart/eviction, combine liveness/readiness probes with preStop and an adequate terminationGracePeriodSeconds. Remember probe timing knobs: periodSeconds controls frequency, timeoutSeconds controls per-attempt timeout, and failureThreshold controls consecutive failures before action. This is a common pattern for background workers consuming Pub/Sub or other external dependencies.

5
Question 5

Your mobile gaming platform’s matchmaking service (running on Cloud Run behind an external HTTP(S) Load Balancer) has been instrumented with OpenTelemetry and uses a 10% sampling rate; you need to validate end-to-end latency in Cloud Trace for a single test curl request from your laptop without changing the global sampler. How can you guarantee that this specific request is traced regardless of the default sampling decision?

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.

Adding X-Cloud-Trace-Context with a valid trace ID, span ID, and o=1 is the only option that conveys an explicit sampling decision for that individual request. In Google Cloud tracing scenarios, this header is the Google-specific trace propagation format, and the sampled bit is intended to signal that the request should be traced. This makes it the correct exam answer because it targets one request directly instead of changing the global sampler or relying on chance. In practice, the exact behavior depends on whether the Cloud Run service and its OpenTelemetry propagators honor that incoming header, but among the listed choices it is clearly the best and expected solution.

Analyse de la question

Core concept: This question is about per-request trace sampling control for a service on Cloud Run behind an external HTTP(S) Load Balancer. When you need to inspect one specific request without changing the application’s global sampling rate, the correct approach is to send trace context that explicitly marks the request as sampled so the tracing stack can honor that decision. In Google Cloud contexts, X-Cloud-Trace-Context is the Google-specific propagation header, and the sampled flag is represented by o=1. Why correct: Option D is the best answer because it is the only choice that attempts to carry an explicit per-request sampling decision in trace context rather than relying on probability or post-processing. If the service and tracing configuration honor incoming trace context, setting a valid trace ID/span ID and o=1 causes that request to be treated as sampled, which is the standard targeted-debugging technique for validating a single request path. Key features: - X-Cloud-Trace-Context includes a trace ID, span ID, and trace options field. - The o=1 flag indicates that the request should be sampled. - This approach is designed for one-off validation and avoids increasing the global sampling rate or generating unnecessary traffic. - It is preferable to probabilistic retries because it expresses intent directly in the request metadata. Common misconceptions: A common mistake is assuming repeated requests or waiting longer can guarantee capture of a specific request; they cannot. Another misconception is that the Trace API can force an already-unsampled request to appear in Cloud Trace, but sampling decisions are generally made when the trace is created by the instrumentation. Also note that some OpenTelemetry setups primarily use W3C traceparent/tracestate, so honoring X-Cloud-Trace-Context depends on the configured propagators and environment. Exam tips: When the prompt says 'single request,' 'do not change the global sampler,' and 'guarantee' or 'force' tracing, look for an option that injects trace context with a sampled flag. On Google Cloud exams, X-Cloud-Trace-Context with o=1 is the expected pattern when that header is offered as an option, even though real-world behavior can depend on the tracing library configuration.

Envie de vous entraîner partout ?

Téléchargez Cloud Pass — inclut des tests d'entraînement, le suivi de progression et plus encore.

6
Question 6

Your analytics team needs to run a 30-minute spike test reaching up to 8,000 requests per second against a new HTTPS API running on GKE Autopilot in us-central1 using JMeter. You must generate load from a consistent, in-region source, capture request and latency logs for rapid analysis, and publish a dashboard within 1 hour after the test. Following Google-recommended practices, which setup should you use to orchestrate the test and analysis?

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.

Compute Engine in us-central1 provides a consistent, controllable load source close to the GKE Autopilot API, improving repeatability and reducing network noise. A Cloud Logging sink to BigQuery enables immediate SQL analysis of request/latency logs at scale, which is ideal for quickly computing error rates and latency percentiles. Looker Studio connects directly to BigQuery and is the fastest way to publish a shareable dashboard within an hour.

Analyse de la question

Core Concept: This question tests practical load testing and rapid observability on Google Cloud: generating in-region traffic (to avoid internet variability), exporting Cloud Logging data for fast querying, and building a dashboard quickly using Google-recommended, low-friction tools. Why the Answer is Correct: You need a consistent, in-region load generator for a 30-minute spike up to 8,000 RPS against an HTTPS API on GKE Autopilot in us-central1. Running JMeter on a Compute Engine VM in us-central1 provides a stable, controllable source close to the target, minimizing latency noise and egress unpredictability compared to a local machine. For “capture request and latency logs for rapid analysis,” exporting logs to BigQuery is the best fit because it enables immediate SQL-based exploration, aggregation (p50/p95/p99), and joining across fields at scale. Finally, “publish a dashboard within 1 hour” aligns well with Looker Studio (free, fast to set up) connected directly to BigQuery for near-real-time charts. Key Features / Best Practices: - Compute Engine VM in us-central1: consistent network path, predictable throughput, and ability to size CPU/network for 8,000 RPS (and scale out if needed). - Cloud Logging sink to BigQuery: structured log analytics, fast ad hoc queries, and easy integration with BI tools. - Looker Studio + BigQuery: quickest path to a shareable dashboard without provisioning Looker (enterprise) infrastructure. This follows Google Cloud Architecture Framework principles around operational excellence and observability: centralize telemetry, make it queryable, and enable rapid feedback. Common Misconceptions: Cloud Storage sinks are good for archival and batch processing, but they slow down “rapid analysis” because you must parse files and load them into an analytics engine. Looker (enterprise) is powerful but typically not the fastest to stand up within an hour if it’s not already deployed and configured. Exam Tips: When you see “rapid analysis” of logs/latency, think BigQuery sinks. When you see “publish a dashboard quickly,” think Looker Studio. For load generation, avoid local machines; use in-region compute (often Compute Engine) to reduce variability and meet repeatability requirements.

7
Question 7

You containerized a Node.js API and deployed it to Cloud Run (2 vCPU, 1 GiB RAM, max concurrency 80, min instances 0); locally the /orders endpoint averages 120 ms per request under a load test of 200 RPS, but in production Cloud Monitoring shows p95 latency at 1.6 s with CPU at ~30% and memory at ~45%, and you want to pinpoint which parts of the code are causing the delay in production with minimal overhead and without adding custom timing code. What should you do?

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.

Cloud Profiler is the best choice because it identifies which functions and call paths consume CPU time and, importantly here, wall time, with very low overhead in production. It avoids adding custom timing code and helps explain high latency even when CPU is not saturated (e.g., I/O waits, blocking calls, contention). This directly matches the requirement to pinpoint code areas causing delay in production.

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.

Analyse de la question

Core Concept: This question tests production performance diagnosis on Cloud Run using managed observability tools, specifically Cloud Profiler (part of Google Cloud Observability). The goal is to find code-level latency contributors (CPU time and wall time) with minimal overhead and without instrumenting the code. Why the Answer is Correct: Cloud Profiler is designed to continuously sample running applications in production and attribute resource usage and latency to specific functions and call paths. In this scenario, p95 latency is high (1.6 s) while CPU (~30%) and memory (~45%) are not saturated, suggesting the bottleneck may be I/O waits (database/network), lock contention, synchronous blocking, or inefficient code paths that manifest under Cloud Run’s runtime conditions (cold starts, different network path, upstream dependencies). Profiler’s wall-time profiles help pinpoint where time is spent even when CPU is not maxed, and it does so with very low overhead compared to pervasive logging. Key Features / Best Practices: Cloud Profiler supports Node.js and can be enabled to collect CPU and wall-time profiles. It integrates with Cloud Monitoring/Trace context and helps identify hot functions, slow call stacks, and regressions across versions. It is well aligned with the Google Cloud Architecture Framework’s Operational Excellence pillar: use managed observability, measure in production, and minimize performance impact of diagnostics. For Cloud Run, you typically enable the Profiler agent in the container and configure the service name/version so you can compare profiles across revisions. Common Misconceptions: Cloud Debugger (snapshots) is often confused with profiling. Debugger is for inspecting state and variables at a point in time, not for systematically finding latency hotspots. Adding timing logs can work but violates the “minimal overhead” and “without adding custom timing code” requirements and can increase latency and cost. Exam Tips: When asked to “pinpoint which parts of the code are causing delay in production” with “minimal overhead” and “no custom timing,” think Cloud Profiler. Use Debugger for state inspection, Trace for request-level latency breakdown across services, and Logging for event records—not for high-cardinality, high-volume timing instrumentation.

8
Question 8

Your data engineering team maintains batch analytics jobs packaged as containers and stored in an Artifact Registry repository named analytics-jobs in europe-west1. Images can be pushed from multiple paths: a standard CI sequence, ad hoc docker push from engineers' laptops during on-call hotfixes, and occasional emergency retags. You are responsible for configuring CI/CD automation in Cloud Build. Every time any new image or tag is pushed to Artifact Registry, a separate Cloud Build pipeline must start within 1 minute to run a vulnerability scan and write results to a BigQuery dataset. You want to meet this requirement with the least engineering effort and without missing manual pushes. What should you do?

This is the most direct managed design. Artifact Registry can publish events for image pushes and tag changes to Pub/Sub, and Cloud Build can use a Pub/Sub trigger to start the vulnerability scanning pipeline when those messages arrive. That means all push paths are covered, including standard CI, engineers pushing from laptops, and emergency retags, because the trigger is attached to the registry event rather than to one specific workflow. It also satisfies the within-1-minute requirement with minimal operational effort because there is no need to maintain custom code or polling logic.

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.

Analyse de la question

Core concept: use an event-driven integration so every Artifact Registry image push or tag update emits an event that immediately starts a separate Cloud Build pipeline. Why correct: Artifact Registry can publish repository events to Pub/Sub, and Cloud Build supports Pub/Sub triggers, allowing a direct managed path from image push to build execution. Key features: this captures all push sources including CI, manual docker push, and retags; it is near real time and typically well within the 1-minute requirement; and it avoids custom glue code. Common misconceptions: modifying only CI does not cover manual pushes, and adding Cloud Functions is unnecessary when Cloud Build can already subscribe to Pub/Sub. Exam tips: when the requirement emphasizes all producers, low latency, and least engineering effort, prefer native event sources and native triggers over custom bridging or polling.

9
Question 9
(Sélectionnez 2)

Your media analytics company is breaking a legacy ad-serving platform into roughly 40 independently deployable microservices running on Google Kubernetes Engine (GKE) and Cloud Run; three consumer teams (Java, Go, and Python) will integrate with these services, weekly releases must not break existing clients, backward compatibility must be maintained for at least 12 months, average per‑service load is 600 RPS with p95 latency SLO of 200 ms and bursts up to 2,500 RPS during major events, and you need to choose which design aspects to implement to meet these requirements while enabling composability and team autonomy; which two should you prioritize? (Choose two.)

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.

A clear API contract (OpenAPI/proto) is foundational for composability and team autonomy. It enables contract-first development, code generation for multiple languages, consistent error handling, and automated validation in CI to detect breaking changes before release. This directly supports weekly releases without breaking existing clients and is the most important integration design aspect in a multi-team microservices environment.

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.

A versioning strategy is essential to support backward-incompatible changes while maintaining older clients for at least 12 months. Common patterns include /v1 and /v2 endpoints, header-based versions, or protobuf package/service versioning. Versioning enables parallel operation of old and new interfaces, controlled deprecation, and predictable client migration timelines—key for independent deployments and frequent releases.

Analyse de la question

Core Concept: This question tests API design for microservices: contract-first interfaces and explicit versioning to enable independent deployments, multi-language consumers, and long-lived backward compatibility. This aligns with the Google Cloud Architecture Framework pillars of Reliability (avoiding breaking changes), Operational Excellence (clear ownership boundaries), and Performance/Scalability (interfaces that support efficient evolution without destabilizing clients). Why the Answer is Correct: With ~40 independently deployable services and three consumer teams (Java/Go/Python), the primary risk to weekly releases is breaking client integrations. The two highest-leverage design aspects are (B) a clear, enforceable API contract and (E) a versioning strategy. A contract (OpenAPI for REST or protobuf for gRPC) defines request/response shapes, error models, and semantics so teams can develop independently and validate changes via automated compatibility checks. Versioning provides a controlled path for backward-incompatible changes while maintaining older versions for at least 12 months, meeting the stated requirement. Key Features / Best Practices: - Contract-first development: publish OpenAPI/Proto schemas, generate client SDKs for Java/Go/Python, and use CI checks (e.g., breaking-change detection for OpenAPI/proto) before deployment. - Backward compatibility: additive changes (new optional fields) are preferred; avoid renaming/removing fields. - Versioning patterns: URI versioning (e.g., /v1, /v2), header-based versioning, or protobuf package/service versioning; run v1 and v2 concurrently during the 12-month deprecation window. - For GKE/Cloud Run, pair this with progressive delivery (canary/blue-green) and SLO monitoring, but those are secondary to interface stability for this prompt. Common Misconceptions: Teams often try to “solve” compatibility by forcing a single language (A) or mandating event-driven async everywhere (C). Those can help in some contexts but don’t directly guarantee non-breaking weekly releases across heterogeneous consumers. Similarly, pre-provisioning peak capacity (D) addresses burst performance but not interface evolution; autoscaling and right-sizing are typically better. Exam Tips: When requirements emphasize independent deployments, multiple consumer languages, and long backward-compatibility windows, prioritize API contracts + versioning. In GCP microservices (GKE/Cloud Run), scalability tactics (autoscaling, concurrency, HPA) matter, but they don’t replace disciplined interface governance and deprecation/version policies.

10
Question 10

You must stress-test a GraphQL mutation webhook hosted on Cloud Functions (2nd gen) behind HTTPS. The endpoint accepts HTTP POST requests with a 1 KB JSON payload and must sustain burst traffic of 5,000 requests per second for 3 minutes. Your load tests must meet the following requirements: • Load is initiated from multiple parallel threads per generator. • Client traffic to the endpoint originates from multiple source IP addresses. • Load can be scaled up by adding additional test instances as needed. • Test runs are repeatable and provide latency/throughput metrics. You want to follow Google-recommended best practices. How should you configure the load testing?

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.

GKE is well-suited for distributed load testing: run a controller plus many worker Pods, scale replicas and nodes to reach 5,000 RPS, and use the tool’s metrics for latency/throughput reporting. Multiple parallel threads per generator are supported by Locust/JMeter workers. Multiple source IPs can be achieved by distributing workers across nodes and configuring Cloud NAT with multiple external IPs. Containerization and manifests make runs repeatable and scalable.

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.

Analyse de la question

Core concept: This question tests how to run scalable, repeatable, metrics-driven load tests on Google Cloud using a distributed load-testing framework. It emphasizes best practices for generating high RPS with parallelism, multiple source IPs, and horizontal scalability. Why the answer is correct: A distributed framework such as Locust or Apache JMeter running on Google Kubernetes Engine (GKE) is the most appropriate way to achieve 5,000 requests/second bursts for 3 minutes while meeting all constraints. A controller/leader coordinates the test plan and aggregates results, while worker Pods generate load in parallel threads/processes. You can scale load by increasing worker replicas and/or node pool size. Because traffic originates from multiple nodes (and potentially multiple NAT egress IPs), you can satisfy the “multiple source IP addresses” requirement in a controlled, repeatable way. Key features / configurations (best practices): - Use a GKE cluster (private is fine) with a dedicated node pool for load generators; scale node pool and worker replicas to reach target RPS. - Ensure egress uses Cloud NAT; to guarantee multiple source IPs, allocate multiple external NAT IP addresses and configure Cloud NAT to use them (or use multiple node pools/regions if required). - Use the framework’s built-in metrics (latency percentiles, throughput, error rates) and export to Cloud Monitoring/Cloud Logging for repeatable reporting. - Use container images and declarative manifests (Deployment/Job) for repeatability and versioned test plans. Common misconceptions: Using simple cURL loops on VMs (A/B) seems straightforward, but it lacks robust coordination, repeatability, and rich metrics, and it is difficult to reliably generate and control parallel user behavior at scale. Cloud Shell (D) is not designed for sustained high-throughput distributed testing and is constrained by session limits and resource quotas. Exam tips: For high-scale load testing on GCP, prefer containerized, distributed load tools on GKE (or managed load testing services when available) because they provide horizontal scaling, centralized control, and metrics. Also remember that “multiple source IPs” typically requires multiple egress IPs (e.g., Cloud NAT with multiple addresses) rather than just multiple threads or Pods on a single node.

Témoignages de réussite(6)

V
V***********Nov 24, 2025

Période de préparation: 2 months

The scenarios in this app were extremely useful. The explanations made even the tricky deployment questions easy to understand. Definitely worth using.

B
B************Nov 21, 2025

Période de préparation: 2 months

The questions weren’t just easy recalls — they taught me how to approach real developer scenarios. I passed this week thanks to these practice sets.

철
철**Nov 17, 2025

Période de préparation: 1 month

1개월 구독하니 빠르게 풀어야 한다는 강박이 생기면서 더 열심히 공부하게 됐던거 같아요. 다행히 문제들이 비슷해서 쉽게 풀 수 있었네요

이
이**Nov 15, 2025

Période de préparation: 1 month

이 앱의 문제들과 실제 시험 문제들이 많이 비슷해서 쉽게 풀었어요! 첫 시험만에 합격하니 좋네요 굿굿

R
R***********Nov 6, 2025

Période de préparation: 1 month

I prepared for three weeks using Cloud Pass and the improvement was huge. The difficulty level was close to the real Cloud Developer exam, and the explanations helped me fill in my knowledge gaps quickly.

Autres tests d'entraînement

Practice Test #1

50 Questions·120 min·Réussite 700/1000

Practice Test #3

50 Questions·120 min·Réussite 700/1000

Practice Test #4

50 Questions·120 min·Réussite 700/1000
← Voir toutes les questions Google Professional Cloud Developer

Commencer à s'entraîner

Téléchargez Cloud Pass et commencez à vous entraîner sur toutes les questions Google Professional Cloud Developer.

Get it on Google PlayDownload on the App Store
Cloud PassCloud Pass

Application d'entraînement aux certifications IT

Get it on Google PlayDownload on the App Store

Certifications

AWSGCPMicrosoftCiscoCompTIADatabricks

Mentions légales

FAQPolitique de confidentialitéConditions d'utilisation

Entreprise

ContactSupprimer le compte

© Copyright 2026 Cloud Pass, Tous droits réservés.

Envie de vous entraîner partout ?

Obtenir l'application

Téléchargez Cloud Pass — inclut des tests d'entraînement, le suivi de progression et plus encore.