Examkin

All practice questions

1598 questions

All types1,598Multiple choice815Multiple select537Numeric8Matching64Ordering174
Question 321Question →

An operations engineer needs to set up automated alerts whenever specific application error log entries occur in Google Cloud. Order the steps required to configure an operational alert using a custom log-based metric and Cloud Monitoring.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for configuring operational alerts based on log events is: 1) Define the filter query in Cloud Logging, 2) Create a custom log-based metric from the filter, 3) Configure an alerting policy in Cloud Monitoring referencing the custom metric, and 4) Attach notification channels to the alerting policy.
The logical sequence for establishing operational alerting from raw logs begins by defining a log filter in Cloud Logging. Next, a custom log-based metric is created to extract data or count matching log lines over time. Then, Cloud Monitoring uses this log-based metric to build an alerting policy with specific threshold triggers. Finally, notification channels are associated with the policy to complete the alert delivery setup.

Step-by-Step Solution

1
Filter Logs in Cloud Logging
Specific error log entries are isolated from general log streams.
Before metrics or alerts can be built, the exact criteria matching the desired log entries must be identified.
2
Generate Log-based Metric
A continuous metric stream is made available to Cloud Monitoring based on log occurrence count or extracted values.
Cloud Monitoring requires metric data to evaluate threshold alerts over time.
3
Create Cloud Monitoring Alerting Policy
Alert condition threshold rules are defined against the log-based metric.
The monitoring system evaluates incoming metric data against defined operational thresholds.
4
Attach Notification Channels & Enable Policy
The operational alerting pipeline is fully functional and alerts appropriate personnel upon breach.
Without designated notification channels, alerts cannot reach operations teams.

Key Concept

Configuring Log-Based Metrics and Operational Alerting in GCP
Estimated Time:1m 0s
Question 322Question →

An enterprise needs to perform an offline bulk migration of 200 TB of archive data from an on-premises data center to Google Cloud Storage using a Transfer Appliance. In what chronological sequence should the cloud architect perform the key steps of this transfer strategy?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with requesting and receiving the Transfer Appliance, followed by connecting and copying encrypted data locally, shipping the device back to Google for ingestion, and concluding with checksum integrity verification in Cloud Storage.
The correct workflow for offline migration using Transfer Appliance requires procuring the physical hardware first, copying and encrypting data locally, shipping the appliance to Google for data ingestion, and validating object integrity in Cloud Storage once upload completes.

Step-by-Step Solution

1
Device Procurement
The physical Transfer Appliance is delivered to the on-premises data center.
Hardware must be on site before local staging can start.
2
Local Data Ingestion
The 200 TB of archive data is written to and encrypted on the appliance.
Data must be loaded onto the device locally using high-speed network interfaces.
3
Return Shipment & Cloud Ingestion
Google receives the device and uploads the data into the designated Cloud Storage bucket.
Physical transportation to Google avoids consuming external network bandwidth.
4
Post-Transfer Validation
Objects in Cloud Storage are confirmed accurate and ready for operational use.
Final validation ensures no corruption occurred during transport and ingestion.

Key Concept

Offline Data Transfer Lifecycle using Transfer Appliance
Estimated Time:1m 0s
Question 323Question →

An operations team needs to set up automated alerting for specific application error logs occurring in a Compute Engine environment. Order the configuration steps from first to last to establish a complete log-based alerting workflow.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with defining the log filter query in Cloud Logging, followed by building a custom log-based metric, configuring the Cloud Monitoring alert policy threshold on that metric, and finally attaching notification channels to deliver the alerts.
To alert on log events, you must first construct a log filter query in Cloud Logging to identify matching log lines. Second, you convert those matching logs into a time-series metric by creating a log-based metric. Third, you set up an alert policy within Cloud Monitoring that monitors the log-based metric threshold. Finally, you attach notification channels to the alert policy to notify personnel when the condition is violated.

Step-by-Step Solution

1
Construct the log query filter in Cloud Logging
Specific error log entries are precisely selected from the project log streams.
Log-based metrics require a precise filter string to select which log events should be counted.
2
Create a custom counter log-based metric
A new time series metric (logging.googleapis.com/user/<metric_name>) is generated whenever matching log events arrive.
Cloud Monitoring cannot directly set alert policies on raw unstructured logs; log entries must first be converted into numerical metric time-series data.
3
Create an Alert Policy in Cloud Monitoring using the log-based metric
Threshold condition and aggregation window (e.g., rate of error logs > 5 over 5 minutes) are established.
Alerting policies evaluate conditions against metric time series data to determine incident status.
4
Configure and attach notification channels to the Alert Policy
Alert notifications are routed to on-call engineers via SMS, Email, PagerDuty, or Webhooks when incidents open.
Notification channels direct alert state changes to operational teams.

Key Concept

Configuring custom log-based metrics and operational alert policies in Google Cloud Monitoring
Estimated Time:1m 30s
Question 324Question →

A cloud engineering team needs to safely migrate an existing local Terraform state file to a secure Google Cloud Storage (GCS) remote backend with state locking enabled. Arrange the operational steps in the correct sequence to complete this migration.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with provisioning the private GCS bucket with Object Versioning enabled, adding the GCS backend configuration block to the Terraform module, executing terraform init to migrate the state data, and finally verifying remote state creation before deleting the local state file.
Safely migrating Terraform state requires provisioning the remote GCS bucket with Object Versioning first, defining the backend block in the Terraform code second, executing terraform init to copy existing local state into GCS third, and removing local state files fourth to maintain a single source of truth.

Step-by-Step Solution

1
Provision Destination GCS Bucket
A secure GCS bucket configured with Object Versioning and uniform bucket-level access is available.
Google Cloud Storage must exist to host state files and provide Cloud KMS/IAM lock capabilities.
2
Configure Terraform Backend
The backend configuration is declared in code.
Terraform requires explicit backend parameters in code to identify the migration target.
3
Run State Migration Command
Local state file contents are securely uploaded to GCS.
Executing terraform init triggers Terraform's internal state migration mechanism.
4
Post-Migration Verification and Cleanup
Local state artifacts are deleted, establishing GCS as the single source of truth.
Removing redundant local state files prevents unauthorized access and operational confusion.

Key Concept

Terraform GCS Remote Backend State Migration
Estimated Time:1m 30s
Question 325Question →

An organization is building an automated continuous integration pipeline to provision a memory-intensive batch processing workload on Google Cloud. The architecture utilizes Compute Engine Managed Instance Groups (MIGs) with custom instance templates. A CI/CD service account executes Infrastructure as Code (IaC) scripts to instantiate the instances and attach a runtime service account that accesses Cloud Storage. Which TWO operational and security configurations must be implemented during compute provisioning? (Select TWO choices.)

Select all that apply

Show answer & explanation

Answer: Request regional Compute Engine CPU and memory quota increases in advance prior to executing large-scale instance group provisioning.; Grant the CI/CD pipeline service account the Service Account User role (roles/iam.serviceAccountUser) on the specific runtime service account attached to the Compute Engine instances.

Answer

The deployment requires requesting regional Compute Engine resource quotas in advance and granting the Service Account User role (roles/iam.serviceAccountUser) to the CI/CD deployment identity on the specific runtime service account.
Requesting regional compute quota increases in advance ensures that large-scale automated deployments execute without encountering compute capacity limits. Additionally, granting the Service Account User role (roles/iam.serviceAccountUser) on the runtime service account allows the deployment pipeline to attach that identity to new Compute Engine instances while adhering to least privilege principles.

Step-by-Step Solution

1
Evaluate resource quota pre-requisites for compute provisioning
Identified that large-scale instance group deployments require checking and requesting regional quota increases beforehand to prevent API deployment failures.
GCP projects have default regional limits on compute resources such as CPUs and RAM which must be adjusted before launching large instance groups.
2
Determine minimum required IAM permissions for attaching service accounts to compute instances
Identified that the deployment principal needs roles/iam.serviceAccountUser on the target runtime service account.
This permission allows a principal to bind a service account to a Compute Engine instance without exposing administrative controls over IAM policy definitions.

Key Concept

Compute Resource Provisioning and IAM Privilege Scoping
Estimated Time:1m 30s
Question 326Question →

A global logistics provider is architecting a new tracking platform on Google Cloud. The system consists of two distinct components: (1) A stateless, event-driven gRPC web microservice that experiences unpredictable traffic spikes and requires rapid scaling down to zero to minimize idle costs, and (2) A legacy data transformation batch processing engine that requires custom OS kernel modules, specialized system drivers, and direct access to high-performance local NVMe storage. Which architectural compute platform choices should you recommend to satisfy these requirements while minimizing operational management overhead? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Deploy the stateless gRPC microservice on Cloud Run to leverage managed auto-scaling to zero and native HTTP/2 support.; Deploy the legacy data transformation batch engine on Compute Engine Virtual Machines with attached Local SSDs.

Answer

The optimal architecture combines Cloud Run for the stateless gRPC microservice and Compute Engine VMs with Local SSDs for the legacy data transformation engine requiring custom OS kernel modules.
Selecting Cloud Run for the stateless gRPC microservice satisfies the requirement for scale-to-zero, low maintenance overhead, and gRPC support. Selecting Compute Engine VMs for the legacy batch processing engine provides the necessary root OS access and kernel flexibility required to install custom drivers and utilize Local SSDs.

Step-by-Step Solution

1
Analyze the stateless gRPC microservice requirements
Identified statelessness, variable traffic, scale-to-zero requirement, and gRPC protocol support.
Cloud Run natively supports gRPC over HTTP/2, auto-scales down to zero instances, and incurs zero infrastructure management overhead.
2
Analyze the legacy data transformation batch engine requirements
Identified strict dependencies on custom OS kernel modules, specialized hardware drivers, and high-performance local storage.
Managed serverless and container platforms (Cloud Run, GKE Autopilot, App Engine) restrict host kernel modifications, making Compute Engine VMs the only suitable platform.

Key Concept

Selecting GCP Compute Platforms based on OS kernel customization requirements, statefulness, protocol support, and operational overhead.
Estimated Time:2m 0s
Question 327Question →

A DevOps engineer needs to migrate an existing local Terraform state file to a Google Cloud Storage (GCS) remote backend for shared team access. What is the correct sequence of steps to migrate the local Terraform state to the GCS remote backend?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with creating the GCS storage bucket with versioning, followed by declaring the GCS backend in the Terraform code, executing terraform init to migrate state, and finally confirming successful migration before cleaning up local state files.
The GCS bucket must be created first because Terraform requires an existing bucket to initialize its remote state. Once the bucket exists, the backend configuration block is added to code. Running terraform init detects the new backend configuration and performs the migration from local disk to GCS. Finally, verification and cleanup ensure all team members use the single remote source of truth.

Step-by-Step Solution

1
Provision the destination storage bucket in Google Cloud
A secure GCS bucket with versioning enabled is ready to accept state files
Terraform cannot automatically create the remote backend bucket during backend initialization if it does not exist
2
Add the backend backend 'gcs' block to main.tf or provider configuration
Terraform configuration is updated with remote state directives
Terraform requires the explicit bucket name and prefix to connect to the remote backend
3
Execute terraform init
Terraform detects the backend change and transfers state from local disk to GCS
The initialization command performs the state migration process interactively or automatically
4
Verify remote state in GCS and remove local state files
Single source of truth is established in remote storage without duplicate local state
Removing redundant local state files prevents accidental state drift and local execution

Key Concept

Terraform GCS Remote Backend State Migration Workflow
Question 328Question →

An enterprise organization is planning to deploy two new stateless workloads to Google Cloud with the goal of minimizing operational overhead and infrastructure management:

1. A RESTful web microservice packaged as a Docker container that handles HTTP traffic.
2. A small, lightweight event handler that executes code automatically whenever a file is uploaded to a Cloud Storage bucket.

Which TWO Google Cloud compute platforms should the cloud architect select to host these workloads according to Google recommended practices?

Select all that apply

Show answer & explanation

Answer: Deploy the containerized RESTful web microservice on Cloud Run.; Deploy the file upload event handler using Cloud Functions.

Answer

The cloud architect should deploy the containerized RESTful web microservice on Cloud Run and deploy the file upload event handler using Cloud Functions.
For stateless containerized HTTP microservices, Cloud Run provides a serverless platform that automatically scales containers to zero and handles infrastructure management. For event-driven execution responding to Cloud Storage events, Cloud Functions offers direct integration without needing persistent server management, achieving minimal operational overhead for both requirements.

Step-by-Step Solution

1
Analyze workload 1 requirements
Workload 1 is a stateless HTTP microservice packaged in a Docker container.
Cloud Run is the optimal Google Cloud serverless compute platform for containerized stateless web applications.
2
Analyze workload 2 requirements
Workload 2 is a lightweight event handler triggered by Cloud Storage file uploads.
Cloud Functions natively integrates with Cloud Storage events to execute code on-demand without server management.
3
Evaluate operational overhead constraint
Both Cloud Run and Cloud Functions are fully managed serverless compute services requiring zero cluster management.
This minimizes operational maintenance compared to managing Kubernetes clusters or virtual machine instances.

Key Concept

Selecting Serverless Compute Platforms for Stateless and Event-Driven Workloads
Question 329Question →

A global logistics organization is designing a vehicle telemetry processing system on Google Cloud. The system consists of two distinct workloads: (1) a stateless gRPC event-ingestion microservice that receives high-throughput data streams with unpredictable load spikes, and (2) a high-performance batch simulation service that requires custom Linux kernel sysctl modifications and custom C++ container runtime drivers. The engineering team must minimize infrastructure management overhead and avoid paying for idle compute during off-peak hours. Which TWO compute architecture options should the Cloud Architect select to satisfy these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Deploy the stateless gRPC event-ingestion microservice to Cloud Run using container instances with HTTP/2 enabled.; Deploy the batch simulation workload to Google Kubernetes Engine (GKE) Autopilot using custom pod security contexts for kernel parameters.

Answer

The optimal architecture combines Cloud Run for the stateless gRPC microservice and GKE Autopilot for the kernel-customized batch simulation workload.
Selecting Cloud Run for the stateless gRPC microservice provides fully managed, zero-to-n auto-scaling with native gRPC/HTTP2 support, meeting the zero idle-cost requirement. Selecting GKE Autopilot for the batch simulation workload accommodates custom Linux kernel (sysctl) settings via pod security contexts while maintaining a serverless operational model where Google manages node infrastructure.

Step-by-Step Solution

1
Evaluate the stateless gRPC streaming ingestion workload requirements.
Cloud Run is selected because it natively supports HTTP/2 and gRPC streams, automatically scales down to zero to eliminate idle compute costs, and requires zero cluster maintenance.
Stateless containerized services with fluctuating traffic benefit most from fully managed serverless container platforms.
2
Evaluate the batch simulation workload requirements requiring low-level system settings.
GKE Autopilot is selected because it supports specific Kubernetes pod security context configurations (such as sysctl settings) while offloading node lifecycle management and provisioning to Google Cloud.
Workloads requiring low-level kernel parameters cannot run on sandboxed serverless environments like App Engine Standard but still need minimized operational complexity.

Key Concept

Compute Platform Selection Matrix (Cloud Run vs. GKE Autopilot vs. App Engine)
Question 330Question →

An enterprise is planning a near-zero downtime database migration from an on-premises PostgreSQL database to Google Cloud SQL for PostgreSQL using Database Migration Service (DMS). Place the following migration steps in the correct chronological execution order from initial preparation to final cutover.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequential order for a Database Migration Service baseline and CDC workflow is: first configure source WAL and private network access, then provision Cloud SQL and establish schema structures, launch the initial full data snapshot transfer, monitor CDC replication latency until synced, and finally halt source writes, promote Cloud SQL, and update application connection endpoints.
A structured online migration requires enabling WAL logging and network connectivity first, provisioning the destination schema, running the full baseline dump via DMS, monitoring CDC until lag reaches near zero, and performing final application cutover.

Step-by-Step Solution

1
Configure network and source logging prerequisites
WAL and private connectivity ready for streaming
Database Migration Service requires network line-of-sight and WAL configuration to track change data.
2
Provision Cloud SQL instance and apply schema DDL
Target database ready to receive snapshot data
The destination database environment must be structured with matching schema DDL prior to snapshot ingestion.
3
Initiate snapshot data loading via DMS
Baseline historical dataset transferred to Cloud SQL
Initial full dump populates the baseline state before delta sync can occur.
4
Track continuous CDC stream lag
Target database continuously synced with ongoing source writes
Monitoring CDC lag ensures the destination is in sync prior to executing scheduled cutover windows.
5
Execute cutover and promote target instance
Application traffic directed to new Cloud SQL database
Pausing source writes and promoting target database completes the migration cleanly without missing data.

Key Concept

Homogeneous database migration sequencing using Google Cloud Database Migration Service (DMS) with continuous CDC.
Estimated Time:2m 0s
Question 331Question →

A multinational retail enterprise is planning to migrate its core e-commerce database (a 40 TB PostgreSQL instance) and associated 300 TB object store from an on-premises data center to Google Cloud (Cloud SQL for PostgreSQL and Cloud Storage). The enterprise mandates continuous data synchronization prior to cutover to comply with a strict maximum allowed maintenance window of 30 minutes. What is the correct sequence of steps to plan and execute this zero-data-loss migration strategy?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct execution sequence is: Establish hybrid network connectivity -> Perform baseline data and database snapshot transfer -> Configure continuous CDC via Database Migration Service -> Freeze on-premises writes, wait for zero replication lag, and promote target database -> Redirect application traffic to GCP endpoints and validate operational status.
A structured database migration designed for strict SLA maintenance windows must follow a logical dependency chain: 1) Secure network connectivity via Interconnect, 2) Bulk initial baseline transfer for large static storage and initial database snapshot, 3) Real-time CDC streaming via Database Migration Service to minimize divergence, 4) Controlled maintenance window freeze of source write operations, confirmation of zero replication lag, and promotion of target instance, and 5) Final application endpoint redirection and validation.

Step-by-Step Solution

1
Establish network connectivity foundation
Hybrid connectivity via Dedicated or Partner Interconnect with Cloud Router BGP sessions established.
Secure, reliable, high-throughput private communication must precede any bulk or streaming data movement between environments.
2
Execute initial bulk baseline load
300 TB object data transferred via Storage Transfer Service and 40 TB database snapshot restored onto Cloud SQL target.
Establishes the initial historical data baseline in Google Cloud before starting delta capture.
3
Enable continuous Change Data Capture (CDC)
GCP Database Migration Service (DMS) actively streams logical write-ahead logs (WAL) from on-premises PostgreSQL to Cloud SQL.
Maintains low replication lag and near-real-time parity between source and target databases while production remains live.
4
Execute cutover and promote target instance
On-premises application writes are stopped, DMS sync achieves zero-second lag, continuous replication is stopped, and Cloud SQL target is promoted to standalone primary.
Guarantees zero data loss and prepares the target database to accept new write operations within the 30-minute maintenance window.
5
Redirect traffic and complete migration
Application configuration endpoints updated to target Cloud SQL and Cloud Storage; health checks pass.
Completes final transition of user requests to the GCP infrastructure.

Key Concept

Minimal-downtime database and data migration using baseline snapshot transfer and continuous CDC replication via GCP Database Migration Service.
Question 332Question →

A Cloud Architect needs to migrate an existing local Terraform state file containing critical production Google Cloud resources to a secure Google Cloud Storage (GCS) remote backend with state locking and CMEK encryption. Arrange the operational steps in the correct chronological order to safely complete this backend migration while maintaining resource integrity.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with provisioning and securing the remote GCS bucket, adding the `backend "gcs"` configuration to the Terraform code, executing `terraform init -migrate-state` to copy state data, running `terraform plan` to verify zero drift, and finally purging local state file artifacts.
Migrating Terraform state safely requires creating the remote GCS backend infrastructure first, declaring the backend in HCL, using the CLI tool's dedicated `-migrate-state` command to copy existing resource records under a state lock, verifying state synchronization via a plan, and lastly removing legacy local state files.

Step-by-Step Solution

1
Provision GCS storage bucket with object versioning, CMEK, and minimal IAM permissions.
Secure storage destination for remote state management is established.
The GCS bucket must exist and have proper state locking and security controls before Terraform can communicate with it.
2
Add the `backend "gcs"` block into the Terraform root configuration.
Terraform configuration points to the targeted GCS bucket.
Terraform needs backend definitions in HCL to recognize the change from local backend to remote GCS storage.
3
Execute `terraform init -migrate-state`.
Local state contents are safely copied into GCS state storage under state lock protection.
The `-migrate-state` flag explicitly instructs Terraform to copy existing local state metadata to the newly configured backend.
4
Run `terraform plan` to validate infrastructure synchronization.
Confirmation of zero resource changes or state corruption.
Validation against live Google Cloud resources ensures that state pointers were migrated without drift.
5
Remove local `terraform.tfstate` files.
Prevention of concurrent local executions and credential exposure.
Deleting local state files enforces central GCS state usage across team members.

Key Concept

Terraform Remote State Migration to Google Cloud Storage
Question 333Question →

An site reliability engineering (SRE) team needs to create an operational alert system for a mission-critical web application on Google Cloud. The alert must fire whenever HTTP 500 status codes exceed a rate of 50 occurrences within a 5-minute window. The team must construct a log-based metric from application logs and link it to an alerting policy that sends alerts via an external Webhook notification channel. In what sequence should the SRE team perform the following tasks to establish this monitoring pipeline?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Construct and test the log filter query in Log Explorer, 2) Create the user-defined log-based metric using the query, 3) Configure and verify the Webhook notification channel, and 4) Build the alerting policy using the log-based metric, threshold conditions, and notification channel.
The workflow follows a strict dependency chain: First, the log entry criteria must be tested in Log Explorer. Second, a custom log-based metric must be defined from that query so Cloud Monitoring can generate time-series data points. Third, the Webhook notification channel must be provisioned so alerting destinations exist. Finally, the Cloud Monitoring alerting policy is created, selecting the metric stream, configuring threshold evaluation, and linking the notification channel.

Step-by-Step Solution

1
Filter log payload
Validated Cloud Logging query specifying severity and resource payload attributes for HTTP 500 errors.
Before creating a metric, the exact filter criteria must be verified to prevent capturing unwanted log events or missing target errors.
2
Generate custom metric stream
User-defined counter metric registered in Cloud Logging.
Cloud Monitoring cannot monitor log entries directly; log entries must first be mapped into custom time-series metric data by Cloud Logging.
3
Establish notification endpoints
Active, verified Webhook notification channel registered in Cloud Monitoring settings.
Alerting policies require a target notification channel during or after creation to deliver incident notifications upon breach.
4
Configure alert policy and attach channels
Enabled Cloud Monitoring alerting policy monitoring the log-based metric threshold and pointing to the notification channel.
The alerting policy synthesizes the metric threshold condition and notification delivery target into a functional alerting rule.

Key Concept

Configuring custom log-based metrics and operational alert policies in GCP Cloud Operations suite
Estimated Time:2m 0s
Question 334Question →

Your team needs to migrate a monolithic local Terraform state file (`terraform.tfstate`) managing production GCP resources to an enterprise remote backend hosted on Google Cloud Storage (GCS) with object versioning and state locking. Place the steps in the correct order to perform this state migration safely without losing resource state or creating concurrency issues.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for migrating local Terraform state to a GCS remote backend begins by adding the backend block, running terraform init, approving the automatic state copy prompt, and validating remote locking before removing local state files.
The migration process requires declaring the backend configuration first, invoking backend initialization via terraform init, approving the state transfer to GCS, and finally validating state lock functionality before removing local state backups.

Step-by-Step Solution

1
Add the backend 'gcs' configuration block to the Terraform code.
Defines the target Google Cloud Storage bucket and prefix for remote state management.
Terraform requires explicit backend block definitions to locate target state storage.
2
Execute 'terraform init' in the workspace directory.
Terraform identifies the backend change and initiates backend migration workflows.
The init command parses new provider and backend settings to set up state transfer.
3
Confirm the state copy operation when prompted by Terraform.
Local state entries are safely copied into the target GCS bucket.
Interactive confirmation ensures state tracking continuity without destroying managed resource mappings.
4
Run 'terraform plan' to test remote state locking and clean up the local tfstate file.
Remote backend operation is validated and local state file duplication is eliminated.
Prevents future accidental usage of local state files while validating GCS backend permissions.

Key Concept

Migrating local Terraform state to remote Google Cloud Storage (GCS) backend with state locking.
Question 335Question →

A logistics enterprise is deploying an automated CI/CD pipeline using Infrastructure as Code (IaC) with Terraform to provision regional Compute Engine Managed Instance Groups (MIGs) across multiple GCP projects. The design requirements mandate enforcing least-privilege access for deployment service accounts, maintaining Infrastructure as Code state integrity against concurrent execution conflicts, and preventing deployment failures during large-scale compute resource provisioning. Which architectural and provisioning practices should you incorporate into this solution? (Select THREE choices.)

Select all that apply

Show answer & explanation

Answer: Configure the Terraform backend to use a Google Cloud Storage bucket with object versioning and state locking enabled.; Grant the deployment service account the Service Account User role (roles/iam.serviceAccountUser) on the target workload service account.; Verify and request regional Compute Engine CPU and instance quota increases prior to executing automated large-scale instance group provisioning.

Answer

To securely and reliably provision compute resources using automated pipelines, configure a Cloud Storage backend with object versioning and state locking for Terraform, grant the deployment worker the Service Account User role on the target workload service account, and request regional resource quotas prior to scaling deployment capacity.
Safe compute provisioning requires establishing remote state locks on IaC backends to prevent concurrent modification, applying the Service Account User role to delegate compute identity access securely, and verifying regional compute quota headroom in advance of scaling operations.

Step-by-Step Solution

1
Configure backend state storage for automated provisioning pipelines.
Terraform state is stored remotely in Cloud Storage with locking and object versioning to avoid race conditions and state corruption.
Safe Infrastructure as Code execution requires centralized state locking when multiple automated execution pipelines run concurrently.
2
Enforce fine-grained IAM permissions for service account delegation.
The CI/CD pipeline account impersonates or attaches specific runtime service accounts using `roles/iam.serviceAccountUser` instead of holding broad administration permissions.
Following least privilege prevents automated deployment tools from having full resource control across the project.
3
Validate compute capacity constraints before provisioning.
Regional CPU and VM instance quota limits are checked and expanded in advance of launching large Managed Instance Groups.
Automated deployments will encounter API errors and fail mid-rollout if regional quota limits are exceeded.

Key Concept

Best practices for provisioning Compute Engine resources using Infrastructure as Code (IaC) state management, IAM least privilege, and resource quota planning.
Question 336Question →

A cloud administrator is setting up a shared Google Cloud Storage (GCS) backend for a team using Terraform to provision Google Cloud infrastructure. The administrator must ensure that simultaneous deployments by different engineers do not cause race conditions or state file corruption. Which GCS backend capability does Terraform automatically utilize to prevent concurrent state updates?

Show answer & explanation

Answer: Native object locking built into the Google Cloud Storage backend plugin

Answer

Terraform natively uses built-in Google Cloud Storage object locking within the GCS backend to handle state locking automatically during operations.
The correct choice highlights the built-in capability of Terraform's GCS backend plugin, which utilizes native Google Cloud Storage locking mechanisms to lock the state file during execution automatically. This prevents concurrent operations from corrupting the state file without needing extra IAM overrides or external databases.

Step-by-Step Solution

1
Identify the requirement for remote state management in team environments.
Multiple engineers deploying infrastructure concurrently require a centralized state backend with locking capabilities to prevent state file corruption.
Simultaneous execution of Terraform commands against the same state file causes race conditions.
2
Evaluate the native features of the Terraform Google Cloud Storage (GCS) backend.
The GCS backend for Terraform automatically supports object locking out of the box.
When `terraform apply` or `terraform plan` runs, Terraform creates a lock file in the GCS bucket to ensure exclusive access until the operation completes.

Key Concept

Terraform Remote State Management and Locking using Google Cloud Storage Backend
Question 337Question →

An enterprise gaming company is planning to migrate its mission-critical PostgreSQL database and associated multi-terabyte media storage from an on-premises data center to Google Cloud (Cloud SQL for PostgreSQL and Cloud Storage) with minimal operational downtime. What is the correct sequence of steps to execute this migration strategy while ensuring zero data loss and minimal service interruption?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: 1) Establish dedicated network connectivity via Cloud Interconnect and set up target GCP IAM roles and VPC infrastructure, 2) Initiate initial baseline data transfer for media files to Cloud Storage via Storage Transfer Service and start continuous Database Migration Service (DMS) CDC replication, 3) Verify data consistency, schema validation, and monitor CDC replication lag between the on-premises database and Cloud SQL, 4) Place the on-premises database in read-only mode, allow final CDC catch-up, and promote the Cloud SQL instance to primary, and 5) Update client application database connection strings and DNS records to direct production traffic to GCP.
The correct sequence follows GCP migration best practices: pre-provisioning secure network and IAM foundations, establishing baseline file transfers alongside continuous database replication (CDC), validating sync status, executing a zero-loss cutover (setting source read-only, draining CDC, promoting target), and re-pointing application endpoints.

Step-by-Step Solution

1
Provision underlying network and access foundations.
Secure, high-bandwidth connection between on-premises and GCP VPC is established.
Data migration tools and replication streams require network routes and IAM permissions before initiation.
2
Start baseline storage migration and continuous database replication.
Historical media files land in Cloud Storage while database CDC catches up initial state.
Both file transfer and CDC replication run concurrently to minimize overall migration timeline.
3
Validate synchronization status and replication lag.
Target environment parity is confirmed with minimal CDC replication lag.
Cutting over without verifying synchronization risks data loss or extended cutover downtime.
4
Execute database cutover sequence: set source read-only, drain CDC stream, and promote target.
Target Cloud SQL instance becomes the writable primary database with zero lost transactions.
Locking writes at the source prevents data divergence and guarantees transactional consistency.
5
Re-point application traffic to the target GCP environment.
Production traffic successfully operates against GCP.
Final stage switches active workload to GCP once the target database is promoted and operational.

Key Concept

Staging continuous database and data transfer migrations to achieve minimal downtime and zero data loss on GCP.
Question 338Question →

A healthcare organization is architecting a high-throughput genomic processing platform on Google Cloud. The core containerized pipeline executes compute-intensive analysis jobs that run continuously for up to 4 hours per execution. The pipeline depends on specialized third-party Linux kernel modules that must be loaded directly into the host operating system kernel, and it requires raw block access to high-performance local NVMe SSDs formatted with custom filesystem mount parameters. The organization wants to minimize operational overhead while fully satisfying all technical requirements. Which compute platform should the Cloud Architect select for this workload?

Show answer & explanation

Answer: Compute Engine Managed Instance Groups (MIGs) using a custom VM OS image pre-configured with the required kernel modules and local NVMe SSD scripts

Answer

Compute Engine Managed Instance Groups (MIGs) using a custom VM OS image pre-configured with the required kernel modules and local NVMe SSD scripts.
Compute Engine provides full Infrastructure-as-a-Service (IaaS) control over virtual machines. When a workload demands specific Linux kernel modules loaded at the host layer and custom local NVMe SSD storage initialization, custom Compute Engine OS images built into Managed Instance Groups provide the required control alongside operational automation.

Step-by-Step Solution

1
Analyze host-level system dependencies
Identified requirements for third-party host Linux kernel module loading and direct local NVMe SSD custom formatting.
Managed compute abstractions (Cloud Run, App Engine, GKE Autopilot) restrict access to host OS kernel modifications and raw hardware tuning.
2
Evaluate serverless and fully managed compute services against host customization constraints
Ruled out Cloud Run, App Engine Flexible, and GKE Autopilot.
Fully managed compute options lock down node OS kernels for stability and security, preventing custom kernel module injection.
3
Select the optimal compute platform providing OS kernel control with automation capabilities
Compute Engine Managed Instance Groups with a custom OS image.
Compute Engine provides complete root access to VM instances, allowing custom image builds with pre-loaded kernel modules, custom disk mount scripts, and automated lifecycle management via MIG auto-healing and scaling.

Key Concept

Compute Platform Selection Constraints and Host OS Customization
Question 339Question →

A financial analytics firm is planning to migrate its core infrastructure to Google Cloud. The workload includes 1.2 PB of historical unstructured market data stored on an on-premises SAN and an active 8 TB MySQL database supporting real-time trading analytics. The firm has a dedicated 1 Gbps network connection to Google Cloud via Dedicated Interconnect, with a maximum allocated bandwidth of 700 Mbps for migration traffic. Enterprise compliance requires complete transfer of historical data within 21 days, and the business allows a maximum database cutover downtime window of 4 hours. Which architecture and data transfer strategy successfully meets these operational and business constraints?

Show answer & explanation

Answer: Order a GCP Transfer Appliance to transfer the 1.2 PB historical market data offline to Cloud Storage, and utilize Database Migration Service (DMS) for Cloud SQL for MySQL to perform initial data loading and continuous change data capture (CDC) over Dedicated Interconnect prior to final cutover.

Answer

Order a GCP Transfer Appliance to perform an offline transfer of the 1.2 PB historical market data to Cloud Storage, and use Database Migration Service (DMS) with continuous Change Data Capture (CDC) over Dedicated Interconnect to migrate the 8 TB MySQL database to Cloud SQL for MySQL.
The correct strategy combines an offline Transfer Appliance for the 1.2 PB static historical dataset with Database Migration Service (DMS) over Dedicated Interconnect for the 8 TB MySQL database. The network calculation shows that transferring 1.2 PB over 700 Mbps would take over 150 days, making an offline appliance necessary to meet the 21-day timeline. Furthermore, continuous CDC via DMS keeps the destination database updated in real-time, allowing the final cutover to take place well within the 4-hour downtime window.

Step-by-Step Solution

1
Calculate network throughput feasibility for historical data transfer.
Streaming 1.2 PB (1.2×10151.2 \times 10^{15} bytes) over 700 Mbps (0.7 Gbps0.7 \text{ Gbps}) yields ≈7.56 TB/day\approx 7.56 \text{ TB/day}, taking over 158 days. Offline appliance transfer is mandatory to meet the 21-day window.
Online transfer cannot meet the time constraints of the SLA over the existing network bandwidth.
2
Evaluate database cutover downtime constraints.
Moving an 8 TB database within a 4-hour downtime window requires continuous replication (CDC) to keep the target cloud database synchronized prior to a swift DNS cutover.
Full offline dump and restore of 8 TB would exceed 4 hours of downtime.
3
Select appropriate target GCP database and migration service.
Use Cloud SQL for MySQL with Database Migration Service (DMS) using Dedicated Interconnect for secure, low-latency CDC replication streams.
Cloud SQL maintains native MySQL compatibility without requiring application refactoring for Spanner, while DMS handles continuous CDC seamlessly.

Key Concept

Designing hybrid data migration strategies balancing network bandwidth limitations, offline appliances, and database replication services.
Question 340Question →

A platform engineering team operates a legacy web application on a fleet of Compute Engine instances. The application writes structured JSON operational logs to a local file at `/var/log/app/service.log`. The team needs to configure automated real-time operational alerts in Cloud Monitoring whenever the frequency of HTTP 5xx server errors parsed from this log file exceeds 50 occurrences within a 1-minute rolling window across the fleet. The solution must follow Google Cloud best practices for observability and operational alerting. Which approach should the team implement?

Show answer & explanation

Answer: Install and configure the Google Cloud Ops Agent on the Compute Engine instances to collect and parse the custom log file. Create a Cloud Logging log-based counter metric with a filter matching HTTP 5xx response codes, and configure a Cloud Monitoring alert policy based on the log-based metric threshold exceeding 50 per minute.

Answer

Install and configure the Google Cloud Ops Agent on the Compute Engine instances to collect and parse the custom log file, create a Cloud Logging log-based counter metric with a filter matching HTTP 5xx response codes, and configure a Cloud Monitoring alert policy based on the log-based metric threshold exceeding 50 per minute.
The correct approach uses the Ops Agent to collect and parse custom application logs from Compute Engine instances. Creating a Cloud Logging log-based metric extracts a count of HTTP 5xx errors into Cloud Monitoring, where an alert policy can monitor the metric threshold (50 errors per minute) and trigger notifications appropriately.

Step-by-Step Solution

1
Configure log ingestion and parsing with the Ops Agent
Custom application log entries from `/var/log/app/service.log` are ingested into Cloud Logging as structured log payload fields.
Compute Engine instances require the Ops Agent to read local custom log files and parse structured log fields such as HTTP status codes.
2
Create a Cloud Logging log-based counter metric
A numerical time-series metric is generated based on the frequency of log entries matching HTTP status code ≥500\geq 500.
Log-based metrics extract numerical data from log entries, allowing Cloud Monitoring to evaluate threshold conditions over time.
3
Set up a Cloud Monitoring alert policy
An alert is triggered automatically whenever the log-based metric count exceeds 50 within a 1-minute window.
Cloud Monitoring alert policies continuously evaluate metric time-series against defined thresholds and send notifications when breached.

Key Concept

Configuring Cloud Logging log-based metrics and Cloud Monitoring alert policies for custom application logs
PreviousPage 17 / 80Next
All practice questions — Google Cloud Professional Cloud Architect | Examkin