All practice questions

815 questions

All types1,598 Multiple choice815 Multiple select537 Numeric8 Matching64 Ordering174

An enterprise financial organization is deploying a private Google Kubernetes Engine (GKE) cluster to host compliance-sensitive microservices. Operational policy dictates that worker nodes must not have public IP addresses and that the GKE control plane private endpoint must be accessible only to security operators connecting via an existing Cloud VPN from an on-premises network subnet (10.200.0.0/24). Public internet access to the control plane must be completely disabled. Which configuration architectural strategy should you implement to provision this cluster securely while enabling operational management?

Provision a private GKE cluster with the private endpoint enabled and public endpoint disabled, and configure Control Plane Authorized Networks to allow the 10.200.0.0/24 subnet.

Provision a private GKE cluster with the private endpoint enabled and public endpoint disabled, relying on automatic VPC network routing over Cloud VPN to grant control plane access without specifying authorized networks.

Grant security operators the Project Owner primitive IAM role so their authenticated credentials automatically bypass GKE control plane network restrictions.

Grant security operators the Service Account Admin role to allow administrative access to cluster management service accounts across the private network endpoint.

Show answer & explanation

Answer: Provision a private GKE cluster with the private endpoint enabled and public endpoint disabled, and configure Control Plane Authorized Networks to allow the 10.200.0.0/24 subnet.

Answer

Provision a private GKE cluster with the private endpoint enabled and public endpoint disabled, and configure Control Plane Authorized Networks to allow the 10.200.0.0/24 subnet.

The correct strategy is to provision a private GKE cluster with the private endpoint enabled and public endpoint disabled, while configuring Control Plane Authorized Networks to allow the on-premises subnet (10.200.0.0/24). GKE control planes are hosted in a Google-managed tenant VPC connected via VPC Network Peering. When public access is disabled, access from remote networks connected via Cloud VPN or Dedicated Interconnect requires explicitly adding the client IP ranges to the Control Plane Authorized Networks configuration.

Step-by-Step Solution

Identify cluster isolation requirements

Worker nodes must have private IPs only, and the control plane must not be exposed to the public internet.

Meets compliance policies disabling public endpoints for GKE compute and master nodes.

Determine master endpoint accessibility mechanism

Enable private endpoint access and disable public endpoint access during GKE cluster creation.

Ensures the control plane endpoint is assigned an internal IP accessible via VPC and connected networks.

Configure Control Plane Authorized Networks

Explicitly add the on-premises management subnet (10.200.0.0/24) to the cluster's Control Plane Authorized Networks list.

Private control plane endpoints enforce strict IP authorization filters; non-VPC custom CIDRs reaching the cluster over VPN/Interconnect must be explicitly permitted.

Key Concept

Private GKE Cluster Control Plane Security & Authorized Networks

Question 2Question →

A healthcare organization is migrating its core platform from an on-premises data center to Google Cloud. The migration scope includes 850 TB of archived historical imaging data and an active 12 TB PostgreSQL transactional database supporting critical clinical workflows. The organization has an existing 1 Gbps Dedicated Interconnect with an average baseline utilization of 70%. Security policies strictly mandate that all data must travel over private connectivity without traversing the public internet, and the maximum permissible downtime window for the transactional database during final cutover is 4 hours. Which data transfer and migration strategy should a Cloud Architect recommend to satisfy all business and technical constraints?

Stream the 850 TB imaging dataset over the Dedicated Interconnect using Storage Transfer Service while concurrently configuring continuous replication for the PostgreSQL database using Database Migration Service.

Provision multiple High Availability (HA) VPN tunnels over the public internet to burst total throughput up to 10 Gbps for transferring the 850 TB imaging dataset, while performing an offline database dump and restore over the Dedicated Interconnect during the maintenance window.

Order a GCP Transfer Appliance to move the 850 TB imaging dataset offline, while using Database Migration Service over the Dedicated Interconnect with continuous change data capture (CDC) to synchronize the PostgreSQL database prior to cutover.

Order a GCP Transfer Appliance for the 850 TB imaging dataset, but migrate the PostgreSQL database to Cloud Spanner by exporting the database and running a full schema and bulk data import during the 4-hour cutover window.

Show answer & explanation

Answer: Order a GCP Transfer Appliance to move the 850 TB imaging dataset offline, while using Database Migration Service over the Dedicated Interconnect with continuous change data capture (CDC) to synchronize the PostgreSQL database prior to cutover.

Answer

The optimal strategy is ordering a GCP Transfer Appliance to transport the 850 TB imaging dataset offline while utilizing Database Migration Service with continuous change data capture (CDC) over the Dedicated Interconnect for the 12 TB PostgreSQL database.

The solution combining GCP Transfer Appliance for the 850 TB unstructured dataset with Database Migration Service (DMS) continuous replication for the 12 TB database is the only strategy that satisfies all constraints. Transfer Appliance moves petabyte-scale data offline without saturating the limited 300 Mbps available bandwidth, while DMS over Dedicated Interconnect performs online CDC to keep downtime during cutover well under the 4-hour SLA without traversing the public internet.

Step-by-Step Solution

Calculate available network bandwidth and time required for online data transfer of the unstructured dataset.

With 70% of the 1 Gbps link utilized, only 300 Mbps (

0.3\text{ Gbps}

) remains available. Transferring

850\text{ TB} = 6.8 \times 10^6\text{ Gb}

0.3\text{ Gbps}

takes approximately

\frac{6.8 \times 10^6}{0.3} \approx 22.67 \times 10^6\text{ seconds} \approx 262\text{ days}

. This mandates an offline physical appliance transfer.

Large multi-hundred terabyte datasets cannot be moved online over low-bandwidth connections within reasonable operational timeframes.

Evaluate connectivity and security constraints for the offline data transfer.

Transfer Appliance provides hardware-encrypted physical ingestion that avoids public internet routing, satisfying compliance requirements.

Security policy strictly forbids sending sensitive healthcare data over the public internet.

Design the database migration path to achieve a cutover window under 4 hours.

Using Database Migration Service (DMS) over the Dedicated Interconnect enables continuous initial snapshot sync followed by Change Data Capture (CDC). During cutover, only the remaining minimal replication lag must be processed, completing cutover in minutes.

Offline dumps of a 12 TB database take many hours to export and restore, exceeding the 4-hour maximum downtime SLA.

Key Concept

Selecting appropriate GCP data transfer mechanisms based on data volume, bandwidth constraints, security policies, and downtime SLAs.

Question 3Question →

An enterprise organization manages multiple Google Cloud projects across production and non-production environments using Terraform within a centralized CI/CD pipeline. Engineers report intermittent deployment failures caused by concurrent pipeline executions modifying state simultaneously, and security audits identified Terraform state files containing sensitive data stored locally on transient build runners. You need to redesign the Infrastructure as Code (IaC) architecture to align with Google Cloud security and operational best practices. Which strategy should you recommend?

Configure a dedicated Cloud Storage bucket per environment with Object Versioning enabled as the Terraform remote backend, enforce state locking via Cloud Storage native locking mechanisms, and restrict bucket access using fine-grained IAM roles granted to the CI/CD execution service account.

Store state files in a local directory on the CI/CD runner host and execute a post-deployment script that uploads state snapshots to a Cloud Storage bucket without object versioning.

Configure a single shared Cloud Storage backend for all environments, disable Object Versioning to control storage costs, and grant the primitive Owner role to all deployment pipelines to ensure full resource management rights.

Store state files in a central Git repository and grant the Service Account Admin role (roles/iam.serviceAccountAdmin) to the deployment pipeline service account to dynamically generate service account keys during execution.

Show answer & explanation

Answer: Configure a dedicated Cloud Storage bucket per environment with Object Versioning enabled as the Terraform remote backend, enforce state locking via Cloud Storage native locking mechanisms, and restrict bucket access using fine-grained IAM roles granted to the CI/CD execution service account.

Answer

Configuring a dedicated Cloud Storage bucket with Object Versioning enabled as the Terraform remote backend guarantees state persistence, prevents state corruption from concurrent runs via native GCS state locking, allows point-in-time state recovery through object versions, and secures state contents by applying fine-grained IAM roles to the automated pipeline service account.

Step-by-Step Solution

Identify current IaC state management and pipeline vulnerabilities

Local storage on build runners exposes cleartext state files to loss/exposure and causes state corruption due to lack of concurrency locking.

Terraform state contains sensitive metadata and resource mappings that require remote persistence, encryption at rest, state locking, and point-in-time recovery capabilities.

Evaluate GCP remote backend features for Terraform

Google Cloud Storage (GCS) provides built-in state locking natively, object versioning for rollback capabilities, and integration with IAM for least-privilege access control.

A GCS remote backend prevents simultaneous pipeline runs from corrupting state, while Object Versioning safeguards against accidental deletion or state corruption.

Implement environmental separation and identity controls

Isolate environments using separate GCS buckets for each stage (e.g., development, production) and assign fine-grained predefined storage roles to dedicated pipeline service accounts.

Environment separation limits the blast radius of misconfigurations, and dedicated service accounts enforce security boundaries without over-granting primitive roles.

Key Concept

Terraform Remote State Management and Security Best Practices in GCP

Estimated Time:2m 0s

Question 4Question →

A healthcare telemetry platform is deploying a bursty event-processing workload on Google Cloud using Compute Engine Managed Instance Groups (MIGs). The autoscaling policy scales compute nodes based on custom Cloud Monitoring queue depth metrics, rapidly expanding from 10 instances to over 400 N2 high-memory instances during peak ingestion windows. The deployment pipeline uses Terraform to automate infrastructure provisioning, and the worker instances must securely assume a custom identity to interact with Bigtable. During initial stress testing of a new region, scaling events stalled halfway through expansion, and Terraform updates failed. Which combination of administrative and provisioning actions must the architecture team implement to prevent these failures?

Submit regional vCPU quota increase requests in advance for the target compute instance family, and grant the deployment pipeline service account the Service Account User role (roles/iam.serviceAccountUser) on the worker service account.

Migrate the processing workload to a Google Kubernetes Engine (GKE) Autopilot cluster, as GKE managed clusters automatically override and bypass project-level regional compute quotas.

Store the Terraform state file in a local ephemeral container volume during deployment to reduce network latency and state locking timeouts during large autoscaling events.

Assign the Owner primitive IAM role (roles/owner) to the deployment pipeline service account to ensure it bypasses service account identity configuration checks.

Show answer & explanation

Answer: Submit regional vCPU quota increase requests in advance for the target compute instance family, and grant the deployment pipeline service account the Service Account User role (roles/iam.serviceAccountUser) on the worker service account.

Answer

Provisioning large-scale Managed Instance Groups (MIGs) requires verifying and requesting regional compute quotas (such as N2 vCPUs) prior to deployment to handle maximum autoscaling bounds. Additionally, for automated Infrastructure as Code pipelines (like Terraform) to provision instances running under a custom worker identity, the pipeline's executing principal must be granted the `roles/iam.serviceAccountUser` role on that worker service account.

Step-by-Step Solution

Analyze capacity requirements for burst autoscaling.

Scaling up to 400 N2 high-memory instances requires confirming that regional vCPU quotas in the destination region accommodate the peak compute footprint.

Default GCP project quotas often cap regional vCPUs below large-scale burst requirements, causing provisioning calls to fail.

Evaluate service account delegation for automated compute provisioning.

The deployment pipeline service account requires the `roles/iam.serviceAccountUser` role on the dedicated worker service account.

This grant enables the pipeline to attach the specific runtime identity to newly created Compute Engine instance templates without granting overly permissive administrative rights.

Key Concept

Compute Resource Provisioning, Regional Quota Planning, and Identity Delegation

Estimated Time:2m 0s

Question 5Question →

A renewable energy enterprise is designing the architecture for a new web application backend that ingests real-time telemetry from solar inverter gateways over HTTPS. The application logic is packaged into a stateless container image that requires custom system-level C libraries. Traffic fluctuates heavily throughout the day, dropping to zero during nighttime hours. The engineering team has strict instructions to minimize operational overhead and avoid paying for compute resources when idle. Which compute platform should you recommend to meet these requirements?

Deploy the application container on Cloud Run, setting the minimum number of instances to zero and allowing fully managed autoscaling based on HTTP request concurrency.

Deploy the application container to a Google Kubernetes Engine (GKE) cluster using Standard mode with the Cluster Autoscaler enabled to scale nodes down during off-peak hours.

Deploy the application container across a Compute Engine Managed Instance Group (MIG) using custom VM images, and configure autoscaling strictly based on target CPU utilization.

Provision a fixed cluster of Compute Engine virtual machines covered by a 3-year Committed Use Discount (CUD) to handle the daily peak load at the lowest hourly rate.

Show answer & explanation

Answer: Deploy the application container on Cloud Run, setting the minimum number of instances to zero and allowing fully managed autoscaling based on HTTP request concurrency.

Answer

Deploy the application container on Cloud Run, setting the minimum number of instances to zero and allowing fully managed autoscaling based on HTTP request concurrency.

Cloud Run is the optimal Google Cloud compute platform for stateless containerized web microservices with variable HTTP/HTTPS traffic. It supports custom binary dependencies within standard Docker images, abstracts all underlying infrastructure management, and natively scales instances down to zero when no requests are being processed, satisfying the zero idle cost mandate.

Step-by-Step Solution

Analyze workload requirements

Identified a stateless containerized web service with custom binary dependencies, variable HTTPS traffic, zero night traffic, and a requirement for minimal operational overhead.

Determining container compatibility and scaling dynamics dictates compute choice.

Evaluate candidate compute platforms against constraints

Cloud Run supports arbitrary containers with custom C libraries, automatically scales down to 0 instances when traffic stops, and requires zero infrastructure management.

Serverless containers fit stateless HTTP workloads without cluster management overhead.

Eliminate non-optimal options

GKE adds unnecessary cluster management complexity, Compute Engine MIGs require OS maintenance, and Committed Use Discounts lead to paying for unused capacity during zero-traffic periods.

Avoiding operational overhead and idle costs excludes GKE and VM-based options.

Key Concept

Selecting serverless container platforms (Cloud Run) for stateless HTTP workloads with variable demand and zero-scale requirements

Estimated Time:1m 30s

Question 6Question →

A DevOps engineering team is operating a microservices application deployed on Cloud Run. During peak usage, transient database connectivity issues generate log entries containing the structured field payload status: CRITICAL_DATABASE_TIMEOUT. The team needs to configure automated alerting to notify on-call engineers via an existing Cloud Monitoring notification channel whenever this log entry appears more than 10 times within any 5-minute rolling window. Which configuration should the team implement?

Create a counter log-based metric in Cloud Logging filtered for the database timeout log payload, and configure a Cloud Monitoring alerting policy based on this metric using a 5-minute rolling alignment window.

Configure an exclusion filter in Cloud Logging for the timeout log payload, and attach the PagerDuty notification channel directly to the exclusion filter definition.

Assign the primitive Owner role (roles/owner) to the application service account so Cloud Logging automatically elevates matching log entries to high-priority operational incidents.

Submit a regional quota increase request for Cloud Logging log ingestion capacity before creating log routing pipelines.

Show answer & explanation

Answer: Create a counter log-based metric in Cloud Logging filtered for the database timeout log payload, and configure a Cloud Monitoring alerting policy based on this metric using a 5-minute rolling alignment window.

Answer

Creating a counter log-based metric allows Cloud Logging to count occurrence instances of specific log entries matching a filter. Cloud Monitoring reads this metric and evaluates threshold conditions over specified time windows (such as 5 minutes) to trigger alerting policies and push notifications to operational channels.

Step-by-Step Solution

Define a counter log-based metric in Cloud Logging

Cloud Logging starts counting matching log entries containing status: CRITICAL_DATABASE_TIMEOUT as time-series metric data points.

Log-based metrics convert unstructured or structured log event frequencies into numerical metrics accessible by Cloud Monitoring.

Create an alerting policy in Cloud Monitoring

An alerting policy condition monitors the log-based metric with a 5-minute alignment period and a threshold of > 10 occurrences.

Cloud Monitoring aggregation functions compute the rate of occurrence over the specified time window.

Attach the notification channel to the alerting policy

When the threshold is breached, Cloud Monitoring automatically sends an operational alert to the on-call team.

Notification channels route incident alerts to external operations systems like PagerDuty or Slack.

Key Concept

Log-based Metrics and Cloud Monitoring Alert Policies

Estimated Time:1m 30s

Question 7Question →

A enterprise logistics company is designing a dual-workload telemetry platform on Google Cloud. The platform consists of two main services:

1. Stateless Ingestion API: Accepts unpredictable bursts of short-lived HTTPS POST requests from IoT devices. The service must automatically scale to zero during off-peak hours to minimize cost, require minimal infrastructure management, and run standard container images.
2. Custom Protocol Engine: Maintains persistent, long-lived TCP socket connections with custom kernel-level TCP buffer configuration (`sysctl`) tunings for legacy gateway hardware.

Which architectural strategy minimizes operational overhead while satisfying the technical requirements of both workloads?

Deploy the stateless Ingestion API on Cloud Run, and deploy the Custom Protocol Engine on Compute Engine Managed Instance Groups (MIGs).

Deploy both the stateless Ingestion API and the Custom Protocol Engine onto a Google Kubernetes Engine (GKE) Standard cluster using custom node pools.

Deploy the stateless Ingestion API on Compute Engine Managed Instance Groups configured to scale strictly on average CPU utilization, and run the Custom Protocol Engine on Cloud Run.

Deploy both services on Compute Engine Virtual Machines while purchasing 3-year Committed Use Discounts (CUDs) for all instances to cover peak capacity.

Show answer & explanation

Answer: Deploy the stateless Ingestion API on Cloud Run, and deploy the Custom Protocol Engine on Compute Engine Managed Instance Groups (MIGs).

Answer

Deploying the stateless Ingestion API on Cloud Run and the Custom Protocol Engine on Compute Engine Managed Instance Groups (MIGs) provides the optimal balance of scale-to-zero serverless efficiency and low-level OS configuration control.

The solution correctly assigns stateless HTTPS API workloads with bursty traffic patterns to Cloud Run (achieving zero operational overhead and automatic scaling to zero) while placing the custom protocol workload requiring OS kernel tuning on Compute Engine MIGs.

Step-by-Step Solution

Evaluate the Stateless Ingestion API requirements

Identified HTTPS payload handling, unpredictable bursty traffic, requirement to scale to zero, containerized packaging, and minimal management overhead.

Cloud Run is the recommended serverless compute platform on Google Cloud for stateless HTTP/HTTPS containerized services requiring automatic scale-to-zero functionality.

Evaluate the Custom Protocol Engine requirements

Identified persistent long-lived TCP socket connections and OS kernel-level tuning (`sysctl`).

Compute Engine Virtual Machines or MIGs provide full access to the underlying guest OS kernel parameters required for specialized network buffer tuning.

Combine compute platforms to optimize operational overhead and cost

Selected Cloud Run for the API ingestion layer and Compute Engine MIGs for the OS-customized protocol layer.

Decoupling workloads onto purpose-fit GCP compute platforms minimizes operational toil and prevents paying for unnecessary control planes or unused baseline instances.

Key Concept

Compute Platform Selection Strategy (Cloud Run vs Compute Engine MIGs vs GKE)

Estimated Time:2m 0s

Question 8Question →

A global online brokerage firm is designing its hybrid network topology to connect two primary on-premises data centers (located in Chicago and London) to Google Cloud. The architecture requires a sustained throughput of 15 Gbps per location with a 99.99% availability Service Level Agreement (SLA). Additionally, on-premises systems in Chicago must be able to reach GCP resources deployed in the Europe region (europe-west2) via the GCP backbone if the direct London link experiences a physical fiber disruption, without requiring custom overlay tunnels or virtual network appliances. Which network architecture should the Principal Cloud Architect recommend to meet these performance, redundancy, and routing requirements?

Provision two 10 Gbps Dedicated Interconnect connections at separate edge availability domains in both us-central1 and europe-west2, configure a single Shared VPC with Global Dynamic Routing enabled, and establish BGP sessions on Cloud Routers in both regions.

Deploy six HA VPN tunnels per region grouped with equal-cost multi-path (ECMP) routing to aggregate bandwidth to 18 Gbps, and configure Cloud Routers with Regional Dynamic Routing in separate VPC networks for us-central1 and europe-west2.

Establish Dedicated Interconnect connections in us-central1 and europe-west2 into separate standalone VPC networks for each region, and set up VPC Network Peering between the us-central1 VPC and europe-west2 VPC to route on-premises Chicago traffic across the peering connection.

Provision Dedicated Interconnect connections in us-central1 for 15 Gbps throughput, deploy HA VPN gateways in europe-west2 for cost optimization, and peer the two regional VPC networks together using custom route exchanges.

Show answer & explanation

Answer: Provision two 10 Gbps Dedicated Interconnect connections at separate edge availability domains in both us-central1 and europe-west2, configure a single Shared VPC with Global Dynamic Routing enabled, and establish BGP sessions on Cloud Routers in both regions.

Answer

Dedicated Interconnect is required for bandwidth exceeding 3 Gbps per tunnel and for achieving a 99.99% SLA using redundant circuits across two metropolitan edge availability domains per region. Utilizing a single Shared VPC (or global VPC) with Global Dynamic Routing enables BGP route propagation across regions over GCP's private fiber backbone, allowing traffic from the Chicago data center to reach europe-west2 resources if the local London connection drops, without hitting non-transitive VPC Peering limits.

Step-by-Step Solution

Evaluate hybrid connectivity bandwidth and SLA requirements.

Requirements specify 15 Gbps sustained throughput and 99.99% SLA. Dedicated Interconnect (using 10 Gbps or 100 Gbps circuits across two edge availability domains per region) is required, as Cloud VPN maxes out at 3 Gbps per tunnel.

HA VPN cannot meet the 15 Gbps SLA guarantee or single-pipe performance expectations for high-throughput enterprise connectivity.

Analyze cross-region failover and transitivity constraints.

On-premises systems in one site must reach GCP resources in another region via the GCP global network if local link fails.

VPC Network Peering does not support transitive routing (on-premises to VPC A to VPC B is prohibited). A unified Shared VPC (or VPC connected via Cloud Router with Global Dynamic Routing) must be used.

Select the proper dynamic routing scope.

Enable Global Dynamic Routing on the VPC network containing the Cloud Routers.

Global Dynamic Routing allows Cloud Routers in us-central1 to advertise routes learned via BGP in europe-west2 to the Chicago data center, allowing seamless failover across GCP's global backbone.

Key Concept

Hybrid Connectivity Selection & Global Dynamic Routing Transitivity

Question 9Question →

A global financial technology enterprise is designing a secure payment execution platform on Google Cloud. The architecture mandates provisioning a private Google Kubernetes Engine (GKE) cluster where worker nodes have no public IP addresses. Internal compliance requires that administrative cluster management using kubectl must strictly originate from a management VPC subnet connected via VPC Network Peering, with public access to the Kubernetes control plane completely disabled. Furthermore, containerized workloads running inside the cluster must securely consume Google Cloud API resources without embedding or downloading long-lived service account keys. Which set of provisioning actions should the cloud architect specify to fulfill these requirements while following Google Cloud best practices?

Provision a private GKE cluster with the control plane private endpoint enabled and public endpoint disabled, define Control Plane Authorized Networks to include the management VPC subnet CIDR, and configure Workload Identity to map Kubernetes Service Accounts to GCP Service Accounts with least-privilege IAM roles.

Provision a private GKE cluster with private nodes, disable Control Plane Authorized Networks to allow automatic transitive routing from the management VPC, and mount JSON service account keys as Kubernetes secrets for application pods.

Provision a standard GKE cluster with public endpoints restricted by Cloud Armor firewall rules, and grant the Service Account Admin role to the node service account so pods can dynamically acquire privileges.

Provision an unmanaged Compute Engine instance group behind an Internal HTTP(S) Load Balancer, manually install Kubernetes control plane components, and assign the primitive Editor IAM role to the default Compute Engine service account.

Show answer & explanation

Answer: Provision a private GKE cluster with the control plane private endpoint enabled and public endpoint disabled, define Control Plane Authorized Networks to include the management VPC subnet CIDR, and configure Workload Identity to map Kubernetes Service Accounts to GCP Service Accounts with least-privilege IAM roles.

Answer

The correct architecture requires creating a private GKE cluster with the private endpoint enabled and public endpoint disabled for complete isolation of the API server. Configuring Control Plane Authorized Networks with the management VPC CIDR permits authorized administration over VPC Network Peering. Employing Workload Identity enables pods to access GCP services using IAM service account mapping without needing static key files.

Step-by-Step Solution

Evaluate private GKE control plane endpoint requirements

Disabling the public endpoint requires accessing the Kubernetes API via its internal private endpoint IP within the master peering network.

Ensures zero exposure of the GKE API server to the public internet.

Configure Control Plane Authorized Networks for peered network access

Explicitly authorizing the CIDR range of the management VPC allows cluster management traffic from the peered network to pass to the private control plane endpoint.

GKE private master endpoints block external CIDRs by default unless explicitly permitted through Control Plane Authorized Networks.

Establish secure workload authentication to Google Cloud APIs

Workload Identity allows Kubernetes Service Accounts (KSAs) to impersonate Google Service Accounts (GSAs) seamlessly without long-lived keys.

Eliminates security risks associated with storing and rotating JSON service account keys in Kubernetes secrets.

Key Concept

Private GKE Cluster Provisioning, Authorized Networks, and Workload Identity

Question 10Question →

A global media streaming organization currently manages its core Google Cloud Virtual Private Cloud (VPC) subnets and Compute Engine template deployments using legacy Google Cloud Deployment Manager deployments. The enterprise platform team is executing a strategic migration to standardize all infrastructure automation on Terraform. The Cloud Architect must establish a state migration workflow that imports existing live resources into Terraform without destroying active workloads or causing configuration drift, while ensuring automated CI/CD execution complies with Google Cloud identity and state management security best practices. Which migration and operational workflow should the Cloud Architect recommend?

Export existing Deployment Manager manifests to local disk, configure a remote Terraform state backend using a Cloud Storage bucket, and grant the CI/CD pipeline service account the primitive Owner role (roles/owner) on the target project to ensure terraform import bypasses granular permission checks.

Define equivalent HCL resource declarations in Terraform, configure a remote Cloud Storage backend with object versioning and state locking enabled, authenticate the automated CI/CD pipeline using short-lived Service Account impersonation via Workload Identity Federation, and execute terraform import commands for existing resources.

Define equivalent HCL resource declarations, store state files locally within the CI/CD build worker directory using a Git commit hook to sync state back to Cloud Source Repositories, and execute gcloud deployment-manager deployments delete with the ABANDON flag prior to running terraform apply.

Grant the deployment service account the Service Account Admin role (roles/iam.serviceAccountAdmin) across the organization hierarchy, download static JSON service account keys into the CI/CD pipeline secrets, and execute terraform apply to recreate all managed resources from scratch.

Show answer & explanation

Answer: Define equivalent HCL resource declarations in Terraform, configure a remote Cloud Storage backend with object versioning and state locking enabled, authenticate the automated CI/CD pipeline using short-lived Service Account impersonation via Workload Identity Federation, and execute terraform import commands for existing resources.

Answer

The recommended approach combines remote state governance in Cloud Storage with state locking and object versioning, keyless pipeline authentication using Workload Identity Federation, and non-destructive state ingestion via terraform import. This ensures active live resources managed by Cloud Deployment Manager are seamlessly mapped into Terraform management without service downtime, while enforcing Google Cloud security standards.

Step-by-Step Solution

Configure Remote State Management

Establish a Cloud Storage backend configured with object versioning and state locking (via Cloud KMS or native GCS state lock support) to prevent state corruption and enable state history recovery.

Enterprise Terraform execution requires centralized, locked, and versioned state storage to allow concurrent pipeline executions safely.

Implement Keyless CI/CD Pipeline Authentication

Configure Workload Identity Federation to allow external CI/CD pipelines to impersonate dedicated deployment service accounts with fine-grained IAM roles without static JSON keys.

Eliminates security risks associated with managing and storing long-lived service account keys.

Import Legacy Deployment Manager Resources into Terraform State

Write corresponding HCL resource blocks matching existing cloud infrastructure parameters and execute `terraform import` targeting existing Google Cloud resource IDs.

Binds existing live infrastructure to the Terraform state file without destroying or redeploying running workloads, avoiding downtime.

Key Concept

Terraform Remote State Locking, Resource Import, and Workload Identity Impersonation

Estimated Time:2m 30s

Question 11Question →

A multinational e-commerce company plans to migrate its legacy product management system to Google Cloud. The environment includes an active 2 TB MySQL database requiring continuous replication with near-zero downtime cutover, along with $80\text{ TB}$ of static product image assets stored on an on-premises NAS network. The company already maintains an active 10 Gbps Dedicated Interconnect with Google Cloud with ample unutilized bandwidth. Which migration strategy should the Cloud Architect recommend to minimize cutover downtime and operational overhead?

Use Storage Transfer Service with on-premises agents to stream static media assets over the Dedicated Interconnect into Cloud Storage, and deploy Database Migration Service (DMS) with continuous Change Data Capture (CDC) to replicate the MySQL database to Cloud SQL.

Order a Google Cloud Transfer Appliance to physically ingest and ship the

80\text{ TB}

static image repository to Google Cloud, and use Database Migration Service (DMS) with continuous replication for the MySQL database.

Use Storage Transfer Service for static image files, but migrate the MySQL database to Cloud Spanner using custom export/import scripts during the cutover window to achieve higher scale.

Establish multiple high-availability Cloud VPN tunnels to isolate static file migration traffic from the primary network, and perform a dump and restore of the MySQL database using mysqldump during cutover.

Show answer & explanation

Answer: Use Storage Transfer Service with on-premises agents to stream static media assets over the Dedicated Interconnect into Cloud Storage, and deploy Database Migration Service (DMS) with continuous Change Data Capture (CDC) to replicate the MySQL database to Cloud SQL.

Answer

Use Storage Transfer Service with on-premises agents over Dedicated Interconnect for static media files, combined with Database Migration Service using continuous CDC for the MySQL database migration to Cloud SQL.

The combination of Storage Transfer Service for file ingestion and Database Migration Service (DMS) with continuous CDC for relational database replication provides an automated, managed migration path. Because an active 10 Gbps Dedicated Interconnect with spare capacity exists, online transfer of

80\text{ TB}

is optimal and avoids the delay of physical appliance shipping, while DMS ensures near-zero database downtime during cutover.

Step-by-Step Solution

Analyze data volume and network throughput capacity

80\text{ TB}

dataset over a 10 Gbps Dedicated Interconnect can easily be transferred online via network streaming within a few days, eliminating the need for offline physical appliance shipping.

Calculating network transfer capacity ensures online tools like Storage Transfer Service are prioritized when high-speed dedicated connectivity is active.

Evaluate database continuous replication requirements

Database Migration Service (DMS) supports native MySQL binlog-based Change Data Capture (CDC) to keep target Cloud SQL instances synchronized until final cutover.

Continuous CDC minimizes cutover downtime to just the time needed to switch application connection endpoints.

Select optimal managed GCP services

Combining Storage Transfer Service for unstructured files and Database Migration Service for transactional databases provides a fully managed, low-overhead migration architecture.

Using native GCP managed migration services minimizes operational overhead and custom script maintenance.

Key Concept

Combining Storage Transfer Service for online file transfer over Interconnect with Database Migration Service for low-downtime database cutover.

Question 12Question →

An enterprise media processing team is setting up an automated Deployment Manager pipeline to provision a fleet of Compute Engine instances managed by a regional Managed Instance Group (MIG). The deployment pipeline runs under a dedicated deployment service account `[email protected]`. The Compute Engine instances must run under a separate application runtime service account `[email protected]`. During the initial pipeline run, instance template creation fails with an IAM permission error when attempting to attach `app-runner` to the VM template. Which IAM configuration resolves the deployment failure while adhering to the principle of least privilege?

Grant the Service Account User role (roles/iam.serviceAccountUser) on the app-runner service account to the deploy-sa service account.

Grant the Service Account Admin role (roles/iam.serviceAccountAdmin) at the project level to the deploy-sa service account.

Grant the Owner primitive role (roles/owner) on the app-runner service account to the deploy-sa service account.

Submit a regional quota increase request for Compute Engine API service account attachments before executing the deployment pipeline.

Show answer & explanation

Answer: Grant the Service Account User role (roles/iam.serviceAccountUser) on the app-runner service account to the deploy-sa service account.

Answer

Granting the Service Account User role (`roles/iam.serviceAccountUser`) on the `app-runner` service account to the `deploy-sa` deployment service account allows the deployment pipeline to attach `app-runner` to Compute Engine instances under the principle of least privilege.

To attach a service account to a Compute Engine instance template or VM, the identity running the provisioning job must have the `iam.serviceAccounts.actAs` permission on the target service account. The predefined role `roles/iam.serviceAccountUser` grants this permission. Applying this role at the resource level on the target service account enforces least privilege.

Step-by-Step Solution

Identify the cause of the provisioning failure

The deployment pipeline service account (`deploy-sa`) requires permission to impersonate or bind the runtime service account (`app-runner`) to the compute resources being created.

Compute Engine instance creation requires the acting entity to possess authority to attach the target service account to the virtual machine.

Evaluate required IAM roles against the least privilege principle

The `roles/iam.serviceAccountUser` role grants permission to act on behalf of the service account without allowing administrative modifications to IAM policies or key management.

Predefined granular roles prevent over-provisioning security access during automated deployments.

Select resource-level binding target

Binding `roles/iam.serviceAccountUser` specifically on the `app-runner` resource (rather than project-wide) limits scope to only the intended runtime identity.

Resource-level IAM bindings restrict access exclusively to the specific identity needed by the deployment pipeline.

Key Concept

Compute Engine Service Account Impersonation and Attachment Permissions

Question 13Question →

A multinational pharmaceutical enterprise is designing a hybrid network topology to connect its primary on-premises genomic research laboratory with Google Cloud. The hybrid interconnect must support a continuous sustained throughput of 15 Gbps for genomic payload ingestion and mandate an uptime SLA of 99.99%. Furthermore, multiple application teams operating in distinct regional VPC networks must access on-premises databases through a central network architecture. Which networking solution fulfills the SLA, bandwidth, and transitive connectivity requirements while maintaining operational simplicity?

Provision two Dedicated Interconnect connections across two distinct Google Cloud edge availability domains (EADs) in a Shared VPC host project, configure Cloud Routers with global dynamic routing, and attach spoke service projects to the Shared VPC network.

Deploy six High Availability (HA) Cloud VPN tunnels across dual gateway pairs, configure Equal-Cost Multi-Path (ECMP) routing via Cloud Router in a central transit VPC, and connect regional spoke VPCs via standard VPC Network Peering.

Provision two 10 Gbps Dedicated Interconnect circuits attached to a central transit VPC, configure regional dynamic routing on Cloud Routers, and establish standard VPC Network Peering between the central transit VPC and all regional spoke VPCs.

Deploy a single 100 Gbps Dedicated Interconnect circuit in one edge availability domain, establish classic VPN tunnels from regional spoke VPCs to the central VPC, and enable static routing on the on-premises edge router.

Show answer & explanation

Answer: Provision two Dedicated Interconnect connections across two distinct Google Cloud edge availability domains (EADs) in a Shared VPC host project, configure Cloud Routers with global dynamic routing, and attach spoke service projects to the Shared VPC network.

Answer

The optimal architecture requires deploying redundant Dedicated Interconnect connections across two edge availability domains in a Shared VPC network with global dynamic routing configured on Cloud Routers.

Provisioning two Dedicated Interconnect circuits across distinct edge availability domains satisfies the 15 Gbps bandwidth requirement and the 99.99% availability SLA. Integrating Cloud Routers with global dynamic routing inside a Shared VPC host project allows regional service project workloads to natively access on-premises resources while respecting GCP network transitivity rules.

Step-by-Step Solution

Evaluate throughput and SLA requirements for hybrid connectivity.

Sustained 15 Gbps bandwidth exceeds the capacity of individual Cloud VPN tunnels (3 Gbps per tunnel), necessitating Dedicated Interconnect (10 Gbps or 100 Gbps circuits). A 99.99% SLA requires dual circuits across two edge availability domains (EADs).

HA VPN is unsuitable for high-throughput baseline traffic >10 Gbps, whereas Dedicated Interconnect meets enterprise SLA and bandwidth standards.

Evaluate cross-VPC topology and routing transit limits.

VPC Network Peering is strictly non-transitive in GCP. Spoke VPCs cannot route traffic to on-premises via an Interconnect attached to a central Peered Transit VPC.

To grant multiple regional workload teams access to the hybrid Interconnect without overlay overhead, Shared VPC must be used where spoke service projects directly share the host project's network resources.

Configure dynamic routing mode.

Global dynamic routing must be enabled on Cloud Routers so that routes learned from on-premises BGP sessions are propagated across all GCP regions in the Shared VPC network.

Regional dynamic routing limits route propagation to the region of the Cloud Router, failing multi-region access requirements.

Key Concept

Designing 99.99% SLA Hybrid Connectivity and Transitive Routing with Shared VPC

Question 14Question →

An enterprise financial organization is migrating mission-critical systems to Google Cloud. The solution requires a hybrid connectivity architecture between their primary on-premises data center and a multi-region Google Cloud VPC network. The design must satisfy three mandatory requirements:
1. Maintain a SLA-backed availability SLA of 99.99% for hybrid connectivity.
2. Ensure all data in transit across the hybrid connection is encrypted using IPsec.
3. Provide sustained aggregate encrypted throughput exceeding 20 Gbps.

How should the Principal Cloud Architect design and provision this hybrid connectivity architecture to satisfy all requirements?

Provision a 99.99% HA Dedicated Interconnect deployment across two distinct metropolitan locations with four total VLAN attachments, and configure HA VPN over Private IP across the interconnect attachments with multiple scaled IPsec tunnels.

Provision multiple multi-region HA VPN gateways operating directly over public internet connections with eight active IPsec tunnels managed by regional Cloud Routers.

Deploy a 99.99% HA Dedicated Interconnect topology terminating in a central Hub VPC, relying on VPC Network Peering to transit unencrypted on-premises traffic to multiple spoke VPCs.

Provision a 99.99% HA Partner Interconnect topology and configure VPC Service Controls perimeter policies on the interconnect subnets to handle layer 3 payload IPsec encryption.

Show answer & explanation

Answer: Provision a 99.99% HA Dedicated Interconnect deployment across two distinct metropolitan locations with four total VLAN attachments, and configure HA VPN over Private IP across the interconnect attachments with multiple scaled IPsec tunnels.

Answer

Deploy a 99.99% HA Dedicated Interconnect architecture across two metropolitan locations with four VLAN attachments, and establish HA VPN over Private IP across those attachments.

To achieve a 99.99% availability SLA on Google Cloud hybrid connectivity alongside IPsec transit encryption and >20 Gbps throughput, the architecture must combine 99.99% HA Dedicated Interconnect (4 VLAN attachments across 2 metros and 2 regions) with HA VPN over Private IP. This setup uses Dedicated Interconnect links to transport IPsec-encrypted private traffic while delivering high availability and deterministic performance.

Step-by-Step Solution

Analyze availability and SLA requirements

Determined that achieving a 99.99% SLA requires Dedicated Interconnect provisioned across two distinct edge availability domains (metropolitan locations) with at least 4 total VLAN attachments connected to Cloud Routers in two GCP regions.

Google Cloud guarantees 99.99% availability for Dedicated Interconnect only when deployed across dual metros and dual regions.

Evaluate bandwidth and transit encryption requirements

Identified HA VPN over Private IP (HA VPN over Cloud Interconnect) as the required architecture to combine IPsec encryption with high-capacity Dedicated Interconnect capacity.

Standard IPsec VPN over public internet cannot guarantee high-throughput SLAs, whereas HA VPN running over Private IP on Dedicated Interconnect provides encrypted transit at scale over dedicated links.

Validate BGP dynamic routing and tunnel scaling

Configured multiple HA VPN tunnels over the private IP attachments using Cloud Routers with dynamic BGP to scale past individual tunnel limits and achieve over 20 Gbps aggregate throughput.

Multiple private IP VPN tunnels load balanced with ECMP BGP routing deliver the necessary aggregate throughput while keeping all traffic encrypted.

Key Concept

HA VPN over Dedicated Interconnect (Private IP IPsec Encryption with 99.99% SLA Topology)

Question 15Question →

A smart energy grid company plans to migrate its legacy telemetry and management infrastructure to Google Cloud within a strict 4-week window. The environment consists of $800\text{ TB}$ of historical meter reading archives stored on an on-premises NFS storage system and an active $12\text{ TB}$ transactional PostgreSQL database. The organization has an existing dedicated $1\text{ Gbps}$ network connection to Google Cloud, which is currently heavily utilized by business-critical operations. The business requires minimal downtime for the transactional database during cutover and must complete the entire static file migration within the 4-week timeframe. Which data transfer and migration strategy should you recommend?

Order a Google Cloud Transfer Appliance to physically transport the

800\text{ TB}

of historical meter archives to Cloud Storage, and deploy Database Migration Service (DMS) with continuous Change Data Capture (CDC) over the existing network connection to replicate the PostgreSQL database prior to cutover.

Configure Storage Transfer Service with self-hosted transfer agents to stream the

800\text{ TB}

of historical archives directly over the

1\text{ Gbps}

network connection, and deploy Database Migration Service (DMS) for the PostgreSQL database.

Order a Google Cloud Transfer Appliance for the

800\text{ TB}

historical archives, and migrate the PostgreSQL database by exporting full database dumps to Cloud Storage and loading them into Cloud Spanner during the cutover window.

Establish multiple high-throughput Cloud VPN tunnels in parallel to transfer the

800\text{ TB}

static archives to Cloud Storage, and perform a manual database backup and restore procedure to Cloud SQL during cutover.

Show answer & explanation

Answer: Order a Google Cloud Transfer Appliance to physically transport the $800\text{ TB}$ of historical meter archives to Cloud Storage, and deploy Database Migration Service (DMS) with continuous Change Data Capture (CDC) over the existing network connection to replicate the PostgreSQL database prior to cutover.

Answer

Order a Google Cloud Transfer Appliance for the

800\text{ TB}

static archives and use Database Migration Service (DMS) with CDC for the PostgreSQL database.

The correct strategy combines Google Cloud Transfer Appliance for offline transfer of the

800\text{ TB}

historical archives and Database Migration Service (DMS) with continuous Change Data Capture (CDC) for the

12\text{ TB}

PostgreSQL database. Network calculations show that transferring

800\text{ TB}

over a

1\text{ Gbps}

link requires over 74 days, making online streaming impossible within the 4-week window. Transfer Appliance avoids network congestion and completes the bulk load on time. Meanwhile, DMS with CDC handles continuous database replication in the background, allowing a near-zero downtime cutover.

Step-by-Step Solution

Calculate network bandwidth capacity for static data transfer

Streaming

800\text{ TB}

over

1\text{ Gbps}

takes

\frac{800 \times 10^{12} \times 8}{10^9} \approx 6.4 \times 10^6\text{ seconds} \approx 74\text{ days}

, exceeding the 4-week (28-day) constraint.

Large multi-hundred terabyte or petabyte dataset transfers over low or shared bandwidth links must use offline physical appliances to meet time limits.

Select the appropriate offline data transfer method

Google Cloud Transfer Appliance enables shipping

800\text{ TB}

of data securely within a few days without using network bandwidth.

Transfer Appliance bypasses network constraints and protects production traffic on the existing

1\text{ Gbps}

link.

Select the database migration pattern for minimal downtime

Database Migration Service (DMS) uses Change Data Capture (CDC) to perform an initial backfill followed by real-time continuous sync.

Continuous replication allows the application to stay online until a very quick final cutover phase.

Key Concept

Selecting data transfer appliances vs. online transfer services based on bandwidth calculations and choosing CDC-based database migration tools for minimal downtime cutovers.

Question 16Question →

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 17Question →

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 18Question →

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 19Question →

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 20Question →

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)

Page 1 / 41Next

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