All practice questions

1591 questions

All types1,591 Multiple choice816 Multiple select491 Numeric12 Matching10 Ordering262

An infrastructure team is deploying two serverless microservices to Google Cloud using the gcloud CLI:

1. A containerized backend service deployed to Cloud Run that listens internally on custom TCP port 9090.
2. A lightweight HTTP-triggered webhook processing service deployed as a Cloud Functions (2nd gen) service.

Which TWO configuration choices or gcloud command options must be specified to successfully deploy these serverless applications? (Select TWO.)

Select all that apply

Pass the `--port=9090` flag during `gcloud run deploy` so Cloud Run routes incoming HTTP requests to the container's custom listening port.

Hardcode the environment variable `PORT=8080` inside the container Dockerfile and rely on Cloud Run to automatically translate incoming traffic from port 9090.

Execute `gcloud functions deploy` specifying `--gen2` and `--trigger-http` to deploy the webhook processor as a 2nd gen function.

Execute `gcloud functions deploy` with the `--image` flag pointing to an Artifact Registry container image to deploy multi-container serverless applications.

Show answer & explanation

Answer: Pass the `--port=9090` flag during `gcloud run deploy` so Cloud Run routes incoming HTTP requests to the container's custom listening port.; Execute `gcloud functions deploy` specifying `--gen2` and `--trigger-http` to deploy the webhook processor as a 2nd gen function.

Answer

The correct configurations are specifying `--port=9090` in `gcloud run deploy` to instruct Cloud Run to forward ingress traffic to custom port 9090, and executing `gcloud functions deploy` with `--gen2` and `--trigger-http` for the 2nd gen HTTP Cloud Function.

Specifying `--port=9090` during Cloud Run deployment explicitly configures the platform to route incoming HTTP requests to port 9090 inside the container. Additionally, deploying an HTTP-triggered 2nd gen Cloud Function requires `gcloud functions deploy` with the `--gen2` and `--trigger-http` flags.

Step-by-Step Solution

Analyze Cloud Run port binding requirements for custom container images.

Cloud Run expects containers to listen on the port defined by the `PORT` environment variable (defaulting to 8080). If the application binary listens on custom port 9090, specifying `--port=9090` during `gcloud run deploy` tells Cloud Run which port to target.

Prevents port mismatch errors and ensures successful health checks.

Identify the standard CLI invocation for deploying Cloud Functions 2nd gen HTTP services.

Executing `gcloud functions deploy [FUNCTION_NAME] --gen2 --trigger-http` deploys the function source to the 2nd gen runtime backed by Cloud Run and Eventarc.

Matches the required gcloud syntax for 2nd gen HTTP event handlers.

Key Concept

Deploying serverless applications using Cloud Run custom port configurations and Cloud Functions (2nd gen) CLI deployment flags

Estimated Time:2m 0s

Question 702Question →

A healthcare analytics platform ingests raw genomic sequencing data into Google Cloud Storage. The data undergoes intensive analytical processing during its first 14 days. After 14 days, the files are rarely accessed, but regulatory compliance mandates that all raw sequence files must be preserved for at least 7 years. Additionally, business continuity policies require that the data be synchronously replicated across two specific geographic regions within North America to guarantee continuous availability during a regional outage. Which TWO configuration steps should the Cloud Engineer implement to satisfy both operational and cost-optimization requirements? (Select TWO)

Select all that apply

Create the Cloud Storage bucket with a Dual-region location setting specifying the two required North American regions.

Configure an Object Lifecycle Management rule to set the bucket's default storage class to Coldline immediately upon object creation.

Configure an Object Lifecycle Management rule to transition objects from Standard storage class to Archive storage class 14 days after creation.

Disable Uniform Bucket-Level Access and configure per-object Access Control Lists (ACLs) to manage object storage classes.

Show answer & explanation

Answer: Create the Cloud Storage bucket with a Dual-region location setting specifying the two required North American regions.; Configure an Object Lifecycle Management rule to transition objects from Standard storage class to Archive storage class 14 days after creation.

Answer

The Cloud Engineer should create a bucket using a Dual-region location setting across the designated regions and apply an Object Lifecycle Management rule transitioning objects from Standard to Archive storage class after 14 days.

Selecting a Dual-region location ensures data replication between the two designated North American regions for high availability. Setting an Object Lifecycle Management rule to move objects from Standard to Archive storage class after 14 days ensures low-cost long-term storage while avoiding retrieval charges during the active analytical processing window.

Step-by-Step Solution

Analyze regional availability requirements.

Dual-region location setting is required to replicate data across two designated regions within North America.

Single-region does not provide multi-region resilience, while Multi-region spans an entire continent without confining data to two specific user-selected regions.

Evaluate data lifecycle access patterns.

Use Standard storage class for the first 14 days of frequent processing, then transition to Archive storage for the 7-year retention period.

Standard storage avoids retrieval fees during high-frequency processing. Transitioning to Archive storage after 14 days minimizes long-term storage costs for compliance data that is rarely accessed.

Key Concept

Cloud Storage Bucket Location Types and Storage Class Lifecycle Management

Question 703Question →

A data engineering team needs to estimate the monthly GCP expenses for storing 50 TB of telemetry logs that are continuously read and analyzed multiple times per hour by real-time operational dashboards. When modeling this workload in the Google Cloud Pricing Calculator, which configuration strategy provides an accurate cost baseline while accounting for the workload access pattern?

Select the Standard Storage class for the bucket estimation to account for frequent data retrieval without incurring data access penalties.

Select the Archive Storage class in the calculator to minimize the per-gigabyte storage rate, assuming read operations will not affect overall costs.

Apply a 3-year Committed Use Discount (CUD) to the Cloud Storage capacity in the calculator to lower the monthly per-gigabyte rate.

Configure Spot VM pricing for the storage bucket to lower hourly rate estimates for the telemetry data.

Show answer & explanation

Answer: Select the Standard Storage class for the bucket estimation to account for frequent data retrieval without incurring data access penalties.

Answer

The correct strategy is to select the Standard Storage class in the calculator because frequently retrieved data will incur heavy per-GB retrieval fees if placed in cold or archive storage tiers.

Selecting Standard Storage is correct because telemetry data accessed multiple times per hour requires zero-retrieval-cost storage. While colder storage classes offer lower baseline per-gigabyte pricing, their high data retrieval fees make them inappropriate for frequently queried active data.

Step-by-Step Solution

Analyze the access pattern specified in the scenario.

The telemetry log data is continuously read and analyzed multiple times per hour by live operational dashboards.

Storage class pricing in Google Cloud depends heavily on access frequency due to retrieval fees on colder tiers.

Evaluate Cloud Storage class cost structures in the Google Cloud Pricing Calculator.

Coldline and Archive classes offer lower storage rates per GB but impose per-GB retrieval costs when data is read. Standard Storage charges zero retrieval fees for data access.

Frequent retrieval renders colder storage tiers significantly more expensive due to operational access fees.

Determine valid discount mechanisms applicable to Cloud Storage.

Committed Use Discounts (CUDs) and Spot pricing models apply to compute infrastructure (vCPUs/RAM), not object storage capacity.

The pricing calculator correctly isolates compute discount mechanisms from standard storage tiering.

Key Concept

Selecting appropriate Cloud Storage classes in the Google Cloud Pricing Calculator based on access patterns and retrieval fees

Question 704Question →

A cloud administrator needs to configure their local terminal environment to manage an existing Google Kubernetes Engine (GKE) cluster named `prod-cluster` located in zone `us-central1-a` using `kubectl`. Which command should the administrator run to fetch cluster credentials and update the local `kubeconfig` file?

gcloud container clusters get-credentials prod-cluster --zone us-central1-a

kubectl config set-cluster prod-cluster --zone us-central1-a

gcloud container clusters describe prod-cluster --zone us-central1-a

gcloud iam service-accounts keys create cluster-key.json --iam-account [email protected]

Show answer & explanation

Answer: gcloud container clusters get-credentials prod-cluster --zone us-central1-a

Answer

The command `gcloud container clusters get-credentials prod-cluster --zone us-central1-a` is the standard tool used to populate the local `kubeconfig` file with cluster endpoint details and authentication tokens.

To manage a GKE cluster with `kubectl`, the administrator must retrieve the cluster's endpoint and authentication credentials using `gcloud container clusters get-credentials <cluster-name> --zone <zone>`. This updates the local `kubeconfig` entry automatically.

Step-by-Step Solution

Identify the target GKE cluster name and location.

Cluster name is `prod-cluster` located in zone `us-central1-a`.

GKE requires location flags (--zone or --region) to locate specific regional or zonal clusters.

Use the Google Cloud CLI `container clusters get-credentials` command.

The local `~/.kube/config` file is generated or updated with context, cluster endpoints, and OAuth credentials.

This bridges GCP IAM permissions with Kubernetes RBAC so `kubectl` CLI commands can authenticate.

Key Concept

Fetching GKE cluster credentials for kubectl authentication

Question 705Question →

An administrator is configuring ingress firewall rules for a Virtual Private Cloud (VPC) network in Google Cloud. Rule-Alpha is configured with a priority of 200 and an action of DENY. Rule-Beta is configured with a priority of 800 and an action of ALLOW. Both rules target the exact same Compute Engine instances and match the exact same protocol and port. Which rule takes precedence when matching traffic arrives?

Rule-Alpha takes precedence because in Google Cloud VPC networks, lower numerical priority values denote higher precedence.

Rule-Beta takes precedence because higher numerical priority values override lower priority values in Google Cloud VPC networks.

Rule-Beta takes precedence because ALLOW rules automatically override DENY rules regardless of priority integer values.

Both rules are evaluated simultaneously, and traffic is allowed by default if any matching ALLOW rule exists.

Show answer & explanation

Answer: Rule-Alpha takes precedence because in Google Cloud VPC networks, lower numerical priority values denote higher precedence.

Answer

Rule-Alpha takes precedence because in Google Cloud VPC networks, lower numerical priority values denote higher precedence.

In Google Cloud VPC firewall rule evaluation, priority is specified as an integer from 0 to 65535. Lower numerical values represent higher relative priority. Because Rule-Alpha has a priority of 200 and Rule-Beta has a priority of 800, Rule-Alpha is evaluated first and its DENY action is enforced.

Step-by-Step Solution

Identify the priority integers assigned to both firewall rules matching the traffic.

Rule-Alpha has priority 200; Rule-Beta has priority 800.

Firewall precedence in GCP is governed by numerical priority values.

Apply Google Cloud VPC firewall rule evaluation ordering rules.

Lower numerical integers indicate higher relative priority (0 is the highest possible priority).

Rule-Alpha (200) is evaluated before Rule-Beta (800).

Determine the outcome for incoming matching network traffic.

Rule-Alpha matches first and enforces its DENY action.

Evaluation stops at the first matching rule in priority order.

Key Concept

GCP VPC Firewall Rule Priority Precedence

Question 706Question →

An enterprise is migrating a custom media-rendering workstation service to Google Cloud Compute Engine instances hosted in a single regional VPC network. The service receives raw, non-HTTP TCP traffic on port 8900 from on-premises client workstations connected across Dedicated Interconnect. You must design a solution that satisfies two core requirements:
1. Route incoming internal traffic across the backend instances while preserving the original client source IP addresses for security auditing.
2. Allow on-premises client workstations to resolve the internal domain name of the load balancer using Cloud DNS.

Which combination of Google Cloud networking services should you plan?

Provision an Internal Passthrough Network Load Balancer targeting the backend instance group, and create a Cloud DNS private zone with an inbound DNS forwarding entry point.

Provision an Internal Application Load Balancer targeting the backend instance group, and create a Cloud DNS private zone with an outbound DNS forwarding policy.

Provision an External Proxy Network Load Balancer targeting the backend instance group, and create a Cloud DNS public zone with DNSSEC enabled.

Provision an External Passthrough Network Load Balancer targeting the backend instance group, and create a Cloud DNS peering zone.

Show answer & explanation

Answer: Provision an Internal Passthrough Network Load Balancer targeting the backend instance group, and create a Cloud DNS private zone with an inbound DNS forwarding entry point.

Answer

Provisioning an Internal Passthrough Network Load Balancer targeting the backend instance group, alongside a Cloud DNS private zone configured with inbound DNS forwarding, meets all protocol, IP preservation, and DNS resolution requirements.

Selecting an Internal Passthrough Network Load Balancer correctly handles regional, private non-HTTP TCP traffic while preserving original client source IP addresses because it is a non-proxied Layer 4 load balancer. Pairing this with a Cloud DNS private zone configured for inbound DNS forwarding allows on-premises systems connected via Dedicated Interconnect to query GCP internal DNS entry points.

Step-by-Step Solution

Analyze protocol and traffic path requirements

Traffic is raw non-HTTP TCP on port 8900 originating internally over Dedicated Interconnect.

This eliminates external load balancers and L7 (HTTP/HTTPS) load balancers which require HTTP/HTTPS traffic protocols.

Evaluate source IP preservation constraints

Internal Passthrough Network Load Balancer is selected.

Passthrough load balancers route packets directly to backends without proxying, preserving the original client source IP address required for security auditing.

Determine DNS forwarding architecture for on-premises clients

Cloud DNS private zone with inbound DNS forwarding policy is selected.

Inbound DNS forwarding provides internal IP entry points for on-premises DNS resolvers to query private DNS zones hosted inside Google Cloud.

Key Concept

Selecting Layer 4 vs Layer 7 load balancers and configuring Cloud DNS Inbound Forwarding for hybrid network architecture.

Estimated Time:2m 0s

Question 707Question →

An organization is configuring billing controls for a newly provisioned Google Cloud environment. The cloud operations team must set up programmatic alert notifications whenever project spending exceeds defined monthly thresholds and export detailed usage data to BigQuery for analytical reporting. Which TWO steps or configuration requirements are necessary to achieve this setup? (Select TWO.)

Select all that apply

Grant the user configuring the budgets and exports the Billing Account Costs Manager or Billing Account Administrator role on the target Cloud Billing account.

Pub/Sub integration must be enabled on the budget to publish message payloads to a Cloud Pub/Sub topic for downstream programmatic handling.

Enable automated resource capping directly within the budget threshold rules to shut down Compute Engine instances when

100\%

of the budget is spent.

Grant the user configuring the billing export the Project Viewer role on the target project to automatically inherit Cloud Billing export administrative access.

Show answer & explanation

Answer: Grant the user configuring the budgets and exports the Billing Account Costs Manager or Billing Account Administrator role on the target Cloud Billing account.; Pub/Sub integration must be enabled on the budget to publish message payloads to a Cloud Pub/Sub topic for downstream programmatic handling.

Answer

The correct requirements are assigning the Billing Account Costs Manager or Administrator role on the Cloud Billing account, and connecting the budget to a Cloud Pub/Sub topic for programmatic alerts.

Configuring Cloud Billing budgets, setting up alerts, and enabling BigQuery billing exports require permissions on the Cloud Billing account itself (such as Billing Account Costs Manager or Billing Account Administrator). Furthermore, for programmatic alert actions (e.g., executing custom code on threshold breach), budgets must publish notifications to a Cloud Pub/Sub topic.

Step-by-Step Solution

Identify IAM role prerequisites for budget and export configuration

Creating budgets and enabling Cloud Billing BigQuery exports requires IAM permissions (such as Billing Account Costs Manager or Billing Account Administrator) at the Billing Account level, not just project level.

Cloud Billing resources reside above project scope in the Google Cloud resource hierarchy.

Determine programmatic notification requirements

Configuring Pub/Sub notifications on the budget sends spend telemetry to a Cloud Pub/Sub topic whenever threshold rules fire.

Budgets do not natively terminate resources; programmatic action relies on Pub/Sub messages consumed by Cloud Functions, Cloud Run, or custom services.

Key Concept

Cloud Billing budget alerts send emails or Pub/Sub notifications but do not cap resources automatically; setup requires Cloud Billing IAM permissions.

Estimated Time:1m 30s

Question 708Question →

A cloud engineering team is constructing an automated CI/CD deployment pipeline to provision infrastructure in a new Google Cloud project named `prod-workloads-456` using Terraform. The pipeline executes using a dedicated deployment service account residing in a central management project `ci-cd-tools-100`. During the initial run of `terraform apply` targeting `prod-workloads-456`, the deployment fails with an error indicating that `compute.googleapis.com` is not enabled. Furthermore, corporate security policy strictly prohibits storing long-lived credentials in pipeline secrets. Which set of actions adheres to Google Cloud best practices to resolve the deployment failure and secure pipeline authentication?

Enable the Compute Engine API directly within the target project `prod-workloads-456`, and configure the CI/CD pipeline to authenticate using short-lived credentials via IAM Service Account Impersonation.

Enable the Compute Engine API in the central management project `ci-cd-tools-100` where the Terraform CLI executes, and export a long-lived service account JSON key for pipeline authentication.

Generate a downloadable service account JSON key, store it in the repository secret manager, and grant the service account `roles/owner` at the organization level to automatically bypass project-level API requirements.

Grant `roles/resourcemanager.organizationAdmin` to the pipeline service account at the parent folder level so that API enablement settings are inherited down the resource hierarchy without modifying the target project.

Show answer & explanation

Answer: Enable the Compute Engine API directly within the target project `prod-workloads-456`, and configure the CI/CD pipeline to authenticate using short-lived credentials via IAM Service Account Impersonation.

Answer

The correct approach requires enabling the required Cloud API (`compute.googleapis.com`) directly on the target project (`prod-workloads-456`) where resources will reside. For pipeline security, Google Cloud recommends using short-lived credentials generated via IAM Service Account Impersonation or Workload Identity Federation instead of downloading persistent JSON keys.

Step-by-Step Solution

Identify API enablement scoping

Determine that Google Cloud APIs (such as `compute.googleapis.com`) are project-scoped and must be enabled specifically in target project `prod-workloads-456` where resources are being created.

Enabling an API in the CI/CD runner's project does not grant permission or enable endpoints in a remote target project.

Select secure authentication mechanism

Choose IAM Service Account Impersonation or Workload Identity Federation instead of downloading persistent JSON service account keys.

Generating static service account keys violates the mandatory policy against persistent key storage in pipeline environments.

Synthesize compliant workflow

Enable the API on `prod-workloads-456` (via `gcloud services enable` or Terraform project service resource) and run Terraform via short-lived impersonated tokens.

This guarantees successful resource provisioning while maintaining compliance with identity and credential security standards.

Key Concept

GCP IaC Security Best Practices and Service API Scoping

Question 709Question →

A firmware distribution engineering team needs to provision a new public Cloud Storage bucket in a dual-region, enforce uniform security permissions, grant anonymous public read access, and attach an object lifecycle policy using the gcloud CLI. What is the correct sequence of steps to configure this storage solution?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: First, create the bucket using gcloud storage buckets create; second, enable Uniform Bucket-Level Access; third, bind the roles/storage.objectViewer IAM role to allUsers; fourth, apply the lifecycle configuration file.

The deployment sequence follows logical GCP operational lifecycle order: provisioning the container resource (gcloud storage buckets create), setting security boundaries (enabling Uniform Bucket-Level Access), defining identity access controls (granting roles/storage.objectViewer to allUsers), and finally applying automated lifecycle rules (updating bucket with --lifecycle-file).

Step-by-Step Solution

Provision the initial Cloud Storage bucket resource.

Bucket gs://firmware-dist-2026 is created in the nam4 dual-region location.

Subsequent configuration commands require an existing bucket target.

Configure bucket security controls.

Uniform Bucket-Level Access is enabled on the bucket.

Best practice requires enforcing uniform access control before assigning bucket-level IAM roles.

Apply IAM access controls.

allUsers identity is assigned roles/storage.objectViewer on the bucket.

Allows public read access to firmware binaries stored inside the bucket.

Apply object lifecycle management.

Lifecycle rules defined in policy.json are active on the bucket.

Automates long-term object state transitions once the bucket operational profile is established.

Key Concept

Sequential provisioning and configuration of Cloud Storage buckets using modern gcloud storage CLI tooling.

Estimated Time:2m 0s

Question 710Question →

A cloud engineer at a genomics research firm needs to set up a new Cloud Storage bucket in `us-east1` to store raw sequencing data. The deployment must enforce Uniform Bucket-Level Access, apply a 30-day object transition rule to Nearline storage defined in a local JSON file, and ingest the initial dataset. In what operational sequence should the engineer execute these tasks?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Provision the bucket using `gcloud storage buckets create` with `--uniform-bucket-level-access`, 2) Create the local `lifecycle.json` policy file, 3) Apply the policy using `gcloud storage buckets update --lifecycle-file=lifecycle.json`, and 4) Upload the data files using `gcloud storage cp`.

The deployment workflow follows a strict dependency order: provision the Cloud Storage bucket with security constraints (Uniform Bucket-Level Access) first, author the local lifecycle policy JSON file second, attach the policy to the existing bucket third, and upload the data files fourth.

Step-by-Step Solution

Provision the Cloud Storage bucket using `gcloud storage buckets create` with `--uniform-bucket-level-access`.

The target bucket `gs://genomics-sequencing-data-2026` is created in `us-east1` with uniform bucket-level access enabled.

A Cloud Storage bucket must exist before any configuration updates or object uploads can take place.

Draft the lifecycle rule definition in a local file named `lifecycle.json`.

A JSON configuration file containing the rule to transition objects to Nearline storage after 30 days is available locally.

The Google Cloud CLI requires a local file path to read the lifecycle policy JSON definition.

Apply the lifecycle policy to the bucket using `gcloud storage buckets update` with `--lifecycle-file`.

The lifecycle rule is attached and active on the target bucket.

Configuring lifecycle policies prior to data ingest ensures all newly uploaded objects are immediately governed by lifecycle rules.

Upload raw sequencing files to the bucket using `gcloud storage cp`.

Sequencing data files are safely transferred into the fully configured Cloud Storage bucket.

Objects should be uploaded only after the bucket parameters and lifecycle rules are active.

Key Concept

Deploying Cloud Storage buckets using modern gcloud storage CLI commands and configuring object lifecycle management policies.

Question 711Question →

A Cloud Engineer needs to provision a new Google Kubernetes Engine (GKE) cluster in zone `us-central1-a` named `web-cluster`, configure local command-line access, and deploy an application defined in a local file named `web-deployment.yaml`. In which sequence should the engineer execute the following commands to successfully deploy and verify the workload?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Create the GKE cluster using `gcloud container clusters create`, 2) Generate local authentication credentials with `gcloud container clusters get-credentials`, 3) Deploy the workload manifest using `kubectl apply -f web-deployment.yaml`, and 4) Verify pod status using `kubectl get pods`.

The correct operational order follows the logical deployment lifecycle in GCP: first create the cluster infrastructure (`gcloud container clusters create`), then obtain API cluster credentials and configure local context (`gcloud container clusters get-credentials`), next apply the workload deployment manifest (`kubectl apply -f`), and finally verify that the pods are running correctly (`kubectl get pods`).

Step-by-Step Solution

Provision the GKE cluster control plane and worker nodes.

The GKE cluster `web-cluster` becomes active and accessible in the target Google Cloud zone.

You cannot retrieve credentials or apply Kubernetes manifests without an active running cluster.

Execute `gcloud container clusters get-credentials` for the cluster.

The local `~/.kube/config` file is populated with entry endpoints and auth tokens for `web-cluster`.

`kubectl` requires local authentication parameters and cluster endpoints to communicate with the GKE control plane API.

Execute `kubectl apply -f web-deployment.yaml`.

Kubernetes API creates the specified Deployment object and starts scheduling Pods.

Manifests can only be applied after `kubectl` has a valid active context pointing to the target cluster.

Execute `kubectl get pods` to verify execution.

Returns the status (e.g., Running) of the newly spawned application pods.

Checking resource status confirms whether image pulling, scheduling, and pod startup succeeded.

Key Concept

GKE Cluster Deployment and Administration Lifecycle

Question 712Question →

A cloud engineering team wants to store Terraform state files remotely in Google Cloud to support team collaboration and state locking. Which TWO steps are required to configure a Cloud Storage bucket as a remote backend for Terraform?

Select all that apply

Create a Cloud Storage bucket in Google Cloud to store the Terraform state file.

Add a `backend "gcs"` block inside the Terraform configuration and specify the bucket name.

Enable the Cloud Monitoring API in the organization root project to initialize state locking.

Generate and export long-lived JSON service account keys to be committed into the shared source repository.

Show answer & explanation

Answer: Create a Cloud Storage bucket in Google Cloud to store the Terraform state file.; Add a `backend "gcs"` block inside the Terraform configuration and specify the bucket name.

Answer

The two required steps are creating a Cloud Storage bucket in Google Cloud to host the state file, and defining a `backend "gcs"` configuration block specifying that bucket.

To set up a remote state backend in Google Cloud using Terraform, you must create a GCS bucket and configure the `backend "gcs"` block in your Terraform configuration files before executing `terraform init`.

Step-by-Step Solution

Provision remote storage

A Google Cloud Storage bucket exists to store state.

Terraform needs an target storage location in GCP before remote initialization.

Define backend configuration

A `terraform { backend "gcs" { bucket = "..." } }` block is added to code.

This instructs Terraform CLI to migrate local state to GCS when running `terraform init`.

Key Concept

Configuring Cloud Storage (GCS) as a remote backend for Terraform state

Question 713Question →

A bio-pharmaceutical research laboratory is planning a Google Kubernetes Engine (GKE) cluster architecture to execute fault-tolerant genomic sequencing batch workloads. The processing engine requires custom Linux kernel sysctl modifications directly on the underlying host node OS to optimize memory paging. Additionally, the finance team requires minimizing compute expenditure for these stateless batch processing jobs. Which TWO architectural decisions should the cloud team implement to satisfy all requirements?

Select all that apply

Provision the cluster using GKE Standard mode to allow custom node pool configurations and node OS kernel tuning.

Configure node pools using Spot VMs to run the fault-tolerant batch processing workloads at a significantly lower cost.

Deploy the workload on GKE Autopilot mode so Google automatically applies the necessary custom kernel sysctl parameters to the worker nodes.

Configure the Horizontal Pod Autoscaler (HPA) to provision additional Compute Engine worker VM instances when genomic processing queues increase.

Avoid Spot VMs and mandate standard On-Demand instances, as GKE node pools do not support fault-tolerant compute configurations.

Show answer & explanation

Answer: Provision the cluster using GKE Standard mode to allow custom node pool configurations and node OS kernel tuning.; Configure node pools using Spot VMs to run the fault-tolerant batch processing workloads at a significantly lower cost.

Answer

The team should select GKE Standard mode to support custom host sysctl kernel parameters and configure node pools with Spot VMs for cost optimization on stateless batch jobs.

Choosing GKE Standard mode grants administrative control over node OS configuration, allowing custom sysctl kernel adjustments needed for memory paging. Combining this with Spot VM node pools optimizes compute expenditure for stateless, fault-tolerant batch workloads.

Step-by-Step Solution

Analyze host OS control requirements

Identify that custom sysctl kernel parameters require node-level OS access.

GKE Autopilot locks down worker node OS configurations to manage security and operations automatically, whereas GKE Standard allows custom node pool settings and sysctl modifications.

Analyze workload fault tolerance and cost requirements

Select Spot VMs for batch workloads.

Genomic sequencing batch jobs are fault-tolerant and stateless, making them perfect candidates for Spot VMs to minimize compute costs.

Key Concept

GKE Cluster Modes & Node Pool Compute Types

Question 714Question →

A DevOps engineer is managing a stateless microservice deployed on a Google Kubernetes Engine (GKE) Standard cluster. The application experiences unpredictable traffic surges. You must configure scaling so that the microservice automatically increases its pod count when average CPU utilization exceeds $75\%$ , and the underlying cluster automatically adds worker nodes whenever pods cannot be scheduled due to insufficient CPU capacity. Which TWO actions should you perform to meet these requirements?

Select all that apply

Create a Horizontal Pod Autoscaler (HPA) resource targeting the deployment with a target CPU utilization of

75\%

Enable the Cluster Autoscaler on the GKE node pool so new nodes are provisioned when pods are in a Pending state due to resource constraints.

Configure Cluster Autoscaler to monitor pod CPU usage thresholds and trigger pod replica scaling within existing nodes.

Provision a GKE Autopilot cluster with fixed node pool limits and disable Horizontal Pod Autoscaler to guarantee zero node management overhead for custom kernel modules.

Show answer & explanation

Answer: Create a Horizontal Pod Autoscaler (HPA) resource targeting the deployment with a target CPU utilization of $75\%$ .; Enable the Cluster Autoscaler on the GKE node pool so new nodes are provisioned when pods are in a Pending state due to resource constraints.

Answer

To handle both workload replica scaling and underlying node infrastructure scaling, create a Horizontal Pod Autoscaler targeting the deployment to manage pod counts based on CPU usage, and enable Cluster Autoscaler on the GKE node pool to manage node capacity when pods are pending.

Proper GKE scaling requires combining Horizontal Pod Autoscaler (HPA) to scale pod replicas based on workload metrics like CPU usage, and Cluster Autoscaler to expand node pool capacity when unschedulable pods are in a Pending state due to resource deficits.

Step-by-Step Solution

Identify the mechanism required for pod-level scaling based on CPU utilization.

Select the Horizontal Pod Autoscaler (HPA) configuration targeting the microservice deployment.

HPA adjusts pod replica counts in response to workload metrics such as CPU utilization reaching

75\%

Identify the mechanism required for node-level capacity expansion when pods cannot be scheduled.

Enable Cluster Autoscaler on the GKE cluster node pool.

Cluster Autoscaler monitors for pods in a Pending state due to insufficient cluster resources and adds compute nodes to accommodate them.

Key Concept

Differentiating Horizontal Pod Autoscaler (HPA) for pod workload scaling and Cluster Autoscaler for node infrastructure scaling in GKE.

Question 715Question →

An organization is preparing to deploy a multi-region workload across `us-central1` and `europe-west1` in Google Cloud. The infrastructure must connect via Cloud VPN to an existing on-premises data center using the IPv4 CIDR block $192.168.0.0/16$ . The cloud networking team needs to plan the Virtual Private Cloud (VPC) network and subnets to prevent IP routing conflicts and accommodate future capacity growth. Which TWO design practices should the team follow? (Select TWO.)

Select all that apply

Create the Virtual Private Cloud (VPC) network in Custom mode rather than Auto mode.

Allocate unique, non-overlapping internal IP ranges (such as

10.10.0.0/24

for `us-central1` and

10.20.0.0/24

for `europe-west1`) for each regional subnet.

Deploy an Auto mode VPC network so Google Cloud automatically manages and expands subnet CIDRs dynamically across regions when IP addresses run low.

Assign the

192.168.10.0/24

CIDR range to the `us-central1` subnet to simplify subnet routing tables shared with the on-premises data center.

Show answer & explanation

Answer: Create the Virtual Private Cloud (VPC) network in Custom mode rather than Auto mode.; Allocate unique, non-overlapping internal IP ranges (such as $10.10.0.0/24$ for `us-central1` and $10.20.0.0/24$ for `europe-west1`) for each regional subnet.

Answer

The team should create the VPC network in Custom mode rather than Auto mode and allocate unique, non-overlapping internal IP ranges (such as 10.10.0.0/24 for us-central1 and 10.20.0.0/24 for europe-west1) for each regional subnet.

Selecting Custom mode gives network administrators full control over subnet creation and IP address assignment. Defining distinct, non-overlapping IP address ranges for each region ensures seamless hybrid connectivity over Cloud VPN without packet drops or routing conflicts.

Step-by-Step Solution

Evaluate VPC Creation Mode for Hybrid Connectivity

Custom mode is chosen because Auto mode creates default subnets in every region using predefined CIDRs that risk overlapping with existing internal on-premises networks.

Enterprise hybrid network planning requires strict manual control over subnet CIDR allocations.

Plan Regional Subnet IPv4 CIDR Allocation

Assign distinct ranges (

10.10.0.0/24

and

10.20.0.0/24

) that do not overlap with each other or the on-premises range (

192.168.0.0/16

Preventing overlapping IP addresses is essential for IP routing across Google Cloud regions and on-premises VPN endpoints.

Key Concept

VPC Subnet IP Address Planning & Custom Mode Network Design

Question 716Question →

Your company manages two separate Virtual Private Cloud (VPC) networks, `corp-app-vpc` and `corp-services-vpc`, within the same Google Cloud project. You have configured a Cloud DNS private zone named `internal.dev.example.com` that is currently visible only to resources in `corp-app-vpc`. Virtual machines deployed in `corp-services-vpc` need to resolve domain names hosted within this private zone without deploying custom DNS forwarding proxy instances. What should you do to allow `corp-services-vpc` to resolve records in `internal.dev.example.com`?

Update the existing Cloud DNS private zone `internal.dev.example.com` to add `corp-services-vpc` to its list of authorized networks.

Enable the Cloud DNS API within the subnet configuration settings of `corp-services-vpc` to allow cross-VPC API inheritance.

Configure an Organization Policy at the project root level to automatically delegate DNS zone resolution inheritance down to all subnets.

Deploy a Network Passthrough Load Balancer in `corp-app-vpc` to load balance incoming DNS traffic from `corp-services-vpc`.

Show answer & explanation

Answer: Update the existing Cloud DNS private zone `internal.dev.example.com` to add `corp-services-vpc` to its list of authorized networks.

Answer

Update the existing Cloud DNS private zone `internal.dev.example.com` to add `corp-services-vpc` to its list of authorized networks.

In Google Cloud, a Cloud DNS private zone can be shared across multiple VPC networks in the same project or across projects. Adding `corp-services-vpc` to the list of authorized networks for the `internal.dev.example.com` private zone allows instances in `corp-services-vpc` to resolve private DNS records natively through Google Cloud's internal DNS service without deploying extra proxy infrastructure.

Step-by-Step Solution

Identify the requirement for cross-VPC private DNS resolution

Determine that VMs in `corp-services-vpc` need native name resolution for records defined in `internal.dev.example.com`.

Cloud DNS private zones are by default scoped only to the authorized VPC networks specified during or after zone creation.

Evaluate the native Cloud DNS configuration settings

Recognize that Cloud DNS allows attaching multiple VPC networks within the same project to a single private zone's authorized networks list.

Modifying the zone's authorized networks grants immediate name resolution access to the specified VPC without requiring extra proxy compute instances or load balancers.

Select the optimal configuration action

Add `corp-services-vpc` to the authorized networks parameter of `internal.dev.example.com`.

This action directly satisfies the operational requirement with minimal complexity and zero additional infrastructure overhead.

Key Concept

Cloud DNS Private Zone Authorization across Multiple VPC Networks

Question 717Question →

An administrator observes that a recent container image update to a Google Kubernetes Engine (GKE) deployment named `web-app` introduced application errors. The administrator needs to inspect the revision history, roll back the deployment to the previous working revision, and confirm that the rollback completes successfully. What is the correct chronological sequence of `kubectl` commands to perform this operation?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of operations is: First, inspect the revision history (`kubectl rollout history deployment/web-app`). Second, execute the rollback to the previous revision (`kubectl rollout undo deployment/web-app`). Third, monitor and verify the rollout status (`kubectl rollout status deployment/web-app`).

When managing GKE workloads, the proper sequence for restoring a failed deployment rollout is: 1) inspect the revision history to identify previous versions (`kubectl rollout history`), 2) revert the deployment to the previous revision (`kubectl rollout undo`), and 3) monitor the progress until completion (`kubectl rollout status`).

Step-by-Step Solution

Run `kubectl rollout history deployment/web-app`

Displays the list of deployment revisions and change causes.

You must inspect the revision history first to verify previous revision numbers before performing a rollback.

Run `kubectl rollout undo deployment/web-app`

Initiates a rolling update to revert the deployment spec to the previous revision.

The `rollout undo` command is the standard Kubernetes command to revert a workload deployment to its prior state.

Run `kubectl rollout status deployment/web-app`

Streams the status updates until all target replicas are running and ready.

Monitoring the status ensures the rollback completes without hanging or failing due to pod creation issues.

Key Concept

GKE Deployment Rollback Operations

Question 718Question →

What is the correct sequence of operational steps to deploy a custom Virtual Private Cloud (VPC) network, provision a regional subnet, deploy a VM instance into that subnet, and enforce ingress firewall rules targeting the instance?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with creating the custom mode VPC network, followed by defining a regional subnet, deploying the VM instance with a target network tag inside that subnet, and finally creating an ingress firewall rule matching the target tag.

In Google Cloud, resource creation follows a strict logical dependency chain. A custom VPC network must be created first because subnets depend on a parent network. Once the custom network exists, a regional subnet must be created to provide IP address space. A VM instance can then be provisioned within that subnet with appropriate target network tags. Finally, an ingress firewall rule is created to target those tags and permit incoming network traffic.

Step-by-Step Solution

Create the parent custom-mode VPC network.

A VPC network resource is created without any automatic default subnets.

Subnets require a parent VPC network resource to exist first.

Create a regional subnet inside the new VPC network.

A subnet IP range is allocated in the specified GCP region.

Compute instances in custom VPC networks require an existing regional subnet for primary network interfaces.

Provision a VM instance in the subnet and apply target network tags.

The VM instance starts with an IP address from the subnet and carries the network tag.

Target tags on instances allow fine-grained firewall rule association.

Create an ingress firewall rule referencing the target network tag.

Traffic matching allowed ports and protocols reaches the tagged VM instance.

Firewall rules govern network access to instances filtered by target network tags.

Key Concept

Deployment lifecycle order for custom mode VPC networks, subnets, VM instances, and firewall rules in Google Cloud.

Question 719Question →

An operations engineer manages a production Google Kubernetes Engine (GKE) Standard cluster named `prod-cluster` in zone `us-central1-a`. The cluster currently runs a batch processing deployment on an on-demand node pool named `batch-pool-v1`. To optimize infrastructure costs, the team must convert this workload to run on Spot VMs without causing service interruption. The engineer attempts to execute an in-place update command on `batch-pool-v1` to convert its VM provisioning type to Spot VMs, but the operational update fails. Which procedure should the engineer perform to successfully transition the workload to Spot VMs?

Create a new node pool named `batch-pool-v2` with the `--spot` flag using `gcloud container node-pools create`, cordon and drain the nodes in `batch-pool-v1` using `kubectl`, and then delete `batch-pool-v1`.

Execute `kubectl autoscale deployment batch-app --enable-spot-instances --min=2 --max=10` to instruct the Horizontal Pod Autoscaler to provision Spot nodes automatically.

Run `gcloud container node-pools update batch-pool-v1 --cluster=prod-cluster --zone=us-central1-a --enable-spot` to force a rolling update of the underlying compute instances.

Update the cluster configuration to GKE Autopilot mode using `gcloud container clusters update prod-cluster --enable-autopilot`, which automatically converts all existing standard node pools to Spot VM pools.

Show answer & explanation

Answer: Create a new node pool named `batch-pool-v2` with the `--spot` flag using `gcloud container node-pools create`, cordon and drain the nodes in `batch-pool-v1` using `kubectl`, and then delete `batch-pool-v1`.

Answer

GKE node pools cannot modify their VM provisioning model (such as switching from On-Demand to Spot VMs) after creation. The standard operational procedure requires creating a new node pool configured with the `--spot` flag, cordoning and draining the existing nodes to smoothly migrate running pods to the new capacity, and subsequently deleting the old node pool.

Step-by-Step Solution

Analyze GKE node pool immutability rules.

Determine that core node pool properties such as machine type, boot disk size, and Spot/Preemptible instance configuration are immutable post-creation.

Google Cloud Engine instance templates backing GKE node pools do not allow changing instance billing/provisioning models on existing pools.

Provision a replacement node pool with Spot VMs enabled.

Execute `gcloud container node-pools create batch-pool-v2 --cluster=prod-cluster --zone=us-central1-a --spot`.

This establishes new node capacity configured specifically to run Spot instances.

Migrate workloads cleanly using Kubernetes administrative commands.

Mark `batch-pool-v1` nodes as unschedulable using `kubectl cordon` and safely evict running pods using `kubectl drain`.

Cordoning prevents new pods from landing on old nodes, while draining forces existing pods to reschedule onto the newly available Spot node pool (`batch-pool-v2`).

Decommission the legacy node pool.

Execute `gcloud container node-pools delete batch-pool-v1 --cluster=prod-cluster --zone=us-central1-a`.

Removes the unneeded on-demand node capacity once all workloads have migrated.

Key Concept

GKE Node Pool Immutability and Blue-Green Workload Migration

Estimated Time:2m 0s

Question 720Question →

An enterprise security auditor requires read-only access to inspect the configuration and operational status of Google Kubernetes Engine (GKE) clusters within a Google Cloud project. The auditor must not have permission to modify cluster settings, delete nodes, or deploy workloads. Following Google's recommended security best practices for least privilege, which IAM role should be assigned to the auditor?

Kubernetes Engine Viewer (roles/container.viewer)

Project Viewer (roles/viewer)

Kubernetes Engine Developer (roles/container.developer)

Kubernetes Engine Cluster Admin (roles/container.clusterAdmin)

Show answer & explanation

Answer: Kubernetes Engine Viewer (roles/container.viewer)

Answer

Kubernetes Engine Viewer (roles/container.viewer)

The Kubernetes Engine Viewer role (roles/container.viewer) grants read-only permissions to view GKE clusters, workloads, and related resources without enabling any modification, creation, or deletion capabilities. This aligns strictly with the principle of least privilege.

Step-by-Step Solution

Analyze the access requirement

The target user requires read-only access to GKE cluster configurations and status without modification rights.

Security auditing requires inspection capabilities without operational control.

Evaluate role options against the Principle of Least Privilege

Primitive roles like Project Viewer grant overly broad access across unrelated GCP services. Service-specific administrative or developer roles grant write access to resources.

Google Cloud IAM best practices dictate assigning predefined roles restricted specifically to the target service and requested access level.

Select the specific predefined role

Kubernetes Engine Viewer (roles/container.viewer) provides read-only access to GKE resources.

It fulfills the exact requirements without granting excess permissions or broad project-wide visibility.

Key Concept

Selecting service-specific predefined IAM roles over primitive roles to satisfy least privilege

Estimated Time:1m 15s

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