GCP
Google Professional Cloud Architect
199+ questions d'entraînement gratuites avec réponses vérifiées par IA
Toutes les questions
et réponses gratuites
GCP
199+ questions d'entraînement gratuites avec réponses vérifiées par IA
Toutes les questions
et réponses gratuites
Au plus proche
de l'examen réelPropulsé par l'IA
Chaque réponse Google Professional Cloud Architect 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.
A global logistics firm operates 650 smart loading bays across 8 distribution centers on 3 continents, and each bay has a beam-break sensor that reports its state once per second; each event contains only a sensor ID and several discrete status flags, and analysts must correlate this data with driver account records, scheduled dock assignments, and warehouse location metadata to run join-heavy queries and produce operational reports; which database type should you use?
Flat files (e.g., CSV/JSON on a filesystem or object storage) are inexpensive for raw storage and simple batch processing, but they are not a database type optimized for frequent, join-heavy analytical queries. You would need an external query engine and careful data modeling to make joins performant. Managing schema evolution, indexing, and concurrent analyst access is also difficult compared to a relational/SQL system.
NoSQL databases (document, key-value, wide-column) can ingest high-velocity sensor events and scale horizontally, but they typically do not support complex relational joins efficiently. To correlate events with drivers, assignments, and location metadata, you’d usually denormalize data or perform joins in application code or pipelines, increasing complexity and risking inconsistency. NoSQL fits simple access patterns, not analyst-driven join-heavy reporting.
Relational databases are designed for structured data with relationships and support efficient joins using SQL. This matches the requirement to correlate sensor events with driver accounts, dock schedules, and warehouse metadata. In Google Cloud, BigQuery is the common choice for large-scale operational reporting and join-heavy analytics (partitioning, clustering, distributed joins). If the workload were primarily transactional, Cloud Spanner/Cloud SQL would be considered, but the question emphasizes analytics.
A blobstore (object storage like Cloud Storage) is ideal for durable, low-cost storage of raw event logs, backups, and data lake files, but it is not a database for interactive join-heavy queries. You would still need to load/query the data with a SQL engine (e.g., BigQuery external tables) to perform joins and reporting. By itself, blob storage lacks indexing, query planning, and relational capabilities.
Core concept: This question tests choosing the right database model based on query patterns. The key requirement is “join-heavy queries” that correlate high-frequency sensor events with multiple reference datasets (driver accounts, dock assignments, warehouse/location metadata). That points to a relational/SQL analytics pattern where normalized dimensions are joined to a fact/event table. Why the answer is correct: A relational database type is best when you need strong support for joins, referential integrity, and expressive SQL across multiple entities. Here, analysts must routinely join sensor events to several structured tables to produce operational reports. SQL engines and relational schemas (fact + dimensions) are designed for this. In Google Cloud, this typically maps to BigQuery for large-scale analytical joins (columnar storage, distributed execution) or Cloud Spanner/Cloud SQL if the workload is primarily transactional. Given 650 sensors reporting once per second (~650 events/sec, ~56M/day), analytics/reporting with joins strongly aligns with BigQuery’s strengths. Key features / best practices: Use a star schema: a large append-only fact table for events (partitioned by ingestion/event time; clustered by sensor_id or distribution_center) and dimension tables for drivers, assignments, and locations. BigQuery supports standard SQL joins, partitioning/clustering for cost/performance, and can ingest via Pub/Sub + Dataflow. If you need globally consistent OLTP updates to assignments/accounts, keep those in a transactional store (e.g., Spanner/Cloud SQL) and replicate/export to BigQuery for reporting. Common misconceptions: NoSQL is often chosen for “IoT/time-series,” but many NoSQL systems trade away complex joins; you’d denormalize or do application-side joins, which is inefficient for analyst-driven, ad hoc reporting. Flat files or blob storage can store data cheaply but do not provide query optimization, indexing, or join execution. Exam tips: Let the query pattern drive the choice: “join-heavy,” “analysts,” and “reports” are strong signals for relational/SQL analytics. In GCP, think BigQuery for analytical joins at scale; consider a separate OLTP database only if you also need low-latency transactional updates and strong consistency for operational apps.
A ticketing company needs to expose a public HTTPS webhook API written in Go 1.20 that is idle most of the day but can surge from ~0 to 10,000 requests per minute within 90 seconds when major sales go live; the service must maintain at least 99.95% availability during spikes, support request timeouts up to 60 seconds, auto-scale without pre-provisioning capacity, and minimize operational overhead by avoiding server, cluster, or OS management—what deployment approach should you recommend?
Google Kubernetes Engine can certainly run a Go 1.20 container and scale horizontally, but it does not satisfy the requirement to avoid cluster management. Even in highly managed GKE modes, you still own cluster configuration, deployment strategy, scaling behavior, and parts of the security and upgrade lifecycle. Rapid scale from near-zero without pre-provisioned capacity is also harder because node provisioning and pod startup can introduce delay during sudden spikes. This makes GKE more operationally heavy than necessary for a simple public webhook API.
App Engine standard is attractive for low-ops autoscaling web services, but it is not the best answer when the application specifically requires Go 1.20 and the option does not mention a compatible runtime generation or custom runtime support. Standard environment is more opinionated and constrained than flexible, which can create compatibility issues for exact language versions and dependencies. While it can autoscale well, the runtime requirement is the deciding factor here. Therefore, it is less suitable than App Engine flexible with a custom runtime.
A Managed Instance Group on Compute Engine is the least aligned with the operational requirements because it requires managing VM images, OS patching, instance templates, and scaling behavior. It can be made highly available and autoscaled, but handling a sudden surge from idle to very high traffic within 90 seconds often requires warm capacity or careful tuning. That directly conflicts with the goal of minimizing operational overhead and avoiding server management. MIGs are better suited when you need VM-level control, which this scenario does not require.
App Engine flexible environment supports custom runtimes, which makes it the strongest option here for a Go 1.20 application when the exact runtime version matters. It provides a managed platform for deploying HTTP services with built-in HTTPS support and autoscaling, while avoiding direct management of servers, operating systems, or Kubernetes clusters. Although it is VM-backed, it still significantly reduces operational overhead compared with GKE or Managed Instance Groups. It also supports request durations well beyond 60 seconds, so the timeout requirement is comfortably met for a webhook-style API.
Core concept: Choose the Google Cloud compute platform that best balances burst autoscaling, managed operations, runtime flexibility, and HTTP request handling constraints. The workload is a public HTTPS webhook API in Go 1.20 that is mostly idle, can spike rapidly, needs up to 60-second request duration, and should avoid server, cluster, or OS management. Why correct: App Engine flexible environment with a custom runtime supports Go 1.20 in a containerized deployment model while still abstracting away most infrastructure operations, and it supports automatic scaling for web services exposed over HTTPS. Key features: custom runtime support, managed HTTPS ingress, autoscaling, and no need to manage Kubernetes clusters or Compute Engine instances directly. Common misconceptions: App Engine standard is often chosen for low-ops web apps, but its runtime constraints and platform limitations make it a weaker fit when a specific newer language runtime and custom environment are required. Exam tips: When the question emphasizes a specific runtime version not natively guaranteed by standard runtimes, plus minimal ops and autoscaling, favor a managed custom-runtime platform over GKE or Compute Engine if Cloud Run is not offered.
Your media analytics firm stores 150 TB of sensitive video feature vectors on regional SSD persistent disks attached to a Dataproc cluster in us-central1. For regulatory reasons, you must be able to rotate the encryption key protecting the data at rest on these disks at least every 90 days without manually re-encrypting data or changing Spark jobs. Pipelines must continue to run with minimal operational overhead and no plaintext copies written to intermediate storage. You want to follow Google-recommended practices for security. What should you do?
Encrypting in ingestion jobs with Cloud KMS (application-level encryption) can meet confidentiality goals, but it violates the requirement to avoid changing Spark jobs/processing logic and increases operational overhead. It also risks plaintext exposure during processing (decryption needed in Spark) and can create plaintext intermediates (shuffle/spill/temp files) unless carefully engineered. This is not the Google-recommended simplest approach for disk-at-rest key rotation.
CMEK for persistent disks is the correct approach: configure Dataproc’s attached regional SSD persistent disks to use a Cloud KMS key. Rotate by adding new key versions and setting a new primary version, enabling regular rotation without manually re-encrypting 150 TB or modifying Spark jobs. Encryption remains transparent to HDFS/Spark, minimizes operational overhead, avoids plaintext copies to intermediate storage, and provides centralized auditing and access control.
GPG-based encryption is custom, operationally heavy, and not integrated with Google Cloud’s managed encryption controls. You would need to manage key distribution, rotation, and decryption inside Spark jobs, which conflicts with the requirement to avoid changing jobs and to minimize overhead. It also increases the risk of plaintext data appearing in memory, temp files, or spill locations during processing and is not a recommended managed-cloud practice.
CSEK (customer-supplied encryption keys) requires you to provide the raw AES-256 key material to Google for each disk operation and manage secure storage, rotation, and access yourself. This creates significant operational overhead and higher risk (key handling, distribution, potential loss). It also does not align as well with Google-recommended practices compared to CMEK with Cloud KMS, which centralizes control, auditing, and rotation via key versions.
Core Concept: This question tests encryption at rest for Google Cloud persistent disks using Cloud KMS customer-managed encryption keys (CMEK), and how key rotation works without re-encrypting data or changing applications. It also touches Dataproc’s use of Compute Engine persistent disks and Google-recommended security practices. Why the Answer is Correct: Using CMEK with Cloud KMS for the Dataproc cluster’s persistent disks allows Google-managed disk encryption to be wrapped by your KMS key. Rotating the key is done by creating a new key version in Cloud KMS and setting it as primary. New writes use the new version, and Google handles the cryptographic wrapping/rewrapping of the data encryption keys without you manually re-encrypting 150 TB, without changing Spark jobs, and without producing plaintext intermediate copies. Pipelines continue running with minimal operational overhead because encryption/decryption is transparent to the VM and HDFS layer. Key Features / Configurations: - Create a Cloud KMS key ring and key in the same location/region as the disks (us-central1) to satisfy regional constraints and reduce operational issues. - Configure Dataproc/Compute Engine persistent disks with CMEK at creation time (and ensure IAM: the Compute Engine/Dataproc service accounts have roles/cloudkms.cryptoKeyEncrypterDecrypter). - Rotate by adding new key versions and promoting a new primary version; audit and enforce rotation via Cloud KMS policies and Cloud Audit Logs. - Aligns with Google Cloud Architecture Framework security principles: centralized key management, least privilege, auditability, and automation. Common Misconceptions: Many assume they must encrypt data in the application (e.g., Spark/HDFS) to rotate keys. That adds complexity, risks plaintext spill, and requires code/job changes. Others confuse CMEK with CSEK; CSEK requires you to supply and manage raw keys per request, increasing operational burden and risk. Exam Tips: For “rotate keys without re-encrypting data” and “no app changes,” prefer CMEK with Cloud KMS integrated at the storage layer (Persistent Disk, Cloud Storage, BigQuery, etc.). Choose CSEK only when explicitly required to provide the key material to Google per operation. Also watch for location constraints: KMS key location must match the resource’s location/region.
Cinemetrix, a media analytics firm, enabled Google Workspace (domain: cinemetrix.com) last week and created a Google Cloud Organization; they currently have 85 projects across 6 folders. The security office now mandates that, effective immediately, no principals from outside cinemetrix.com may be granted any IAM role on any project, folder, or resource within the Organization. The control must be enforced centrally at the Organization level, automatically apply to newly created projects, work without custom scripts or periodic jobs, take effect within 30 minutes, and must not break existing or future service-account-based workloads. What should you do?
Correct. constraints/iam.allowedPolicyMemberDomains is the Organization Policy constraint specifically intended to restrict which principals can appear in IAM policies based on the organization’s allowed identity domain/customer. Applying it at the Organization root gives centralized governance and inheritance to all folders and projects, so existing resources and newly created projects are covered automatically. This is a preventive control, meaning attempts to add disallowed external principals are rejected at policy update time rather than being cleaned up later. It also aligns with the requirement to avoid custom scripts or periodic jobs and is the standard Google Cloud mechanism for this type of guardrail.
Incorrect. Preventing service account creation does not stop administrators from granting IAM roles to external users, groups, or domains, which is the actual requirement in the question. It addresses a different problem entirely and would likely disrupt many workloads and Google Cloud services that depend on service accounts for authentication and authorization. The question explicitly says the solution must not break existing or future service-account-based workloads, so this option conflicts with that requirement. It also fails to provide the requested domain-based restriction on IAM members.
Incorrect. A Cloud Scheduler and Cloud Function solution is a custom scripted remediation process, which the question explicitly rules out. It is also reactive rather than preventive, so an external principal could be granted access and retain it until the next scheduled run, creating a compliance and security gap. Because it runs every 60 minutes, it does not meet the requirement to take effect within 30 minutes. Operationally, it adds complexity, requires broad IAM permissions to inspect and modify policies, and is less reliable than a native Organization Policy control.
Incorrect. Running a cron job on a VM to scan and modify IAM policies is another custom periodic remediation approach, so it violates the requirement to avoid scripts and scheduled jobs. Like option C, it is not preventive and leaves a window during which unauthorized external principals could retain access. It also introduces unnecessary operational burden and security risk, especially if the VM or technical user has Organization-level Owner privileges. This is the opposite of the managed, inherited, policy-based control that the question is signaling.
Core concept: This question tests centralized preventive governance using Organization Policy Service for IAM, specifically restricting who can be added to IAM policies across an entire Google Cloud Organization. This aligns with the Google Cloud Architecture Framework’s Security, Privacy, and Compliance pillar: enforce policy-as-code guardrails centrally, consistently, and automatically. Why the answer is correct: The requirement is to ensure that no principals from outside cinemetrix.com can be granted IAM roles anywhere in the Organization (projects, folders, or resources), with automatic inheritance to new projects, no scripts/jobs, and near-real-time enforcement (within ~30 minutes). The organization policy constraint constraints/iam.allowedPolicyMemberDomains is designed for exactly this: it restricts IAM policy members to an allowlist of customer-managed identity domains. When set at the Organization root, it is inherited by all folders/projects unless explicitly overridden (and you can also enforce it to prevent overrides). This provides preventive control: attempts to add disallowed principals are rejected. Key features / configuration notes: - Set the policy at the Organization node to allow only the cinemetrix.com Cloud Identity/Google Workspace domain. - Ensure service accounts are not broken: workloads commonly use Google-managed service account identities (e.g., *.gserviceaccount.com). The constraint supports allowing required service account domains so existing and future service-account-based workloads continue to function. - Inheritance ensures newly created projects automatically comply without additional automation. - Organization Policy changes typically propagate quickly (the question’s 30-minute requirement matches expected propagation behavior). Common misconceptions: Many candidates jump to “scan and remediate” (scheduled scripts) rather than “prevent.” Remediation jobs (Cloud Scheduler/cron) are not immediate, can miss short-lived privilege grants, add operational risk, and violate the no-scripts requirement. Another misconception is blocking service account creation; that does not prevent external users from being granted roles and would break workloads. Exam tips: - Prefer Organization Policy constraints for centralized, automatic, preventive controls. - Distinguish preventive guardrails (Org Policy) from detective/remedial controls (Asset Inventory + Functions, cron jobs). - When restricting IAM members, always consider service accounts and Google-managed identities so you don’t disrupt platform services and CI/CD pipelines. - For questions requiring “applies to new projects automatically” and “no periodic jobs,” Organization Policy at the Organization root is a strong signal.
Your retail analytics team needs to run 40 legacy Hadoop MapReduce jobs on Google Cloud for weekly batch processing without changing any job code or deployment scripts; they want to minimize both compute cost and infrastructure management effort; each batch runs 3–6 hours and the pipelines can tolerate up to 20% worker loss without failing. What should you do?
Dataproc with standard workers meets the “no code/script changes” and “minimize management” requirements because Dataproc is a managed Hadoop service. However, it does not best meet the “minimize compute cost” requirement. For weekly 3–6 hour batches, paying full on-demand price for all workers is typically unnecessary when the workload can tolerate worker loss and can leverage cheaper preemptible capacity.
Dataproc with preemptible workers best matches all constraints: managed Hadoop (minimal ops), compatibility with existing MapReduce jobs (no code changes), and lower compute cost. Because the pipelines can tolerate up to 20% worker loss, preemptions are acceptable; YARN can reschedule tasks and the job can still complete if the cluster is sized appropriately. Keep the master on standard instances for stability.
A self-managed Hadoop cluster on Compute Engine using standard instances increases infrastructure management effort: you must install/configure Hadoop, manage upgrades/patching, handle monitoring, and maintain cluster reliability. While it can run legacy jobs without code changes, it fails the “minimize infrastructure management effort” requirement and is usually more expensive operationally than Dataproc for periodic batch workloads.
Self-managed Hadoop on preemptible instances may reduce compute cost, but it significantly increases operational complexity and risk. You must build automation to handle preemptions, node replacement, and cluster health, and still manage Hadoop lifecycle yourself. This conflicts with the requirement to minimize infrastructure management effort. Dataproc provides the managed control plane and simpler integration while still enabling preemptible workers.
Core Concept: This question tests choosing the right managed Hadoop service and VM purchasing model for batch MapReduce workloads. The key services are Cloud Dataproc (managed Hadoop/Spark) and Compute Engine (self-managed Hadoop). The key pricing/availability concept is preemptible VMs (Spot VMs in newer terminology), which are significantly cheaper but can be terminated. Why the Answer is Correct: The team must run 40 legacy Hadoop MapReduce jobs “without changing any job code or deployment scripts,” and wants minimal infrastructure management. Cloud Dataproc is purpose-built for running existing Hadoop jobs with minimal changes because it provides a managed Hadoop environment (HDFS/YARN/MapReduce) and integrates with Cloud Storage. To minimize compute cost, use preemptible worker instances. The workload is weekly, 3–6 hours, and can tolerate up to 20% worker loss—this aligns well with preemptible workers because occasional VM termination won’t necessarily fail the job if the cluster has enough capacity and YARN can reschedule tasks. Key Features / Best Practices: - Dataproc reduces ops effort: automated cluster provisioning, configuration, monitoring integration, and easy job submission. - Use preemptible workers for cost savings (often 60–80% cheaper) while keeping the master (and optionally some core workers) on standard instances for stability. - Design for fault tolerance: ensure adequate replication/inputs in Cloud Storage, and size the cluster so losing up to 20% workers still meets SLAs. - Use ephemeral clusters (create per batch, delete after) to avoid paying when idle; this further reduces cost and aligns with weekly processing. Common Misconceptions: - “Standard workers are safer” (Option A) but cost is a primary requirement and the workload explicitly tolerates worker loss. - “Manual Hadoop on Compute Engine gives more control” (Options C/D) but violates the requirement to minimize infrastructure management effort and increases operational burden (patching, configuration drift, monitoring, scaling). Exam Tips: When you see “legacy Hadoop/MapReduce with minimal changes,” default to Dataproc. When you see “batch, fault-tolerant, cost-sensitive,” consider preemptible/Spot workers. Also remember the architectural principle: prefer managed services to reduce operational overhead (Google Cloud Architecture Framework: operational excellence and cost optimization).
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.
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?
Google Cloud Dataproc provides managed Hadoop/Spark clusters and is strong for batch ETL and existing Spark streaming jobs. However, it still requires cluster management (node sizing, upgrades, autoscaling policies) and is not the lowest-ops choice. With no existing analytics codebase, adopting Spark plus cluster operations is heavier than using Dataflow’s serverless model for both streaming windowed aggregations and batch reconciliations.
Google Cloud Dataflow is the best fit: a fully managed, serverless service for Apache Beam that supports both streaming and batch with one programming model. It natively handles event-time windowing, triggers, and late data—ideal for sub-5-second aggregations at 8k–12k events/sec. Autoscaling and managed execution minimize operational overhead, and it integrates cleanly with Pub/Sub, BigQuery, Bigtable, and Cloud Storage.
GKE with Cloud Bigtable can be used to build a custom streaming pipeline (e.g., microservices consuming Pub/Sub and writing to Bigtable). Bigtable is excellent for high-throughput, low-latency key-value access, but it is not a stream processing engine. This option increases operational complexity (cluster management, scaling, deployments, observability) and requires building windowed aggregation logic yourself, conflicting with the “fully managed/minimal ops” requirement.
Compute Engine with BigQuery implies running custom processing on VMs and loading results into BigQuery. BigQuery is a managed analytics warehouse and supports streaming inserts, but it does not replace a streaming processing engine for sub-5-second windowed aggregations. Using Compute Engine adds significant operational overhead (VM management, scaling, fault tolerance) and is not the recommended managed approach compared to Dataflow for unified batch and streaming pipelines.
Core Concept: This question tests selecting a fully managed data processing service that supports both streaming (low-latency, continuous) and batch (scheduled/periodic) pipelines with minimal operational overhead. In Google Cloud, the canonical choice is Dataflow (Apache Beam managed service). Why the Answer is Correct: The company must ingest 8,000–12,000 events/second and compute sub-5-second aggregations. Dataflow is designed for exactly this: high-throughput streaming with windowing (tumbling/sliding/session windows), triggers, and watermarks to handle out-of-order telemetry. The same service can run hourly batch reconciliations using the same Beam programming model, which is important because they have no existing analytics codebase and want a unified approach rather than maintaining separate systems. Key Features / Best Practices: Dataflow is serverless and autoscaling, reducing ops overhead (no cluster sizing, patching, or capacity planning). For streaming, use Pub/Sub as the ingestion layer and implement fixed windows (e.g., 5 seconds) with appropriate triggers (early/on-time/late) and allowed lateness. Dataflow Streaming Engine can improve performance and reduce worker resource usage for stateful/windowed pipelines. For batch reconciliations, schedule Dataflow batch jobs via Cloud Scheduler/Workflows or orchestrate with Composer if needed. Outputs commonly land in BigQuery for analytics, Bigtable for low-latency lookups, or Cloud Storage for archival. Common Misconceptions: Dataproc is “managed,” but it is still a cluster you operate (lifecycle, sizing, upgrades) and is better when you already have Spark/Hadoop jobs. GKE + Bigtable can handle streaming architectures, but it increases operational burden and requires building/operating custom stream processors. Compute Engine + BigQuery is not a streaming processing service; VMs would host custom code and add significant ops. Exam Tips: When you see “streaming + batch,” “windowing,” “sub-second to seconds latency,” and “fully managed/minimal ops,” think Dataflow. Dataproc is for lift-and-shift Spark/Hadoop; GKE is for custom platforms; Compute Engine is lowest-level and rarely the best answer for managed analytics pipelines. Align with Google Cloud Architecture Framework principles: operational excellence (serverless), performance efficiency (autoscaling), and reliability (managed service).
A regional film studio needs to move a one-time 12-TB set of 4K render files from its on-premises NAS into a Google Cloud Storage bucket for archival. The studio has a reliable 1 Gbps internet connection to Google Cloud and a 48-hour maintenance window. They want to minimize total transfer time and cost while following Google-recommended practices. What should they do?
Dataflow is designed for distributed data processing (ETL/ELT) and streaming/batch transformations, not for straightforward bulk file migration from a NAS. Building a pipeline to read files and write to Cloud Storage adds engineering effort, operational overhead, and Dataflow job cost without improving transfer speed versus a direct upload. It also introduces more failure modes than necessary for a one-time archival copy.
Transfer Appliance is best when network transfer is too slow, unreliable, or would exceed the allowed window (or when moving very large datasets). Here, 12 TB over 1 Gbps in 48 hours is achievable online, so an appliance would likely increase end-to-end time due to ordering, delivery, loading, shipping, and Google ingestion steps, and it adds appliance/shipping costs.
A commercial partner ETL solution is unnecessary for a one-time file upload and typically increases cost and complexity. ETL tools are valuable when you need transformations, metadata enrichment, orchestration across heterogeneous systems, or ongoing pipelines. For simply copying render files into Cloud Storage for archival, native Google tools provide better cost efficiency and fewer components to manage.
Using gcloud storage cp is the simplest, lowest-cost approach for a one-time upload when bandwidth and time allow. It supports resumable uploads and can leverage parallelism to better utilize a 1 Gbps connection. This aligns with Google-recommended operational practices: minimize custom code, use supported tooling, and complete the transfer within the maintenance window while controlling cost.
Core concept: This question tests choosing the right data-ingestion method into Cloud Storage based on dataset size, available bandwidth, time window, and cost. For one-time online transfers, Google-recommended practice is to use Storage Transfer Service (STS) when applicable, or use parallelized CLI tools (gcloud storage) for direct uploads. Transfer Appliance is recommended when network transfer is too slow or impractical. Why the answer is correct: 12 TB over a reliable 1 Gbps link within 48 hours is feasible online. Theoretical throughput at 1 Gbps is ~125 MB/s. Over 48 hours, that is ~21.6 TB maximum (125 MB/s * 172,800 s), so even with protocol overhead, TLS, and less-than-perfect utilization, 12 TB is comfortably within the window if the upload is executed efficiently. Using gcloud storage cp (ideally with parallel composite uploads enabled by default behavior in modern gcloud storage and with appropriate parallelism) is the lowest-cost, simplest, and fastest-to-start approach for a one-time transfer from a NAS to a Cloud Storage bucket. Key features / best practices: Use the newer “gcloud storage” commands (not legacy gsutil) for performance and simplicity. Run from a machine with fast local/network access to the NAS, ensure sufficient CPU for checksum/TLS, and use parallelism (multiple processes/threads) to saturate the 1 Gbps link. Consider resumable uploads (supported) to handle interruptions. Validate with checksums and consider setting the appropriate storage class (e.g., Archive) and lifecycle policies after upload for archival cost optimization. Common misconceptions: Transfer Appliance sounds “fast,” but it introduces shipping time, scheduling, and appliance fees—unnecessary when the network can meet the SLA. Dataflow/ETL tools are for transformation pipelines, not bulk file copy, and add cost/complexity. Exam tips: Always do the bandwidth-time math. If online transfer fits the window, prefer simple native tools (gcloud storage/STS). Choose Transfer Appliance when data is very large (often tens to hundreds of TB+) or network/time constraints make online transfer impractical. Map the choice to the Architecture Framework: optimize cost and operational excellence by minimizing moving parts for a one-time migration.
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?
Correct. Readiness probes are the Kubernetes-native mechanism that determines whether a Pod is added to a Service's endpoints and can receive traffic. During a rolling update, this prevents newly created Pods from serving requests until they have fully initialized and passed health validation. In this scenario, a readiness probe can catch bad production-only configuration before the Pod is considered available, which prevents 5xx errors from the faulty version. Liveness probes may also be useful for self-healing, but the essential preventive control here is readiness.
Incorrect. Managed instance group (MIG) health checks apply to Compute Engine VM-based workloads behind load balancers, not to Kubernetes Pods in a GKE Autopilot cluster. In GKE, Pod health and traffic eligibility are controlled by Kubernetes readiness/liveness probes and (optionally) load balancer integrations, not MIG health checks.
Incorrect. A scheduled task that checks availability is a reactive, external mechanism and typically runs at coarse intervals. It cannot reliably gate traffic at the moment new Pods come online during a rolling update, nor does it integrate with Kubernetes endpoint readiness to automatically exclude unhealthy Pods from receiving requests.
Incorrect. Uptime alerts in Cloud Monitoring detect outages and notify operators after symptoms appear. They do not prevent traffic from reaching newly started Pods, and they do not influence Kubernetes readiness or rollout behavior. Alerts are important for operations, but they are not a preventive rollout control.
Core concept: This question tests Kubernetes rollout safety in GKE Autopilot and how to ensure only healthy Pods receive traffic during a Deployment update. The key mechanism is the readiness probe, which controls whether a Pod is added to Service endpoints and therefore eligible to receive requests. Why the answer is correct: With maxUnavailable=0 and maxSurge=2, Kubernetes creates new Pods before removing old ones. If a new Pod is marked Ready too early, it can immediately receive production traffic and cause errors. A properly designed readiness probe verifies that the application has fully initialized and can safely serve requests, including validating configuration and dependency availability. Until the readiness probe succeeds, the Pod is excluded from Service load balancing, which prevents faulty versions from receiving traffic during the rollout. Key features: - Readiness probe: determines whether a Pod should receive traffic through a Service. - startupProbe: useful when startup is slow, so readiness/liveness checks do not fail prematurely. - Liveness probe: helps restart a hung or dead container after it is running, but it is not the primary traffic-gating control. - Meaningful health endpoints should validate real serving readiness, not just that the process has started. Common misconceptions: External monitoring, scheduled checks, and alerts are reactive controls. They can detect failures after impact begins, but they do not integrate with Kubernetes endpoint readiness to prevent traffic from reaching bad Pods during rollout. MIG health checks are also not the mechanism used to control Pod readiness in GKE. Exam tips: When a GKE or Kubernetes question asks how to ensure only healthy Pods receive traffic, the best answer is readiness probes. If the scenario mentions rollout safety, endpoint membership, or preventing bad versions from serving requests, think readiness first; liveness is for restart behavior, not traffic gating.
You are deploying a telemetry ingestion service in Google Cloud that must privately exchange data with a vendor-managed control system hosted in a third-party colocation facility outside Google Cloud. The average sustained traffic is 300 kbps, with occasional bursts up to 1 Mbps. The business requires 99.99% connectivity availability and emphasizes cost optimization. You need to design private connectivity between the Google Cloud VPC and the external site to meet these requirements. What should you provision?
This is the best answer because HA Cloud VPN is the Google Cloud VPN offering designed for high availability and is the cost-optimized choice for low-bandwidth private connectivity. It uses a regional HA gateway with two interfaces and supports redundant tunnels, which is the standard pattern for meeting a 99.99% availability target on the Google Cloud side. Compared with the other options, it avoids the unnecessary extra gateways and peer devices in option C while still selecting the correct product family. On certification exams, when HA Cloud VPN is available and the traffic volume is very small, it is typically the intended answer over more complex or legacy alternatives.
Classic Cloud VPN is the legacy offering and is not the recommended design when the requirement explicitly calls for 99.99% connectivity availability. Even if you configure two tunnels, Classic VPN does not provide the HA gateway architecture associated with the higher-availability design pattern. This makes it a weaker fit than HA Cloud VPN for strict uptime requirements. Therefore, it fails both the availability and best-practice aspects of the question.
This option provides more redundancy than necessary and is not cost-optimized for a workload that only needs a few hundred kbps to 1 Mbps. Deploying two HA Cloud VPN gateways in Google Cloud plus two on-premises VPN gateways significantly increases complexity and cost beyond what the requirement suggests. While it may be highly resilient, the question explicitly emphasizes cost optimization, so an overbuilt design is not the best answer. In exam terms, this is a distractor that is technically strong but not the most appropriate solution.
A single Classic Cloud VPN tunnel has no meaningful redundancy and cannot satisfy a 99.99% availability requirement. Any tunnel, device, or path failure would interrupt connectivity until manual or automatic recovery occurs on that single path. It also uses the legacy VPN product rather than HA Cloud VPN. This is clearly the least suitable option for both reliability and architecture best practices.
Core concept: This question is about selecting the most cost-effective private hybrid connectivity option that still meets a 99.99% availability target. For very low throughput such as 300 kbps sustained and 1 Mbps bursts, Cloud VPN is far more economical than Interconnect, and HA Cloud VPN is the Google-recommended option when high availability is required. The correct choice is the HA Cloud VPN-based design because it is the only option aligned with the 99.99% availability requirement while remaining cost-conscious. A common misconception is that you must deploy multiple HA Cloud VPN gateways in Google Cloud to achieve 99.99%, but that adds unnecessary cost and complexity; the key is using HA Cloud VPN rather than Classic VPN. Exam tip: when bandwidth is low and availability is high, prefer HA Cloud VPN over Interconnect or Classic VPN, and avoid overengineering beyond the stated requirement.
A retail analytics team runs a Google Kubernetes Engine (GKE) worker that pulls events from a Pub/Sub pull subscription (orders-events) and writes batch outputs to Cloud Storage; the app was deployed as a single pod and Pub/Sub monitoring shows a backlog of about 12,000 undelivered messages with the 90th percentile wait time at 8 minutes, while each pod processes roughly 6 messages per second when disk throughput is near 80 MB/s, indicating the workload is I/O-intensive; you must scale the processing so the backlog stays under 500 messages and per-message latency remains under 60 seconds without changing the application code; what should you do?
CPU-based HPA is easy to configure, but it’s the wrong control signal for an I/O-intensive Pub/Sub consumer. Disk throughput is the limiting factor, so CPU may remain below 50% even while messages pile up, preventing scale-out and violating backlog/latency targets. This option also doesn’t directly tie scaling to the SLOs (backlog < 500, latency < 60s).
This suggests scaling on subscription/push_request_latencies, but the workload uses a pull subscription. Push request latency metrics apply to Pub/Sub push delivery to an HTTPS endpoint, not to a pull-based consumer running in GKE. Even if a latency metric were available, backlog depth is typically a more stable and actionable scaling signal for pull consumers.
Enabling cluster autoscaling only allows GKE to add/remove nodes when pods can’t be scheduled due to insufficient resources. It does not decide how many replicas of the consumer pod should run, so it won’t reduce Pub/Sub backlog by itself. You still need HPA (or another controller) to increase pod replicas based on workload demand.
Scaling the deployment based on subscription/num_undelivered_messages directly targets the backlog, which is the key symptom and the SLO constraint. As backlog grows, HPA increases replicas to raise total consumption throughput; as backlog shrinks, it scales down. This approach works without application changes and is appropriate for pull-based Pub/Sub consumers where CPU is not the bottleneck.
Core Concept: This question tests event-driven autoscaling for a GKE workload consuming from Pub/Sub, and choosing the right scaling signal when you cannot change application code. It also touches on aligning scaling with SLOs (backlog < 500, latency < 60s) and using Cloud Monitoring metrics to drive Kubernetes Horizontal Pod Autoscaler (HPA) via custom/external metrics. Why the Answer is Correct: To keep backlog and latency low, you must scale based on demand (how many messages are waiting), not on CPU. The workload is explicitly I/O-intensive (disk throughput near 80 MB/s), so CPU utilization is a poor proxy for throughput. Pub/Sub exposes subscription/num_undelivered_messages, which directly represents backlog pressure. Configuring HPA to scale the deployment based on this metric increases pod count when backlog grows and reduces it when backlog is drained, meeting the requirement without code changes. Key Features / Best Practices: - Use HPA with external/custom metrics sourced from Cloud Monitoring (Pub/Sub subscription metrics). In practice, this is commonly implemented with a metrics adapter (e.g., Google Cloud Managed Service for Prometheus + adapter, or external metrics adapter) so HPA can read Cloud Monitoring metrics. - Choose a target backlog per pod (or per replica) derived from throughput and latency SLOs. Example reasoning: each pod ~6 msg/s; to keep worst-case wait <60s, you want enough replicas so backlog drains quickly (e.g., total processing rate >= incoming rate and backlog/total_rate <= 60s). Backlog-based scaling is the most direct control loop. - This aligns with the Google Cloud Architecture Framework (Operational Excellence and Performance Optimization): measure the right signals, automate scaling, and design for elasticity. Common Misconceptions: - CPU-based autoscaling (option A) is tempting because it’s the default and easy, but it fails for I/O-bound consumers where CPU stays low while backlog grows. - Latency metrics (option B) can be misleading here: the option references push_request_latencies, which is for push subscriptions, while the workload uses a pull subscription. - Cluster autoscaling (option C) is not the same as pod autoscaling; it only adds/removes nodes when pods are pending due to insufficient capacity. Exam Tips: When a system consumes from a queue/stream (Pub/Sub, Kafka) and you need to control backlog/latency without code changes, prefer autoscaling on queue depth (num_undelivered_messages) or a derived “work items per replica” metric. Use CPU only when CPU is the bottleneck. Also verify metric applicability (push vs pull) and distinguish HPA (pods) from Cluster Autoscaler (nodes).
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.
Your media streaming company wants to maintain a near–real-time warm standby of its on-premises billing MariaDB cluster in Google Cloud for disaster recovery. The dataset is approximately 4 TB, and change data capture can burst to 800 Mbps during nightly reconciliations (hundreds of GB per hour). The replication engine requires endpoints to communicate over RFC1918 private IP space and must not traverse NAT or public addresses; you also need predictable, low-latency connectivity. Which networking approach should you use?
Dedicated Interconnect is the best fit for private, non-internet connectivity with predictable latency and high throughput. It supports RFC1918 addressing without NAT, uses VLAN attachments with Cloud Router (BGP), and can be provisioned redundantly for HA. This matches the replication engine’s strict private endpoint requirement and the bandwidth needs for large initial sync and nightly CDC bursts.
Cloud VPN can securely connect on-premises networks to Google Cloud while preserving private IP communication between workloads, but the tunnel itself traverses the public internet. That means latency and jitter are less predictable than with Interconnect, which is a problem for a replication workload that explicitly requires predictable low-latency connectivity. Although VPN throughput may be sufficient in some cases, it is not the best fit for sustained heavy replication and large burst windows when deterministic performance is important. Therefore, it does not satisfy the networking requirement as well as Dedicated Interconnect.
A NAT and TLS translation gateway is incompatible with the stated requirement that the replication endpoints must not traverse NAT or public addresses. Even if encryption and translation were technically possible, the design would alter addressing behavior in a way the replication engine explicitly forbids. It would also introduce unnecessary complexity, operational overhead, and a potential bottleneck for large replication bursts. Because the question asks for a private, predictable hybrid networking approach, this option is clearly unsuitable.
A self-managed VPN server on a Compute Engine instance is not a recommended enterprise connectivity pattern for this type of hybrid replication workload. It adds operational burden for patching, scaling, failover, and monitoring, and it still typically depends on internet-based VPN behavior rather than dedicated private connectivity. That means it does not provide the same predictability, resilience, or managed networking characteristics as Dedicated Interconnect. For a large warm standby replication design with strict private-path requirements, this option is inferior to the managed Interconnect solution.
Core concept: This question tests hybrid connectivity design for disaster recovery replication with strict private-IP (RFC1918) requirements, high sustained throughput, and predictable low latency. The key services are Dedicated Interconnect vs Cloud VPN and why “private, no NAT/public” plus performance points to Interconnect. Why the answer is correct: Google Cloud Dedicated Interconnect provides a private, SLA-backed Layer 2 connection between your on-prem network and a Google Cloud VPC via VLAN attachments (Cloud Interconnect). Traffic stays on private RFC1918 addressing end-to-end and does not traverse the public internet. This meets the replication engine constraint (no NAT, no public endpoints) and provides predictable latency and high throughput suitable for bursts up to ~800 Mbps and large data movement (4 TB initial sync plus nightly CDC spikes). It also aligns with the Google Cloud Architecture Framework’s reliability and performance pillars by reducing internet variability and enabling deterministic network behavior for DR. Key features / configurations / best practices: - Use Dedicated Interconnect with redundant connections (at least two 10/100 G links) in separate edge availability domains/metros for high availability. - Create VLAN attachments to Cloud Router (BGP) for dynamic route exchange; advertise on-prem RFC1918 prefixes and VPC subnets. - Ensure sufficient capacity headroom for reconciliation bursts; consider multiple VLAN attachments and QoS/traffic engineering on-prem. - For warm standby, pair with regional design on the GCP side (e.g., Cloud SQL for MySQL-compatible engines or self-managed MariaDB on GCE) and validate replication lag under peak throughput. Common misconceptions: Cloud VPN can use private IPs, but it rides the public internet and is subject to jitter/variable latency; it may also struggle with sustained high throughput unless using HA VPN with multiple tunnels and still lacks the same predictability. NAT/TLS translation violates the “must not traverse NAT/public addresses” requirement. A DIY VPN server on GCE adds operational risk and is not the recommended enterprise pattern. Exam tips: When you see “predictable low latency,” “high throughput,” “private RFC1918 end-to-end,” and enterprise DR replication, default to Interconnect (Dedicated or Partner). Choose VPN when cost is primary and performance/latency variability is acceptable. Eliminate any option introducing NAT/public endpoints when the requirement explicitly forbids it.
An aerospace research division must move 12 Windows Server 2022 Datacenter VMs from a classified on-premises lab to Google Cloud within 30 days while reusing existing Microsoft Windows Server licenses covered by active Software Assurance; no Google-provided Windows licensing fees are permitted. Workloads must run in the europe-west4 region with host-level isolation under your control, and each migrated VM must boot from its original OS disk to preserve in-guest agents and local policies. You need a repeatable approach for the first validation VM that keeps licensing compliant and maintains the existing OS state. What should you do?
This option partially addresses the requirement to preserve the original operating system by moving a raw image into Google Cloud. However, it does not specify running the VM on sole-tenant infrastructure, so it fails the explicit requirement for host-level isolation under customer control. It also omits the dedicated-host aspect needed for the no-Google-provided-Windows-license-fee scenario in this question. In addition, simply saying to import the disk is less precise than using the supported Windows image import workflow that prepares the image for Compute Engine boot compatibility.
This option is incorrect because it creates a new VM from a public Windows image rather than preserving the original on-premises OS disk. Public Windows images on Compute Engine use Google-provided Windows licensing, which directly violates the requirement that no Google-provided Windows licensing fees be incurred. It also fails the host-level isolation requirement because standard Compute Engine instances are not sole-tenant by default. Most importantly, deploying from a fresh image would not preserve the existing in-guest agents, local policies, and system state from the original VM.
This option imports the original VM image but then uses it only as a data disk, which does not meet the requirement that the migrated VM boot from its original OS disk. Because the instance is created from a public Windows image, it would still use Google-provided Windows licensing and therefore violate the licensing constraint. It also does not specify sole-tenant placement, so it misses the host-level isolation requirement. Attaching the imported disk as secondary storage may preserve files, but it does not preserve the original running operating system environment needed for validation.
This option is the only one that satisfies every requirement in the prompt. The image import step brings the existing Windows Server 2022 system into Compute Engine in a form that can boot on Google Cloud while preserving the original OS state, including installed agents, local security policies, and machine-specific configuration. Creating the VM as a sole-tenant instance in europe-west4 provides dedicated host placement under customer control, which directly addresses the host-level isolation requirement. It also avoids relying on a Google-provided Windows public image, which is important because the prompt explicitly disallows Google-provided Windows licensing fees. Finally, using the imported disk as the boot disk ensures the migrated VM starts from the original system volume rather than from a newly installed operating system.
Core concept: This question tests Windows license mobility (BYOL) on Google Cloud, VM migration while preserving the original OS disk state, and isolation requirements. In Google Cloud, reusing existing Windows Server licenses with Software Assurance is supported via Bring Your Own License (BYOL) only on Sole-tenant nodes (and certain dedicated offerings), not on standard shared-tenancy Compute Engine VMs. Why the answer is correct: The division requires (1) no Google-provided Windows licensing fees, (2) host-level isolation under customer control, (3) europe-west4 placement, and (4) each VM must boot from its original OS disk to preserve in-guest agents and local policies. Option D satisfies all four: you import the on-prem OS disk into a Compute Engine image using the supported import tooling (gcloud compute images import with the correct Windows OS flag), then create a Sole-tenant instance and explicitly use the imported disk as the boot disk. Sole-tenant nodes provide dedicated physical hosts, which is the key prerequisite for compliant Windows BYOL in Google Cloud. Key features / configurations: - Sole-tenant nodes: dedicated host hardware, node affinity, and placement control; aligns with compliance/isolation requirements and enables Windows BYOL. - Image import tooling: gcloud compute images import (built on VM import) performs format conversion and Windows-specific preparation/driver injection so the imported disk can boot reliably on Compute Engine. - Booting from the imported disk: preserves the OS state, installed agents, and local policies because you are not reinstalling from a public image. - Regional requirement: create the node and VM in europe-west4. Common misconceptions: Many assume that simply importing a disk (Option A) is enough; however, without Sole-tenant, Windows BYOL is not permitted and you would incur Google Windows licensing charges on standard instances. Options B and C look attractive because they use familiar public images, but they inherently use Google-provided Windows licensing and do not preserve the original OS disk as the boot disk. Exam tips: When you see “reuse existing Windows licenses” + “no Google Windows fees,” immediately think “Sole-tenant nodes” for Compute Engine. When you see “must boot from original OS disk,” prefer VM import/image import workflows and then create the VM using the imported disk as the boot disk (not as a data disk). Also verify region constraints and isolation language, which often signals dedicated hosts and compliance controls per the Google Cloud Architecture Framework (security/compliance pillar).
Your media-streaming company deploys a Node.js service to Google Kubernetes Engine (GKE) across dev, staging, and prod using Cloud Build and Artifact Registry. Compliance requires that every production deployment can be traced to the exact Git commit that produced the running container, and that this linkage is auditable via registry and CI/CD records for at least 180 days; what should you do?
Tagging commits with date/time is manual and not a strong, unique identifier for traceability. Multiple commits can occur in the same time window, tags can be moved or deleted, and it does not directly connect the running container image in Artifact Registry to the exact commit. It also doesn’t leverage CI/CD system records, making audits harder and less reliable.
Including a deployment ticket in commit messages can help with process tracking, but it is not a deterministic linkage between the production container and the exact source state. Commit messages are not enforced as immutable compliance evidence, and they don’t automatically connect to Artifact Registry image metadata or Cloud Build build provenance. This is supplementary metadata, not a primary trace mechanism.
Tagging container images with the exact Git commit SHA provides a direct, unique mapping from source to artifact. Cloud Build can automatically apply the commit SHA tag, Artifact Registry stores the tag-to-digest association, and GKE can deploy that specific tag (or digest) for immutability. Combined with log retention/export and artifact retention policies, this creates an auditable chain for 180+ days.
Using latest is a classic anti-pattern for production compliance because it is mutable: the same tag can point to different image digests over time. Even if developers tag commits as latest, the registry tag can be overwritten, breaking the audit trail and making it impossible to prove which commit produced the running container at a given time. This fails traceability and audit requirements.
Core Concept: This question tests software supply-chain traceability and auditability in a container-based CI/CD pipeline on Google Cloud. The key services are Cloud Build (build provenance and logs), Artifact Registry (immutable image references and metadata), and GKE (deploying a specific image digest/tag). This maps directly to security and compliance requirements: being able to prove exactly what code is running in production and retain evidence for a defined period. Why the Answer is Correct: Tagging each built image with the exact Git commit SHA creates a deterministic, auditable link between source and runtime artifact. Cloud Build can inject the commit SHA (e.g., $COMMIT_SHA) into the image tag at build time, and Artifact Registry will store that tag associated with the image digest. When production deploys that immutable tag (or, even stronger, the image digest), auditors can trace: (1) the Kubernetes Deployment manifest references the tag, (2) Artifact Registry shows which digest that tag points to and when it was pushed, and (3) Cloud Build history/logs show the build triggered from that commit and the push to the registry. Retaining these records for 180 days is then a matter of log retention and artifact retention policies. Key Features / Best Practices: Use Cloud Build substitutions ($COMMIT_SHA) to tag images (e.g., app:$COMMIT_SHA) and push to Artifact Registry. Prefer immutable references for production: commit-SHA tags are effectively immutable by convention; for maximum rigor, deploy by digest (image@sha256:...). Configure Cloud Logging retention (or export logs to BigQuery/Cloud Storage) to meet 180-day audit requirements. Configure Artifact Registry cleanup/retention policies to ensure images and metadata remain available for the required period. Common Misconceptions: Teams often rely on mutable tags like latest or human-entered metadata (tickets, timestamps). These do not guarantee a cryptographic or deterministic mapping from running container to source commit, and they are easy to overwrite or forge, weakening compliance evidence. Exam Tips: For compliance traceability questions, look for immutable identifiers (commit SHA, image digest) and systems of record (CI logs + registry metadata). Avoid answers involving latest or manual developer processes. Also consider retention: logs and artifacts must be kept long enough via retention settings or exports.
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?
Cloud NAT provides outbound (egress) NAT for instances without external IPs so they can reach the internet. It does not create an inbound endpoint you can SSH to, and you cannot “SSH to the Cloud NAT IP” to reach a VM. NAT is not a reverse proxy or port forwarder. This option confuses outbound connectivity with inbound administrative access.
An external TCP Proxy Load Balancer would expose a public IP and accept inbound connections on port 22, effectively creating new inbound internet access. It also adds unnecessary complexity and is not a recommended pattern for SSH. Additionally, it conflicts with the requirement to avoid opening new inbound access and undermines least-privilege security posture.
IAP TCP forwarding is designed for exactly this scenario: SSH/RDP to VMs that have no external IPs and no VPN connectivity. You authenticate with IAM, then tunnel through IAP using gcloud. The only network change is a targeted firewall rule allowing tcp:22 from 35.235.240.0/20 to the VM (via tag/service account). This preserves a private VM posture and provides auditability.
A bastion host with an external IP introduces a new public ingress path, which violates the requirement to avoid opening new inbound internet access. It may also be blocked by the organization policy prohibiting any VM from having an external IP. Even if allowed, bastions increase operational overhead (patching, hardening, key management) compared to IAP’s managed, identity-centric approach.
Core concept: This question tests secure administrative access to private Compute Engine VMs without external IPs or inbound internet exposure. The key service is Identity-Aware Proxy (IAP) TCP forwarding (IAP tunneling), which provides authenticated, authorized access to VM ports (like SSH/22) through Google’s edge, aligning with least privilege and zero-trust principles. Why the answer is correct: You cannot SSH directly because the org policy blocks external IPs and there is no VPN/Interconnect from the office network. You also must not open new inbound internet access. IAP TCP forwarding solves this by letting an admin initiate an SSH session using gcloud with --tunnel-through-iap. The VM remains without a public IP; the connection is established outbound from Google’s infrastructure to the VM over the VPC. The only firewall change required is to allow ingress to tcp:22 from the IAP TCP forwarding IP range (35.235.240.0/20) to the target VM (typically via network tag or service account targeting). Access is controlled by IAM (IAP-secured Tunnel User) and can be audited. Key features / configurations: - Enable IAP for the project (and ensure the VM has connectivity to required Google APIs, typically via Private Google Access on the subnet or appropriate egress). - Grant roles/iap.tunnelResourceAccessor (IAP-secured Tunnel User) to the operator. - Add a narrow firewall rule: allow tcp:22 from 35.235.240.0/20 to the VM (tagged) or its service account. - Use: gcloud compute ssh etl-node-03 --zone us-central1-a --tunnel-through-iap. This approach matches Google Cloud Architecture Framework security guidance: minimize exposure, use centralized identity, and maintain auditability. Common misconceptions: - Cloud NAT (option A) is for outbound internet egress only; it does not accept inbound SSH connections. - Load balancers (option B) and bastion hosts with external IPs (option D) introduce new public entry points, violating the requirement to avoid opening inbound internet access and conflicting with the org policy intent. Exam tips: When you see “no external IPs,” “no VPN,” and “need SSH,” the default best-practice answer is IAP TCP forwarding. Remember the required firewall source range (35.235.240.0/20) and the IAM role requirement. Also distinguish inbound access methods (IAP) from outbound egress tools (Cloud NAT).
Your online gaming operations team enabled a trace export from all match servers to push every gameplay event to Google Cloud Storage for later analysis; each event payload is between 50 KB and 15 MB, and traffic can spike to 3,000 events per second during peak tournaments. You need to minimize data loss while sustaining high write throughput; which process should you implement?
Creating a new bucket every hour is operationally heavy and doesn’t solve the main scaling issue. The naming pattern serverName-Timestamp can still create hot prefixes (many servers writing similarly structured names, often time-ordered), which can reduce write throughput. While embedding metadata and compressing per object are fine, bucket rotation is not a recommended performance strategy and can run into bucket management overhead and quota considerations.
Batching 10,000 events into an archive reduces request count, but it increases blast radius: if an upload fails, you lose a large batch, which conflicts with “minimize data loss.” It also delays availability for analysis and complicates partial retries. Daily bucket rotation is unnecessary and adds complexity. This approach can be useful for offline bulk transfer, but it’s not ideal for spiky, near-real-time ingest reliability.
serverName-EventSequence creates a sequential naming pattern that can hot-spot writes, especially per server, limiting throughput during spikes. The separate metadata update call doubles the number of API operations and introduces a two-phase behavior: the object may exist without metadata if the update fails, increasing inconsistency and operational burden. This option is the opposite of minimizing failure points under high QPS.
Randomized (or hashed) prefixes are a key Cloud Storage best practice to distribute load and sustain high write throughput under heavy concurrency. Keeping everything in a single bucket is typically sufficient because GCS scales, and it avoids bucket sprawl. Embedding metadata in the file body avoids extra update calls, reducing failure surface area and helping minimize data loss during spikes.
Core Concept: This question tests Google Cloud Storage (GCS) high-throughput ingest patterns and how object naming affects write scalability. It also touches on minimizing data loss by avoiding multi-step writes/updates and by using durable, atomic object uploads. Why the Answer is Correct: At peak, 3,000 events/sec with objects up to 15 MB is a very high request rate. In GCS, object creation is strongly consistent and durable, but you must avoid hot-spotting caused by sequential or time-based object name prefixes (for example, serverName-Timestamp or serverName-Sequence). Hot prefixes can concentrate traffic on a subset of internal partitions and reduce achievable throughput. Option D explicitly uses a randomized prefix pattern, which is a well-known best practice for distributing load across GCS’s internal indexing/partitioning and sustaining high write QPS. Key Features / Best Practices: 1) Randomized object name prefixes: Use a short random string (or hashed prefix) before the rest of the name to spread writes. 2) Single bucket is fine: You generally do not need bucket sharding for performance; GCS scales horizontally. Creating many buckets adds operational overhead and can hit project/bucket quotas. 3) Embed metadata in the object body: This avoids a second API call per object (which increases failure surface area and doubles request volume). If you need searchable metadata later, you can extract it during downstream processing. 4) Compression per object: Reasonable to reduce storage and network, but ensure it doesn’t add excessive CPU latency on match servers. Common Misconceptions: A and B try to “scale” by creating new buckets periodically. This is usually unnecessary and can create management complexity without addressing the core bottleneck (hot object name prefixes). C looks attractive because it uses EventSequence naming, but that is exactly the kind of sequential prefix pattern that can throttle throughput; it also adds a separate metadata update call, increasing the chance of partial failure. Exam Tips: When you see “high write throughput to Cloud Storage,” immediately evaluate object naming. Prefer randomized or hashed prefixes and avoid timestamp/sequence prefixes. Also prefer single-step uploads over multi-step workflows to minimize data loss and operational risk, aligning with Google Cloud Architecture Framework principles for reliability and operational excellence.
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.
A telehealth company runs a consultation-booking application on Google Kubernetes Engine (Autopilot) across two prod clusters in us-central1 and europe-west1, with managed Anthos Service Mesh and Config Sync enabled; over the last 15 minutes (10:00–10:15 UTC), the 95th percentile latency for the /book endpoint increased from 200 ms to 1.3 s while error rate stayed below 0.2% and pod CPU usage remained under 40%; you need to pinpoint which microservice-to-microservice call is introducing the delay without redeploying any workloads. What should you do?
Correct. Anthos Service Mesh provides L7 telemetry between services (P95 latency, request volume, error rates) and a service graph that highlights problematic edges. This directly answers “which microservice-to-microservice call is introducing the delay” and works immediately without redeploying workloads. It is the standard operational approach for isolating latency regressions in a service-mesh-enabled microservices environment.
Incorrect. Config Sync ClusterSelector and filtering workloads helps understand what is deployed where, but it does not provide runtime request-path latency attribution. Inspecting manifests may show resource requests/limits or config differences, yet it cannot identify which inter-service call became slow during a specific 15-minute window. This is configuration management, not performance observability.
Incorrect. A NamespaceSelector and reviewing workload configurations in the booking namespace is still a static configuration inspection. It won’t reveal which downstream service hop is causing the /book endpoint’s P95 latency increase. The problem statement asks for pinpointing the delaying microservice-to-microservice call, which requires runtime telemetry (service mesh metrics/traces), not GitOps configuration views.
Incorrect. Reinstalling Anthos Service Mesh is unnecessary because ASM is already enabled and managed, and the question explicitly requires no redeploying workloads. Reinstallation introduces risk, potential downtime, and configuration drift. Moreover, latency metrics are typically already available via ASM/Cloud Monitoring; the correct action is to use existing dashboards to identify the high-latency edge.
Core Concept: This question tests observability and troubleshooting in a microservices architecture on GKE using Anthos Service Mesh (managed Istio). Specifically, it focuses on using service-mesh telemetry (golden signals: latency, traffic, errors, saturation) to isolate which service-to-service hop is causing increased end-to-end latency, without redeploying workloads. Why the Answer is Correct: Because Anthos Service Mesh is already enabled and managed, each pod’s Envoy sidecar (or equivalent managed data plane) emits L7 metrics for requests between services. When /book P95 latency jumps from 200 ms to 1.3 s while error rate stays low and CPU is under 40%, the likely issue is not compute saturation but a downstream dependency slowdown (e.g., database call, external API, or a specific internal service). The fastest way to pinpoint the problematic hop is to use the Anthos Service Mesh service graph/traffic dashboards to drill into edge-level telemetry and identify which microservice-to-microservice call shows elevated P95 latency during 10:00–10:15 UTC. Key Features / Best Practices: Anthos Service Mesh provides service graph, request volume, error rate, and latency metrics per service and per edge, enabling “blame assignment” across microservices. This aligns with Google Cloud Architecture Framework “Operational Excellence” principles: instrument, observe, and troubleshoot using centralized telemetry rather than redeploying or changing workloads. It also avoids risky changes in production and leverages existing managed control plane capabilities. Common Misconceptions: Config Sync/Anthos Config Management is for desired-state configuration (GitOps) and policy enforcement, not for runtime performance diagnosis. Reviewing manifests won’t reveal which call path is slow in the last 15 minutes. Reinstalling Anthos Service Mesh is unnecessary and violates the constraint (no redeployments) while introducing operational risk. Exam Tips: When asked to identify a slow microservice-to-microservice call, think “service mesh telemetry/service graph” (or distributed tracing if mentioned). When constraints include “no redeploy,” prefer existing observability tools (ASM dashboards, Cloud Monitoring) over configuration changes. Also note the signal pattern: high latency with low errors and low CPU often indicates downstream dependency latency, network issues, or contention outside the app’s CPU-bound work.
Your company runs a city-event ticketing API on Compute Engine behind a global HTTP(S) Load Balancer, with containerized NGINX (web) and Node.js (app) tiers each deployed as autoscaled managed instance groups across two zones (europe-west3-a and europe-west3-b), while the database runs on Cloud SQL for MySQL with HA but a fixed machine type (no autoscaling); under a limited beta of 500 authenticated testers the system meets a 99.99% availability SLA at a peak of 120 requests/second, but next month the API will be opened to the public (including unauthenticated requests) with an expected 10x increase to 1,200 requests/second and existing autoscaling policies target 60% CPU on the MIGs; you must design a resiliency testing strategy to validate that the system will maintain the SLA under the additional load without harming real users; what should you do?
Correct. Replaying recorded beta traffic preserves realistic endpoint mix, authentication patterns, and payload sizes, making capacity results meaningful. Scaling to 1,200 RPS validates autoscaling behavior at the configured 60% CPU target. Simulating a full zonal outage (drain LB + terminate instances) tests the primary failure domain for a two-zone MIG design and confirms the remaining zone plus Cloud SQL HA can sustain the SLA without impacting real users when run in a test environment.
Not best. Synthetic random requests often fail to reflect real production behavior (hot endpoints, cache hit ratios, DB query patterns), so it can under- or over-estimate capacity. Randomly terminating instances is useful chaos engineering, but it does not explicitly validate the most important scenario here: complete loss of one zone and the resulting capacity/latency impact. It also may not stress Cloud SQL in the same way real traffic does.
Incorrect because it risks harming real users, directly violating the requirement. Canary releases are a deployment-risk mitigation technique, not a primary resiliency testing strategy for a known 10x traffic increase. Adding concurrent chaos (terminating resources) during a real-user canary further increases blast radius and makes it difficult to attribute issues to load vs. injected failures, which is poor operational practice for an SLA-critical public launch.
Incorrect. This is capacity planning by overprovisioning, not resiliency testing. Driving CPU to 80% and then pre-provisioning 200% of estimated load does not validate behavior under failure (zonal outage) or confirm that Cloud SQL (fixed size, no autoscaling) can handle 10x traffic. It also ignores other saturation points (connections, IOPS, memory, LB/backend limits) and can be unnecessarily expensive without proving the SLA.
Core concept: This question tests resiliency and load testing for a multi-tier, zonally distributed Compute Engine architecture behind a global HTTP(S) Load Balancer, with autoscaled managed instance groups (MIGs) and a stateful backend (Cloud SQL for MySQL HA) that does not autoscale. It aligns to Google Cloud Architecture Framework “Reliability” and “Operational Excellence” pillars: validate behavior under expected load and under failure, without impacting real users. Why the answer is correct: Option A is the best strategy because it uses representative traffic (recorded beta traffic) scaled to the expected 10x RPS, and it combines this with a controlled, realistic failure mode: loss of an entire zone. This directly validates that (1) autoscaling policies at 60% CPU can react quickly enough at 1,200 RPS, (2) the global load balancer and MIGs can sustain service when one zone is unavailable, and (3) the system’s true bottleneck (often Cloud SQL) remains within capacity during both scale-out and zonal failover. Importantly, this can be executed in a dedicated test environment (or via shadow testing) so real users are not harmed. Key features / best practices: - Use traffic replay based on real request mix (endpoints, auth patterns, cacheability, payload sizes) rather than random synthetic traffic. - Validate zonal resilience: drain/disable backends in one zone and terminate instances to simulate a real outage; confirm health checks, connection draining, and capacity in the remaining zone. - Observe end-to-end SLOs: latency, error rate, saturation (CPU, memory, connection pools), and Cloud SQL metrics (CPU, IOPS, connections, replication/failover behavior). Cloud SQL HA provides failover, but not horizontal scaling; ensure it can handle 10x load. - Run tests safely: isolate via separate project/VPC or use a mirrored environment and ensure quotas (MIG size, load balancer limits, Cloud SQL connections) are sufficient. Common misconceptions: Chaos testing at the instance level (B) can be useful, but it may not validate the most important failure domain (zone loss) and random traffic may miss critical hot paths. Canarying real users (C) violates the requirement to avoid harming real users. Overprovisioning (D) is not a resiliency test and ignores failover behavior and database constraints. Exam tips: Prefer strategies that (1) use production-like traffic, (2) test realistic failure domains (zone/region), (3) validate autoscaling and stateful dependencies, and (4) protect users by running in isolated environments or controlled shadow tests. For 99.99% targets, explicitly test zonal failure and capacity headroom, not just average CPU.
A genomics research institute needs to import 82 TB of raw sequencing data from its on-premises NAS into Google Cloud within 30 days. Their internet link averages 500 Mbps during off-peak hours and must remain available for other workloads. They will store the data in Cloud Storage and want to follow Google-recommended, secure, and predictable migration practices. What should they do?
Correct. Transfer Appliance is Google’s recommended solution for large, time-bound transfers when WAN bandwidth is constrained. You copy data locally, ship the appliance, and then use the supported Transfer Appliance rehydration process to decrypt and write into the destination Cloud Storage bucket. This provides predictable completion, preserves the on-prem internet link for other workloads, and follows secure handling and encryption best practices.
Incorrect. Cloud Dataprep is a data preparation/ETL tool (wrangling, profiling, transformations) and is not the supported mechanism to decrypt or ingest Transfer Appliance payloads into Cloud Storage. Transfer Appliance has a specific rehydration workflow/tooling for secure decryption and upload. Using Dataprep here is a category error and would not align with Google-recommended migration practices.
Incorrect. gsutil with resumable and parallel uploads is appropriate for WAN-based transfers, but the constraints make it unpredictable: the link averages 500 Mbps only off-peak and must remain available for other workloads. Real throughput will likely be much lower than theoretical, and contention/retries can jeopardize the 30-day deadline. This approach also increases operational complexity and risk compared to an offline appliance.
Incorrect. Streaming uploads are generally less resilient than resumable uploads for large transfers because interruptions can force restarts and increase failure risk. With constrained, shared bandwidth and a large dataset, streaming is the least predictable option. Even if it worked, it would still consume WAN capacity and could impact other workloads, conflicting with the requirement for secure, predictable migration practices.
Core Concept: This question tests choosing the right data migration approach into Cloud Storage when bandwidth is constrained and timelines are fixed. The key services are Transfer Appliance (offline bulk transfer) and Cloud Storage ingestion best practices. Why the Answer is Correct: 82 TB over a 500 Mbps link is risky within 30 days, especially because the link must remain available for other workloads. Even if 500 Mbps were fully dedicated 24/7, theoretical transfer is ~162 TB in 30 days (500/8=62.5 MB/s; ~5.4 TB/day). In reality, protocol overhead, contention, retries, and limited off-peak windows reduce throughput significantly, making the schedule unpredictable. Google-recommended practice for large, time-bound migrations with limited WAN capacity is Transfer Appliance: copy data locally to the appliance, ship it to Google, and have Google upload it into the target Cloud Storage bucket. The Transfer Appliance Rehydrator is the supported mechanism to decrypt/rehydrate the data in Google Cloud and write it to Cloud Storage, providing a secure chain of custody and predictable completion. Key Features / Best Practices: - Predictability: shipping avoids WAN variability and protects business-critical bandwidth. - Security: Transfer Appliance uses encryption; keys are managed by the customer, and rehydration occurs in Google-controlled facilities/workflows. - Operational fit: designed for NAS/file-based sources and bulk object ingestion to Cloud Storage. - Architecture Framework alignment: reliability (meeting the 30-day objective), security (encrypted transport and controlled handling), and cost optimization (avoids prolonged WAN saturation and operational firefighting). Common Misconceptions: - “gsutil parallel uploads will be enough”: parallelism helps but cannot overcome limited available bandwidth and off-peak-only constraints; it also increases operational risk (throttling, retries, noisy-neighbor effects on the shared link). - “Any tool can decrypt”: decryption/rehydration is not a Dataprep use case; Dataprep is for data wrangling/ETL, not Transfer Appliance ingestion. Exam Tips: When you see multi-tens-of-terabytes, a hard deadline, and constrained/shared internet, default to offline transfer (Transfer Appliance). Choose options that mention the official rehydration workflow into Cloud Storage. Use WAN tools (Storage Transfer Service, gsutil) when bandwidth is sufficient and predictable or when incremental/ongoing sync is needed.
All Compute Engine instances in your project must be able to connect only to an internal code repository at 10.30.40.50 over TCP ports 22 and 443; any other outbound traffic from these instances must be blocked. You will enforce this using VPC firewall rules. How should you configure the firewall rules?
Correct. The allow rule has priority 100 (evaluated first) permitting TCP 22/443 to 10.30.40.50. The deny-all rule has priority 1000 (evaluated after) blocking any other destinations (0.0.0.0/0). This matches VPC firewall processing: first match wins, and lower numeric priority takes precedence. This enforces least-privilege outbound access.
Incorrect. The deny-all rule at priority 100 is evaluated before the allow rule at priority 1000. Because the deny rule matches all destinations (0.0.0.0/0), it will deny the traffic to 10.30.40.50 as well, and evaluation stops. The later allow rule never takes effect, resulting in no outbound access at all.
Incorrect. It assumes an implied deny egress rule exists. In Google Cloud VPC, the implied egress rule is allow to 0.0.0.0/0, not deny. If you only add an allow rule to 10.30.40.50, all other egress traffic would still be allowed by the implied egress allow rule, violating the requirement to block all other outbound traffic.
Incorrect for the same reason as C: it relies on an implied deny egress rule, but implied egress is allow-all. Even though the allow rule priority is 100, without an explicit deny-all egress rule, instances can still send traffic to any other destination due to the default implied egress allow. Priority numbers here don’t fix the missing explicit deny.
Core Concept: This question tests VPC firewall egress controls in Google Cloud: rule evaluation order (priority), allow vs deny behavior, and the existence of implied rules. It also touches the security principle of least privilege from the Google Cloud Architecture Framework (Design for Security). Why the Answer is Correct: To ensure instances can only reach 10.30.40.50 on TCP 22 and 443 and nothing else, you must (1) explicitly allow the required destination/ports and (2) explicitly deny all other egress. In VPC firewall rules, lower numeric priority is evaluated first. If a packet matches a rule, that action (allow/deny) is applied and evaluation stops. Therefore, you create a higher-precedence allow rule (priority 100) for destination 10.30.40.50 with TCP:22,443, and then a lower-precedence deny-all rule (priority 1000) for destination 0.0.0.0/0. This guarantees the exception is permitted while everything else is blocked. Key Features / Configurations: - Use EGRESS direction rules. - Apply to “all instances” via broad target (no target tags) or, best practice, a dedicated service account or network tag to avoid impacting unintended workloads. - Allow rule: destination 10.30.40.50/32, protocol tcp, ports 22 and 443. - Deny rule: destination 0.0.0.0/0, all protocols (or at least tcp/udp/icmp as required), action deny. - Remember that implied rules exist, but relying on them is risky if they don’t match your intent (notably, implied egress is allow). Common Misconceptions: Many assume there is an implied “deny egress” rule. In Google Cloud VPC, the implied egress rule is allow (to 0.0.0.0/0). So options that “rely on implied deny egress” are incorrect. Another common mistake is reversing priorities: placing deny at a higher precedence than allow will block even the intended traffic. Exam Tips: - Memorize: lower number = higher priority. - Implied rules: ingress deny-all; egress allow-all. - For “only allow X and block everything else,” you almost always need two explicit egress rules: an allow exception with higher precedence and a deny-all with lower precedence. - Consider operational safety: scope rules with service accounts/tags and document priorities to prevent future rule conflicts.
You are leading the migration of a digital media platform to Google Cloud, and a major pain point is the on-premises scale-out NAS that requires frequent and costly upgrades to handle diverse workloads identified as follows: 18 TB of audit video fragments that must be retained for 7 years for compliance; 600 GB of VM images and golden templates used for occasional rebuilds; 700 GB of photo preview thumbnails served to end users; and 250 GB of user playlist/cart session state that must persist so users can resume activity even after being offline for up to 5 days. Which of the following best reflects your recommendations for a cost-effective storage allocation?
Local SSD is ephemeral and data is lost on VM stop/terminate events, host maintenance, or instance recreation. That directly violates the requirement that user session state persist for up to 5 days. The Cloud Storage recommendation for audit archives, thumbnails, and VM images/templates is directionally correct (object storage + lifecycle), but the session-state choice makes this option incorrect for reliability and durability.
This matches a common scalable pattern: Memorystore for Memcached provides low-latency access for active sessions, while Firestore (Datastore mode) provides durable persistence so users can resume after being offline for days. Firestore scales horizontally and supports TTL policies to expire session entities after ~5 days. Cloud Storage with lifecycle/retention policies is cost-effective for 7-year audit archives and occasional VM templates, and works well for thumbnails (often paired with Cloud CDN).
Cloud SQL can persist session state, but it is typically less elastic and can become a bottleneck for high-throughput session workloads due to connection limits and vertical scaling characteristics (unless carefully engineered with pooling/sharding). Using assorted local SSD–backed instances for VM boot/data volumes is also not cost-effective or operationally sound for golden images/templates; those should be stored as images/snapshots or in Cloud Storage rather than tied to specific instances.
Persistent Disk SSD is durable, but using it as the backing store for session state is an anti-pattern: it couples state to VM instances, complicates scaling, and lacks native TTL/expiration semantics for 5-day offline windows. It also increases operational overhead compared to a managed database. Like option C, using local SSD–backed instances for VM boot/data volumes is not the right approach for golden templates; use images/snapshots or Cloud Storage instead.
Core concept: This question tests storage tiering and state management on Google Cloud: using Cloud Storage lifecycle policies for large, durable objects (archives, images, thumbnails) and using a database-backed pattern for session/state that must survive cache loss and user offline periods. Why the answer is correct: Audit video fragments (18 TB, 7-year retention) are classic object storage + lifecycle/retention use cases. Cloud Storage supports retention policies (WORM-style governance) and lifecycle rules to transition to colder classes (Nearline/Coldline/Archive) for lowest cost over long retention. VM images/templates (600 GB) are also well suited to Cloud Storage (or Compute Engine Images stored in Google-managed storage), accessed occasionally, so colder classes reduce cost. Photo thumbnails (700 GB) are frequently served to end users and fit Cloud Storage Standard with Cloud CDN in front for performance and cost efficiency. User playlist/cart session state (250 GB) must persist for up to 5 days even if users are offline; that is not a “cache-only” requirement. A common pattern is Memorystore (Memcached) for low-latency reads/writes plus a durable backing store. Firestore (Datastore mode) provides managed, highly available, horizontally scalable persistence with TTL policies (to expire session entities after ~5 days), avoiding operational overhead and scaling limits. Key features / best practices: - Cloud Storage: lifecycle rules + storage classes; retention policies for compliance; optional Object Versioning; Cloud Audit Logs for access. - Thumbnails: Cloud Storage + Cloud CDN; consider signed URLs if needed. - Session state: Memorystore for Memcached for speed; Firestore (Datastore mode) for durability, automatic scaling, and TTL-based cleanup. - Architecture Framework alignment: cost optimization (tiering), reliability (durable backing store), operational excellence (managed services). Common misconceptions: Local SSD is fast but ephemeral; it does not meet “persist up to 5 days” if an instance restarts/terminates. Persistent Disk SSD is durable but tying session state to VM disks is an anti-pattern for scalable web state; it adds management complexity and doesn’t provide a natural TTL/expiration model. Cloud SQL can store sessions, but it introduces relational scaling/connection management constraints and can be costlier/less elastic for high-throughput key-value access. Exam tips: Map each dataset to access pattern + durability + retention. For long-term compliance archives, think Cloud Storage + retention/lifecycle. For frequently served static content, think Cloud Storage Standard + CDN. For session/state that must survive cache loss, always choose a durable managed database (Firestore/Spanner/Cloud SQL) behind a cache; avoid local SSD for persistence requirements.
Période de préparation: 1 month
Many of the scenario patterns I saw on Cloud Pass showed up in the actual PCA exam. The explanations were detailed, which helped strengthen my weak areas. I’ll definitely use this app again for other GCP exams.
Période de préparation: 1 month
실제 시험 문제하고 유사했던게 15개 이상 나온거 같아요! 굿굿
Période de préparation: 1 month
앱 너무 좋네요
Période de préparation: 2 weeks
These questions forced me to deeply understand GCP networking, IAM, storage trade-offs, and high-availability design. After a month of consistent practice, I finally passed my PCA exam. Amazing app!
Période de préparation: 1 month
I passed on the first try. The practice questions were tough but very close to the real exam. The explanations helped me understand why each answer was correct. Highly recommended.
Professional
Associate
Professional
Associate
Foundational
Professional
Professional
Professional
Professional
Professional
Téléchargez Cloud Pass et accédez gratuitement à toutes les questions d'entraînement Google Professional Cloud Architect.
Envie de vous entraîner partout ?
Obtenir l'application gratuite
Téléchargez Cloud Pass gratuitement — inclut des tests d'entraînement, le suivi de progression et plus encore.