All practice questions

1598 questions

All types1,598 Multiple choice815 Multiple select537 Numeric8 Matching64 Ordering174

When configuring Terraform to use a Google Cloud Storage bucket as a secure remote backend for team collaboration, in what sequence should you execute the provisioning and configuration workflow?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order begins with creating the GCS bucket with Object Versioning, followed by writing the backend 'gcs' configuration block in Terraform, then running 'terraform init' to migrate state, and finally running 'terraform plan' to verify state locking and plan execution against the remote backend.

Establishing a remote Terraform state backend requires the storage infrastructure to exist first (GCS bucket creation with Object Versioning), declaring the storage destination inside the Terraform configuration, initializing the directory with 'terraform init' to establish remote state locking, and executing 'terraform plan' to verify operational readiness.

Step-by-Step Solution

Provision GCS Storage Bucket

A secure GCS bucket is available in GCP with Object Versioning enabled to prevent state corruption.

Terraform cannot store state in a GCS bucket that does not yet exist.

Declare Backend Configuration

The terraform block specifies backend 'gcs' with the target bucket and prefix.

Terraform requires code configuration to know where the state file should be stored remotely.

Initialize Terraform Backend

Terraform downloads the GCS provider plugin and migrates local state to the remote GCS bucket.

The initialization command establishes the remote backend connection.

Validate State Execution Plan

Terraform acquires a state lock on the GCS bucket and checks proposed changes against remote state.

Running plan confirms that remote state locking and reading work seamlessly.

Key Concept

Terraform GCS Remote Backend Provisioning Workflow

Question 382Question →

A media broadcasting company needs to migrate $450\text{ TB}$ of static video archives from an on-premises data center to a Cloud Storage bucket in Google Cloud. The company has a single dedicated $1\text{ Gbps}$ internet connection, and the migration must be completed within $3$ days due to a data center facility closure. Which data transfer strategy should the Cloud Architect recommend?

Order a Google Cloud Transfer Appliance, ingest the video data locally, and ship the device to Google for upload into Cloud Storage.

Configure Storage Transfer Service to transfer the video archives directly to Cloud Storage over the existing 1 Gbps internet connection.

Establish an HA VPN tunnel over the internet link to stream the files directly into Cloud Storage using parallel gsutil threads.

Import the static video files into Cloud Spanner tables to enable high-throughput parallel database loading over the network.

Show answer & explanation

Answer: Order a Google Cloud Transfer Appliance, ingest the video data locally, and ship the device to Google for upload into Cloud Storage.

Answer

Order a Google Cloud Transfer Appliance, ingest the video data locally, and ship the device to Google for upload into Cloud Storage.

Transferring

450\text{ TB}

over a

1\text{ Gbps}

network connection takes approximately 41.6 days under ideal conditions (

450,000\text{ GB} \times 8\text{ bits} / 1\text{ Gbps} = 3,600,000\text{ seconds}

). Because the deadline is 3 days, online transfer methods are physically impossible. Ordering a physical Transfer Appliance allows rapid local copying over high-speed local network interfaces and shipping the hardware directly to Google for ingestion into Cloud Storage.

Step-by-Step Solution

Calculate required network transfer time for 450 TB over 1 Gbps

Total bits =

450 \times 10^{12} \times 8 = 3.6 \times 10^{15}\text{ bits}

. At

1\text{ Gbps}

(

10^9\text{ bits/sec}

), duration =

3.6 \times 10^6\text{ seconds} \approx 41.6\text{ days}

Evaluating online transfer feasibility against the 3-day deadline constraint.

Compare network transfer time to business window

Online transfer (41.6 days) vastly exceeds the required 3-day timeframe.

Determines that an offline physical transfer method is necessary.

Select appropriate GCP data transfer service

Google Cloud Transfer Appliance provides high-capacity local ingestion and physical shipment to Google Cloud.

Transfer Appliance is designed specifically for multi-hundred terabyte datasets when network bandwidth is insufficient.

Key Concept

Offline Data Transfer using Transfer Appliance for Large Datasets under Bandwidth and Time Constraints

Estimated Time:1m 0s

Question 383Question →

A digital media enterprise is redesigning its cloud media processing architecture on Google Cloud to handle two distinct application workloads:

1. Ingestion Webhook Service: A stateless microservice handling high-burst HTTP/2 traffic from global content providers. It requires rapid scaling to zero, zero infrastructure management overhead, and low per-request processing latency.
2. Video Transcoding Engine: A legacy batch rendering application that requires custom Linux kernel parameters (`sysctl`), proprietary C++ libraries, specialized NVIDIA GPU driver installations, and direct POSIX filesystem mounts for block storage.

Which TWO platform architectural choices should the Lead Cloud Architect recommend to satisfy the technical requirements while optimizing for cost efficiency and operational overhead?

Select all that apply

Deploy the stateless Ingestion Webhook Service on Cloud Run to leverage serverless automatic scaling and eliminate cluster control plane management.

Deploy the Video Transcoding Engine on Compute Engine Managed Instance Groups (MIGs) using custom VM disk images configured with the required kernel modifications and GPU drivers.

Deploy the stateless Ingestion Webhook Service on a dedicated Google Kubernetes Engine (GKE) Enterprise cluster to ensure maximum infrastructure control and custom ingress routing.

Deploy the Video Transcoding Engine on Cloud Run jobs mounted to Cloud Storage buckets using FUSE to execute the custom kernel configurations and GPU driver modules.

Configure the Video Transcoding Engine compute instances to autoscale exclusively based on CPU utilization and purchase 3-year Committed Use Discounts (CUDs) for peak capacity.

Show answer & explanation

Answer: Deploy the stateless Ingestion Webhook Service on Cloud Run to leverage serverless automatic scaling and eliminate cluster control plane management.; Deploy the Video Transcoding Engine on Compute Engine Managed Instance Groups (MIGs) using custom VM disk images configured with the required kernel modifications and GPU drivers.

Answer

The optimal architectural strategy is to deploy the stateless Ingestion Webhook Service on Cloud Run and deploy the specialized Video Transcoding Engine on Compute Engine Managed Instance Groups (MIGs) using custom VM images.

Cloud Run is the optimal target for stateless HTTP microservices that require rapid scaling to zero and minimal operational maintenance. Compute Engine MIGs with custom images provide the required OS-level flexibility for custom kernel tuning (`sysctl`), specialized GPU driver installations, and direct POSIX block storage attachments.

Step-by-Step Solution

Evaluate the Ingestion Webhook Service requirements.

The service is stateless, uses HTTP/2, experiences bursty traffic, and mandates zero operational management.

Cloud Run provides fully managed serverless container execution that scales to zero and eliminates infrastructure node maintenance.

Evaluate the Video Transcoding Engine requirements.

The application requires custom sysctl kernel settings, specialized GPU drivers, custom binaries, and POSIX filesystem access.

Fully managed serverless platforms restrict host kernel modifications and custom driver installations, making Compute Engine MIGs with custom images the appropriate platform choice.

Identify misallocations in distractor options.

GKE introduces unnecessary cluster lifecycle overhead for simple HTTP microservices, while Cloud Run cannot support host-level kernel driver modifications.

Selecting the right GCP compute service requires balancing operational control against management burden based on workload statefulness and OS-level dependencies.

Key Concept

Selecting GCP Compute Platforms Based on Kernel Customization, Statefulness, and Operational Overhead

Question 384Question →

A global retail supply-chain enterprise is designing its hybrid connectivity architecture to connect diverse operational sites to Google Cloud. Match each business unit's network and SLA requirement to the optimal Google Cloud hybrid networking solution.

Click a left item, then click its matching right item

Show answer & explanation

Answer

The primary distribution hubs match Dual Dedicated Interconnect across distinct metro facilities; remote micro-warehouses match HA VPN with dynamic BGP routing; third-party vendor networks match Private Service Connect; legacy data centers without colocation match Partner Interconnect through a service provider.

Each requirement aligns precisely with official GCP hybrid connectivity design guidelines: Dedicated Interconnect provides physical high-capacity links; HA VPN provides cost-effective encrypted tunnels over public IP; Private Service Connect delivers unidirectional service-level access without VPC peering or subnet overlap; and Partner Interconnect connects sites via service provider networks where direct Google colocation does not exist.

Step-by-Step Solution

Analyze high-bandwidth and SLA requirements for primary regional distribution hubs.

Requirements exceed 10 Gbps with 99.99% SLA, ruling out Cloud VPN. Dedicated Interconnect across two distinct metro facilities is required for 99.99% availability.

Dedicated Interconnect offers physical 10 Gbps/100 Gbps links directly to Google edge facilities, achieving 99.99% SLA only when dual-hosted in separate metros.

Evaluate encrypted broadband connectivity for low-bandwidth remote fulfillment sites.

HA VPN with active-active tunnels and Cloud Router dynamic BGP routing is chosen.

HA VPN provides 99.99% SLA over public internet connections with native IPsec encryption suitable for low-throughput remote locations.

Identify isolated service exposure mechanism for third-party networks with potential overlapping CIDRs.

Private Service Connect (PSC) is selected.

PSC exposes specific internal load balancers using NAT endpoint IPs in consumer VPCs without peering entire networks or causing IP address collision.

Determine private connection method for facilities lacking direct Google edge colocation presence.

Partner Interconnect with service provider VLAN attachments is chosen.

Partner Interconnect bridges facilities to GCP via supported carrier networks when direct physical colocation with Google is unavailable.

Key Concept

Selecting GCP Hybrid Connectivity Solutions Based on Bandwidth, Encryption, SLA, and Location Constraints

Question 385Question →

A specialized genomics enterprise is provisioning core infrastructure in Google Cloud to run large-scale DNA sequencing batch operations alongside a containerized administrative management plane. The target architecture specifies a private Google Kubernetes Engine (GKE) cluster for control services and a Compute Engine Managed Instance Group (MIG) configured with Spot VMs to handle high-volume compute tasks. During automated deployment, the pipeline fails to provision the intended 500 N2 Spot VMs in us-central1 due to immediate quota constraints. Simultaneously, security auditors notice that internal bioinformaticians cannot connect to the private GKE cluster control plane via `kubectl` from their corporate VPN subnet. Which combination of provisioning and security modifications correctly resolves both the compute deployment failure and the administrative connectivity issue?

Submit a regional quota increase request for Spot N2 CPU cores in us-central1 prior to deployment, and add the corporate VPN egress CIDR range to the GKE Control Plane Authorized Networks configuration.

Migrate the entire batch workload onto the private GKE cluster using an Autopilot node pool, assuming GKE Autopilot automatically bypasses GCP project resource quotas and enables master endpoint access globally by default.

Grant the bioinformaticians the Service Account User role (roles/iam.serviceAccountUser) on the cluster service account to bypass private master network restrictions, and configure the MIG to dynamically override regional quotas.

Assign the primitive Owner role to all internal bioinformaticians to grant administrative master endpoint privileges, and update the Terraform state file manually to force resource creation despite active quota limits.

Show answer & explanation

Answer: Submit a regional quota increase request for Spot N2 CPU cores in us-central1 prior to deployment, and add the corporate VPN egress CIDR range to the GKE Control Plane Authorized Networks configuration.

Answer

Provisioning high-capacity compute workloads (such as 500 Spot VMs) requires verifying and requesting regional quota increases in advance. For private GKE clusters, master endpoint administration is restricted by default and requires explicit IP ranges to be configured under Control Plane Authorized Networks so authorized corporate VPN subnets can access the cluster control plane.

Step-by-Step Solution

Analyze the Compute Engine MIG provisioning failure

Identify that launching 500 N2 Spot VMs requires sufficient preemptible/Spot CPU core quota in the target region (us-central1).

Large-scale node provisioning fails immediately if the requested capacity exceeds the GCP project regional quota.

Identify the proper remediation for GCP resource quotas

Submit a quota increase request in advance for Spot N2 CPUs in us-central1.

Quota adjustments must be requested and approved prior to automated IaC executions to prevent resource allocation errors.

Analyze the GKE master endpoint connectivity issue

Recognize that private GKE clusters block access to the control plane endpoint unless explicit IP ranges are permitted.

Private GKE control planes require Control Plane Authorized Networks to allow specific source CIDRs (such as corporate VPN egress IPs) to reach the master endpoint.

Key Concept

Provisioning Compute Engine MIGs and Securing Private GKE Clusters

Question 386Question →

A healthcare technology company is building a cloud application on Google Cloud that comprises two distinct service workloads:

1. A stateless HTTP REST API microservice that receives unpredictable web traffic, requiring rapid scaling and the ability to scale down to zero when idle.
2. A specialized data stream processing agent that requires installing custom Linux host kernel modules for hardware acceleration.

Which of the following compute platform decisions should the Cloud Architect recommend to meet these requirements with optimal operational efficiency and minimal cost? (Select TWO choices.)

Select all that apply

Deploy the stateless HTTP REST API microservice on Cloud Run to achieve automatic scaling to zero and eliminate infrastructure management overhead.

Deploy the specialized data stream processing agent on Compute Engine Virtual Machines using a custom OS image to support custom Linux kernel module installation.

Deploy the stateless HTTP REST API microservice on a GKE Autopilot cluster to run containerized microservices with zero underlying node management.

Deploy the specialized data stream processing agent on Cloud Run by passing custom host kernel parameters inside the container deployment manifest.

Purchase 3-year Committed Use Discounts (CUDs) for the stateless HTTP microservice baseline compute resources prior to deployment.

Show answer & explanation

Answer: Deploy the stateless HTTP REST API microservice on Cloud Run to achieve automatic scaling to zero and eliminate infrastructure management overhead.; Deploy the specialized data stream processing agent on Compute Engine Virtual Machines using a custom OS image to support custom Linux kernel module installation.

Answer

The optimal architectural design requires deploying the stateless HTTP REST service on Cloud Run (for automatic scale-to-zero capability and minimal operational overhead) and deploying the kernel-dependent processing agent on Compute Engine Virtual Machines (to allow host OS kernel module installation).

Cloud Run is the recommended platform for stateless HTTP services with unpredictable traffic because it scales down to zero instances when idle, minimizing compute cost while removing cluster provisioning overhead. Compute Engine virtual machines are necessary for workloads requiring host-level modifications, such as loading custom Linux kernel modules, because managed container platforms enforce sandbox isolation that prevents direct host kernel modification.

Step-by-Step Solution

Analyze the requirements for the stateless HTTP microservice

Select Cloud Run because it natively supports containerized stateless HTTP APIs, scales automatically from zero to meet demand spikes, and incurs zero cost when idle.

Fully managed serverless container execution eliminates cluster management overhead for simple stateless web endpoints.

Analyze the requirements for the custom kernel driver workload

Select Compute Engine VMs with custom images because low-level kernel drivers require direct host operating system access.

Managed serverless container platforms restrict host kernel access and do not permit loading custom kernel modules.

Key Concept

Selecting GCP Compute Platforms based on workload statefulness, operational overhead, autoscaling behavior, and OS-level customization needs

Question 387Question →

A system administrator needs to securely provision a private Google Kubernetes Engine (GKE) cluster for an internal enterprise application. The cluster control plane must be accessible only from designated administrative jump-hosts, and deployment scripts must follow the principle of least privilege. Which TWO configuration steps should you take?

Select all that apply

Enable Control Plane Authorized Networks on the GKE cluster and specify the IP address ranges of the administrative jump-hosts.

Grant the Service Account User role (roles/iam.serviceAccountUser) to the deployment service account so it can attach runtime service accounts to node pools.

Leave the cluster control plane publicly accessible without restrictions to simplify remote management.

Assign the Project Owner primitive role (roles/owner) to the deployment service account to prevent permission errors.

Grant the Service Account Admin role (roles/iam.serviceAccountAdmin) to the GKE worker nodes.

Show answer & explanation

Answer: Enable Control Plane Authorized Networks on the GKE cluster and specify the IP address ranges of the administrative jump-hosts.; Grant the Service Account User role (roles/iam.serviceAccountUser) to the deployment service account so it can attach runtime service accounts to node pools.

Answer

The correct configuration steps are enabling Control Plane Authorized Networks with designated administrative IP ranges and granting the Service Account User role to the deployment service account.

Securing a private GKE cluster requires enforcing Control Plane Authorized Networks to limit master endpoint access exclusively to designated management IP ranges. In addition, applying the Service Account User role to the deployment identity grants only the necessary permission to assign runtime service accounts to worker nodes without exposing administrative IAM capabilities.

Step-by-Step Solution

Restrict control plane network access

Control plane master endpoint only accepts requests from designated administrative subnets

Control Plane Authorized Networks blocks unauthorized external access to the Kubernetes master API.

Assign minimal necessary IAM permissions for identity binding

Deployment service account can assign service accounts to cluster instances without administrative over-privilege

The Service Account User role provides the exact privilege required to impersonate or attach a service account to a compute workload.

Key Concept

Provisioning secure private GKE clusters using Control Plane Authorized Networks and least-privilege IAM service account roles.

Question 388Question →

A enterprise security team is provisioning a private Google Kubernetes Engine (GKE) cluster to host sensitive online payment processing services. The architectural requirements specify that the cluster control plane must only accept administrative traffic from a designated corporate management subnet, and pods running inside the cluster must access Cloud Storage buckets without mounting long-lived service account key files. Which of the following configuration choices should the cloud architect implement during cluster provisioning? (Select TWO.)

Select all that apply

Enable Control Plane Authorized Networks on the cluster and restrict access to the CIDR block of the corporate management subnet.

Enable Workload Identity on the GKE cluster and bind Kubernetes service accounts to dedicated Google Cloud service accounts.

Grant the Service Account Admin role (roles/iam.serviceAccountAdmin) to the Compute Engine default service account assigned to cluster worker nodes.

Store the deployment pipeline's Terraform state file on an unencrypted local disk of the provisioning workstation to accelerate apply execution.

Assign the primitive Owner role to the cluster's worker node service accounts to simplify Cloud Storage bucket authorization.

Show answer & explanation

Answer: Enable Control Plane Authorized Networks on the cluster and restrict access to the CIDR block of the corporate management subnet.; Enable Workload Identity on the GKE cluster and bind Kubernetes service accounts to dedicated Google Cloud service accounts.

Answer

The correct configurations are to enable Control Plane Authorized Networks specifying the corporate management subnet CIDR, and to enable Workload Identity to map Kubernetes service accounts to Google Cloud service accounts.

Configuring Control Plane Authorized Networks ensures that the GKE master API server accepts administrative requests strictly from approved internal IP ranges. Combining this with Workload Identity allows pod workloads to authenticate natively to GCP services like Cloud Storage using temporary, auto-rotated tokens under least privilege rules.

Step-by-Step Solution

Determine the control plane endpoint security configuration.

Enable Control Plane Authorized Networks with the management subnet CIDR range.

Private GKE cluster control planes require authorized network rules to block administrative API access from untrusted subnets and public endpoints.

Select the secure credential mechanism for application pod authentication.

Configure Workload Identity mapping between Kubernetes and GCP service accounts.

Workload Identity provides secure, short-lived IAM token exchange without storing long-lived service account key files within container file systems.

Key Concept

Provisioning secure private GKE clusters using Control Plane Authorized Networks and Workload Identity.

Estimated Time:2m 0s

Question 389Question →

A cloud administrator provisions a private Google Kubernetes Engine (GKE) cluster for an internal enterprise application. After establishing an active VPN connection to the VPC, the administrator attempts to manage the cluster using `kubectl` from an on-premises management workstation, but connection attempts to the cluster master endpoint time out. Which configuration issue is the cause of this connection failure?

The control plane authorized networks feature is enabled on the cluster, but the on-premises workstation subnet was omitted from the allowed IP ranges.

The service account attached to the GKE cluster node pool was not granted the primitive Owner role on the Google Cloud project.

The Infrastructure as Code pipeline stored the Terraform state file in an unversioned local directory instead of a Cloud Storage backend.

The project exceeded its regional Compute Engine CPU quota when auto-repairing node instances.

Show answer & explanation

Answer: The control plane authorized networks feature is enabled on the cluster, but the on-premises workstation subnet was omitted from the allowed IP ranges.

Answer

The control plane authorized networks feature is enabled on the cluster, but the on-premises workstation subnet was omitted from the allowed IP ranges.

In Google Kubernetes Engine (GKE), private clusters allow restricting access to the control plane endpoint via Control Plane Authorized Networks. When this feature is active, traffic from IP addresses outside specified CIDR blocks is blocked by default, causing client connections via `kubectl` to time out even if underlying VPC/VPN routing is functional.

Step-by-Step Solution

Identify the resource component and symptoms described in the scenario.

The user is attempting to reach a private GKE cluster control plane over VPN via kubectl, but experiencing connection timeouts.

Private GKE control plane endpoints enforce explicit network security controls beyond standard VPC routing.

Evaluate GKE control plane security settings.

Control Plane Authorized Networks acts as an IP firewall for the GKE master endpoint.

If authorized networks are enabled, any source IP outside the configured CIDR blocks is dropped at the control plane proxy layer.

Determine the necessary remediation.

Add the management workstation CIDR block to the control plane authorized networks list.

This allows master endpoint access while keeping unauthorized VPC traffic restricted.

Key Concept

GKE Private Cluster Control Plane Authorized Networks

Question 390Question →

A financial quantitative trading firm is designing a web microservice on Google Cloud to handle real-time HTTP REST market data validation. The workload is completely stateless, packaged into standard Docker container images, and experiences extreme traffic fluctuations—scaling down to zero traffic outside of trading hours and bursting to thousands of HTTP requests per second during peak market volatility. The development team has no dedicated infrastructure management capacity and requires a compute execution environment with minimal operational overhead and zero cost during idle periods. Which Google Cloud compute platform should you recommend?

Deploy the containerized service directly to Cloud Run.

Deploy the service workloads onto a Google Kubernetes Engine (GKE) Autopilot cluster.

Deploy the container workloads onto a Compute Engine Managed Instance Group (MIG) configured with CPU-based autoscaling.

Deploy the container workloads onto Compute Engine Sole-Tenant Nodes with automated instance scaling.

Show answer & explanation

Answer: Deploy the containerized service directly to Cloud Run.

Answer

Deploy the containerized service directly to Cloud Run.

Cloud Run is the optimal platform choice because it is a fully managed serverless container environment designed specifically for stateless HTTP workloads. It automatically scales instances down to zero when there is no traffic (eliminating idle infrastructure costs) and rapidly scales up to handle heavy demand spikes, all while removing the operational burden of infrastructure provisioning, OS patching, and cluster management.

Step-by-Step Solution

Analyze the technical requirements of the microservice.

Identified key constraints: stateless HTTP REST protocol, standard container packaging, extreme burst traffic, scale-to-zero requirement (zero idle cost), and minimal operational management capacity.

Matching workload operational patterns to cloud platform capabilities is essential for optimal cloud architecture.

Evaluate compute execution environments on Google Cloud based on operational overhead and autoscaling.

Cloud Run natively supports containerized stateless HTTP applications, automatically scales down to zero instances when unutilized, scales up instantly on request demand, and requires no cluster or node management.

Cloud Run fulfills all serverless requirements with the lowest possible management burden.

Eliminate alternative platform options based on cost and overhead requirements.

GKE introduces Kubernetes abstraction overhead; Compute Engine MIGs incur OS patching and scaling latency; Sole-Tenant Nodes incur fixed hardware baseline costs.

Alternative compute services fail either the scale-to-zero financial requirement or the minimal operational overhead constraint.

Key Concept

Selecting serverless compute platforms (Cloud Run) vs. container orchestration (GKE) or IaaS (Compute Engine) based on statelessness, scale-to-zero capabilities, and operational maintenance overhead.

Question 391Question →

An enterprise architecture team is designing a database migration strategy to move an active, mission-critical PostgreSQL database from an on-premises data center to Cloud SQL for PostgreSQL with minimal downtime. Arrange the operational steps in the correct execution sequence from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for a minimal-downtime database migration starts with network and target schema provisioning, followed by the initial bulk historical data load, enabling continuous Change Data Capture (CDC) replication, and concluding with a cutover window where source writes are paused, zero lag is verified, and traffic is re-routed.

A standard minimal-downtime database migration follows a structured lifecycle: establishing connectivity and target schema infrastructure first, carrying out an initial bulk snapshot export/import, initiating continuous CDC stream replication to catch up and maintain sync, and finally performing cutover by stopping source writes, draining replication queues to zero lag, and re-pointing application endpoints.

Step-by-Step Solution

Provision network connectivity and target database structure

Cloud Interconnect connects environments and Cloud SQL is initialized with the required schema.

Data transfer targets must be securely accessible and schema-ready before ingesting data.

Perform initial bulk baseline data load

Existing bulk records are transferred to establish a baseline snapshot in the target database.

CDC stream synchronization requires a base state snapshot to apply transaction deltas against.

Initiate continuous transaction log replication (CDC)

Live changes made to the source database stream continuously to the target database.

Continuous sync minimizes data lag during ongoing production operations prior to cutover.

Execute final cutover during maintenance window

Source writes are stopped, remaining replication log items apply, and applications connect to Cloud SQL.

Ensures zero data loss and data consistency across application clients during final cutover.

Key Concept

Minimal-Downtime Database Migration Pipeline Staging

Estimated Time:2m 0s

Question 392Question →

A Site Reliability Engineering (SRE) team needs to set up real-time operational alerting for high rates of HTTP 5xx application errors captured in Cloud Logging. What is the correct chronological sequence of steps to configure a log-based metric and activate an automated alerting policy in Google Cloud?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: first construct a log filter in Cloud Logging, second create a custom log-based counter metric from the filtered logs, third create an Alerting Policy in Cloud Monitoring referencing the custom metric, and fourth configure the condition threshold and attach the notification channel.

To create operational alerts based on log patterns in Google Cloud, you must first isolate the relevant log messages using a log filter in Cloud Logging. Next, convert those filtered log entries into a numeric metric by creating a log-based counter metric. Once the metric is registered, navigate to Cloud Monitoring to create an Alerting Policy that selects this metric as its target. Finally, define the numerical threshold condition and attach the target notification channel to enable automated alerting.

Step-by-Step Solution

Construct a log filter in Cloud Logging.

HTTP 5xx application log events are accurately targeted and isolated from surrounding log streams.

Filters define the precise log criteria required to calculate operational metric counts.

Create a custom log-based counter metric.

Matching log occurrences are exposed as a numeric time-series metric to Cloud Monitoring.

Cloud Monitoring alerting policies operate on numerical metric time-series data rather than raw text logs.

Create an Alerting Policy referencing the log-based metric.

An alerting policy shell is bound to the new custom log metric resource.

The metric time-series must exist in Cloud Monitoring prior to selecting it within an alerting policy.

Specify threshold conditions and attach notification channels.

The alerting policy is fully configured and ready to trigger alerts upon threshold breaches.

Conditions define when an incident triggers, while notification channels dictate where alert notifications are routed.

Key Concept

Configuring custom log-based metrics and binding them to operational alerting policies in Google Cloud Observability.

Question 393Question →

A biopharmaceutical research organization is modernizing its genomic sequence processing platform on Google Cloud. The platform consists of two distinct workloads:

1. Stateless API Gateway: A lightweight HTTP webhook service that receives small metadata payloads from laboratory sequencers and enqueues jobs. Traffic is highly unpredictable, experiencing intense bursts followed by extended idle periods (down to zero requests) during non-business hours. The organization demands zero management overhead for server administration.

2. Bio-Analytics Pipeline: A high-performance computation engine executing long-duration batch workloads (up to 18 hours per execution). This engine relies on legacy C++ binaries compiled with specialized Linux kernel patches and requires mounting a POSIX shared memory file system (`/dev/shm`) allocated at 128 GB.

Which TWO compute platform architectural choices should you implement to satisfy the technical requirements while minimizing operational cost and management overhead? (Select TWO.)

Select all that apply

Deploy the Stateless API Gateway on Cloud Run, configuring minimum instances to zero and allowing HTTP traffic to scale dynamically based on request volume.

Deploy the Stateless API Gateway on a dedicated Google Kubernetes Engine (GKE) Autopilot cluster configured with a fixed minimum node count to prevent cold starts during idle periods.

Deploy the Bio-Analytics Pipeline as Cloud Run Jobs, setting container memory limits to 128 GB and configuring job execution timeout to 24 hours.

Deploy the Bio-Analytics Pipeline on Compute Engine Managed Instance Groups (MIGs) using custom VM images pre-loaded with the modified Linux kernel.

Purchase 3-year Committed Use Discounts (CUDs) covering the peak auto-scaled instance capacity for the Stateless API Gateway.

Show answer & explanation

Answer: Deploy the Stateless API Gateway on Cloud Run, configuring minimum instances to zero and allowing HTTP traffic to scale dynamically based on request volume.; Deploy the Bio-Analytics Pipeline on Compute Engine Managed Instance Groups (MIGs) using custom VM images pre-loaded with the modified Linux kernel.

Answer

The optimal architecture requires deploying the Stateless API Gateway on Cloud Run (scaling to zero to eliminate idle operational costs and administration overhead) and hosting the Bio-Analytics Pipeline on Compute Engine Managed Instance Groups (MIGs) using custom VM images to support specialized Linux kernel modifications and large POSIX shared memory allocations.

The correct architectural choices combine Cloud Run for the stateless web service and Compute Engine for the kernel-dependent analytics engine. Cloud Run provides a serverless execution environment that automatically scales down to zero when idle, eliminating management overhead and baseline costs for the webhook API. Compute Engine VMs allow custom OS images with specialized Linux kernel patches and configurable system memory layout (`/dev/shm`), satisfying the strict low-level system requirements of the C++ bio-analytics pipeline.

Step-by-Step Solution

Evaluate the Stateless API Gateway requirements

The service is stateless, handles HTTP webhooks, has unpredictable bursty traffic with periods of zero volume, and requires zero administration overhead.

Cloud Run is the optimal compute platform for stateless HTTP services with scale-to-zero capabilities and fully managed serverless infrastructure.

Evaluate the Bio-Analytics Pipeline requirements

The workload requires custom Linux kernel patches, long execution times (18 hours), and a 128 GB POSIX shared memory mount (`/dev/shm`).

Serverless container platforms (such as Cloud Run or Cloud Run Jobs) run on standardized managed kernels that do not permit low-level host kernel customization. Compute Engine VMs provide full root access and OS kernel customization capabilities.

Assess cost optimization and distractor trade-offs

GKE Autopilot adds baseline management overhead for simple microservices; CUDs covering peak capacity for bursty workloads lead to over-provisioning spend; container platforms cannot host custom kernel patches.

Matching workload operational characteristics to platform capabilities ensures architectural compliance with Google Cloud best practices.

Key Concept

Compute Platform Selection Strategy (Cloud Run vs. Compute Engine)

Question 394Question →

An operations engineering team needs to set up automated alerting for unexpected HTTP 500 application error rates occurring in a Cloud Run service. The team wants to track these errors using a custom log-based metric and send real-time alerts to a dedicated Webhook notification channel. What is the correct sequence of steps to configure this logging, metric, and alerting pipeline?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The operational pipeline must be built logically from metric creation to alert delivery: first, create the custom log-based counter metric in Cloud Logging filtering for HTTP 500 logs; second, set up and verify the target Webhook notification channel in Cloud Monitoring; third, create the alerting policy targeting the log-based metric threshold; finally, attach the notification channel to the alerting policy and activate it.

Configuring operational alerting on log data requires a strict dependency sequence. First, the log entry pattern must be captured as a custom metric in Cloud Logging. Next, the target notification endpoint (Webhook) must be registered in Cloud Monitoring. Third, the alerting policy rule must be created using the metric time series as its condition source. Finally, the notification channel is linked to the policy to finalize alert delivery.

Step-by-Step Solution

Create the custom log-based counter metric in Cloud Logging using filter parameters for resource.type="cloud_run_revision" AND httpRequest.status=500.

Cloud Logging creates a metric descriptor and starts extracting time-series metric data into Cloud Monitoring whenever matching logs arrive.

Cloud Monitoring alerting policies cannot reference a log-based metric until the metric descriptor has been created in Cloud Logging.

Navigate to Cloud Monitoring Notification Channels and create a new Webhook endpoint channel.

A valid notification channel object is provisioned and available within the workspace.

Notification channels must be defined prior to assigning them to policy notification targets.

Define an alerting policy in Cloud Monitoring that monitors the rate of change or count of the custom log-based metric against a specific threshold.

The monitoring policy logic is established to evaluate incoming time-series points.

The policy defines when an incident is opened based on metric evaluation.

Bind the Webhook notification channel to the alerting policy and set the policy state to enabled.

The end-to-end logging, monitoring, and operational alerting pipeline is fully operational.

Linking the channel enables active incident routing upon threshold breaches.

Key Concept

Log-based metric and alerting policy configuration workflow in Google Cloud Observability

Question 395Question →

A financial technology enterprise is establishing an automated deployment pipeline to provision a hybrid compute workload on Google Cloud. The solution requires private Google Kubernetes Engine (GKE) clusters for microservices and Managed Instance Groups (MIGs) for batch calculations, managed declaratively via Infrastructure as Code (IaC). To ensure secure master access, proper identity isolation, and resilient infrastructure state management during provisioning, which TWO actions should the Cloud Architect incorporate into the design?

Select all that apply

Configure Control Plane Authorized Networks on the private GKE cluster to restrict access to the cluster master endpoint to explicit, authorized internal administrative CIDR ranges.

Grant the deployment pipeline service account the Service Account User role (roles/iam.serviceAccountUser) on the specific workload service account assigned to the Compute Engine instances.

Omit Control Plane Authorized Networks configuration and rely exclusively on private node IP isolation to secure cluster management communications.

Store the primary Terraform state file in ephemeral local storage on the CI/CD runner to avoid network overhead and external state locking mechanisms.

Assign the primitive Owner role (roles/owner) to the Compute Engine node service account to ensure compute instances have sufficient permission to interact with all cloud resources.

Show answer & explanation

Answer: Configure Control Plane Authorized Networks on the private GKE cluster to restrict access to the cluster master endpoint to explicit, authorized internal administrative CIDR ranges.; Grant the deployment pipeline service account the Service Account User role (roles/iam.serviceAccountUser) on the specific workload service account assigned to the Compute Engine instances.

Answer

The Cloud Architect must configure Control Plane Authorized Networks on the private GKE cluster to restrict control plane endpoint access to specified CIDR blocks, and grant the CI/CD deployment service account the Service Account User role on the dedicated workload service account.

Configuring Control Plane Authorized Networks restricts API server access to specified internal networks, preventing unauthorized access to the cluster master. Granting the Service Account User role on the target service account enables the deployment pipeline to launch Compute Engine instances under that identity while strictly adhering to least privilege principles.

Step-by-Step Solution

Analyze control plane endpoint security for private GKE clusters.

Determined that private clusters still require Control Plane Authorized Networks to limit master endpoint access strictly to authorized administrative CIDRs.

Private node IP isolation does not automatically restrict network access to the GKE API server endpoint.

Evaluate service account privilege delegation for automated compute provisioning.

Identified that the deployment pipeline requires `roles/iam.serviceAccountUser` scoped to the compute workload service account.

This allows the automated worker to provision instances bound to the workload identity without conferring excessive primitive or administrative privileges.

Eliminate risky provisioning practices related to state persistence and IAM over-privileging.

Rejected local state storage and primitive Owner role assignments.

Infrastructure state must be held in remote backends like Cloud Storage with object locking, and instance service accounts must follow least privilege.

Key Concept

GKE Private Cluster Master Protection and IAM Service Account User Scoping

Question 396Question →

An enterprise needs to connect its on-premises data center directly to a Google Cloud VPC to support high-volume data transfers. The requirement specifies a dedicated physical connection capable of delivering 10 Gbps bandwidth over private IP addresses. Which Google Cloud hybrid connectivity option should you configure?

Dedicated Interconnect

HA Cloud VPN

VPC Network Peering through a partner transit VPC

Identity-Aware Proxy with custom IAM roles over public internet

Show answer & explanation

Answer: Dedicated Interconnect

Answer

Dedicated Interconnect is the correct choice because it provides a private, direct physical connection to Google Cloud supporting 10 Gbps or 100 Gbps bandwidth.

Dedicated Interconnect extends an on-premises network to Google Cloud through a direct physical link at a Google colocation facility. It supports 10 Gbps and 100 Gbps link speeds and private RFC 1918 communication, fully satisfying high-bandwidth requirements.

Step-by-Step Solution

Analyze the bandwidth and connectivity requirements.

The requirement specifies a dedicated physical connection supporting 10 Gbps bandwidth with private IP access.

Selecting the correct hybrid connectivity product depends on bandwidth scale, physical infrastructure, and routing requirements.

Compare available Google Cloud hybrid connectivity offerings.

Dedicated Interconnect directly bridges on-premises facilities to Google Cloud using 10 Gbps or 100 Gbps circuits.

Cloud VPN is limited to 3 Gbps per tunnel over public internet, and VPC Peering lacks transitive routing support for on-premises connectivity.

Key Concept

Selecting and configuring Google Cloud Dedicated Interconnect for high-bandwidth hybrid connectivity

Question 397Question →

An enterprise logistics provider is migrating its core operational architecture from an on-premises data center to Google Cloud. The workload comprises a live $5\text{ TB}$ transactional PostgreSQL database migrating to Cloud SQL for PostgreSQL, along with $300\text{ TB}$ of unstructured document attachments migrating to Cloud Storage. The business demands continuous data replication with near-zero downtime during final cutover. Arrange the operational steps in the correct sequential order to execute this migration plan.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps is: 1) Establish connectivity, start continuous DMS CDC, and launch Storage Transfer Service initial bulk transfer; 2) Monitor replication lag and run delta syncs until synchronization parity is reached; 3) Set source database to read-only mode and run final incremental file transfer; 4) Verify zero replication lag, promote Cloud SQL to standalone primary, and update application connection endpoints; 5) Complete health validation checks and open write traffic on Google Cloud.

The migration cutover must proceed in a logical sequence to minimize downtime and prevent data loss. Baseline connectivity and replication (DMS CDC + Storage Transfer Service) are established first while the source remains active. Next, replication lag is monitored until parity is achieved. To prevent data divergence, write traffic on the source database is stopped by putting it in read-only mode, followed by a final incremental file transfer. After verifying zero replication lag, the Cloud SQL target instance is promoted to a standalone primary database and connection endpoints are updated. Finally, post-migration health checks validate system integrity before resuming production write traffic on GCP.

Step-by-Step Solution

Establish connectivity and start baseline replication tools.

Continuous CDC streaming begins via DMS alongside baseline Storage Transfer Service object ingestion without interrupting live source writes.

Data transfer tools must establish baseline copies and streaming CDC while the on-premises application remains fully operational.

Track replication lag and perform incremental synchronization.

Target Cloud SQL and Cloud Storage environments reach continuous near-zero latency synchronization with source data.

Verifying sync parity guarantees that the cutover window can be kept as brief as possible.

Quiesce source writes and trigger final delta syncs.

On-premises state is frozen to guarantee consistency while final transactions flush across the pipeline.

Preventing new writes eliminates data divergence and ensures strict zero-data-loss cutover.

Promote target database instance and rebind endpoints.

Cloud SQL becomes a standalone primary write instance, and application connection strings are pointed to GCP services.

Promoting Cloud SQL converts it from a replication target to the active master database.

Validate deployment health and resume production writes.

System end-to-end functionality is confirmed and production operations resume cleanly on GCP.

Final validation verifies that all application endpoints and data stores behave correctly under load before live user writes begin.

Key Concept

Database migration staging, CDC continuous replication, and cutover sequencing using GCP Database Migration Service and Storage Transfer Service.

Question 398Question →

A multinational healthcare enterprise is migrating biomedical imaging workloads to Google Cloud. The primary network architecture requires a high-throughput, unencrypted direct private link supporting a 99.99% availability SLA. Additionally, compliance standards require an independent, IPsec-encrypted backup path established over the public internet with automated failover that prioritizes the direct link when healthy. Which TWO configuration steps must the lead network architect implement to meet both the 99.99% availability SLA and the automated routing requirements?

Select all that apply

Provision four Dedicated Interconnect VLAN attachments across two distinct Google Cloud locations (metropolitan areas) and two edge availability domains per location, paired with Cloud Routers using global dynamic routing.

Deploy a single Dedicated Interconnect circuit with two VLAN attachments in one metro area, relying on an active HA VPN connection to compensate and satisfy the 99.99% direct link SLA.

Establish an HA VPN gateway with two IPsec tunnels connected to a Cloud Router, and configure BGP route metrics (such as lower Multi-Exit Discriminator/MED or shorter AS-Path) to favor Dedicated Interconnect routes during normal operation.

Configure VPC Network Peering between the hybrid transit VPC and internal application VPCs to automatically transit on-premises dynamic BGP routes from the VPN gateway to all peered networks.

Apply VPC Service Controls perimeters across the Cloud Routers to automatically enforce IPsec tunnel encryption over the physical Dedicated Interconnect fiber circuits.

Show answer & explanation

Answer: Provision four Dedicated Interconnect VLAN attachments across two distinct Google Cloud locations (metropolitan areas) and two edge availability domains per location, paired with Cloud Routers using global dynamic routing.; Establish an HA VPN gateway with two IPsec tunnels connected to a Cloud Router, and configure BGP route metrics (such as lower Multi-Exit Discriminator/MED or shorter AS-Path) to favor Dedicated Interconnect routes during normal operation.

Answer

The correct architecture requires provisioning four Dedicated Interconnect VLAN attachments distributed across two separate metropolitan locations and two edge availability domains in each location with global dynamic routing, along with deploying an HA VPN gateway paired with Cloud Router using BGP metrics (such as MED) to ensure traffic prefers the Interconnect route during healthy operation.

To guarantee a 99.99% availability SLA for Dedicated Interconnect, Google Cloud mandates four VLAN attachments deployed across two distinct metropolitan locations and two edge availability domains in each location, linked with Cloud Routers using global dynamic routing. For automated, encrypted failover, deploying HA VPN tunnels and setting BGP attributes (such as lower Multi-Exit Discriminator/MED values on the Interconnect paths) ensures that traffic defaults to the high-throughput direct connection during normal operations and automatically reroutes through the encrypted VPN tunnels if the primary connection fails.

Step-by-Step Solution

Evaluate the SLA requirements for Dedicated Interconnect topology.

Determined that achieving a 99.99% SLA for Dedicated Interconnect requires 4 VLAN attachments total: 2 in one metropolitan location (across 2 edge availability domains) and 2 in a separate metropolitan location (across 2 edge availability domains).

Google Cloud's 99.99% availability framework for Dedicated Interconnect explicitly mandates dual-metro, dual-edge domain redundancy with Global Dynamic Routing.

Design the encrypted backup path and automated failover strategy using dynamic BGP routing.

Configured HA VPN with Cloud Router and tuned BGP attributes (such as MED or AS-Path prepending).

BGP route attributes allow on-premises and GCP routers to select Dedicated Interconnect as the primary path when available and fail over to the encrypted HA VPN tunnels seamlessly if the primary path degrades.

Key Concept

Configuring 99.99% High Availability Dedicated Interconnect alongside HA VPN backup using Cloud Router dynamic BGP path selection.

Question 399Question →

An enterprise platform engineering team is designing an automated continuous integration and continuous deployment (CI/CD) framework to provision Google Cloud infrastructure across multiple target projects using Terraform. The security architecture requires that pipeline runners execute without static service account keys, state management prevents concurrent runs and state corruption, and deployments follow the principle of least privilege. Which architectural implementation best meets these requirements?

Configure a centralized Google Cloud Storage bucket with object versioning enabled for the Terraform backend, and authenticate pipeline runners using Workload Identity Federation to impersonate a service account assigned fine-grained predefined or custom IAM roles on target resources.

Store Terraform state files in a shared local repository directory synchronized across pipeline build nodes, and assign the primitive Owner role to the deployment service account to ensure all infrastructure provisioning operations succeed without credential failure.

Configure a Google Cloud Storage bucket for Terraform state management, export a long-lived service account JSON key into CI/CD secrets variables, and grant the service account the primitive Editor role across all managed target projects.

Configure a Google Cloud Storage bucket for Terraform remote state, and grant the Service Account Admin role directly to pipeline execution users so they can dynamically generate and rotate credentials during each plan and apply workflow.

Show answer & explanation

Answer: Configure a centralized Google Cloud Storage bucket with object versioning enabled for the Terraform backend, and authenticate pipeline runners using Workload Identity Federation to impersonate a service account assigned fine-grained predefined or custom IAM roles on target resources.

Answer

The solution leveraging a Cloud Storage bucket with object versioning alongside Workload Identity Federation provides native state locking, protection against accidental state deletion, zero static key management overhead, and adherence to least-privilege IAM controls.

Step-by-Step Solution

Analyze State Management Requirements

Identify that Cloud Storage remote backends with object versioning and state locking are required to prevent concurrency conflicts and allow recovery from corrupted states.

Terraform remote backends natively support locking via Cloud Storage, which prevents simultaneous pipeline executions from mutating state.

Evaluate Authentication Mechanism

Select Workload Identity Federation over static JSON keys.

Workload Identity Federation removes the operational and security burden of managing and rotating long-lived service account keys by exchanging external identity tokens for short-lived GCP tokens.

Evaluate IAM Role Scoping

Assign fine-grained predefined or custom IAM roles to the deployment service account.

Using least-privilege roles prevents unauthorized modifications and limits blast radius compared to granting broad primitive Editor or Owner roles.

Key Concept

Terraform Remote Backend & Workload Identity Federation Governance

Question 400Question →

An online publishing company is developing a containerized RESTful microservice to process user comment metadata. The service is completely stateless, experiences unpredictable traffic spikes throughout the day, and requires a serverless deployment model to minimize operational overhead and automatically scale down to zero instances when idle. Which Google Cloud compute platform should the architect select?

Deploy the containerized application to Cloud Run.

Deploy the application to a Google Kubernetes Engine (GKE) standard cluster.

Deploy the application on Compute Engine Managed Instance Groups configured with static CPU autoscaling thresholds.

Deploy the application on Compute Engine dedicated sole-tenant nodes with committed use discounts.

Show answer & explanation

Answer: Deploy the containerized application to Cloud Run.

Answer

Deploy the containerized application to Cloud Run.

Cloud Run is the recommended Google Cloud platform for stateless containerized web workloads requiring minimal operational overhead. It automatically handles autoscaling based on incoming request metrics down to zero instances, eliminating baseline infrastructure costs during idle periods.

Step-by-Step Solution

Analyze workload characteristics

Workload is a stateless containerized HTTP microservice with variable traffic patterns and a requirement for zero-idle scaling.

Determining statelessness and scaling requirements dictates whether serverless or container orchestration is required.

Evaluate Google Cloud compute options against operational overhead and scaling needs

Cloud Run manages underlying infrastructure, scales seamlessly to zero when traffic stops, and executes standard container images.

Cloud Run fits stateless serverless container execution best without management overhead.

Key Concept

Compute Platform Selection: Cloud Run for Stateless Containers

Estimated Time:45s

PreviousPage 20 / 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