Questions d'entraînement

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?

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.

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?

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.

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?

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?

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.

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?

Envie de vous entraîner partout ?

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

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?

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?

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?

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

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.

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?

Practice Test #2

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

Questions d'entraînement

Témoignages de réussite(6)

Autres tests d'entraînement

Practice Test #1

Practice Test #3

Practice Test #4

Commencer à s'entraîner