Questions d'entraînement

Question 1

A regional logistics company on Google Cloud needs to process live telemetry from delivery vans (8,000–12,000 events/second with sub-5-second aggregation windows) while also running hourly batch reconciliations of daily manifests; they have no existing analytics codebase and want a fully managed service that supports both batch and streaming with minimal operations overhead. Which technology should they use?

Question 2

Your fintech company runs a payment authorization microservice as a Kubernetes Deployment with 12 replicas in a regional GKE Autopilot cluster in us-central1. During rolling updates (maxUnavailable=0, maxSurge=2), production-only configuration mistakes have intermittently caused 5xx errors at ~1,500 RPS because new Pods begin receiving traffic before the bad settings cause runtime failures. You need a platform-level preventive control so that only healthy Pods receive traffic during the rollout and faulty versions do not trigger outages. What should you do?

Question 3

You operate a healthcare data processing environment on Google Cloud. All Compute Engine VMs run in VPC 'med-analytics-vpc' on subnet 'proc-subnet' (10.24.0.0/20), and an organization policy prohibits any VM from having an external (public) IP. A firewall rule denies ingress tcp:22 from 0.0.0.0/0, and there is no Cloud VPN or Cloud Interconnect to your office network (198.51.100.0/24). You must initiate an SSH session to a specific VM named 'etl-node-03' in us-central1-a for an urgent diagnosis, without assigning any public IPs or opening new inbound internet access. What should you do?

Question 4

Your media analytics team runs a custom regression test harness that executes Linux-native binaries and shell scripts to validate a new codec pipeline; the full suite currently takes about 6 hours on 4 on-premises servers (24 vCPUs total) and must be reduced to under 45 minutes by parallelizing runs without rewriting the tests, with each test job needing a standard Linux VM, a custom startup script, and access to a 50-GB artifact set in Cloud Storage, and the lab triggers 10–20 full runs per workday with peak concurrency of up to 800 short-lived workers during business hours while preferring pay-as-you-go and minimal operational overhead. Which Google Cloud infrastructure should you recommend?

Question 5

Your media company is building a new production environment on Google Cloud in a single VPC named media-prod with a subnet in us-central1 and will connect it to your data center using HA Cloud VPN with Cloud Router (dynamic routing); your on-premises RFC1918 address space is 10.20.0.0/16 and 172.18.0.0/16, and during a 6-month coexistence period every on-prem host must be reachable from Google Cloud and every Google Cloud workload must be reachable from on-prem without using NAT; you will also deploy a GKE cluster using alias IPs that requires two secondary ranges for Pods and Services; how should you plan the Google Cloud IP ranges to avoid reachability problems over the VPN during the migration?

Analyse de la question

Core Concept: This question tests hybrid networking IP planning with HA Cloud VPN + Cloud Router (dynamic routing/BGP) and GKE VPC-native (alias IP) clusters. The key concept is that with dynamic routing and a no-NAT requirement, all routed prefixes on both sides must be unique (non-overlapping) to avoid ambiguous routing and broken reachability. Why the Answer is Correct: During the 6-month coexistence period, every on-prem host must be reachable from Google Cloud and every Google Cloud workload must be reachable from on-prem “without using NAT.” With HA VPN + Cloud Router, routes are exchanged via BGP. If any Google Cloud subnet primary range or GKE secondary range overlaps with on-prem RFC1918 ranges (10.20.0.0/16 or 172.18.0.0/16), both sides will have competing routes for the same destination space. That creates asymmetric routing, blackholing, or traffic staying local instead of traversing the VPN. Therefore, you must allocate entirely non-overlapping CIDR blocks in Google Cloud for the VPC subnet and for both GKE secondary ranges (Pods and Services). Option C does exactly that. Key Features / Best Practices: - Cloud Router advertises VPC subnet primary ranges and (when configured/needed) relevant secondary ranges; on-prem routers learn these via BGP. Overlaps break deterministic routing. - GKE VPC-native requires two secondary ranges: one for Pod IPs and one for Service ClusterIPs. These are real IPs used in the network and must be routable across the hybrid link if on-prem needs to reach them. - Google Cloud Architecture Framework (Network and Security pillars): plan IP addressing early, avoid overlaps, and design for clear routing domains. - Practical planning: reserve sufficiently large, non-overlapping blocks (often separate /16s or larger aggregates) to accommodate growth and additional clusters/subnets. Common Misconceptions: A and B seem attractive because reusing on-prem ranges can “simplify cutover,” but that only works if you use NAT or if the environments are never simultaneously connected. Here, coexistence plus no NAT makes overlap unacceptable. D assumes “policy routing” can solve it; in practice, overlapping RFC1918 across BGP domains is brittle and not a supported best-practice for HA VPN/Cloud Router route exchange. Exam Tips: When you see: (1) hybrid connectivity, (2) dynamic routing/BGP, and (3) explicit “no NAT,” immediately choose “non-overlapping CIDRs everywhere,” including GKE secondary ranges. Also remember GKE alias IPs consume VPC secondary ranges that participate in routing and must be planned like any other subnet range.

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

Refer to the dark-mode network diagram shown below: your company has three separate VPCs in Google Cloud, each containing one Compute Engine instance. Subnets do not overlap and must remain isolated. Instance #1 is a special case and must communicate directly with Instance #2 and Instance #3 using internal IP addresses. What should you do?

Analyse de la question

Core concept: This question tests VPC isolation and the connectivity patterns available between separate VPC networks: VPC Network Peering, Cloud VPN/Interconnect, and multi-NIC Compute Engine instances. The key requirement is unusual: only Instance #1 must directly reach instances in two other isolated VPCs using internal IPs, while the VPCs/subnets must remain isolated from each other. Why the answer is correct: Adding additional NICs to Instance #1 (one NIC in VPC #2/subnet #2 and one NIC in VPC #3/subnet #3) is the only option that enables Instance #1 to have native, internal-IP presence in each VPC without creating any network-to-network connectivity between the VPCs. With multiple NICs, Instance #1 becomes a dual-/tri-homed host: it can send traffic out the interface that belongs to the destination VPC and reach Instance #2 and Instance #3 via their internal IPs. This preserves the isolation requirement because VPC #2 and VPC #3 are not connected to each other (and VPC #1 is not connected to them at the network layer); only the single VM participates in multiple networks. Key features / configurations: - Compute Engine supports multiple network interfaces (NICs) on a VM (subject to machine type limits). - Each NIC attaches to exactly one VPC network and one subnet, receiving an internal IP from that subnet. - You must update VPC firewall rules in VPC #2 and VPC #3 to allow ingress from Instance #1’s internal IPs (and optionally in VPC #1 depending on return paths). - Ensure OS routing/source-based routing is correct (the guest OS must send traffic to each destination via the correct NIC). Avoid enabling IP forwarding unless intentionally building a router/NVA. Common misconceptions: - Peering (option D) seems simple, but it creates VPC-to-VPC connectivity, violating “must remain isolated,” and it would also allow broader reachability than required. - Cloud VPN (option C) similarly connects networks (and adds cost/ops overhead) rather than limiting connectivity to a single VM. - Cloud Router (option A) is used with BGP for dynamic route exchange for VPN/Interconnect; it does not, by itself, connect isolated VPCs. Exam tips: When you see “only one VM needs access” plus “networks must remain isolated,” think “multi-NIC VM” rather than peering/VPN. Peering/VPN are network-level constructs that generally expand reachability beyond a single instance and require careful justification against isolation requirements.

Question 7

You are deploying a Cloud Run microservice that persists customer profiles in Cloud Datastore; at startup, the service must preload 50 top-level Profile entities whose numeric IDs are provided by a configuration file, and all entities are root entities with no ancestors; you want to minimize Cloud Datastore operational overhead (number of RPCs and index usage) and reduce retrieval latency; what should you do?

Question 8

You operate a latency-sensitive order-matching microservice on Google Kubernetes Engine in us-central1 with a Deployment named matcher-deploy (4 replicas with readinessProbes) exposed internally via a ClusterIP Service named matcher-svc behind an Internal HTTP(S) Load Balancer; you must roll out a new container image gcr.io/acme/matcher:v2 with minimal disruption (no more than 1 pod unavailable at any time) and without recreating the Service or changing the node pool; what should you do?

Question 9

You are designing an ingestion layer for a cross-continent payment event stream that feeds a reconciliation microservice requiring strict per-merchant FIFO ordering and exactly-once delivery; traffic arrives from 7 regions, spikes to 80,000 events per second, and must be processed end-to-end within 1.5 seconds while using only managed GCP services and avoiding custom brokers. Which products should you deploy to ensure guaranteed-once FIFO delivery and meet the scalability and latency requirements?

Analyse de la question

Core concept: This question is about choosing a fully managed GCP ingestion and stream-processing design for very high-throughput global events that need per-merchant ordered handling and practical exactly-once processing semantics. The best fit among the options is Cloud Pub/Sub for durable, low-latency global ingestion combined with Cloud Dataflow for scalable stream processing keyed by merchant. Why correct: Pub/Sub can absorb traffic from multiple regions at very high scale with low operational overhead, while Dataflow can process the stream in parallel and maintain per-key state. By using merchant ID as the key, the pipeline can preserve ordered handling per merchant and perform deduplication or sequence checks before forwarding results. This is the only option listed that can realistically satisfy the throughput and latency goals using managed services, though true end-to-end exactly-once to an external microservice still depends on the downstream sink or consumer being idempotent or transaction-aware. Key features: - Cloud Pub/Sub provides globally distributed, managed event ingestion with high throughput and low latency. - Cloud Dataflow supports streaming pipelines with per-key state, timers, checkpointing, autoscaling, and ordered processing patterns. - Pub/Sub ordering keys can help preserve publish order for a given merchant key, while Dataflow can enforce per-merchant sequencing logic and deduplicate retries. - Dataflow is designed for large-scale streaming workloads and can meet low-latency targets when properly tuned. Common misconceptions: A common mistake is to assume Pub/Sub alone guarantees exactly-once delivery and universal FIFO semantics; in practice, Pub/Sub is fundamentally designed around durable messaging and at-least-once delivery, with ordering only within an ordering key. Another misconception is that Dataflow automatically guarantees end-to-end exactly-once delivery to any downstream microservice; exactly-once is strongest within the pipeline and for supported sinks, while external side effects still require idempotency or transactional design. Exam tips: On the PCA exam, when you see global ingestion plus very high throughput, think Pub/Sub. When you also see per-key ordering, stateful stream logic, deduplication, and low-latency processing, add Dataflow. Be careful with wording like 'guaranteed-once delivery'—in many architectures, the managed services can provide exactly-once processing semantics in the pipeline, but end-to-end guarantees depend on the destination behavior.

Question 10

A nonprofit Earth-observation collective distributes high-resolution satellite imagery bundles for public download (each file 500 MB–3 GB, ~9 TB total), and their audience spans more than 45 countries across 6 continents; they need to minimize download latency for all users and adhere to Google-recommended practices while keeping operations simple. How should they store the files?

Analyse de la question

Core Concept: This question tests Cloud Storage location strategy for globally distributed content: choosing between regional vs multi-regional buckets to optimize user download latency while keeping operations simple. It also implicitly aligns with Google Cloud Architecture Framework principles around performance optimization, reliability, and operational excellence. Why the Answer is Correct: A Multi-Regional Cloud Storage bucket is designed for serving content to users spread across large geographies with low latency and high availability. With an audience in 45+ countries across 6 continents, placing the data in a single region would create consistently higher latency for users far from that region. A multi-regional bucket stores data redundantly across multiple regions within a broad geography (for example, US, EU, or ASIA), improving read performance and resilience without requiring the team to manage multiple buckets or replication workflows. This matches the requirement to minimize download latency “for all users” as much as possible while keeping operations simple. Key Features / Best Practices: Multi-regional buckets provide geo-redundancy and strong durability, and they reduce operational overhead compared to managing per-region buckets and replication. For public downloads, Cloud Storage also integrates well with Cloud CDN (typically via an external HTTP(S) load balancer) to further reduce latency and offload origin reads; however, the question focuses specifically on storage placement, and multi-regional is the Google-recommended default for widely distributed access patterns when simplicity matters. Common Misconceptions: A common trap is thinking “more buckets in more places” always equals better latency. In practice, multiple buckets introduce complexity: object synchronization, consistency of releases, access control duplication, and operational risk. Another misconception is “one bucket per zone”—Cloud Storage buckets are not zonal resources; they are regional, dual-region, or multi-regional. Exam Tips: When you see “global users + public downloads + keep it simple,” default to Multi-Regional Cloud Storage (or Dual-Region/Multi-Region depending on the choices). If the question instead emphasized data residency, strict regional compliance, or write locality, then Regional (or Dual-Region) plus CDN/replication might be preferred. Also remember: Cloud Storage is not zonal, so any option referencing “per zone buckets” is a red flag.

Practice Test #1

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

Questions d'entraînement

Témoignages de réussite(10)

Commencer à s'entraîner