All practice questions

1598 questions

All types1,598 Multiple choice815 Multiple select537 Numeric8 Matching64 Ordering174

A healthcare technology company is architecting a medical diagnostics platform on Google Cloud. The system consists of two distinct components: 1) A stateless REST API backend that receives patient request payloads and returns quick diagnostic summaries with highly variable, bursty web traffic, requiring minimal operational management; 2) A batch processing pipeline that runs legacy, uncontainerized diagnostic algorithms relying on custom Linux kernel modules for 3 hours every night. Which TWO compute solutions should you recommend to fulfill these requirements with the lowest operational overhead and optimal cost efficiency? (Select TWO)

Select all that apply

Deploy the stateless REST API backend onto Cloud Run.

Deploy the batch processing pipeline onto Compute Engine Managed Instance Groups using Spot VMs.

Deploy the stateless REST API backend onto a dedicated Google Kubernetes Engine (GKE) Standard cluster with fixed node pools.

Deploy the legacy batch processing pipeline onto Cloud Functions.

Purchase 3-year Committed Use Discounts (CUDs) for On-Demand Compute Engine instances to run the 3-hour nightly batch workload.

Show answer & explanation

Answer: Deploy the stateless REST API backend onto Cloud Run.; Deploy the batch processing pipeline onto Compute Engine Managed Instance Groups using Spot VMs.

Answer

Select Cloud Run for the stateless REST API backend and Compute Engine Managed Instance Groups using Spot VMs for the legacy batch processing pipeline.

Cloud Run is ideal for stateless REST APIs with bursty traffic because it automatically scales containers and requires zero cluster maintenance. For legacy workloads requiring custom kernel modules and running for short nightly windows, Compute Engine VMs provide the required OS-level access, while Spot VMs and Managed Instance Groups ensure maximum cost efficiency.

Step-by-Step Solution

Analyze the stateless REST API requirements

Identified bursty HTTP traffic, stateless architecture, and minimal operational overhead preference.

Cloud Run is the optimal Google Cloud serverless compute platform for stateless containerized web services, scaling to zero when idle.

Analyze the legacy batch processing pipeline requirements

Identified dependency on custom Linux kernel modules and a 3-hour nightly execution window.

Serverless container environments (Cloud Run, Cloud Functions) do not permit custom host kernel modules. Compute Engine VMs permit full OS/kernel customization, and using Spot VMs within a Managed Instance Group optimizes costs for scheduled batch runs.

Key Concept

Selecting appropriate compute platforms based on containerization status, kernel/OS customization needs, scaling patterns, and management overhead constraints.

Question 22Question →

An enterprise architecture team is configuring network connectivity between two VPC networks, vpc-analytics and vpc-core, in Google Cloud. They decide to establish VPC Network Peering to allow internal IP address communication across the two networks. Which TWO statements accurately describe the requirements and behavior of VPC Network Peering in this scenario? (Select TWO.)

Select all that apply

Peering configuration must be created symmetrically in both directions—from vpc-analytics to vpc-core and from vpc-core to vpc-analytics—before communication is fully established.

Exporting and importing custom routes must be explicitly enabled on the peering configurations if custom static or dynamic routes need to be shared across the peered networks.

Traffic from vpc-analytics can transitively reach a third network, vpc-management, by routing through vpc-core if vpc-core is peered to vpc-management.

HA VPN should be used instead of VPC Network Peering whenever inter-VPC traffic requirements exceed 100 Gbps within the same Google Cloud region.

Standard IAM permissions applied to instances in vpc-analytics automatically prevent unauthorized data copy operations to Cloud Storage buckets in vpc-core without needing security perimeter controls.

Show answer & explanation

Answer: Peering configuration must be created symmetrically in both directions—from vpc-analytics to vpc-core and from vpc-core to vpc-analytics—before communication is fully established.; Exporting and importing custom routes must be explicitly enabled on the peering configurations if custom static or dynamic routes need to be shared across the peered networks.

Answer

VPC Network Peering requires symmetrical peering setup in both directions and explicit configuration of custom route import/export settings to share non-subnet routes.

VPC Network Peering is established only when both VPC networks create a peering request to each other (symmetrical configuration). Additionally, while subnet routes are exchanged automatically upon peering, sharing custom dynamic or static routes across peered VPCs requires explicitly configuring the import and export custom routes flags on both ends.

Step-by-Step Solution

Analyze VPC Network Peering setup requirements.

VPC Peering requires both network administrators to establish a peering configuration pairing both VPCs (bidirectional setup).

Peering stays in an inactive state until both VPCs explicitly approve the peering request.

Evaluate route propagation rules across peered VPC networks.

Subnet routes are exchanged by default, but custom dynamic and static routes require setting import and export custom route flags.

Cloud Router dynamic routes and static routes are not automatically shared without explicitly enabling custom route exchange.

Identify invalid VPC networking assumptions.

Reject transitive routing, lower-bandwidth HA VPN alternatives for intra-cloud high throughput, and relying solely on IAM for perimeter security.

VPC Network Peering is non-transitive, HA VPN has throughput caps per tunnel (3 Gbps), and VPC Service Controls are necessary to prevent data exfiltration.

Key Concept

VPC Network Peering establishing bilateral setup, non-transitivity, and custom route exchange mechanisms.

Question 23Question →

A geospatial mapping firm needs to migrate its legacy processing infrastructure to Google Cloud within a strict 30-day window. The workload consists of $1.2\text{ PB}$ of static, high-resolution satellite raster imagery stored on local network-attached storage (NAS) and an active $2\text{ TB}$ transactional MySQL database supporting customer mapping requests. The firm has a dedicated $200\text{ Mbps}$ network connection allocated for cloud transfer tasks. The cutover plan requires minimal database downtime of less than 15 minutes while ensuring all static and transactional data is fully migrated to Google Cloud before the 30-day deadline. Which data transfer and migration strategy should the Cloud Architect recommend?

Request Transfer Appliance to import the

1.2\text{ PB}

static raster dataset, and deploy Database Migration Service (DMS) with continuous replication (CDC) over a Cloud VPN connection for the

2\text{ TB}

MySQL database.

Configure Storage Transfer Service to upload the

1.2\text{ PB}

static raster dataset over the

200\text{ Mbps}

connection, while performing daily database dump exports to Cloud Storage.

Migrate the

2\text{ TB}

MySQL database to Cloud Spanner using continuous SQL dumps, while transferring the

1.2\text{ PB}

raster imagery over a high-availability Cloud VPN connection.

Provision a 1 Gbps HA VPN tunnel to stream both the

1.2\text{ PB}

raster imagery and database transactions directly into Cloud Storage within the 30-day migration window.

Show answer & explanation

Answer: Request Transfer Appliance to import the $1.2\text{ PB}$ static raster dataset, and deploy Database Migration Service (DMS) with continuous replication (CDC) over a Cloud VPN connection for the $2\text{ TB}$ MySQL database.

Answer

Request Transfer Appliance to import the static raster dataset physically, and use Database Migration Service (DMS) with continuous CDC over Cloud VPN for the MySQL database.

The correct strategy combines offline physical migration via Transfer Appliance for large petabyte-scale static data with Database Migration Service (DMS) continuous CDC replication for active transactional databases. Transfer Appliance circumvents network bottlenecks for

1.2\text{ PB}

of data, while DMS ensures live database sync and minimal cutover downtime.

Step-by-Step Solution

Calculate network throughput limitations for the

1.2\text{ PB}

static dataset.

200\text{ Mbps}

, transferring

1.2\text{ PB}

(

9.6 \times 10^{15}\text{ bits}

) takes

\approx 555\text{ days}

, exceeding the 30-day constraint.

Determines that offline physical migration via Transfer Appliance is required for petabyte-scale data.

Evaluate database migration requirements for

2\text{ TB}

transactional database.

Initial sync of

2\text{ TB}

over

200\text{ Mbps}

takes

\approx 22\text{ hours}

, followed by continuous CDC replication over Cloud VPN.

Allows ongoing data sync while the main application remains online.

Establish cutover procedure.

Stop application writes, allow final CDC lag to drain, promote Cloud SQL instance, and update connection endpoints within 15 minutes.

Meets the requirement of under 15 minutes cutover downtime.

Key Concept

Selecting offline vs. online data transfer mechanisms based on dataset size and network bandwidth, combined with continuous database CDC for minimal downtime.

Question 24Question →

A global media enterprise is designing the cloud storage and database architecture on Google Cloud for a mission-critical application platform. The architecture must address two key technical requirements:

1. An operational relational database that requires strong consistency (ACID compliance) across multiple geographic regions, along with horizontal scaling for write operations.
2. A one-time bulk migration of a $3\text{ PB}$ historical analytics dataset stored on local network-attached storage (NAS) devices, where the available dedicated internet bandwidth is capped at $100\text{ Mbps}$ .

Which TWO design decisions should the architect select to fulfill these requirements?

Select all that apply

Deploy Cloud Spanner as the operational database solution to support multi-region horizontal write scaling while maintaining strong ACID consistency.

Deploy Cloud SQL for PostgreSQL with cross-region read replicas to achieve multi-region write scaling and relational transactional consistency.

Order Google Cloud Transfer Appliance devices to physically capture and ingest the 3 PB dataset into Cloud Storage.

Utilize Storage Transfer Service to stream the 3 PB dataset online over the 100 Mbps connection directly into a Cloud Storage bucket.

Show answer & explanation

Answer: Deploy Cloud Spanner as the operational database solution to support multi-region horizontal write scaling while maintaining strong ACID consistency.; Order Google Cloud Transfer Appliance devices to physically capture and ingest the 3 PB dataset into Cloud Storage.

Answer

The optimal solution requires selecting Cloud Spanner for the globally scalable relational database and using GCP Transfer Appliance for the 3 PB offline bulk data migration.

Cloud Spanner is designed specifically for enterprise relational database workloads that require multi-region horizontal scaling for both reads and writes while preserving strict ACID transactional consistency. For the data migration requirement, transferring

3\text{ PB}

over a

100\text{ Mbps}

network link is mathematically unviable, taking over seven years. Google Cloud Transfer Appliance provides dedicated hardware for offline data ingestion, allowing petabyte-scale data to be physically transported to GCP securely and efficiently.

Step-by-Step Solution

Evaluate operational relational database requirements against GCP database products.

Cloud Spanner satisfies global multi-region horizontal write scaling and strong ACID consistency, whereas Cloud SQL is limited to vertical scaling for writes and a single primary region.

Cloud Spanner uses TrueTime and distributed transactions to allow multi-region relational write scale.

Calculate data transfer time for 3 PB over a 100 Mbps network connection.

Transfer time exceeds 7.5 years (

t = \frac{3 \times 10^{15} \text{ bytes} \times 8 \text{ bits/byte}}{100 \times 10^6 \text{ bits/sec}} \approx 2.4 \times 10^8 \text{ seconds}

Online migration via Storage Transfer Service is unfeasible within reasonable operational timelines.

Select the appropriate offline data transfer mechanism.

GCP Transfer Appliance allows shipping physical storage hardware to securely ingest petabyte-scale data into Cloud Storage.

Offline appliances bypass low-bandwidth WAN connections for massive datasets.

Key Concept

Selecting GCP Database and Storage Migration Services Based on Scale, Latency, and Network Throughput Constraints

Question 25Question →

A regional healthcare provider needs to migrate its core application workload to Google Cloud within a strict 3-week cutover window. The existing environment consists of a 650 TB static medical imaging archive and an active 400 GB MySQL operational database. The facility has a dedicated network connection with 100 Mbps of available uplink bandwidth, and the database requires minimal downtime during final cutover. Which migration strategy should a Cloud Architect recommend?

Order a Google Cloud Transfer Appliance to transfer the 650 TB medical imaging archive offline, and use Database Migration Service (DMS) with continuous replication for the 400 GB MySQL database cutover.

Use Storage Transfer Service to stream both the 650 TB medical imaging archive and the operational database snapshot concurrently over the 100 Mbps network connection.

Migrate the 400 GB operational database into Cloud Spanner, and stream the 650 TB imaging archive directly into Cloud Spanner tables using batch upload scripts.

Configure an HA VPN connection to a transit VPC, and rely on transitive routing over VPC Network Peering to stream all imaging files and database data to destination buckets in a peered workload VPC.

Show answer & explanation

Answer: Order a Google Cloud Transfer Appliance to transfer the 650 TB medical imaging archive offline, and use Database Migration Service (DMS) with continuous replication for the 400 GB MySQL database cutover.

Answer

The solution correctly identifies that moving 650 TB over a 100 Mbps internet connection takes over 600 days, making online transfer impossible within a 3-week timeframe. Transfer Appliance provides an offline physical shipping device capable of ingesting petabyte-scale data into Cloud Storage. Meanwhile, the 400 GB operational MySQL database can easily be seeded online and kept in continuous synchronization using Database Migration Service (DMS) with Change Data Capture (CDC) until final cutover.

Step-by-Step Solution

Calculate network throughput for the static data payload

Moving

650\text{ TB}

(

5.2\times 10^6\text{ Gb}

) over a

100\text{ Mbps}

(

0.1\text{ Gbps}

) link requires approximately

5.2\times 10^7\text{ seconds} \approx 601\text{ days}

, exceeding the 3-week window.

Large multi-hundred terabyte datasets cannot be moved online over narrow bandwidth pipes within short project timelines.

Select the appropriate data transfer mechanism for large static payloads

Select Google Cloud Transfer Appliance for offline physical data transport.

Transfer Appliance allows copying data locally at high speed and shipping hardware securely to a Google data center for ingestion into Cloud Storage.

Select database migration strategy for low downtime

Use Database Migration Service (DMS) with initial snapshot and Change Data Capture (CDC) continuous replication over the

100\text{ Mbps}

connection.

400\text{ GB}

database transfer easily fits within the

100\text{ Mbps}

bandwidth capacity (taking roughly

9\text{ hours}

for initial load), and CDC enables near-zero downtime cutover.

Key Concept

Selecting data transfer mechanisms based on data volume, bandwidth constraints, and downtime requirements

Question 26Question →

An enterprise media streaming company is designing an automated continuous delivery pipeline for microservices deployed on Cloud Run using Cloud Build and Google Cloud Deploy. The architecture team requires progressive traffic shifting with automated rollback whenever latency or error rate metrics exceed defined thresholds during a release. Additionally, all container images deployed to production must be verifiably built by the authorized continuous integration pipeline, and individual developers must be prevented from executing direct manual deployments to production environments. Which TWO architectural configurations should the team implement to satisfy these requirements? (Select TWO)

Select all that apply

Define Google Cloud Deploy targets and release pipelines configured with automated canary deployment strategies, integrating verification routines and automated rollbacks driven by Cloud Monitoring metric checks.

Configure Binary Authorization on the target Cloud Run services requiring attestations generated by Cloud Build, and restrict production deployment permissions strictly to the Cloud Deploy service account using IAM service account impersonation.

Grant the Cloud Build service account the primitive Owner role (`roles/owner`) on the target Google Cloud project to allow full administrative override capability across Cloud Run and Cloud Monitoring resources.

Configure local developer workstations with direct gcloud CLI deployment access to production Cloud Run instances to enable emergency manual overrides bypassing IaC and continuous deployment pipelines.

Grant developers the Service Account Admin role (`roles/iam.serviceAccountAdmin`) on the Cloud Deploy execution service account so they can update service account credentials directly during build runs.

Show answer & explanation

Answer: Define Google Cloud Deploy targets and release pipelines configured with automated canary deployment strategies, integrating verification routines and automated rollbacks driven by Cloud Monitoring metric checks.; Configure Binary Authorization on the target Cloud Run services requiring attestations generated by Cloud Build, and restrict production deployment permissions strictly to the Cloud Deploy service account using IAM service account impersonation.

Answer

The team should configure Google Cloud Deploy progressive canary release strategies with automated rollback capabilities based on metric checks, and enforce Binary Authorization attestations signed by Cloud Build while restricting deployment IAM permissions to the Cloud Deploy execution service account.

To achieve secure, automated release management on GCP, Google Cloud Deploy provides built-in progressive delivery features like canary deployments with automated rollback options upon metric or phase check failures. Pairing this with Binary Authorization ensures container images deployed to Cloud Run originate strictly from the verified Cloud Build pipeline. Restricting IAM rights to the deployment pipeline service account ensures compliance and prevents direct developer modifications.

Step-by-Step Solution

Configure progressive release automation

Google Cloud Deploy delivery pipelines execute automated canary releases that evaluate metrics via Cloud Monitoring and trigger rollbacks if thresholds are breached.

Meets the requirement for progressive traffic shifting and automated failure mitigation.

Enforce artifact governance and minimal IAM access

Binary Authorization ensures only authorized container builds are deployed to Cloud Run, and IAM restrictions prevent developers from deploying directly.

Satisfies supply chain security requirements and enforces centralized CI/CD deployment execution.

Key Concept

Automating Continuous Deployment Pipelines and Release Strategies

Question 27Question →

A global healthcare organization is designing a centralized operational logging architecture across hundreds of Google Cloud projects managed under an organizational hierarchy. The observability team needs to collect all high-severity application error logs from every project and stream them to a central Cloud Pub/Sub topic located in a dedicated operational security project for automated incident triage and event processing. The architecture must strictly adhere to Google Cloud security best practices, minimize administrative overhead, and enforce the principle of least privilege. Which configuration strategy should the platform engineering team implement?

Create an aggregated log sink at the organization root with children inclusion enabled, specifying a log filter for error-severity logs and the central Pub/Sub topic as the destination. Grant the log sink's automatically generated writer identity service account the Pub/Sub Publisher role on the central Pub/Sub topic.

Create an aggregated log sink at the organization root, and grant the sink's unique writer identity service account the primitive Editor role on the security operations project to ensure reliable log delivery across all present and future Pub/Sub topics.

Create individual log sinks in each project, construct a custom service account per project, and grant each service account the Service Account Admin role so the log sinks can impersonate the central logging identity.

Configure log exclusion filters across all individual workload projects to drop non-error logs prior to ingestion, and grant the Compute Engine default service account the Pub/Sub Admin role on the destination topic.

Show answer & explanation

Answer: Create an aggregated log sink at the organization root with children inclusion enabled, specifying a log filter for error-severity logs and the central Pub/Sub topic as the destination. Grant the log sink's automatically generated writer identity service account the Pub/Sub Publisher role on the central Pub/Sub topic.

Answer

The correct strategy configures an aggregated log sink at the organization root with `includeChildren` set to true. This automatically captures matching logs from all descendant folders and projects. Cloud Logging creates a dedicated writer identity service account for the sink; granting this service account the specific Pub/Sub Publisher role on the destination topic ensures minimal privilege and secure cross-project log routing.

Step-by-Step Solution

Define an aggregated log sink at the organization resource level.

Centralizes log ingestion across all existing and newly provisioned folder and project resources using `includeChildren = true`.

Eliminates operational overhead of manually provisioning sinks per project.

Configure the sink filter and destination.

Filters logs to export only `severity >= ERROR` entries directly to the target Cloud Pub/Sub topic in the security operations project.

Ensures only relevant operational incidents stream to the automation pipeline.

Identify the writer identity service account generated by Cloud Logging and assign least-privilege permissions.

Grant `roles/pubsub.publisher` on the target Pub/Sub topic to the writer identity.

Fulfills Google Cloud Security IAM least-privilege standards by granting topic-level publish rights rather than project-level or primitive roles.

Key Concept

Organization-level Aggregated Log Sinks and Least-Privilege IAM Authorization

Estimated Time:3m 0s

Question 28Question →

A cloud operations team is designing a CI/CD pipeline to automate infrastructure provisioning across multiple Google Cloud projects using Terraform. To meet strict enterprise security guidelines, the team must eliminate long-lived service account key files, prevent state file corruption during concurrent pipeline runs, and adhere to the principle of least privilege. Which deployment architecture and authentication strategy adhering to Google Cloud recommended best practices should the team implement?

Configure a Cloud Storage remote backend with Object Versioning and state locking enabled, and authenticate the CI/CD pipeline using Workload Identity Federation with fine-grained IAM roles.

Store Terraform state files in a versioned local directory on the CI/CD runner, and grant the pipeline service account the primitive Editor role to simplify resource creation across all target projects.

Configure a Cloud Storage remote backend for state files, and grant the CI/CD pipeline service account the Service Account Admin role across target projects to manage and impersonate compute workloads.

Store state files in an unversioned local storage directory on the build agent, committing updated state files back to the private repository after each execution while authenticating with static service account keys.

Show answer & explanation

Answer: Configure a Cloud Storage remote backend with Object Versioning and state locking enabled, and authenticate the CI/CD pipeline using Workload Identity Federation with fine-grained IAM roles.

Answer

Configure a Cloud Storage remote backend with Object Versioning and state locking enabled, and authenticate the CI/CD pipeline using Workload Identity Federation with fine-grained IAM roles.

Configuring a Cloud Storage remote backend with Object Versioning provides automated state locking via GCS generation checks to ensure safe concurrent operations. Using Workload Identity Federation allows CI/CD systems to authenticate without long-lived keys while leveraging fine-grained IAM roles.

Step-by-Step Solution

Configure remote state locking and versioning

Terraform state is maintained centrally in a Cloud Storage bucket configured with state locking and Object Versioning.

This prevents state corruption from overlapping pipeline executions and allows state recovery in case of deployment failures.

Implement keyless authentication for CI/CD

Workload Identity Federation allows external CI/CD runners to exchange short-lived OpenID Connect (OIDC) tokens for Google Cloud IAM credentials.

This eliminates the security exposure associated with downloading and managing long-lived JSON service account key files.

Apply least-privilege access control

The impersonated service account is granted fine-grained predefined roles tailored exclusively to the required target GCP resources.

Avoiding primitive roles (Owner/Editor) and identity admin roles minimizes the blast radius of deployment pipeline actions.

Key Concept

Infrastructure as Code Centralized State Governance and Keyless CI/CD Authentication

Estimated Time:1m 30s

Question 29Question →

A financial enterprise is establishing governance controls across its Google Cloud Organization hierarchy. The security compliance team requires that virtual machines cannot be assigned external public IP addresses and that all new infrastructure resources are restricted to the `us-central1` and `europe-west1` regions. Which TWO Organization Policy constraints should the cloud architect implement to enforce these administrative controls?

Select all that apply

Set the `constraints/compute.vmExternalIpAccess` organization policy constraint to deny external IP address allocation on compute instances.

Set the `constraints/gcp.resourceLocations` organization policy constraint to allow resource creation only within `us-central1` and `europe-west1`.

Configure a VPC Service Controls security perimeter around the projects to prevent external IP assignments and enforce regional resource boundaries.

Grant the primitive `roles/owner` role to security administrators at the organization node so they can manually prevent external IP assignment and regional drift.

Show answer & explanation

Answer: Set the `constraints/compute.vmExternalIpAccess` organization policy constraint to deny external IP address allocation on compute instances.; Set the `constraints/gcp.resourceLocations` organization policy constraint to allow resource creation only within `us-central1` and `europe-west1`.

Answer

The cloud architect should configure the `constraints/compute.vmExternalIpAccess` constraint to block public IP assignment on VMs and the `constraints/gcp.resourceLocations` constraint to limit resource creation to the specified allowed regions.

The combination of the `constraints/compute.vmExternalIpAccess` constraint (which restricts public IP assignment to compute instances) and the `constraints/gcp.resourceLocations` constraint (which limits resource creation to designated GCP regions) centrally enforces the security and compliance requirements across the organization.

Step-by-Step Solution

Identify the constraint required for external IP prevention on VMs.

Selecting `constraints/compute.vmExternalIpAccess` prevents Compute Engine instances from receiving external IPv4 or IPv6 addresses.

Organization policies provide programmatic constraints on Compute Engine networking options.

Identify the constraint required to restrict resource provisioning regions.

Selecting `constraints/gcp.resourceLocations` with an allowed list containing `us-central1` and `europe-west1` restricts resource deployment geographically.

Resource location constraints define regional boundaries across all supported GCP services in the resource hierarchy.

Key Concept

Organization Policy constraints define centralized programmatic guardrails across the GCP resource hierarchy to enforce security and compliance standards.

Question 30Question →

A global online gaming company is designing a multi-tier leaderboard and matchmaking architecture on Google Cloud. The conceptual design requires high-concurrency event ingestion, low-latency stateful matchmaking logic, and ACID-compliant transactional persistence for player inventory management across regions. The enterprise architecture team is translating these conceptual requirements into a logical tier structure before finalizing physical GCP resource allocations. Which architecture design correctly maps the conceptual tiers to logical component boundaries and concrete physical GCP services while adhering to Google Cloud best practices?

Map event ingestion to Cloud Pub/Sub, stateful matchmaking to Cloud Run stateless containers backed by Cloud Memoryrange, and transaction persistence to Cloud SQL for PostgreSQL configured with cross-region read replicas.

Map event ingestion to Cloud Pub/Sub, stateful matchmaking logic to GKE clusters with StatefulSets, and inventory transaction persistence to Cloud Spanner across a multi-region instance configuration.

Map event ingestion to HA VPN endpoints, stateful matchmaking logic to Cloud Functions, and inventory transaction persistence to Cloud Bigtable with multi-cluster replication.

Map event ingestion to Cloud Dataflow, stateful matchmaking to a Compute Engine Managed Instance Group with CPU-based autoscaling, and inventory transaction persistence to Cloud Storage dual-region buckets.

Show answer & explanation

Answer: Map event ingestion to Cloud Pub/Sub, stateful matchmaking logic to GKE clusters with StatefulSets, and inventory transaction persistence to Cloud Spanner across a multi-region instance configuration.

Answer

The correct architecture maps event ingestion conceptually to Cloud Pub/Sub, stateful session handling logically to Google Kubernetes Engine (GKE) StatefulSets, and global multi-region transactional persistence physically to Cloud Spanner.

The solution correctly translates high-level conceptual capabilities (scalable ingestion, stateful compute, global transactional database) into logical service boundaries and selects the optimal physical GCP products (Cloud Pub/Sub, GKE StatefulSets, Cloud Spanner). Cloud Spanner provides the global ACID transactions required for multi-region inventory consistency, while GKE StatefulSets support stateful matchmaking sessions.

Step-by-Step Solution

Analyze conceptual requirements for data persistence.

Identified the need for globally distributed, multi-region ACID transactional writes for player inventory.

Standard relational databases like Cloud SQL offer read scalability via replicas but cannot accept multi-region synchronous ACID writes. Cloud Spanner is required.

Evaluate compute execution model requirements.

Selected GKE StatefulSets for complex, stateful matchmaking session logic.

Matchmaking requires persistent in-memory state and long-lived peer-to-peer session management, which serverless platforms like Cloud Run or Cloud Functions cannot natively maintain.

Verify event ingestion component selection.

Selected Cloud Pub/Sub as the asynchronous streaming buffer.

Cloud Pub/Sub decouples real-time telemetry and matchmaking request ingestion at massive global scale.

Key Concept

Mapping Architectural Abstraction Layers (Conceptual to Logical to Physical)

Question 31Question →

A global streaming media enterprise uses Google Cloud for its infrastructure. The enterprise security team needs to establish central governance guardrails across the Google Cloud resource hierarchy without causing immediate downtime to running systems. Specifically, they must satisfy two requirements: first, audit and evaluate the impact of prohibiting external IP addresses on Compute Engine instances within the 'Staging' folder before enforcing the block; second, enforce that all new Cloud Storage buckets across the entire organization are created strictly within the 'us-central1' and 'us-east1' regions. Which TWO architecture design choices should you implement to meet these requirements?

Select all that apply

Configure the boolean constraint 'constraints/compute.vmExternalIpAccess' using a dry-run policy on the 'Staging' folder.

Enforce the list constraint 'constraints/gcp.resourceLocations' at the Organization root level with allowed values set to 'in-regions: [us-central1, us-east1]'.

Create a VPC Service Controls perimeter around the organization root and define egress rules restricting Cloud Storage API calls to specific regional endpoints.

Revoke primitive Editor roles from developer service accounts on the 'Staging' folder and grant the Service Account User role to prevent external IP provisioning.

Show answer & explanation

Answer: Configure the boolean constraint 'constraints/compute.vmExternalIpAccess' using a dry-run policy on the 'Staging' folder.; Enforce the list constraint 'constraints/gcp.resourceLocations' at the Organization root level with allowed values set to 'in-regions: [us-central1, us-east1]'.

Answer

The correct architecture requires configuring the boolean constraint 'constraints/compute.vmExternalIpAccess' in dry-run mode on the 'Staging' folder and enforcing the list constraint 'constraints/gcp.resourceLocations' at the organization root level with allowed values for the designated regions.

The correct solution uses Google Cloud Organization Policies to enforce governance rules across the hierarchy. Applying the boolean constraint for external VM IP access in dry-run mode on the targeted folder enables logging of policy non-compliance without breaking active development workflows. Simultaneously, enforcing the resource location list constraint at the organization root guarantees inherited compliance for resource provisioning locations across all projects.

Step-by-Step Solution

Identify the mechanism for non-disruptive testing of VM external IP restrictions.

Using dry-run organization policies allows security teams to test constraints by generating audit logs upon policy violation without actively denying resource creation.

Dry-run policy evaluation satisfies the requirement to evaluate impact without blocking existing or new staging workloads.

Determine the resource hierarchy node and constraint configuration for regional resource restriction.

Organization policies inherit down the resource hierarchy. Applying 'constraints/gcp.resourceLocations' at the Organization root enforces region constraints across all folders and projects.

List constraints with allowed values restricting regions ensure compliance across all Cloud Storage buckets created in the organization.

Key Concept

Organization Policy Dry-Run Evaluation and Resource Location List Constraints

Question 32Question →

An enterprise security team needs to grant an automated compliance auditing application running in a dedicated security project permission to inspect resource configurations and IAM policies across all projects nested within a folder named Production-Workloads. The security team must also allow a DevOps engineer to deploy and attach this service account to Compute Engine audit instances without granting the engineer the ability to modify IAM policies or elevate their own privileges. Which TWO configuration steps should the security architect implement to achieve this with minimal operational overhead and least privilege? (Select TWO.)

Select all that apply

Grant the automated service account the Cloud Asset Viewer role (roles/cloudasset.viewer) bound at the Production-Workloads folder level.

Grant the DevOps engineer the Service Account User role (roles/iam.serviceAccountUser) on the specific audit service account resource.

Grant the automated service account the primitive Viewer role (roles/viewer) bound at the Organization root node.

Grant the DevOps engineer the Service Account Admin role (roles/iam.serviceAccountAdmin) bound at the Production-Workloads folder level.

Show answer & explanation

Answer: Grant the automated service account the Cloud Asset Viewer role (roles/cloudasset.viewer) bound at the Production-Workloads folder level.; Grant the DevOps engineer the Service Account User role (roles/iam.serviceAccountUser) on the specific audit service account resource.

Answer

Grant the automated service account the Cloud Asset Viewer role (roles/cloudasset.viewer) bound at the Production-Workloads folder level, and grant the DevOps engineer the Service Account User role (roles/iam.serviceAccountUser) on the specific audit service account resource.

Inheriting permissions from the folder level enables an automated service account to inspect assets across all child projects using a targeted predefined role. Restricting the DevOps engineer's permissions to the Service Account User role scoped specifically to the target service account permits deployment onto compute resources while preventing administrative privilege escalation.

Step-by-Step Solution

Determine the optimal scoping and role for the automated auditing application.

Identify that Cloud Asset Viewer (roles/cloudasset.viewer) provides read access to metadata and IAM policies across resources without exposing underlying payload data.

Granting this role at the Production-Workloads folder level leverages resource hierarchy inheritance to cover all current and future child projects automatically.

Determine the least-privilege permission required for the DevOps engineer deploying the compute workload.

Assign the Service Account User role (roles/iam.serviceAccountUser) directly on the target service account resource.

This grants the engineer permission to impersonate or bind the service account to Compute Engine instances without granting Service Account Admin rights or folder-wide IAM administrative capabilities.

Key Concept

Resource Hierarchy IAM Inheritance and Service Account Impersonation Least Privilege

Question 33Question →

A financial technology enterprise is automating the deployment of a high-throughput transaction processing engine on Google Cloud using an automated delivery pipeline. The CI/CD pipeline executes using a dedicated deployment service account that provisions a Compute Engine Managed Instance Group (MIG). The VMs in the instance template are configured to run under a separate application runtime service account with fine-grained database access permissions. During pipeline deployment, Compute Engine returns an authorization failure indicating that the deployment service account is not allowed to attach the runtime service account to the newly provisioned instances. Which action should the cloud architect take to resolve this failure while adhering to the principle of least privilege?

Grant the deployment service account the Service Account User role (roles/iam.serviceAccountUser) specifically on the application runtime service account.

Grant the deployment service account the Service Account Admin role (roles/iam.serviceAccountAdmin) at the project level.

Grant the deployment service account the primitive Editor role (roles/editor) at the project level.

Reconfigure the pipeline to provision a GKE Private Cluster with Control Plane Authorized Networks instead of Compute Engine VMs.

Show answer & explanation

Answer: Grant the deployment service account the Service Account User role (roles/iam.serviceAccountUser) specifically on the application runtime service account.

Answer

Grant the deployment service account the Service Account User role (roles/iam.serviceAccountUser) specifically on the application runtime service account.

To attach a service account to a Compute Engine instance template or VM, the deploying identity needs permission to act as that service account. Granting the Service Account User role (`roles/iam.serviceAccountUser`) directly on the runtime service account fulfills this requirement securely without granting project-wide elevated rights.

Step-by-Step Solution

Identify the missing IAM permission required for compute provisioning.

Compute Engine requires the identity creating the instances to hold `iam.serviceAccounts.actAs` permission on the target runtime service account.

When creating resources that run as a specific service account, GCP enforces security checks so users cannot elevate privileges illegally.

Apply the least-privilege IAM role to the specific target resource.

Granting `roles/iam.serviceAccountUser` specifically on the runtime service account resource gives the deployment service account exactly the required privilege.

Resource-level role bindings prevent over-granting permissions across all service accounts or project-level resources.

Key Concept

Compute Engine Service Account Impersonation and IAM Service Account User Role

Question 34Question →

An enterprise architecture team is designing an automated progressive delivery release pipeline using Google Cloud Deploy for a microservice deployed on Google Kubernetes Engine (GKE). The pipeline must enforce container image provenance via Binary Authorization and perform automated canary metric verification prior to full traffic shifting.

Arrange the following pipeline execution steps in the correct chronological order from source build to final production rollout.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence for the progressive delivery pipeline is: 1) Cloud Build compiles the image and generates a Binary Authorization attestation with Cloud KMS, 2) Cloud Build pushes the image to Artifact Registry and registers a release in Cloud Deploy, 3) Cloud Deploy provisions a canary rollout with 10% traffic routing, 4) Cloud Monitoring verifies SLIs during the observation window, and 5) Cloud Deploy advances the phase to route 100% of production traffic.

The deployment pipeline follows a logical progressive delivery workflow: artifact compilation and Binary Authorization attestation signing (via Cloud KMS in Cloud Build) must precede release registration in Google Cloud Deploy. Once registered, Cloud Deploy executes canary traffic shifting (routing 10% traffic), followed by automated SLI evaluation via Cloud Monitoring during an observation window. Only after metric verification completes successfully can Cloud Deploy promote the deployment phase to shift 100% of production traffic.

Step-by-Step Solution

Generate build artifacts and attestations in CI

Container image is built and signed via Cloud KMS for Binary Authorization enforcement.

Binary Authorization requires attestations to exist prior to image deployment in protected target environments.

Store artifact and trigger Continuous Delivery pipeline

Artifact is stored in Artifact Registry and a Cloud Deploy release is instantiated.

Cloud Deploy releases depend on immutable image digest references stored in Artifact Registry.

Execute initial canary phase deployment

Canary pod revision is deployed to GKE with 10% traffic split.

Progressive delivery starts with limited traffic exposure to restrict potential impact from regressions.

Perform automated metrics analysis

Cloud Monitoring validates error rates and latency SLIs over the observation period.

Automated telemetry checking confirms system stability before expanding deployment scope.

Promote to full production traffic

Cloud Deploy routes 100% of traffic to the new revision.

Successful metric evaluation allows the pipeline to conclude with full production promotion.

Key Concept

Automating Continuous Deployment Pipelines and Release Strategies using Google Cloud Deploy, Binary Authorization, and Canary Analysis

Question 35Question →

A biomedical research company is automating the infrastructure provisioning process on Google Cloud for a distributed genomic processing platform. The architecture requires deploying a private Google Kubernetes Engine (GKE) cluster for core compute services alongside automated Terraform pipelines for provisioning Compute Engine Managed Instance Groups (MIGs). The security and operations teams require that administrative control plane access to the private GKE cluster be strictly limited to trusted corporate networks, and that infrastructure state storage prevents concurrent execution conflicts or loss of state history. Which TWO deployment configuration actions should the Cloud Architect recommend to fulfill these operational and security constraints?

Select all that apply

Configure control plane authorized networks on the private GKE cluster using explicit corporate CIDR ranges.

Configure a Google Cloud Storage remote backend with object versioning and state locking for Terraform state management.

Grant the Service Account Admin role (roles/iam.serviceAccountAdmin) to the CI/CD pipeline service account to allow instance template provisioning.

Maintain the Infrastructure as Code (IaC) state file in unversioned local storage within the transient CI/CD runner container to maximize build execution speed.

Provision an additional dedicated GKE cluster to serve simple stateless static documentation microservices.

Show answer & explanation

Answer: Configure control plane authorized networks on the private GKE cluster using explicit corporate CIDR ranges.; Configure a Google Cloud Storage remote backend with object versioning and state locking for Terraform state management.

Answer

The correct architecture requires enabling control plane authorized networks with explicit corporate CIDR ranges on the private GKE cluster and storing Terraform state in a Google Cloud Storage backend configured with object versioning and state locking.

Configuring control plane authorized networks on private GKE clusters ensures master endpoint communication is strictly constrained to authorized corporate IP blocks. Concurrently, using Google Cloud Storage as a remote backend with versioning and state locking protects infrastructure state from corruption and concurrent pipeline conflicts.

Step-by-Step Solution

Evaluate private GKE cluster control plane security requirements.

Identified that restricting master endpoint access requires configuring GKE control plane authorized networks with specific CIDR blocks.

Private GKE clusters require explicit authorized network rules to block unauthorized public network requests to the control plane.

Evaluate Infrastructure as Code (IaC) state management best practices.

Identified that Cloud Storage backend with state locking and object versioning fulfills concurrency and resilience needs.

Centralized, locked, and versioned remote backends prevent state corruption during automated CI/CD runs.

Analyze distractor options regarding IAM roles, IaC state, and compute platform selection.

Eliminated options recommending excessive IAM primitive/admin roles, local state storage, and redundant cluster creation.

These options violate least privilege, introduce state corruption risks, or add unnecessary operational complexity.

Key Concept

Provisioning private GKE clusters with control plane authorized networks and securing automated IaC state management in Cloud Storage.

Question 36Question →

An enterprise logistics corporation is deploying a new fleet management platform across multiple Google Cloud projects organized under a parent folder named `Fleet-Ops`. The compliance team mandates two strict governance guardrails: (1) prevent users from generating external service account keys to mitigate credential leakage risks, and (2) restrict all infrastructure deployment strictly to European regions (`europe-west1` and `europe-west4`). Additionally, the team must evaluate the operational impact of the key creation restriction on existing pipelines prior to active blocking. Which TWO actions should the security architect take to satisfy these governance requirements using Google Cloud Organization Policies?

Select all that apply

Apply the boolean constraint `iam.disableServiceAccountKeyCreation` at the `Fleet-Ops` folder level with a dry-run policy spec to monitor violations in Cloud Logging before enforcing active blocking.

Apply the list constraint `gcp.resourceLocations` at the `Fleet-Ops` folder level, configuring the allowed values to include `in:europe-west1-locations` and `in:europe-west4-locations`.

Grant the primitive `roles/viewer` IAM role at the `Fleet-Ops` folder level to developer service accounts to prevent them from creating service account keys and provisioning resources in unauthorized regions.

Create a VPC Service Controls security perimeter encompassing all projects under the `Fleet-Ops` folder to restrict resource locations and block service account key generation.

Show answer & explanation

Answer: Apply the boolean constraint `iam.disableServiceAccountKeyCreation` at the `Fleet-Ops` folder level with a dry-run policy spec to monitor violations in Cloud Logging before enforcing active blocking.; Apply the list constraint `gcp.resourceLocations` at the `Fleet-Ops` folder level, configuring the allowed values to include `in:europe-west1-locations` and `in:europe-west4-locations`.

Answer

Configure an Organization Policy with a dry-run spec for the boolean constraint iam.disableServiceAccountKeyCreation at the Fleet-Ops folder level, and configure an Organization Policy with the list constraint gcp.resourceLocations allowing in:europe-west1-locations and in:europe-west4-locations at the Fleet-Ops folder level.

The solution requires applying two distinct Google Cloud Organization Policies at the `Fleet-Ops` folder level. First, applying the `iam.disableServiceAccountKeyCreation` boolean constraint with a dry-run policy spec allows security administrators to monitor logs in Cloud Logging for non-compliant service account key creation attempts without breaking current CI/CD pipelines. Second, enforcing the `gcp.resourceLocations` list constraint with explicit region group values restricts resource provisioning across all child projects strictly to `europe-west1` and `europe-west4`.

Step-by-Step Solution

Identify the governance requirements for service account key restriction and dry-run evaluation.

Selected the boolean Organization Policy constraint `iam.disableServiceAccountKeyCreation` applied at the `Fleet-Ops` folder level with a dry-run configuration.

Dry-run policy enforcement logs violations to Cloud Logging without blocking actions, fulfilling the requirement to test impact on existing pipelines.

Identify the governance requirements for regional resource location boundaries.

Selected the list Organization Policy constraint `gcp.resourceLocations` configured with `in:europe-west1-locations` and `in:europe-west4-locations` at the `Fleet-Ops` folder level.

List constraints at the folder level prevent any underlying project from deploying resources outside the specified regional location groups.

Key Concept

Google Cloud Organization Policies enforcement, dry-run testing, and resource hierarchy inheritance

Question 37Question →

An architectural team at a global financial settlement firm is translating a multi-tier conceptual architecture into concrete logical and physical designs on Google Cloud. The logical tier mandates two key requirements: first, a core relational transaction ledger that guarantees active-active multi-region ACID consistency with low write latency; second, strict network-level security perimeters between the transaction engine and third-party audit reporting components to block unauthorized data exfiltration even if IAM credentials are leaked. Which physical architecture implementation correctly maps these logical requirements to Google Cloud services?

Provision Cloud Spanner with a multi-region instance configuration for the relational transaction ledger, and isolate the transaction processing and audit reporting projects into separate security perimeters using VPC Service Controls.

Provision Cloud SQL for PostgreSQL with cross-region read replicas for the relational transaction ledger, and restrict communication between project environments using IAM primitive Editor roles.

Provision Cloud Spanner with a multi-region instance configuration for the transaction ledger, and rely exclusively on IAM Service Account User role bindings without configuring VPC Service Controls perimeters.

Provision an Autopilot GKE Enterprise cluster to host stateless event ingestion webhooks, while deploying Cloud SQL for global multi-region transactional consistency and Cloud Spanner for long-term audit logging.

Show answer & explanation

Answer: Provision Cloud Spanner with a multi-region instance configuration for the relational transaction ledger, and isolate the transaction processing and audit reporting projects into separate security perimeters using VPC Service Controls.

Answer

The correct solution maps the logical requirements to physical GCP components by choosing Cloud Spanner for multi-region active-active relational consistency and VPC Service Controls to enforce perimeter-based network protection against data exfiltration.

Step-by-Step Solution

Analyze the logical database requirements.

The requirement specifies an active-active multi-region relational database with strict ACID consistency and low latency.

Cloud Spanner is the physical GCP service designed specifically for globally distributed, multi-region synchronous relational transactions, whereas Cloud SQL only provides single-region primary engines with asynchronous cross-region replicas.

Analyze the logical security and isolation requirements.

The requirement demands protection against data exfiltration across security perimeters, even if IAM identities are compromised.

VPC Service Controls create boundary perimeters around GCP resources at the network layer to prevent data theft and exfiltration, which IAM alone cannot prevent.

Synthesize the physical architecture mapping.

Combining Cloud Spanner (multi-region) and VPC Service Controls (project perimeters) satisfies both logical criteria.

This configuration accurately maps conceptual data integrity and isolation policies into enterprise-grade GCP physical infrastructure.

Key Concept

Translating logical data storage and security requirements into GCP physical services (Cloud Spanner and VPC Service Controls)

Question 38Question →

A global online travel booking platform is migrating its infrastructure to Google Cloud within a strict 3-week cutover window. The application stack includes a $15\text{ TB}$ operational PostgreSQL relational database that requires less than 2 hours of downtime during cutover, and a $350\text{ TB}$ historical search log archive. The enterprise maintains an existing $1\text{ Gbps}$ Dedicated Interconnect connection to Google Cloud, but network policies restrict migration bandwidth on this link to off-peak hours (maximum 12 hours per day). Which migration and data transfer strategy should the cloud architect recommend to meet all business and technical constraints?

Order a Google Cloud Transfer Appliance to transfer the

350\text{ TB}

historical search log archive offline, and use Database Migration Service (DMS) with continuous Change Data Capture (CDC) over the Dedicated Interconnect for the PostgreSQL database.

Use Storage Transfer Service over the Dedicated Interconnect during off-peak hours to transfer both the

350\text{ TB}

historical log archive and periodic PostgreSQL database backups.

Migrate the

15\text{ TB}

PostgreSQL database to Cloud Spanner using Database Migration Service to eliminate cutover downtime, and transfer the search log archive via Storage Transfer Service over a temporary HA VPN connection.

Provision additional HA VPN tunnels to stream the

350\text{ TB}

log archive using Storage Transfer Service, and perform a cold database migration using static database exports during the final maintenance window.

Show answer & explanation

Answer: Order a Google Cloud Transfer Appliance to transfer the $350\text{ TB}$ historical search log archive offline, and use Database Migration Service (DMS) with continuous Change Data Capture (CDC) over the Dedicated Interconnect for the PostgreSQL database.

Answer

Order a Google Cloud Transfer Appliance to transfer the historical search log archive offline, and use Database Migration Service (DMS) with continuous Change Data Capture (CDC) over the Dedicated Interconnect for the PostgreSQL database.

Transferring

350\text{ TB}

of data over a

1\text{ Gbps}

line capped at 12 hours per day provides only

\sim 5.4\text{ TB}

of daily ingestion, requiring over two months. Utilizing Google Cloud Transfer Appliance enables shipping the archive offline to meet the 3-week timeline constraint. Meanwhile, Database Migration Service (DMS) continuously replicates PostgreSQL transactions using Change Data Capture (CDC) over the Dedicated Interconnect, allowing the database cutover to complete well within the 2-hour target window.

Step-by-Step Solution

Calculate available online bandwidth capacity for the bulk log archive transfer.

1\text{ Gbps}

(

125\text{ MB/s}

), 12 hours of transfer per day yields

125\text{ MB/s} \times 43,200\text{ seconds} \approx 5.4\text{ TB/day}

. Transferring

350\text{ TB}

requires approximately 65 days.

Because 65 days exceeds the 3-week (

21\text{ days}

) timeline, online transfer via Dedicated Interconnect or HA VPN is unfeasible. An appliance-based offline transfer (Transfer Appliance) is required.

Evaluate relational database migration and cutover requirements.

A static dump/restore of a

15\text{ TB}

database over the network or via appliance would require many hours to export, transport, and re-index, violating the 2-hour maximum downtime window.

Database Migration Service (DMS) utilizes continuous Change Data Capture (CDC) to keep the target Cloud SQL/PostgreSQL instance in sync with on-premises, enabling a rapid cutover within minutes.

Key Concept

Designing hybrid migration plans that combine offline physical appliances (Transfer Appliance) for bandwidth-constrained large datasets with continuous online replication tools (DMS with CDC) for low-downtime database cutovers.

Question 39Question →

A platform engineering team is automating continuous deployment pipelines using Cloud Build and Cloud Deploy for microservice applications hosted on Google Kubernetes Engine (GKE). The architecture requires strict compliance with least-privilege IAM controls for pipeline execution and resilient infrastructure state management for pipeline provisioning. Which TWO design practices should the team implement to achieve these requirements?

Select all that apply

Configure Cloud Deploy execution service accounts with least-privilege roles such as Cloud Deploy Job Runner rather than primitive roles.

Store Infrastructure as Code (IaC) Terraform state files in a Cloud Storage backend with object versioning and state locking enabled.

Assign the primitive Owner role to the Cloud Build service account to ensure uninterrupted execution across all GCP resources.

Store Terraform state files inside the ephemeral Cloud Build runner workspace without remote locking to maximize deployment velocity.

Grant the Service Account Admin role to the deployment pipeline service account to allow workloads to execute under worker identity.

Show answer & explanation

Answer: Configure Cloud Deploy execution service accounts with least-privilege roles such as Cloud Deploy Job Runner rather than primitive roles.; Store Infrastructure as Code (IaC) Terraform state files in a Cloud Storage backend with object versioning and state locking enabled.

Answer

The correct practices are configuring Cloud Deploy execution service accounts with fine-grained roles such as Cloud Deploy Job Runner, and storing Infrastructure as Code (IaC) Terraform state files in a remote Cloud Storage backend with object versioning and state locking enabled.

Configuring Cloud Deploy execution service accounts with granular predefined roles adheres to least-privilege security principles. Concurrently, utilizing a Cloud Storage remote backend with versioning and object locking for Terraform state management prevents configuration drift, race conditions, and state file corruption during automated release deployments.

Step-by-Step Solution

Evaluate IAM least-privilege execution requirements for continuous deployment services.

Identified that dedicated execution service accounts should be assigned granular roles like roles/clouddeploy.jobRunner rather than broad primitive roles.

Restricting deployment pipeline access ensures compliance with enterprise security standards and limits security blast radius.

Evaluate Infrastructure as Code state management requirements for automated delivery pipelines.

Selected Cloud Storage as a remote backend with versioning and state locking enabled.

Remote state backends protect against concurrency race conditions and allow safe rollback in automated IaC pipeline runs.

Key Concept

Automating Continuous Deployment Pipelines and Release Strategies with Least Privilege and Resilient IaC State Management

Question 40Question →

A multinational enterprise is deploying an automated batch processing platform across multiple Google Cloud projects situated inside a dedicated `Data Analytics` resource hierarchy folder. During a scheduled high-volume analytics job, an automated Infrastructure-as-Code (IaC) pipeline attempts to provision 300 additional N2-standard-16 Compute Engine virtual machines in the `us-central1` region. The deployment fails during compute resource creation with a `QUOTA_EXCEEDED` error for `N2_CPUS` in `us-central1`. The architecture team must ensure future automated scale-out events execute successfully without sacrificing security or operational governance. Which strategy should the Cloud Architect recommend?

Increase the Cloud Billing budget alert threshold for the parent folder and enable automatic quota scaling in the Google Cloud Billing console prior to executing the pipeline.

Proactively submit a regional quota increase request for N2 CPUs in `us-central1` via the Cloud Console or Cloud Quotas API, and establish Cloud Monitoring quota usage alerts.

Grant the automation pipeline service account the `roles/owner` primitive role at the Organization level to allow the pipeline to dynamically override regional quota restrictions.

Configure the IaC pipeline to store state files in local runner storage rather than Cloud Storage so that retry logic can bypass GCP quota verification checks.

Show answer & explanation

Answer: Proactively submit a regional quota increase request for N2 CPUs in `us-central1` via the Cloud Console or Cloud Quotas API, and establish Cloud Monitoring quota usage alerts.

Answer

Proactively submit a regional quota increase request for N2 CPUs in `us-central1` via the Cloud Console or Cloud Quotas API, and establish Cloud Monitoring quota usage alerts.

Google Cloud service quotas are enforced at the project and regional level to ensure system stability and prevent unintended resource consumption. For predictable high-volume scale-out workloads, architects must plan ahead by submitting regional quota increase requests (e.g., for N2 CPUs in `us-central1`) via the Google Cloud Console or Cloud Quotas API. Integrating Cloud Monitoring alerts based on quota usage metrics ensures operational visibility before capacity limits cause job failures.

Step-by-Step Solution

Identify the cause of the provisioning failure.

The failure is caused by reaching the per-project regional quota for `N2_CPUS` in `us-central1`.

Compute Engine quotas are enforced per region per project to prevent unexpected resource exhaustion and system overload.

Evaluate GCP quota request procedures.

Quotas must be requested in advance because approval involves capacity verification by Google Cloud.

Automated deployments cannot bypass quotas at runtime without prior quota adjustment requests.

Implement proactive quota governance and monitoring.

Combine preemptive quota increase requests with Cloud Monitoring alerts configured against quota consumption metrics.

This guarantees required capacity for large-scale operations while preventing future unexpected provisioning failures.

Key Concept

Managing Resource Quotas and Proactive Capacity Governance in Google Cloud

PreviousPage 2 / 80Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept