Examkin

All practice questions

1591 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 681Question →

A cloud administrator is using the Google Cloud Pricing Calculator to project monthly compute costs for a dedicated batch worker cluster in `us-central1`. The cluster consists of 4 `n2-standard-4` Compute Engine virtual machine instances running continuously for 730 hours per month. The un-discounted baseline rate for an `n2-standard-4` instance in this region is $0.20 per hour. To lower operational costs, the organization purchases a 1-year Committed Use Discount (CUD) covering these VM resources, which grants a 35% discount off the standard hourly rate. Assuming no other infrastructure or networking fees apply, what is the total estimated monthly cost in USD for this 4-instance cluster after applying the 1-year Committed Use Discount?

Show answer & explanation

Answer: 379.6

Answer

The total estimated monthly cost for running the 4 Compute Engine instances with the 1-year Committed Use Discount applied is $379.60 USD.
The total monthly cost calculation multiplies the number of VM instances (4) by the total operational hours in a standard month (730 hours) and the base hourly rate (0.20/hr),resultinginanun−discountedbaselineof0.20/hr), resulting in an un-discounted baseline of 584.00. Applying the 35% Committed Use Discount results in paying 65% of the baseline cost (584.00×0.65),whichyieldsanestimatedtotalof584.00 × 0.65), which yields an estimated total of 379.60 USD.

Step-by-Step Solution

1
Calculate the total instance-hours required for the month
2,920 instance-hours
Running 4 virtual machines continuously for 730 hours yields 4 × 730 = 2,920 total hours.
2
Calculate the total un-discounted baseline cost
$584.00 USD
Multiplying 2,920 total instance-hours by the standard hourly rate of 0.20yields0.20 yields 584.00.
3
Apply the 1-year Committed Use Discount (35% off)
$379.60 USD
The effective price factor after a 35% discount is 1 - 0.35 = 0.65. Multiplying 584.00by0.65gives584.00 by 0.65 gives 379.60 USD.

Key Concept

Calculating Compute Engine infrastructure cost estimates with Committed Use Discounts in the GCP Pricing Calculator
Question 682Question →

A cloud engineer is designing internal name resolution between a Virtual Private Cloud (VPC) network named `vpc-app` and an on-premises network connected via Cloud Interconnect. Compute Engine instances in `vpc-app` need to resolve corporate domain records hosted on an on-premises DNS server at `10.2.0.50`. Simultaneously, on-premises workloads need to resolve hostnames within a private Cloud DNS zone named `internal.example.com` attached to `vpc-app`. Which TWO configuration actions must be performed in Google Cloud to satisfy these bidirectional DNS requirements?

Select all that apply

Show answer & explanation

Answer: Create a Cloud DNS forwarding zone for the on-premises domain, specifying `10.2.0.50` as the target name server, and authorize `vpc-app` to access the zone.; Create a Cloud DNS server policy for `vpc-app` with inbound DNS forwarding enabled, and configure the on-premises DNS server to forward queries for `internal.example.com` to the Cloud DNS inbound forwarder IP addresses.

Answer

The correct configuration requires creating a Cloud DNS forwarding zone pointing to `10.2.0.50` for outbound resolution, and enabling inbound DNS forwarding on a server policy for `vpc-app` so on-premises clients can reach Cloud DNS via regional inbound entry point IPs.
Bidirectional DNS resolution requires two components: outbound forwarding from Cloud DNS to the on-premises DNS server (achieved via a Cloud DNS forwarding zone) and inbound forwarding from on-premises to Cloud DNS (achieved by enabling inbound DNS forwarding in a Cloud DNS server policy).

Step-by-Step Solution

1
Configure outbound DNS forwarding from Google Cloud to on-premises.
Compute Engine instances in `vpc-app` can resolve corporate domain records by querying the Cloud DNS forwarding zone, which forwards requests to `10.2.0.50`.
Cloud DNS forwarding zones direct requests for designated domains to specified target external DNS servers.
2
Configure inbound DNS forwarding from on-premises to Google Cloud.
Cloud DNS reserves entry point IP addresses in the `vpc-app` subnets that listen for incoming queries from on-premises DNS servers.
Enabling inbound DNS forwarding in a Cloud DNS server policy allows external/on-premises resolvers to query private zones attached to the VPC network.

Key Concept

Bidirectional Cloud DNS forwarding between VPC networks and on-premises DNS infrastructure.
Estimated Time:2m 0s
Question 683Question →

A Cloud Engineer needs to create a new infrastructure deployment in Google Cloud using Google Cloud Deployment Manager. The configuration template file is stored locally as `network-config.yaml`. Which `gcloud` command should the engineer execute to create a new deployment named `production-network`?

Show answer & explanation

Answer: gcloud deployment-manager deployments create production-network --config network-config.yaml

Answer

The command `gcloud deployment-manager deployments create production-network --config network-config.yaml` is the correct syntax for creating a new deployment in Deployment Manager.
To create a brand-new deployment in Google Cloud Deployment Manager, the `gcloud deployment-manager deployments create` command must be used along with the deployment name and the `--config` flag pointing to the YAML or Jinja/Python configuration file.

Step-by-Step Solution

1
Identify the Google Cloud service required for infrastructure as code deployment.
Google Cloud Deployment Manager is specified.
Deployment Manager manages GCP resource lifecycle via configuration templates.
2
Determine the proper gcloud command group and action verb for initial deployment creation.
The target command structure is `gcloud deployment-manager deployments create`.
Creating a new deployment resource requires the `create` action rather than `update` or compute-specific subcommands.
3
Specify mandatory positional arguments and flags.
`production-network` as the deployment name and `--config network-config.yaml` to pass the template file.
The deployment name is a required positional argument, and `--config` defines the path to the YAML configuration.

Key Concept

Deployment Manager CLI Execution
Question 684Question →

An administrator is configuring operational scaling parameters for a Google Kubernetes Engine (GKE) cluster. Which of the following statements accurately describe GKE resource scaling mechanisms? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Horizontal Pod Autoscaler (HPA) automatically increases or decreases the number of pod replicas in a deployment based on observed CPU utilization or custom metrics.; Cluster Autoscaler automatically resizes node pools by adding nodes when pods are unschedulable due to resource constraints and removing underutilized nodes.

Answer

Horizontal Pod Autoscaler (HPA) scales pod replica counts based on workload demand metrics, while Cluster Autoscaler adjusts the underlying node count when pods cannot be scheduled due to resource constraints.
The correct options accurately distinguish between pod-level horizontal scaling (HPA) and node-level infrastructure scaling (Cluster Autoscaler). HPA increases or decreases pod replica count in response to utilization metrics, whereas Cluster Autoscaler provisions or terminates worker VM nodes when pods are unschedulable due to capacity limits.

Step-by-Step Solution

1
Identify the role of pod-level scaling mechanisms in GKE.
Horizontal Pod Autoscaler (HPA) monitors metrics like CPU utilization and adjusts pod replica counts.
HPA functions inside Kubernetes to adjust workload application scaling.
2
Identify the role of infrastructure-level scaling mechanisms in GKE.
Cluster Autoscaler evaluates pending unschedulable pods and resizes node pools accordingly.
Node provisioning is managed by Cluster Autoscaler, not HPA.

Key Concept

Distinction between Horizontal Pod Autoscaler (HPA) for pod workload scaling and Cluster Autoscaler for node infrastructure scaling in GKE.
Estimated Time:1m 0s
Question 685Question →

A cloud engineer is deploying ingress VPC firewall rules to allow HTTPS (TCP port 443) traffic from any external client specifically to a set of Compute Engine virtual machine instances labeled with the network tag `web-frontend`. Which TWO parameters or configurations must be included in the firewall rule specification to achieve this requirement? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Set the direction to INGRESS and specify the source IPv4 ranges as 0.0.0.0/0.; Specify the target tags parameter as `web-frontend` and set the allowed protocol and port to tcp:443.

Answer

The correct configurations are setting the rule direction to INGRESS with source ranges 0.0.0.0/0, and specifying the target tags as `web-frontend` with allowed protocol and port tcp:443.
To allow external HTTPS traffic to targeted instances, a VPC firewall rule must specify INGRESS direction with source range 0.0.0.0/0, match target tag `web-frontend`, and allow protocol and port tcp:443. These parameters correctly scope the traffic origin, destination instances, and permitted network port.

Step-by-Step Solution

1
Define traffic direction and source CIDR range
Setting direction to INGRESS targets incoming traffic, and defining source range 0.0.0.0/0 opens the rule to public internet traffic.
Firewall rules require explicit traffic direction and source IP ranges to determine which incoming requests to evaluate.
2
Specify target network tags and allowed protocols/ports
Configuring target tag `web-frontend` applies the rule exclusively to tagged instances, while `--allow=tcp:443` restricts access to secure HTTPS traffic.
Targeting tags ensures the principle of least privilege scoping across Compute Engine virtual machine instances.

Key Concept

Configuring GCP VPC Ingress Firewall Rules with Target Network Tags and Port Restrictions
Question 686Question →

A digital gaming company is designing the Google Cloud network architecture for a global multiplayer game backend hosted on Compute Engine instances. The platform architecture has two distinct requirements:
1. Incoming client connections from the public internet use a proprietary, non-HTTP raw TCP protocol, but require SSL/TLS termination at the Google network edge to offload encryption processing from backend instances.
2. Internal microservices running in a custom VPC network need to resolve internal service domain names under `game.internal` to private IP addresses without broadcasting DNS queries to the public internet.

Which TWO architectural components should the cloud engineering team plan and implement to satisfy these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Provision a Global External SSL Proxy Load Balancer to terminate client TLS sessions at the edge and proxy the raw TCP traffic to the backend instances.; Create a Cloud DNS Private Zone configured for the domain `game.internal` and authorize access exclusively to the target VPC network.

Answer

The team should provision a Global External SSL Proxy Load Balancer for edge TLS termination of raw TCP traffic, and create a Cloud DNS Private Zone for internal VPC name resolution.
For requirement 1, the Global External SSL Proxy Load Balancer is designed specifically for terminating SSL/TLS connections at the edge for non-HTTP raw TCP traffic. For requirement 2, a Cloud DNS Private Zone provides secure, private name resolution for internal domain names accessible only within authorized VPC networks.

Step-by-Step Solution

1
Analyze the load balancing protocol and scope requirements.
The application requires global external internet ingress, TLS offloading at the edge, and non-HTTP raw TCP protocol proxying.
An SSL Proxy Load Balancer is a Layer 4 external reverse proxy that offloads SSL/TLS at the edge and forwards raw TCP traffic to backends. Application Load Balancers (L7) cannot process raw non-HTTP protocols.
2
Analyze the DNS resolution and privacy requirements.
Internal microservices need custom private domain resolution (`game.internal`) restricted to the VPC.
Cloud DNS Private Zones allow managing DNS records that are resolvable only within designated VPC networks, keeping DNS traffic isolated from the public internet.

Key Concept

Selecting L4 vs L7 external load balancers based on protocol requirements and isolating internal DNS using Cloud DNS Private Zones.
Question 687Question →

An organization needs to set up a continuous export of detailed Cloud Billing cost data to BigQuery for central financial analytics. Place the implementation steps in the correct chronological order from first step to final step.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps is: 1. Create or select a target Google Cloud project and enable the BigQuery API. 2. Create a destination BigQuery dataset in the target project to host the exported billing tables. 3. Ensure the administrator configuring the export is granted the Billing Account Costs Manager role on the Cloud Billing Account. 4. Navigate to the Billing Export page in the Cloud Billing console and enable Detailed Usage Cost export by selecting the target project and dataset.
Establishing BigQuery billing export requires setting up infrastructure prerequisites before linking the billing account. First, create or select the target project and enable the BigQuery API. Second, create the destination BigQuery dataset inside that project. Third, grant the configuring user the Billing Account Costs Manager role on the billing account. Fourth, use the Cloud Billing console to enable Detailed Usage Cost export by selecting the dataset.

Step-by-Step Solution

1
Initialize target project infrastructure and enable the BigQuery API.
The target GCP project is ready to manage BigQuery resources.
BigQuery datasets cannot be created until the hosting project exists and its BigQuery API service is enabled.
2
Create the destination BigQuery dataset.
A specific dataset container is established.
The Cloud Billing Export configuration menu requires selecting an existing dataset as the export destination.
3
Verify IAM billing account permissions for the administrator.
The administrator holds the Billing Account Costs Manager role on the Cloud Billing Account.
Project-level administrative roles are insufficient to edit Cloud Billing Account export settings.
4
Link the Billing Account to the BigQuery dataset in the Cloud Billing Console.
Automated pipeline for Detailed Usage Cost export is active.
Selecting the project and dataset under Billing Export completes the continuous export workflow.

Key Concept

Configuring Cloud Billing BigQuery export requires creating the destination project and dataset, securing Billing Account Costs Manager permissions, and defining the export sink in the Cloud Billing console.
Estimated Time:1m 30s
Question 688Question →

A company is migrating an internal analytics service to Compute Engine. The service needs to run on a dedicated custom Virtual Machine instance named `analytics-worker` in the custom subnet `prod-analytics-subnet` within VPC `prod-vpc`. The VM must authenticate to Google Cloud services using a dedicated user-managed service account `[email protected]` with full access to Cloud Storage API scopes. Additionally, the instance must be provisioned without a public IP address to satisfy strict corporate security policies. Which `gcloud` command correctly provisions this Compute Engine Virtual Machine instance according to these requirements?

Show answer & explanation

Answer: gcloud compute instances create analytics-worker --zone=us-central1-a --subnet=prod-analytics-subnet --no-address --service-account=analytics-sa@my-project.iam.gserviceaccount.com --scopes=https://www.googleapis.com/auth/devstorage.full_control

Answer

The command using `--subnet=prod-analytics-subnet --no-address --service-account=analytics-sa@my-project.iam.gserviceaccount.com --scopes=https://www.googleapis.com/auth/devstorage.full_control` correctly provisions the instance.
The correct option correctly uses `gcloud compute instances create` parameters: `--subnet` to specify the custom VPC subnet, `--no-address` to omit an external IP address, `--service-account` to attach the custom service account email, and `--scopes` to define the API access scope for Cloud Storage.

Step-by-Step Solution

1
Identify the network and public IP flags required for custom subnet and private instance deployment.
Use `--subnet=prod-analytics-subnet` to attach to a custom subnet and `--no-address` to suppress external public IP assignment.
Specifying `--no-address` ensures Compute Engine does not allocate an ephemeral external IP address to the primary network interface.
2
Identify the identity and authorization flags for custom service account attachment.
Use `--service-account=analytics-sa@my-project.iam.gserviceaccount.com` combined with `--scopes=https://www.googleapis.com/auth/devstorage.full_control`.
The `--service-account` flag binds the custom identity, and `--scopes` defines the authorized API access boundaries for that instance's service account tokens.
3
Evaluate invalid flags and incorrect workload configurations among candidate options.
Eliminate options using invalid flag syntax like `--public-ip=false`, `--roles`, or attempting to pass IAM primitive roles to `--scopes`.
`gcloud compute instances create` requires precise CLI flag syntax matching Google Cloud API schemas.

Key Concept

Deploying Compute Engine Virtual Machines with Custom Subnets, Private IPs, and Service Accounts via gcloud CLI
Estimated Time:2m 0s
Question 689Question →

A digital healthcare company is deploying a new data pipeline in Google Cloud to store medical imaging files in the us-central1 region. The organization's security policy mandates that access to all objects in the bucket must be governed strictly using Cloud IAM policies rather than ACLs, requiring Uniform Bucket-Level Access to be enabled upon creation. Additionally, because the medical images are accessed infrequently (approximately once per month for routine audits), the bucket must default to the Nearline storage class. A Cloud Engineer needs to provision this bucket using the modern Google Cloud CLI. Which command should be executed to satisfy all requirements?

Show answer & explanation

Answer: gcloud storage buckets create gs://health-diag-images-2026 --location=us-central1 --default-storage-class=nearline --uniform-bucket-level-access

Answer

Execute `gcloud storage buckets create gs://health-diag-images-2026 --location=us-central1 --default-storage-class=nearline --uniform-bucket-level-access`.
The command correctly uses the standard gcloud storage syntax to create a Cloud Storage bucket with specified location (us-central1), Nearline storage class for monthly access patterns, and Uniform Bucket-Level Access to enforce centralized IAM security policy.

Step-by-Step Solution

1
Identify the required CLI framework
Use modern `gcloud storage buckets create` rather than legacy `gsutil mb` commands.
Google Cloud recommends `gcloud storage` for improved performance and uniform CLI structure.
2
Select the correct location and storage class flags
Use `--location=us-central1` and `--default-storage-class=nearline`.
Medical images accessed monthly match the cost and performance characteristics of Nearline storage.
3
Configure access control settings
Include the `--uniform-bucket-level-access` flag during bucket creation.
Enforcing uniform bucket-level access disables legacy object ACLs and ensures unified access management via IAM.

Key Concept

Cloud Storage Bucket Provisioning via gcloud storage CLI
Estimated Time:2m 0s
Question 690Question →

A DevOps engineer needs to deploy a microservice workload manifest to an existing regional Google Kubernetes Engine (GKE) cluster named `payment-prod-cluster` located in the `europe-west3` region. The engineer is logged into a fresh management virtual machine where the Google Cloud SDK (`gcloud`) and `kubectl` are installed, and the user is authenticated to GCP with proper IAM permissions. However, executing `kubectl apply -f deployment.yaml` fails because `kubectl` lacks the context to communicate with the cluster. Which command must the engineer run to fetch cluster credentials and update `kubeconfig` for `payment-prod-cluster`?

Show answer & explanation

Answer: gcloud container clusters get-credentials payment-prod-cluster --region europe-west3

Answer

The command `gcloud container clusters get-credentials payment-prod-cluster --region europe-west3` must be run to fetch authentication credentials and endpoint information from Google Cloud and write them into the local `kubeconfig` file.
Executing `gcloud container clusters get-credentials payment-prod-cluster --region europe-west3` queries the GKE API for the cluster's endpoint and certificate authority data, generates an authentication token, and writes an entry into the local `$HOME/.kube/config` file. This switches `kubectl`'s active context to `payment-prod-cluster`, enabling deployment commands to succeed.

Step-by-Step Solution

1
Identify the missing requirement for kubectl execution
Recognize that kubectl needs an updated kubeconfig file containing valid access tokens and the cluster control plane IP address.
Installing kubectl alone does not configure network targets or credentials for specific GKE clusters.
2
Select the proper gcloud command for GKE authentication configuration
Use `gcloud container clusters get-credentials` along with cluster name and location flags.
This command communicates with the GKE API to construct the kubeconfig context automatically.
3
Verify regional flag requirement
Specify `--region europe-west3` because `payment-prod-cluster` is a regional cluster rather than a zonal cluster.
Omitting location flags or using `--zone` for a regional cluster causes gcloud credential retrieval to fail.

Key Concept

Configuring kubectl context for Google Kubernetes Engine using gcloud
Estimated Time:1m 30s
Question 691Question →

Your organization runs a batch processing pipeline on a Google Kubernetes Engine (GKE) Standard cluster named `prod-cluster` in zone `us-central1-a`. During daily peak processing hours, incoming pod workloads enter a `Pending` state because the existing node pool named `analytics-pool` reaches its maximum capacity. You need to configure the cluster infrastructure so that GKE automatically provisions additional compute nodes in `analytics-pool` when pods cannot be scheduled due to resource constraints, up to a maximum limit of 15 nodes, and scales down node count during off-peak hours. Which command should you execute to meet this requirement?

Show answer & explanation

Answer: gcloud container node-pools update analytics-pool --cluster=prod-cluster --enable-autoscaling --min-nodes=2 --max-nodes=15 --zone=us-central1-a

Answer

The command 'gcloud container node-pools update analytics-pool --cluster=prod-cluster --enable-autoscaling --min-nodes=2 --max-nodes=15 --zone=us-central1-a' is the correct choice because it enables GKE Cluster Autoscaler on the specific node pool.
Enabling cluster autoscaling on a GKE Standard node pool via 'gcloud container node-pools update' with the '--enable-autoscaling', '--min-nodes', and '--max-nodes' flags allows GKE to automatically adjust the node pool capacity between the specified limits when pods cannot be scheduled.

Step-by-Step Solution

1
Identify the operational requirement.
The requirement is to scale compute nodes (infrastructure capacity) in response to unschedulable pending pods, which requires GKE Cluster Autoscaler rather than Horizontal Pod Autoscaler.
When pods are pending due to lack of node CPU/memory, increasing pod counts does not help; additional VM nodes must be provisioned.
2
Determine the appropriate Google Cloud CLI tool and resource target.
Target the specific node pool using 'gcloud container node-pools update analytics-pool'.
Node pool autoscaling settings are managed at the node pool level under the cluster.
3
Select the correct flags for node pool autoscaling.
Specify '--enable-autoscaling', '--min-nodes=2', '--max-nodes=15', '--cluster=prod-cluster', and '--zone=us-central1-a'.
These flags configure the minimum and maximum node thresholds for the GKE Cluster Autoscaler.

Key Concept

Configuring GKE Cluster Autoscaler on Existing Node Pools
Estimated Time:2m 0s
Question 692Question →

A cloud architect is designing a custom-mode Virtual Private Cloud (VPC) network. The primary subnet in `us-east1` is currently configured with the IP block 10.200.1.0/2410.200.1.0/24. The architecture team intends to expand this primary subnet range in the future to a /23/23 prefix to accommodate up to 500500 virtual machine instances. A second subnet in `us-central1` must be provisioned immediately. To ensure that the future expansion of the `us-east1` subnet will not fail due to IP range overlap, which CIDR range should be allocated to the new `us-central1` subnet?

Show answer & explanation

Answer: 10.200.2.0/2410.200.2.0/24

Answer

The range 10.200.2.0/2410.200.2.0/24 should be allocated to the us-central1 subnet to avoid CIDR overlap when us-east1 is expanded to 10.200.0.0/2310.200.0.0/23.
In Google Cloud VPC networking, primary IP address ranges must be expanded to a larger subnet mask (smaller prefix length) while maintaining strict bit-boundary alignment. Expanding 10.200.1.0/2410.200.1.0/24 to a /23/23 prefix forces the expanded range to become 10.200.0.0/2310.200.0.0/23, spanning 10.200.0.010.200.0.0 to 10.200.1.25510.200.1.255. Therefore, assigning 10.200.2.0/2410.200.2.0/24 to the new subnet leaves the address space 10.200.0.010.200.0.0–10.200.1.25510.200.1.255 completely free for future expansion.

Step-by-Step Solution

1
Determine the binary CIDR boundary for expanding the existing subnet.
Expanding 10.200.1.0/2410.200.1.0/24 to a /23/23 prefix requires aligning to a power-of-two boundary. The enclosing /23/23 block is 10.200.0.0/2310.200.0.0/23, covering IP addresses 10.200.0.010.200.0.0 through 10.200.1.25510.200.1.255.
Google Cloud VPC subnets must align to strict bit-boundary boundaries when expanded.
2
Identify potential CIDR conflicts within the VPC network.
Any subnet allocated within the 10.200.0.0/2410.200.0.0/24 block will prevent the future expansion of 10.200.1.0/2410.200.1.0/24 because 10.200.0.0/2310.200.0.0/23 would overlap with it.
GCP VPC subnets within the same network cannot have overlapping primary IPv4 address ranges.
3
Select a non-overlapping contiguous /24/24 block for the new region.
The range 10.200.2.0/2410.200.2.0/24 starts immediately after the expanded 10.200.0.0/2310.200.0.0/23 range (10.200.0.010.200.0.0–10.200.1.25510.200.1.255), avoiding any overlap.
Choosing 10.200.2.0/2410.200.2.0/24 reserves the entire 10.200.0.0/2310.200.0.0/23 block for the us-east1 subnet expansion.

Key Concept

CIDR Subnet Expansion and Boundary Alignment in GCP VPC Networks
Question 693Question →

An operations team manages a stateless, fault-tolerant processing service deployed on a Google Kubernetes Engine (GKE) Standard cluster. During peak events, high application traffic causes existing pods to consume maximum allocated CPU resources, while new incoming pods remain in a Pending state due to insufficient cluster compute capacity. The team wants to ensure dynamic scalability at both the application level and infrastructure level while optimizing compute costs. Which TWO management strategies should the team implement? (Select TWO answers.)

Select all that apply

Show answer & explanation

Answer: Configure a Horizontal Pod Autoscaler (HPA) targeting the Deployment workload to dynamically scale the number of pod replicas based on CPU utilization metrics.; Enable the GKE Cluster Autoscaler on a node pool configured with Spot VMs to dynamically add node capacity when unschedulable pods are detected.

Answer

The correct operational strategies are to configure a Horizontal Pod Autoscaler (HPA) to scale pod replicas based on workload metrics and enable the GKE Cluster Autoscaler on a Spot VM node pool to automatically provision worker nodes when pending pods cannot be scheduled.
Deploying a Horizontal Pod Autoscaler (HPA) addresses application load by dynamically increasing or decreasing pod replica counts according to metric thresholds. Enabling GKE Cluster Autoscaler on a node pool consisting of Spot VMs addresses cluster capacity limits by adding infrastructure when unschedulable pods exist, while minimizing compute expenditures for stateless workloads.

Step-by-Step Solution

1
Analyze workload scaling requirements at the pod replica level.
Configuring a Horizontal Pod Autoscaler (HPA) allows Kubernetes to automatically adjust the target deployment's replica count in response to CPU utilization spikes.
HPA operates within the Kubernetes control plane to scale pod instances up or down based on defined resource thresholds.
2
Analyze infrastructure scaling and cost optimization requirements at the node level.
Enabling GKE Cluster Autoscaler on a Spot VM node pool ensures that new node instances are added automatically when pending pods lack room on existing nodes, while leveraging lower-cost preemptible capacity suited for stateless workloads.
Cluster Autoscaler monitors for unschedulable pods and resizes node pools dynamically, whereas Spot VMs reduce compute costs for fault-tolerant applications.

Key Concept

Distinguishing between Horizontal Pod Autoscaler (HPA) for scaling pod workload replicas and GKE Cluster Autoscaler for dynamic node pool capacity adjustment.
Question 694Question →

A Cloud Engineer is assigned to create a monthly spend budget and threshold alerts for a production workload. The engineer currently holds the Project Owner role on the Google Cloud project where the resources are deployed. When attempting to create a new budget in the Google Cloud Console, the engineer discovers that they cannot view or manage budgets for the associated Cloud Billing account. Which action must be taken to enable the engineer to create and manage billing budgets?

Show answer & explanation

Answer: Grant the engineer the Billing Account Costs Manager role on the Cloud Billing account.

Answer

Grant the engineer the Billing Account Costs Manager role on the Cloud Billing account.
To create and manage budgets and budget alerts, a user must have permissions on the Cloud Billing account itself. The Billing Account Costs Manager role provides the necessary permissions (`billing.budgets.create`, `billing.budgets.get`, `billing.budgets.update`) to manage budgets without granting full administrative control over billing payment methods.

Step-by-Step Solution

1
Identify the resource scope required for billing budget creation.
Budgets are created and managed at the Cloud Billing account level, not at the individual project level.
Although a budget can monitor costs for specific projects, budget definitions reside on the Cloud Billing account object.
2
Evaluate the engineer's current permissions.
The engineer holds the Project Owner role on a child project, which does not inherit administrative control over the parent Cloud Billing account.
IAM permissions granted on a project do not grant permissions on the parent Cloud Billing account.
3
Select the minimum necessary IAM role on the Cloud Billing account.
Assigning the Billing Account Costs Manager role provides `billing.budgets.create` and `billing.budgets.get` permissions on the billing account.
This adheres to the principle of least privilege while providing full functionality to manage billing budgets and alerts.

Key Concept

Cloud Billing IAM Roles vs Project IAM Roles for Budget Administration
Question 695Question →

A financial services company is architecting a new Google Kubernetes Engine (GKE) cluster to host a stateless REST API. The infrastructure management team requires a cluster architecture that completely eliminates worker node management overhead—including node provisioning, scaling, and OS security patching—while billing strictly for the CPU, memory, and storage resources requested by running Pods rather than unutilized compute node capacity. Which GKE cluster architecture best fulfills these requirements?

Show answer & explanation

Answer: Deploy a GKE Autopilot cluster.

Answer

Deploying a GKE Autopilot cluster meets all requirements by automating node infrastructure management and billing based on Pod resource requests.
GKE Autopilot fully manages cluster infrastructure including node provisioning, auto-scaling, auto-upgrading, and node security hardening. Furthermore, billing in Autopilot mode is calculated based on the CPU, memory, and ephemeral storage requested by deployed Pods rather than provisioned Compute Engine VM capacity.

Step-by-Step Solution

1
Analyze the operational requirements.
Identified two main requirements: zero node management overhead (provisioning, patching, scaling) and Pod-based request billing.
Choosing between GKE Standard and GKE Autopilot depends on operational responsibility boundaries and billing models.
2
Compare GKE Autopilot and GKE Standard operational modes.
GKE Autopilot automates node management and bills strictly per Pod resource request. GKE Standard requires node pool management and charges per compute VM node capacity.
GKE Autopilot abstracts the underlying Compute Engine instances completely from the administrator.
3
Select the matching cluster mode.
GKE Autopilot is the only option that eliminates node management overhead while matching the requested Pod resource billing model.
Standard GKE clusters, even with autoscaling features like Cluster Autoscaler or HPA, retain node-level configuration and VM capacity billing.

Key Concept

GKE Autopilot vs. Standard Operational Boundaries
Estimated Time:1m 30s
Question 696Question →

A cloud engineer is provisioning a high-availability Cloud SQL for MySQL instance named `prod-mysql-db` within a Virtual Private Cloud (VPC) network named `corporate-vpc`. Corporate security guidelines dictate that the database instance must not have a public IP address, must be accessible exclusively via private IP within the VPC, must provide regional high availability, and must encrypt data at rest using a Customer-Managed Encryption Key (CMEK). Which TWO tasks must be performed to successfully deploy this database configuration?

Select all that apply

Show answer & explanation

Answer: Reserve an IP address range in `corporate-vpc` for private service access and establish a VPC peering connection using the Service Networking API.; Execute `gcloud sql instances create prod-mysql-db --network=corporate-vpc --no-assign-ip --availability-type=REGIONAL --kms-key-name=projects/MY_PROJECT/locations/LOCATION/keyRings/RING/cryptoKeys/KEY`.

Answer

The correct steps are reserving an internal IP address range in `corporate-vpc` to establish a Private Services Access connection, and running `gcloud sql instances create prod-mysql-db` with `--network=corporate-vpc`, `--no-assign-ip`, `--availability-type=REGIONAL`, and `--kms-key-name`.
To deploy a Cloud SQL instance with Private IP connectivity, you must first create a Private Services Access connection in the target VPC network using the Service Networking API. When creating the Cloud SQL instance via the gcloud CLI, setting `--no-assign-ip` prevents public IP allocation, `--network` binds the instance to the peered VPC, `--availability-type=REGIONAL` configures automatic failover across zones, and `--kms-key-name` specifies the Cloud KMS key for CMEK encryption.

Step-by-Step Solution

1
Allocate a private IP block and configure Private Services Access.
Establishes VPC peering between the customer VPC network and Google's internal service producer network where Cloud SQL instances reside.
Cloud SQL Private IP connections rely on private service access via the Service Networking API.
2
Ensure the Cloud SQL Service Account has KMS encrypter/decrypter access.
Allows Cloud SQL to use the specified KMS key for CMEK.
Without `roles/cloudkms.cryptoKeyEncrypterDecrypter` granted to the Cloud SQL service agent, instance creation with CMEK will fail.
3
Execute the `gcloud sql instances create` deployment command with required flags.
Creates a regionally available, private IP-only Cloud SQL instance encrypted with CMEK.
`--no-assign-ip` disables public IP, `--network` attaches it to the VPC, `--availability-type=REGIONAL` enables HA failover, and `--kms-key-name` specifies the CMEK key.

Key Concept

Cloud SQL Private IP, High Availability, and Customer-Managed Encryption Keys (CMEK) Configuration
Question 697Question →

An organization runs a web application on a Google Kubernetes Engine (GKE) Standard cluster. During a high-traffic event, existing pods reach high CPU utilization and incoming pod replicas fail to schedule, remaining in a Pending state because the cluster node pool has reached its compute capacity. You need to ensure the cluster automatically provisions additional Compute Engine worker nodes whenever pods are unschedulable due to resource limitations. Which action should you take?

Show answer & explanation

Answer: Enable Cluster Autoscaler on the GKE cluster node pool using gcloud container clusters update with the --enable-autoscaling flag.

Answer

Enable Cluster Autoscaler on the GKE cluster node pool using gcloud container clusters update with the --enable-autoscaling flag.
The Cluster Autoscaler automatically adds nodes to a GKE node pool when pods cannot be scheduled due to insufficient CPU or memory resources on existing nodes. Enabling autoscaling using gcloud container clusters update with --enable-autoscaling configures GKE to dynamically provision Compute Engine instances as demand increases.

Step-by-Step Solution

1
Identify the resource bottleneck in the GKE cluster.
Pods are remaining in a Pending state because the cluster node pool has run out of CPU compute capacity.
When existing nodes cannot accommodate pod resource requests, additional infrastructure capacity (VM nodes) is required.
2
Select the appropriate GKE autoscaling mechanism for infrastructure nodes.
Cluster Autoscaler must be enabled for the node pool.
Cluster Autoscaler monitors for unschedulable pods and automatically resizes the node pool, whereas HPA only scales pod replica counts.
3
Execute the management command to configure node scaling.
Run gcloud container clusters update CLUSTER_NAME --enable-autoscaling with min and max node limits.
This updates the GKE control plane to dynamically add Compute Engine instances when pending pods demand capacity.

Key Concept

GKE Cluster Autoscaler vs. Horizontal Pod Autoscaler (HPA)
Question 698Question →

A enterprise architecture team is deploying a critical enterprise accounting database to Google Cloud using Cloud SQL for PostgreSQL. Security and compliance policies require the following specifications:
1. The instance must be accessible exclusively via Private IP within the custom Virtual Private Cloud (VPC) named `corp-vpc` and must NOT have a public IP address assigned.
2. The deployment must guarantee high availability across availability zones with automatic failover.
3. Automated backups must execute daily at 03:00 UTC, and Point-in-Time Recovery (PITR) must be explicitly enabled.

Which `gcloud` command correctly provisions this Cloud SQL instance while fully satisfying all security and operational constraints?

Show answer & explanation

Answer: gcloud sql instances create acct-db-prod --database-version=POSTGRES_15 --tier=db-custom-4-16384 --region=us-central1 --network=projects/corp-finance-proj/global/networks/corp-vpc --no-assign-ip --availability-type=REGIONAL --backup-start-time=03:00 --enable-point-in-time-recovery

Answer

The command specifying `gcloud sql instances create acct-db-prod` with `--no-assign-ip`, `--network=projects/corp-finance-proj/global/networks/corp-vpc`, `--availability-type=REGIONAL`, `--backup-start-time=03:00`, and `--enable-point-in-time-recovery` correctly provisions the instance.
The correct command explicitly satisfies all three security and operational requirements: disabling public IP using `--no-assign-ip` while binding to the private VPC network, providing cross-zone automatic failover with `--availability-type=REGIONAL`, and enabling point-in-time recovery for PostgreSQL via `--enable-point-in-time-recovery`.

Step-by-Step Solution

1
Evaluate IP Connectivity Flags
By default, `gcloud sql instances create` assigns a public IP address unless `--no-assign-ip` is passed alongside `--network`.
Security requirements mandate private IP connectivity only with zero public IP exposure.
2
Evaluate High Availability Configuration
`--availability-type=REGIONAL` provisions a primary instance and a standby replica in a secondary zone within the region.
`--availability-type=ZONAL` creates a single-zone deployment without automatic failover capabilities.
3
Evaluate Backup and PITR Engine-Specific Syntax
For PostgreSQL instances in Cloud SQL, `--enable-point-in-time-recovery` enables Write-Ahead Log (WAL) archiving for recovery to specific timestamps.
`--enable-bin-log` applies exclusively to MySQL instances; using it on PostgreSQL represents a flag error.

Key Concept

Cloud SQL Private IP, High Availability, and Point-in-Time Recovery Deployment Flags
Estimated Time:3m 0s
Question 699Question →

Your enterprise application hosted on Compute Engine instances in `us-central1` requires an external load balancer to handle incoming HTTP/HTTPS traffic. For strict regional compliance reasons, all load balancing infrastructure must remain confined to `us-central1`, while supporting HTTP path-based routing and SSL termination. You are deploying the backend configuration using the `gcloud` command-line tool. Which command correctly creates the backend service for a Regional External Application Load Balancer?

Show answer & explanation

Answer: gcloud compute backend-services create web-backend --protocol=HTTP --region=us-central1 --load-balancing-scheme=EXTERNAL_MANAGED

Answer

Execute 'gcloud compute backend-services create web-backend --protocol=HTTP --region=us-central1 --load-balancing-scheme=EXTERNAL_MANAGED' to create a regional backend service for a Regional External Application Load Balancer.
Regional External Application Load Balancers are built on Envoy proxies within a specific region. Creating their backend service requires defining both the specific region using `--region` and setting `--load-balancing-scheme=EXTERNAL_MANAGED`.

Step-by-Step Solution

1
Identify the load balancer requirement
The application requires an HTTP/HTTPS load balancer restricted to a single region (Regional External Application Load Balancer).
Compliance constraints require keeping all traffic processing and infrastructure localized to 'us-central1'.
2
Determine the proper backend service flags in gcloud
Regional Envoy-based load balancers require the '--region' flag set to the target region and '--load-balancing-scheme=EXTERNAL_MANAGED'.
Standard 'EXTERNAL' scheme is for global classic or external network passthrough load balancers, whereas 'EXTERNAL_MANAGED' is used for modern Envoy-based regional and global application load balancers.
3
Construct the correct command
gcloud compute backend-services create web-backend --protocol=HTTP --region=us-central1 --load-balancing-scheme=EXTERNAL_MANAGED
This command creates the regional backend service scoped correctly to 'us-central1'.

Key Concept

Regional External Application Load Balancer gcloud backend configuration
Estimated Time:1m 30s
Question 700Question →

A cloud engineer needs to grant a newly hired developer access to view Cloud Storage objects in a specific project using the gcloud CLI while following Google Cloud security best practices. What is the correct sequence of steps to configure this access?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct workflow follows four sequential steps: first identifying the least-privilege predefined role (`roles/storage.objectViewer`), identifying the target user identity, adding the IAM policy binding via `gcloud projects add-iam-policy-binding`, and verifying the binding using `gcloud projects get-iam-policy`.
The correct sequence begins by planning access: selecting the least-privilege predefined role (`roles/storage.objectViewer`) and establishing the user's principal identifier. Next, the administrator applies the policy change using `gcloud projects add-iam-policy-binding`. Finally, standard operational best practices dictate verifying the applied policy with `gcloud projects get-iam-policy`.

Step-by-Step Solution

1
Determine the required predefined role
Selected `roles/storage.objectViewer` instead of primitive roles like `roles/viewer` or `roles/editor` to follow least privilege.
Least privilege requires using specific predefined roles tailored to the minimal necessary permissions.
2
Identify the target user's identity
Obtained the user's principal email address formatted as `user:[email protected]`.
IAM bindings require a correctly formatted member descriptor type and identity.
3
Add the IAM policy binding via CLI
Ran `gcloud projects add-iam-policy-binding` with the target member and role.
This modifies the project IAM policy to grant the specified role to the user identity.
4
Validate permission assignment
Executed `gcloud projects get-iam-policy` to view the updated policy object.
Verification confirms that the policy binding was stored correctly without unintended scope changes.

Key Concept

Managing IAM Roles and Resource Access Permissions via gcloud CLI using least privilege principles
Estimated Time:1m 30s
PreviousPage 35 / 80Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin