All practice questions

1591 questions

All types1,591 Multiple choice816 Multiple select491 Numeric12 Matching10 Ordering262

An enterprise retail organization is planning a Google Kubernetes Engine (GKE) cluster architecture to host an event-driven inventory processing system. The architecture must satisfy the following requirements:
- Worker nodes must reside in private subnets with no public IP addresses assigned to them.
- Nodes must be able to reach external third-party vendor APIs over the internet using a fully managed Google Cloud service.
- Access to the GKE control plane master endpoint must be restricted exclusively to designated management IP addresses.
- Background batch processing workloads are stateless and fault-tolerant, and must run on compute capacity that minimizes infrastructure costs.

Which GKE cluster architecture and configuration should you select to fulfill these requirements?

Provision a Private GKE cluster with Master Authorized Networks enabled, deploy Cloud NAT within the VPC network for outbound traffic, and create a dedicated node pool using Spot VMs for batch processing.

Provision a Private GKE cluster with Master Authorized Networks enabled, rely on the Horizontal Pod Autoscaler (HPA) to provision new Compute Engine instances for outbound connectivity, and disable Cloud NAT.

Provision a Public GKE cluster with Master Authorized Networks disabled, deploy Cloud NAT, and create a Spot VM node pool dedicated to hosting stateful persistent database storage.

Provision a GKE Standard cluster in public mode, configure custom sysctl parameters on private nodes, and rely on Cluster Autoscaler to dynamically provision third-party NAT gateways for outbound traffic.

Show answer & explanation

Answer: Provision a Private GKE cluster with Master Authorized Networks enabled, deploy Cloud NAT within the VPC network for outbound traffic, and create a dedicated node pool using Spot VMs for batch processing.

Answer

The correct choice configures a Private GKE cluster to keep worker nodes on private IP addresses, uses Master Authorized Networks to secure access to the cluster control plane, deploys Cloud NAT for managed outbound internet connectivity, and leverages Spot VMs in a dedicated node pool to minimize infrastructure costs for stateless, fault-tolerant batch workloads.

Step-by-Step Solution

Analyze network isolation and control plane security requirements.

A Private GKE cluster ensures worker nodes receive only internal private IP addresses. Enabling Master Authorized Networks restricts access to the cluster control plane to specified CIDR blocks.

Meets security requirements for private node placement and restricted control plane access.

Determine outbound internet access architecture for private nodes.

Deploying Cloud NAT in the VPC network provides managed, scalable outbound internet access for private nodes without assigning public IP addresses.

Meets the requirement for reaching external APIs without managing self-hosted NAT instances.

Select compute instance type for batch processing workloads.

Provisioning a node pool configured with Spot VMs provides deeply discounted compute capacity suitable for stateless, fault-tolerant batch workloads.

Meets the requirement to minimize infrastructure costs for resilient workloads.

Key Concept

Planning Private GKE Clusters, Cloud NAT Outbound Connectivity, Master Authorized Networks, and Spot VM Node Pools

Estimated Time:2m 0s

Question 582Question →

An associate cloud engineer needs to deploy a Cloud SQL PostgreSQL instance configured exclusively with a Private IP address in a custom Virtual Private Cloud (VPC) network. Place the necessary configuration steps in the correct chronological order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct deployment sequence is: 1) Allocate an IP address range in the VPC network, 2) Create a private connection to the Service Networking API, 3) Provision the Cloud SQL instance with the private network flags, and 4) Create database users and schemas.

Deploying a Cloud SQL instance with Private IP connectivity requires setting up Private Services Access first. You must first reserve an IP address block in your VPC, then establish a private service connection (VPC peering) to the Service Networking API. After peering is established, you create the Cloud SQL instance attached to that network without a public IP assigned. Finally, once the instance is running, you configure database users and application schemas.

Step-by-Step Solution

Allocate an IP range for Private Services Access

Reserved IP range is ready in the VPC network for Google service networking.

Google Cloud SQL private IP instances rely on Private Services Access, which requires a reserved IP address range in your VPC.

Establish VPC Network Peering connection

VPC Network Peering is established between the target VPC network and the Google managed services network.

This private connection enables private IP routing between compute resources in the VPC and the Cloud SQL instance.

Provision the Cloud SQL instance with private IP settings

The instance is created with a private IP address within the peered network range.

Specifying the VPC network and suppressing public IP assignment ensures the database instance is isolated to private traffic.

Configure database users and initial schema

Database instance is populated with access credentials and ready for application connections.

User and schema configuration occurs after the underlying database infrastructure and networking are active.

Key Concept

Provisioning Cloud SQL with Private IP using Private Services Access

Estimated Time:1m 0s

Question 583Question →

A cloud engineer must deploy an updated containerized microservice to an existing private Google Kubernetes Engine (GKE) cluster named `private-app-cluster` in zone `us-east4-a`. The cluster control plane is configured with private endpoint access only, and the engineer is operating from an authorized internal management workstation. In what sequence should the engineer execute the operational steps to establish private cluster connectivity, generate local cluster authentication, deploy the application manifest, and verify workload rollout?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Establish a secure network path to the private GKE control plane, 2) Execute `gcloud container clusters get-credentials private-app-cluster --zone us-east4-a --internal-ip`, 3) Execute `kubectl apply -f microservice-deployment.yaml`, and 4) Execute `kubectl rollout status deployment/microservice-app`.

The deployment of workloads to a private GKE cluster follows a logical dependency chain: network connectivity to the private master endpoint must exist first, followed by authentication setup via `gcloud container clusters get-credentials --internal-ip`. Once `kubectl` context is configured, the manifest is submitted with `kubectl apply`, and finally, the rollout state is verified with `kubectl rollout status` to confirm operational readiness.

Step-by-Step Solution

Ensure network connectivity to the private GKE control plane internal IP address.

Network routes allow TCP traffic to reach the GKE master API server on port 443.

Private GKE clusters disable public endpoint access, requiring internal network routing or bastion access prior to API invocation.

Run `gcloud container clusters get-credentials` using the `--internal-ip` flag.

The local `~/.kube/config` file is updated with cluster endpoint details and user credentials.

Without fetching credentials and specifying `--internal-ip`, local `kubectl` calls will fail to resolve or reach the private control plane.

Run `kubectl apply -f microservice-deployment.yaml`.

The Kubernetes API server accepts the deployment specification and schedules requested pods.

Deploying the manifest requires an active, authenticated `kubectl` context pointing to the control plane.

Run `kubectl rollout status deployment/microservice-app`.

Real-time deployment lifecycle progress is displayed until all updated replicas are healthy and operational.

Verification ensures that the deployment was not only submitted but also successfully completed without container crashes or scheduling failures.

Key Concept

Private GKE Cluster Management and Workload Deployment Workflow

Question 584Question →

You are deploying a Regional Internal Application Load Balancer in Google Cloud to route internal traffic among microservices running on Compute Engine instance groups within a Virtual Private Cloud (VPC) network. What is the correct sequence of administrative steps required to successfully provision this load balancer infrastructure?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins by creating a proxy-only subnet in the region, followed by provisioning the regional health check, backend service, and attaching backend instance groups. Next, the regional URL map and target HTTP proxy are created to handle HTTP routing rules. Finally, the regional forwarding rule is configured to assign an internal IP address and link incoming network traffic to the target HTTP proxy.

The proper sequence follows GCP resource dependency hierarchy for Envoy-based internal load balancers: 1) Allocate a proxy-only subnet in the region to support proxy infrastructure, 2) Define the backend tier (health check, backend service, and instance group membership), 3) Configure routing objects (URL map linked to backend service, then target HTTP proxy linked to URL map), and 4) Provision the frontend forwarding rule that links an internal IP address to the target HTTP proxy.

Step-by-Step Solution

Provision the prerequisite proxy-only subnet

Reserved IP range allocated specifically for Envoy proxy instances in the VPC region.

Regional Internal Application Load Balancers rely on Envoy proxies which demand a dedicated proxy-only subnet in the active region prior to target proxy deployment.

Configure health checking, backend service, and backend MIG resources

Backend service established with health monitoring and attached instance group targets.

Routing abstractions depend on a valid backend service that defines traffic distribution policies and target endpoints.

Define HTTP request routing via URL map and target proxy

URL map points to the backend service, and target proxy binds to the URL map.

The target proxy processes incoming HTTP connections according to the path and host rules defined within the URL map.

Establish the frontend forwarding rule

Internal IP endpoint bound to port 80/443 directing incoming VPC requests to the target proxy.

The forwarding rule serves as the entry point for client traffic, pointing directly to the target proxy.

Key Concept

Deployment dependency sequence for Envoy-based Regional Internal Application Load Balancers in GCP

Question 585Question →

A cloud administrator is provisioning a Compute Engine virtual machine using the Google Cloud CLI. Which of the following command flags or configurations are valid when running `gcloud compute instances create`? Select TWO correct options.

Select all that apply

Passing `--zone=us-central1-a` to designate the specific zonal location where the VM instance will be provisioned.

Passing `--metadata-from-file=startup-script=path/to/script.sh` to execute a local shell script upon VM instance boot.

Passing `--region=us-central1-a` to specify the exact single-zone deployment target for the VM instance.

Passing `--provisioning-model=SPOT` to guarantee zero instance interruptions for a mission-critical transactional database.

Show answer & explanation

Answer: Passing `--zone=us-central1-a` to designate the specific zonal location where the VM instance will be provisioned.; Passing `--metadata-from-file=startup-script=path/to/script.sh` to execute a local shell script upon VM instance boot.

Answer

The valid configurations are designating the zone using `--zone=us-central1-a` and specifying a local startup script file using `--metadata-from-file=startup-script=path/to/script.sh`.

Specifying `--zone=us-central1-a` correctly identifies the specific zone for the Compute Engine instance, and `--metadata-from-file=startup-script=...` is the correct gcloud syntax for supplying a local script file to run during instance initialization.

Step-by-Step Solution

Identify valid zonal deployment flags for Compute Engine CLI deployments.

Confirm that `--zone` accepts zone values like `us-central1-a`, whereas `--region` accepts region values like `us-central1`.

CLI syntax requires proper matching of flags to resource scopes.

Evaluate startup script metadata flag syntax.

Confirm that `--metadata-from-file=startup-script=...` is the proper flag to upload a local file as startup metadata.

This automates instance bootstrapping upon startup.

Evaluate workload suitability for Spot VM provisioning.

Reject Spot instances for critical transactional databases.

Spot/Preemptible VMs can be terminated by GCP at any time.

Key Concept

Deploying Compute Engine VMs via gcloud CLI and configuring placement and metadata options.

Estimated Time:1m 0s

Question 586Question →

A financial analytics firm is deploying a Cloud Storage bucket named `fin-reports-eu-2026` in the `europe-west3` region to store monthly transaction summaries. Security policies require that all object access be managed strictly through Google Cloud IAM permissions rather than per-object Access Control Lists (ACLs). Additionally, to optimize long-term storage costs, transaction reports older than 30 days must automatically transition to Nearline storage. Which TWO actions using modern `gcloud storage` commands should the cloud engineer perform to meet these requirements?

Select all that apply

Run `gcloud storage buckets update gs://fin-reports-eu-2026 --enable-uniform-bucket-level-access` to enforce unified IAM permissions across all objects.

Define a lifecycle configuration JSON file specifying an `age` condition of 30 days with a `SetStorageClass` action set to `NEARLINE`, and execute `gcloud storage buckets update gs://fin-reports-eu-2026 --lifecycle-file=lifecycle.json`.

Run `gsutil acl ch -u AllUsers:R gs://fin-reports-eu-2026` to convert existing ACLs into inherited IAM permissions.

Execute `gcloud storage objects update gs://fin-reports-eu-2026/* --storage-class=NEARLINE --age=30d` to update object classes retroactively.

Show answer & explanation

Answer: Run `gcloud storage buckets update gs://fin-reports-eu-2026 --enable-uniform-bucket-level-access` to enforce unified IAM permissions across all objects.; Define a lifecycle configuration JSON file specifying an `age` condition of 30 days with a `SetStorageClass` action set to `NEARLINE`, and execute `gcloud storage buckets update gs://fin-reports-eu-2026 --lifecycle-file=lifecycle.json`.

Answer

The correct configuration requires running `gcloud storage buckets update gs://fin-reports-eu-2026 --enable-uniform-bucket-level-access` to enforce IAM access control and applying a lifecycle policy JSON file using `gcloud storage buckets update gs://fin-reports-eu-2026 --lifecycle-file=lifecycle.json` to transition objects to Nearline storage after 30 days.

To satisfy security requirements restricting access management solely to IAM, Uniform Bucket-Level Access must be enabled using the `gcloud storage buckets update` command with the `--enable-uniform-bucket-level-access` flag. To automate storage class migration based on object age, a bucket lifecycle rule JSON file must be defined and bound to the bucket using `--lifecycle-file`.

Step-by-Step Solution

Enforce uniform bucket-level access control on the storage bucket.

Disables individual object ACLs and forces permission evaluation through IAM roles.

Security governance mandates IAM-based access control rather than granular ACL grants per object.

Draft a lifecycle JSON policy with an age rule condition of 30 days and action type `SetStorageClass` with value `NEARLINE`.

Defines automated lifecycle management rules for object tiering.

Automating storage class migration minimizes manual operational overhead and reduces storage costs.

Execute `gcloud storage buckets update gs://fin-reports-eu-2026 --lifecycle-file=lifecycle.json`.

Applies the lifecycle policy configuration to the target Cloud Storage bucket using current Google Cloud CLI commands.

`gcloud storage` is the recommended CLI interface for bucket configuration and management in Google Cloud.

Key Concept

Configuring Cloud Storage access governance with Uniform Bucket-Level Access and automated tiering via bucket lifecycle management in `gcloud storage`.

Question 587Question →

An organization requires a security audit service account to review configuration settings for Compute Engine virtual machines and BigQuery datasets across all projects within a folder. The service account must be able to inspect resource metadata and settings, but must NOT be allowed to read table data inside BigQuery or interact with VM guest OS instances. Which TWO predefined IAM roles should be granted to the service account at the folder level to satisfy the principle of least privilege? (Select TWO answers.)

Select all that apply

Compute Viewer (roles/compute.viewer)

BigQuery Metadata Viewer (roles/bigquery.metadataViewer)

Editor (roles/editor)

Viewer (roles/viewer)

Show answer & explanation

Answer: Compute Viewer (roles/compute.viewer); BigQuery Metadata Viewer (roles/bigquery.metadataViewer)

Answer

The correct roles to grant are Compute Viewer (roles/compute.viewer) and BigQuery Metadata Viewer (roles/bigquery.metadataViewer).

Granting Compute Viewer (roles/compute.viewer) and BigQuery Metadata Viewer (roles/bigquery.metadataViewer) perfectly fulfills the security requirements. Compute Viewer allows inspecting VM configurations without granting interactive access or write permissions. BigQuery Metadata Viewer allows listing and viewing dataset schemas and table metadata while explicitly withholding access to actual table contents.

Step-by-Step Solution

Analyze the requirements for Compute Engine access.

The requirement specifies inspecting VM configurations without interactive access, which maps directly to the predefined Compute Viewer role.

Compute Viewer (roles/compute.viewer) grants permission to list and view VM properties without granting SSH or modification capabilities.

Analyze the requirements for BigQuery access.

The requirement specifies reading dataset and table metadata while strictly prohibiting access to table data, which maps directly to BigQuery Metadata Viewer.

BigQuery Metadata Viewer (roles/bigquery.metadataViewer) exposes dataset structures and table schemas without granting table data read permissions.

Evaluate and eliminate primitive roles.

Primitive roles like Editor and Viewer are eliminated because they grant overly broad permissions across all services.

Google Cloud security best practices mandate using granular predefined or custom roles over primitive roles to maintain least privilege.

Key Concept

Selecting predefined IAM roles to enforce least privilege access controls

Question 588Question →

A cloud infrastructure engineer is designing a Google Cloud Virtual Private Cloud (VPC) network for a workload deployed across $2$ specific regions: `us-central1` and `europe-west1`. Corporate policy mandates full control over IP address range allocations to prevent collisions with existing corporate networks, and strictly prohibits provisioning subnets in any unused regions. Which VPC creation method and configuration should the engineer implement?

Create a custom-mode VPC network and manually define subnets only in `us-central1` and `europe-west1` with non-overlapping CIDR ranges.

Create an auto-mode VPC network and select `us-central1` and `europe-west1` as the designated subnet regions during creation.

Create an auto-mode VPC network and delete the automatically generated subnets in all regions except `us-central1` and `europe-west1`.

Create a custom-mode VPC network with the automatic subnet allocation flag enabled specifically for `us-central1` and `europe-west1`.

Show answer & explanation

Answer: Create a custom-mode VPC network and manually define subnets only in `us-central1` and `europe-west1` with non-overlapping CIDR ranges.

Answer

Create a custom-mode VPC network and manually define subnets only in `us-central1` and `europe-west1` with non-overlapping CIDR ranges.

Creating a custom-mode VPC network allows full architectural control because no subnets are created automatically. The network engineer can manually define subnets only in the required regions (`us-central1` and `europe-west1`) and assign specific, non-overlapping IP address ranges that conform to corporate IP governance policies.

Step-by-Step Solution

Evaluate the requirements for subnet provisioning and IP address control.

The requirement specifies provisioning subnets in only two regions while preventing IP range collisions with existing corporate networks.

Enterprise hybrid environments require strict IP management to avoid routing issues and IP address overlaps.

Compare Google Cloud VPC network modes (Auto-mode vs. Custom-mode).

Auto-mode automatically creates a subnet in every GCP region using predefined set ranges (

10.128.0.0/9

). Custom-mode creates zero subnets upon creation, giving full manual control over subnet regions and CIDR blocks.

Auto-mode violates the constraint against provisioning subnets in unused regions and risks IP overlap with corporate networks.

Select the correct VPC deployment pattern.

Custom-mode VPC network creation allows manual specification of subnets exclusively in `us-central1` and `europe-west1`.

This fulfills all security and enterprise IP governance requirements.

Key Concept

Custom-mode vs. Auto-mode VPC Network Planning

Question 589Question →

A developer wants to deploy an HTTP-triggered serverless function written in Python directly from source code using the Google Cloud CLI. Which gcloud command should the developer execute to perform this deployment?

gcloud functions deploy FUNCTION_NAME --runtime=python311 --trigger-http

gcloud run deploy FUNCTION_NAME --image=python311 --trigger-http

gcloud compute instances create FUNCTION_NAME --runtime=python311

gcloud serverless deploy FUNCTION_NAME --runtime=python311

Show answer & explanation

Answer: gcloud functions deploy FUNCTION_NAME --runtime=python311 --trigger-http

Answer

The command 'gcloud functions deploy FUNCTION_NAME --runtime=python311 --trigger-http' correctly deploys a Python function with an HTTP endpoint using the Cloud SDK.

The correct command 'gcloud functions deploy FUNCTION_NAME --runtime=python311 --trigger-http' specifies the correct command group ('functions'), action ('deploy'), function name, runtime environment, and HTTP trigger flag required for deploying a serverless Cloud Function.

Step-by-Step Solution

Identify the target serverless product

The requirement specifies deploying function source code as a Cloud Function, which corresponds to the 'gcloud functions' command group.

Choosing the appropriate command group is essential for invoking the correct service API.

Specify the required deployment parameters

Set the function name, runtime environment ('--runtime=python311'), and invocation type ('--trigger-http').

Cloud Functions deployments require specifying the execution runtime and how the function is triggered.

Key Concept

Deploying Cloud Functions via gcloud CLI

Estimated Time:45s

Question 590Question →

An enterprise healthcare organization is designing the ingestion architecture for a real-time patient monitoring platform. Connected medical sensors deployed worldwide stream telemetry over a proprietary, non-HTTP raw TCP protocol with TLS encryption. The system architecture requires terminating TLS at Google's global edge network to reduce backend handshake latency, and then proxying the raw TCP payload to Compute Engine backend instance groups distributed across multiple Google Cloud regions. Which Google Cloud load balancing solution should you select to satisfy these requirements?

Global External Proxy Network Load Balancer

Global External Application Load Balancer

Regional External Passthrough Network Load Balancer

Regional Internal Passthrough Network Load Balancer

Show answer & explanation

Answer: Global External Proxy Network Load Balancer

Answer

The Global External Proxy Network Load Balancer is the correct choice because it supports raw non-HTTP TCP traffic, terminates TLS at Google's global edge infrastructure, and distributes incoming client connections across multi-region backend instance groups.

The Global External Proxy Network Load Balancer acts as a Layer 4 reverse proxy with global reach. It supports raw non-HTTP TCP protocols, terminates TLS at Google Cloud edge points of presence (PoPs), and balances connection loads to instance groups across multiple GCP regions.

Step-by-Step Solution

Analyze protocol requirements

Workload uses proprietary raw TCP (non-HTTP), eliminating Layer 7 (HTTP/HTTPS) Application Load Balancers.

Application Load Balancers inspect Layer 7 HTTP request headers and fail on raw binary TCP streams.

Analyze security and edge termination requirements

TLS must be terminated at Google's edge network, requiring a reverse proxy architecture.

Passthrough load balancers pass client TCP packets untouched directly to backends without offloading TLS at the edge.

Analyze scope and traffic direction

Clients connect from the internet globally to multi-region backends, requiring a global external load balancer.

Internal load balancers only accept traffic originating from within the VPC or connected private networks.

Key Concept

Selecting GCP Load Balancers based on protocol (L4 vs L7), traffic scope (External vs Internal), and proxying behavior (Passthrough vs Edge Proxy/TLS offloading).

Estimated Time:2m 0s

Question 591Question →

Your company hosts a global web application running on Compute Engine managed instance groups across multiple Google Cloud regions. You need to expose the application externally to internet clients, optimize user latency by routing traffic to the nearest healthy region, and offload SSL/TLS termination at the edge. Which load balancer should you deploy?

Global External Application Load Balancer

Regional External Application Load Balancer

External Passthrough Network Load Balancer

Internal Passthrough Network Load Balancer

Show answer & explanation

Answer: Global External Application Load Balancer

Answer

Global External Application Load Balancer

The Global External Application Load Balancer is a Layer 7 proxy load balancer capable of routing HTTP and HTTPS traffic from external clients to backends located across multiple Google Cloud regions. It terminates TLS connections at Google's point of presence (PoP) edge network, ensuring low-latency routing to the closest healthy instance group.

Step-by-Step Solution

Analyze client accessibility requirements

External internet access is required, ruling out internal load balancers.

The load balancer must accept traffic directly from internet clients.

Analyze protocol and feature requirements

HTTP(S) protocol support and edge SSL termination require a Layer 7 (Application) load balancer.

Passthrough network load balancers operate at Layer 4 and do not terminate SSL/TLS.

Analyze geographical scope requirements

Routing traffic across backend instance groups in multiple regions requires a global load balancer.

Regional load balancers are restricted to backends within a single region.

Key Concept

Selecting GCP Load Balancers based on traffic scope, protocol, and regionality

Estimated Time:1m 30s

Question 592Question →

A DevOps team is deploying a new Google Cloud Storage bucket named `media-ingest-prod-2026` in the `us-central1` region to process incoming video uploads. According to organizational compliance guidelines and Google Cloud best practices, the bucket must enforce uniform access control via IAM policies instead of legacy per-object ACLs, and object versioning must be enabled at creation time. Which `gcloud` command should the team execute to create the bucket with these requirements?

`gcloud storage buckets create gs://media-ingest-prod-2026 --location=us-central1 --uniform-bucket-level-access --enable-object-versioning`

`gsutil mb -l us-central1 -b on gs://media-ingest-prod-2026`

`gcloud storage buckets create gs://media-ingest-prod-2026 --location=us-central1 --no-uniform-bucket-level-access --enable-object-versioning`

`gcloud storage buckets update gs://media-ingest-prod-2026 --location=us-central1 --uniform-bucket-level-access`

Show answer & explanation

Answer: `gcloud storage buckets create gs://media-ingest-prod-2026 --location=us-central1 --uniform-bucket-level-access --enable-object-versioning`

Answer

Execute `gcloud storage buckets create gs://media-ingest-prod-2026 --location=us-central1 --uniform-bucket-level-access --enable-object-versioning` to deploy the bucket with uniform access and versioning enabled.

The correct command uses `gcloud storage buckets create` to provision the bucket and applies `--uniform-bucket-level-access` alongside `--enable-object-versioning` in a single operational step.

Step-by-Step Solution

Identify the primary tool for deployment

Google Cloud recommends using `gcloud storage` CLI commands over legacy `gsutil` for bucket operations.

Modern gcloud storage commands offer improved performance and standardized syntax across GCP tools.

Determine the required flags for security and versioning

Pass `--uniform-bucket-level-access` to enforce IAM-only access and `--enable-object-versioning` to preserve object states.

Uniform bucket-level access disables legacy object ACLs, aligning with security best practices.

Construct the bucket creation command

Combine the bucket URI `gs://media-ingest-prod-2026`, `--location=us-central1`, and the two required configuration flags.

This single gcloud command provisions the bucket with all mandatory parameters at initial creation.

Key Concept

Deploying Cloud Storage Buckets with Uniform Access and Versioning via gcloud CLI

Question 593Question →

A global fleet logistics provider is architecture-planning its next-generation management platform on Google Cloud Compute Engine. The platform requires two distinct traffic paths:

1. Public internet-facing HTTPS web portals accessible to dispatchers globally, requiring low-latency distribution of static web content and media assets using edge cache nodes.
2. Internal-only high-performance gRPC microservice communication between private backend instances located across multiple subnets within the same Virtual Private Cloud (VPC) network.

Which TWO load balancing solutions should the lead cloud architect select to fulfill these requirements? (Select TWO.)

Select all that apply

Deploy a Global External Application Load Balancer for the public dispatcher portal and enable Cloud CDN on its backend service.

Deploy an External SSL Proxy Load Balancer for the public dispatcher portal and enable Cloud CDN on its backend service.

Deploy an Internal Application Load Balancer to manage the internal backend gRPC microservice communication.

Deploy a Regional External Application Load Balancer to route internal gRPC microservice communication between private Compute Engine instances.

Show answer & explanation

Answer: Deploy a Global External Application Load Balancer for the public dispatcher portal and enable Cloud CDN on its backend service.; Deploy an Internal Application Load Balancer to manage the internal backend gRPC microservice communication.

Answer

The architectural requirements are met by deploying a Global External Application Load Balancer with Cloud CDN for the public internet portal, and an Internal Application Load Balancer for private HTTP/2 and gRPC microservice communication.

To serve global HTTPS traffic with edge caching, a Global External Application Load Balancer with Cloud CDN integration is required. For private inter-service gRPC communication within a VPC, an Internal Application Load Balancer provides Layer 7 internal load balancing with native gRPC/HTTP2 support.

Step-by-Step Solution

Analyze public internet traffic and CDN requirements

Identified Layer 7 HTTP(S) requirements along with static content caching at Google edge locations.

Cloud CDN requires an HTTP(S) backend attached to a Global External Application Load Balancer.

Analyze internal microservice communication requirements

Identified private internal VPC traffic using gRPC protocol over HTTP/2.

Internal Application Load Balancers are Layer 7 proxy load balancers operating on private internal IP addresses with native support for HTTP/2 and gRPC.

Evaluate and eliminate non-conforming load balancer options

Disqualified SSL Proxy LB (does not support Cloud CDN) and Regional External LB (exposes private workloads to public internet).

Matching protocol capabilities and exposure scope to load balancer features prevents security breaches and architectural misconfigurations.

Key Concept

Selecting GCP Load Balancers based on Traffic Scope (External vs. Internal), Protocol (Layer 4 vs. Layer 7 / gRPC), and Cloud CDN Integration

Question 594Question →

An enterprise software company is planning the Google Compute Engine infrastructure for a mission-critical, self-hosted in-memory cache running continuously 24/7 with predictable, high-memory resource requirements guaranteed for the next three years. The workload requires high availability and cannot tolerate unexpected VM preemptions or terminations. Which Compute Engine machine configuration and purchasing strategy should the cloud engineer select?

Provision memory-optimized or high-memory standard VM instances and purchase a 3-year Committed Use Discount (CUD) for the baseline compute capacity.

Provision Spot VM instances using memory-optimized machine types to minimize compute costs for the caching layer.

Provision general-purpose VM instances relying solely on automatic Sustained Use Discounts (SUDs) to achieve maximum long-term savings over the 3-year period.

Deploy the in-memory cache workload as a Google Cloud Functions service to eliminate VM server management overhead.

Show answer & explanation

Answer: Provision memory-optimized or high-memory standard VM instances and purchase a 3-year Committed Use Discount (CUD) for the baseline compute capacity.

Answer

Provision memory-optimized or high-memory standard Compute Engine instances paired with a 3-year Committed Use Discount (CUD) commitment.

Memory-optimized or high-memory Compute Engine instance families provide tailored vCPU-to-memory ratios for RAM-heavy workloads such as in-memory caches. Securing capacity with 3-year Committed Use Discounts yields maximum cost optimization for steady, uninterrupted 24/7 baseline workloads without risking VM preemption.

Step-by-Step Solution

Analyze workload resource profile and availability requirements.

Identified a memory-bound, stateful caching workload running 24/7 that cannot tolerate interruptions.

Choosing the correct machine family requires matching high RAM demands while ruling out preemptible/Spot VMs due to zero tolerance for unexpected shutdowns.

Evaluate machine family selection.

Selected memory-optimized or high-memory machine configurations (such as M2/M3 or N2/E2 high-mem).

These machine families deliver optimal cost-per-GB of RAM for memory-intensive caching systems.

Evaluate pricing and commitment options for predictable continuous usage.

Selected 3-year Committed Use Discounts (CUDs).

For continuous 24/7 baseline capacity over 3 years, CUDs provide deep discounts (up to 57%-70%) compared to standard on-demand pricing or automatic Sustained Use Discounts.

Key Concept

Compute Engine Machine Family Selection and Committed Use Discounts (CUDs)

Estimated Time:1m 15s

Question 595Question →

A Cloud Engineer needs to set up a detailed daily Cloud Billing export to BigQuery for central cost governance. Place the steps required to configure and verify this billing export in the correct chronological order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with creating the BigQuery dataset, verifying requisite IAM permissions (Billing Account Administrator and BigQuery Data Editor), navigating to the Cloud Billing export settings in the GCP Console, specifying the target project and dataset to enable Detailed Cost Usage Export, and finally verifying table population in BigQuery.

Configuring BigQuery Cloud Billing exports follows a strict prerequisite workflow: a BigQuery dataset must exist first, proper administrative IAM permissions on both the billing account and dataset must be held, the export sink must be pointed to the project and dataset via the Cloud Billing Console, and data populates into automatically created partitioned tables for verification.

Step-by-Step Solution

Create the destination BigQuery dataset

A target dataset exists to receive billing export data.

Cloud Billing export requires an existing dataset before configuration can be saved.

Confirm IAM permissions

The identity holds Billing Account Administrator on the billing account and BigQuery Data Editor on the dataset.

Without proper roles on both the billing account and destination dataset, setting up the export sink will fail.

Navigate to Cloud Billing export settings

The Billing export management interface is open in the GCP Console.

Billing exports are managed directly within the Cloud Billing account settings.

Configure export details and save

The detailed usage cost export sink is activated pointing to the specified BigQuery dataset.

Explicitly selecting the project ID and dataset binds the billing sink to BigQuery.

Validate table population and query data

Exported tables appear in BigQuery containing resource usage records.

Verifying table generation ensures that automated daily data loading is operating correctly.

Key Concept

Cloud Billing BigQuery Export Configuration Sequence

Question 596Question →

An engineer needs to set up a new environment for processing non-critical batch jobs on Google Kubernetes Engine (GKE) while ensuring efficient resource utilization and enabling direct administration from their local command line interface. Which two steps should the engineer execute to achieve this setup?

Select all that apply

Run gcloud container clusters get-credentials to fetch authentication credentials and update the local kubeconfig file.

Provision a Spot node pool within the GKE cluster to run stateless, fault-tolerant batch processing workloads at reduced compute costs.

Run gcloud config set container/cluster to authenticate the CLI and establish the active kubectl context for cluster management.

Deploy GKE Autopilot clusters when custom Linux kernel parameter modifications and root access to individual node operating systems are required.

Show answer & explanation

Answer: Run gcloud container clusters get-credentials to fetch authentication credentials and update the local kubeconfig file.; Provision a Spot node pool within the GKE cluster to run stateless, fault-tolerant batch processing workloads at reduced compute costs.

Answer

The engineer must run 'gcloud container clusters get-credentials' to populate the local kubeconfig for kubectl access, and provision a Spot node pool to cost-effectively run stateless batch processing workloads.

To interact with a GKE cluster via kubectl, the command 'gcloud container clusters get-credentials' must be used to generate the correct cluster context entry inside kubeconfig. Additionally, running stateless batch workloads on Spot node pools provides significant cost savings while tolerating potential node preemption.

Step-by-Step Solution

Configure command-line administration tools

Local kubeconfig entry created with cluster endpoint and auth token

Executing 'gcloud container clusters get-credentials' allows kubectl to securely connect to the API server.

Select appropriate node pool type for batch workloads

Batch workloads execute on discounted, preemptible Spot instances

Fault-tolerant batch jobs can be reclaimed by GCP without data loss impact, making Spot node pools optimal.

Key Concept

Configuring GKE cluster credentials and selecting appropriate workload compute tiers

Question 597Question →

An organization has two VPC firewall rules applied to a Compute Engine virtual machine instance. Rule A has a priority of 100 and is set to DENY ingress traffic on port 22. Rule B has a priority of 1000 and is set to ALLOW ingress traffic on port 22. Which firewall rule takes precedence when SSH traffic targets the instance?

Rule A takes precedence because in Google Cloud VPC firewall rules, lower priority numbers take higher precedence.

Rule B takes precedence because higher numerical priority values override lower numerical priority values in Google Cloud.

Rule B takes precedence because ALLOW rules automatically override DENY rules regardless of priority settings.

Both rules are evaluated simultaneously, and traffic is permitted because primitive network roles favor connectivity.

Show answer & explanation

Answer: Rule A takes precedence because in Google Cloud VPC firewall rules, lower priority numbers take higher precedence.

Answer

Rule A takes precedence because in Google Cloud VPC firewall rules, lower priority numbers take higher precedence.

In Google Cloud VPC firewall rule ordering, priority is an integer from 0 to 65535, where lower numbers specify higher precedence. Rule A has a priority of 100, which is smaller (higher priority) than Rule B's priority of 1000, so Rule A is evaluated first and DENYs the traffic.

Step-by-Step Solution

Identify the numerical priority values of the competing firewall rules

Rule A has a priority value of 100, and Rule B has a priority value of 1000.

Firewall evaluation in GCP depends primarily on numerical priority order.

Apply Google Cloud VPC firewall priority evaluation logic

Lower integer values denote higher evaluation precedence (0 is highest priority, 65535 is lowest).

Priority 100 is smaller than 1000, so Rule A is evaluated first.

Determine the outcome of the evaluation

Rule A (DENY) matches incoming SSH traffic on port 22 and blocks the connection before Rule B is considered.

Once a matching firewall rule of higher precedence is encountered, it is enforced.

Key Concept

GCP VPC Firewall Rule Priority Precedence

Estimated Time:45s

Question 598Question →

A cloud engineer is deploying a Cloud Storage bucket named `health-analytics-export` to ingest sensitive patient telemetry files that will be accessed occasionally each month. Organization security policy strictly requires that per-object ACLs be disabled in favor of unified IAM management, and that public access to the bucket be explicitly prohibited at the bucket level. Additionally, the bucket must be configured with a default storage class optimized for data accessed at most once a month to minimize storage costs. Which `gcloud storage` CLI command correctly creates the bucket according to Google Cloud best practices?

gcloud storage buckets create gs://health-analytics-export --default-storage-class=nearline --public-access-prevention --uniform-bucket-level-access

gsutil mb -c nearline -b on gs://health-analytics-export && gsutil publicaccessprevention set enforced gs://health-analytics-export

gcloud storage buckets create gs://health-analytics-export --default-storage-class=nearline --public-access-prevention --no-uniform-bucket-level-access

gcloud storage buckets create gs://health-analytics-export --default-storage-class=archive --public-access-prevention --uniform-bucket-level-access

Show answer & explanation

Answer: gcloud storage buckets create gs://health-analytics-export --default-storage-class=nearline --public-access-prevention --uniform-bucket-level-access

Answer

The command 'gcloud storage buckets create gs://health-analytics-export --default-storage-class=nearline --public-access-prevention --uniform-bucket-level-access' is correct because it utilizes the modern gcloud storage CLI to satisfy all operational, access control, and storage tier requirements.

The correct command uses 'gcloud storage buckets create' with '--default-storage-class=nearline' to accommodate monthly access patterns cost-effectively, alongside '--uniform-bucket-level-access' to enforce IAM-only access controls and '--public-access-prevention' to block public internet access.

Step-by-Step Solution

Identify the primary tool recommendation

Use 'gcloud storage buckets create' instead of legacy 'gsutil mb' commands.

Google Cloud recommends using the gcloud storage CLI for all object and bucket operations.

Determine the appropriate storage class

Select Nearline storage class using '--default-storage-class=nearline'.

Data accessed once per month fits the Nearline storage class profile, avoiding the higher retrieval costs of Coldline or Archive classes.

Configure security and access controls

Enable '--uniform-bucket-level-access' and '--public-access-prevention'.

Uniform Bucket-Level Access disables individual object ACLs in favor of IAM, while Public Access Prevention prevents accidental public exposure.

Key Concept

Deploying Cloud Storage buckets with security enforcement and storage class selection via gcloud storage CLI

Question 599Question →

An enterprise is implementing internal name resolution across multiple Virtual Private Cloud (VPC) networks in Google Cloud. A Cloud DNS private managed zone named `corp.internal` was created in `project-a` and initially bound to `vpc-a`. Compute Engine virtual machine instances residing in `vpc-b` (located in `project-b`) require name resolution for endpoints within `corp.internal`. Currently, DNS queries originating from virtual machines in `vpc-b` fail to resolve these internal domain names. How should the cloud engineer configure Cloud DNS to grant `vpc-b` access to resolve names in the private managed zone?

Update the existing private managed zone configuration for `corp.internal` to add `vpc-b` to the list of authorized VPC networks.

Enable the Cloud DNS API within `project-b` and deploy a duplicate public managed zone with identical resource record sets.

Recreate the `corp.internal` private zone at the Organization resource level so child VPC networks inherit private DNS resolution permissions.

Deploy a Global External HTTP(S) Load Balancer in `vpc-a` to intercept and forward port 53 DNS traffic coming from `vpc-b`.

Show answer & explanation

Answer: Update the existing private managed zone configuration for `corp.internal` to add `vpc-b` to the list of authorized VPC networks.

Answer

Update the existing private managed zone configuration for `corp.internal` to add `vpc-b` to the list of authorized VPC networks.

In Google Cloud DNS, private zones provide internal DNS resolution exclusively to VPC networks configured as authorized networks. To allow virtual machines in a secondary VPC network to resolve records in a private zone, the secondary VPC network must be explicitly added to the private zone's authorized networks list.

Step-by-Step Solution

Identify the resource scope and requirements for cross-VPC internal name resolution in Google Cloud.

Recognize that Cloud DNS private managed zones control visibility by maintaining a list of authorized VPC networks.

By default, a private zone is only accessible to the VPC network specified during creation.

Evaluate how to extend access of an existing private zone to another VPC network across projects.

Modify the private zone settings in `project-a` to add `vpc-b` as an authorized network.

Multiple VPC networks (even across different projects) can be authorized to read from a single Cloud DNS private zone without duplicating zones or creating proxies.

Key Concept

Cloud DNS Private Zone Authorized Networks

Question 600Question →

A DevOps engineer is tasked with deploying an API gateway workload defined in `gateway-deployment.yaml` to an existing regional GKE cluster named `api-gateway-prod` located in the `europe-west1` region. When the engineer executes `kubectl apply -f gateway-deployment.yaml` from a freshly provisioned administration workstation, the operation fails with an authorization error because local kubeconfig parameters are missing. Which command must the engineer execute to generate the cluster authentication credentials and update the local kubeconfig context so `kubectl` can successfully interact with the cluster?

gcloud container clusters get-credentials api-gateway-prod --region europe-west1

gcloud config set container/cluster api-gateway-prod

gcloud container node-pools update default-pool --cluster api-gateway-prod --region europe-west1 --enable-autoupgrade

kubectl config set-cluster api-gateway-prod --server=https://container.googleapis.com

Show answer & explanation

Answer: gcloud container clusters get-credentials api-gateway-prod --region europe-west1

Answer

The command 'gcloud container clusters get-credentials api-gateway-prod --region europe-west1' should be executed to fetch the API server credentials and update the local kubeconfig configuration.

The correct command utilizes the 'gcloud container clusters get-credentials' command with the appropriate cluster name and '--region' flag to download the necessary authentication credentials and API endpoint metadata directly into the user's local kubeconfig file, authorizing subsequent 'kubectl' commands.

Step-by-Step Solution

Identify the authentication mechanism between local workstations and GKE clusters.

Recognize that kubectl relies on a valid context entry in ~/.kube/config containing cluster endpoint IP address, CA certificate, and access token.

Without updated kubeconfig entries, kubectl cannot target or authenticate against the remote GKE control plane.

Select the correct gcloud tool command for GKE credential retrieval.

Use 'gcloud container clusters get-credentials' combined with the cluster name and region flag.

This command automatically generates authenticating tokens via Google Cloud IAM and populates local kubeconfig entries.

Apply the Kubernetes workload manifest.

Execute 'kubectl apply -f gateway-deployment.yaml'.

Once the kubeconfig context is populated, kubectl commands successfully route to the target GKE cluster.

Key Concept

GKE Cluster Credential Retrieval and Kubeconfig Management

Estimated Time:2m 0s

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