Examkin

All practice questions

1591 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 841Question →

A financial analytics company is designing a workload on Google Compute Engine that requires attached block storage for a transaction processing cache. The workload demands higher throughput and IOPS than standard HDDs can provide, but does not require the maximum performance tier of Extreme Persistent Disk or Local SSD. The block storage must support data persistence when the VM instance is stopped, support dynamic resizing while online, and offer a cost-effective balance between price and performance. Which Persistent Disk type should you select to meet these requirements?

Show answer & explanation

Answer: Balanced Persistent Disk (pd-balanced)

Answer

Balanced Persistent Disk (pd-balanced) is the optimal storage selection because it provides a cost-effective SSD option with higher performance than HDD disks while maintaining full data persistence across VM instance stops.
Balanced Persistent Disk (pd-balanced) offers SSD performance tailored for general-purpose workloads at a lower price point than pd-ssd, while supporting essential block storage features such as dynamic volume resizing and persistence across VM stop/start cycles.

Step-by-Step Solution

1
Evaluate persistence requirements
Local SSD is excluded because its data is lost when a VM instance stops.
Local SSDs are ephemeral and tied to the physical host lifecycle.
2
Evaluate storage architecture type
Cloud Bigtable is excluded because the requirement is for an attached block storage device, not a managed database engine.
Compute Engine workloads requiring VM-attached file systems require block storage (Persistent Disk).
3
Compare performance and cost across persistent disk types
pd-balanced provides higher IOPS/throughput than pd-standard at a lower cost tier than pd-ssd or pd-extreme.
Balanced Persistent Disk is designed specifically to balance price and performance for general enterprise workloads.

Key Concept

Selecting Compute Engine Persistent Disk types based on performance, cost, and persistence requirements
Question 842Question →

Your organization is deploying a real-time telemetry ingestion service on Compute Engine instances located in the `us-central1` region. The client devices transmit data using a custom UDP-based protocol and require original client source IP addresses to be preserved for logging and routing purposes. Which Google Cloud load balancer should you deploy to meet these requirements?

Show answer & explanation

Answer: External Passthrough Network Load Balancer

Answer

External Passthrough Network Load Balancer
An External Passthrough Network Load Balancer operates at Layer 4 (TCP/UDP) and routes packets directly to backend instances without proxying. This makes it ideal for non-HTTP UDP workloads while preserving original client source IP addresses.

Step-by-Step Solution

1
Analyze the network protocol requirements.
The application uses UDP rather than HTTP/HTTPS or TCP.
Protocol compatibility determines which load balancer types can handle incoming network packets.
2
Analyze IP preservation and proxy behavior requirements.
The workload requires preserving the original client source IP address without proxy termination.
Passthrough load balancers forward packets directly to backend instances without altering headers, whereas proxy load balancers terminate connections.
3
Select the appropriate GCP load balancer.
Deploy an External Passthrough Network Load Balancer.
It is a regional Layer 4 load balancer capable of routing incoming UDP traffic to backends with original source IP addresses preserved.

Key Concept

Load Balancer Protocol and Architecture Selection (Layer 4 Passthrough vs. Layer 7 Proxy)
Estimated Time:1m 0s
Question 843Question →

An organization needs to migrate workloads from an existing GKE Standard node pool to a new node pool featuring larger machine types to handle increased memory demand. To prevent application downtime during the migration, in what sequence should a cloud engineer execute the following operational steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The operational sequence must start with provisioning the new node pool, followed by cordoning the old nodes, draining the old nodes to evict Pods to the new pool, and finally deleting the old node pool.
To achieve zero downtime during node pool replacement in GKE Standard, new compute capacity must be created first. Nodes in the old pool are then cordoned so no new Pods are placed on them. Next, `kubectl drain` gracefully evicts active Pods, causing Kubernetes deployment controllers to recreate them on the newly provisioned node pool. Finally, after verifying all workloads are running safely on the new nodes, the old node pool can be deprovisioned.

Step-by-Step Solution

1
Provision the target node pool
Additional compute capacity with larger machine types becomes available in the cluster.
Before evicting existing workloads, target capacity must be active and available to accept rescheduled Pods without causing resource starvation.
2
Cordon the old nodes
The old nodes are marked with `SchedulingDisabled` status.
Cordoning ensures that new Pod deployments or restarts will not land on the old nodes while migration is prepared.
3
Drain the old nodes
Existing Pods are gracefully evicted and recreated by their controllers on the new node pool.
Draining respects PodDisruptionBudgets and termination grace periods, moving active workloads safely to the new node pool.
4
Delete the old node pool
The old compute resources are deprovisioned from Google Cloud.
Once the old nodes are entirely empty of application workloads, deleting the pool releases compute resources and stops incurring costs.

Key Concept

Zero-downtime GKE Node Pool Migration
Question 844Question →

A financial operations team needs to run custom SQL queries on detailed daily cost breakdown and usage metrics across all Google Cloud projects associated with their Cloud Billing account. They want an automated solution that continuously delivers raw billing logs to an analytical repository without relying on custom ingestion scripts. What is the Google Cloud recommended method to accomplish this configuration?

Show answer & explanation

Answer: Configure detailed Cloud Billing export directly within Cloud Billing, directing the automatic data stream to a target BigQuery dataset located in a centralized management project.

Answer

The correct approach is to configure detailed Cloud Billing export directly within Cloud Billing, specifying a target BigQuery dataset located in a centralized project.
The correct answer specifies enabling BigQuery export directly within the Cloud Billing settings to a target BigQuery dataset. Google Cloud provides built-in Cloud Billing export functionality that automatically streams detailed cost and usage data into BigQuery tables, allowing organizations to run comprehensive SQL queries across all projects linked to the billing account without maintaining custom ingestion pipelines.

Step-by-Step Solution

1
Identify the destination project and create a BigQuery dataset in the same region/location desired for billing analytics.
A repository dataset is prepared to receive billing records.
Cloud Billing export requires an existing dataset with appropriate permissions to write data.
2
Navigate to Cloud Billing in the Google Cloud Console and open the Billing Export settings.
Access to Cloud Billing export options (Standard usage cost, Detailed usage cost, Pricing).
Export settings are managed centrally at the Billing Account level, not per individual workload project.
3
Enable BigQuery export and select the destination project and dataset.
Google Cloud automatically begins loading billing schema tables into the dataset on an ongoing basis.
This native integration handles data streaming automatically without needing custom API scripts or Pub/Sub handlers.

Key Concept

Cloud Billing BigQuery Export Configuration
Question 845Question →

A cloud engineer is tasked with deploying a primary Cloud SQL for PostgreSQL database with Private IP connectivity inside a custom Virtual Private Cloud (VPC), along with a cross-region read replica. What is the correct sequence of administrative steps to provision this infrastructure?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence requires allocating an IP address range for VPC peering first, creating the private services connection between the VPC and Google services second, provisioning the primary Cloud SQL instance with private IP third, and creating the cross-region read replica last.
To deploy Cloud SQL using Private IP, Google Cloud mandates setting up Private Services Access (VPC Peering) first. This process requires allocating a named IP range (`--purpose=VPC_PEERING`) and creating the peering connection (`gcloud services vpc-peerings connect`). Once network connectivity is established, the primary Cloud SQL instance can be created with `--no-assign-ip` and connected to the VPC. Finally, the cross-region read replica is created by referencing the primary instance using `--master-instance`.

Step-by-Step Solution

1
Allocate an IP range for Private Services Access
An IP block is explicitly reserved for VPC peering within the custom VPC.
Google services require a dedicated internal IP address range allocated within the host VPC prior to establishing service peering.
2
Create the Private Services Access connection
A VPC peering connection is established between the host VPC and Google's internal service producer network.
Cloud SQL private instances reside in a Google-managed VPC that communicates with the customer VPC via this peering connection.
3
Deploy the primary Cloud SQL instance with Private IP
The primary PostgreSQL database instance is provisioned with private network access only.
The primary instance must exist and be bound to the peered VPC network before any read replicas can connect to it.
4
Create the cross-region read replica
A secondary Cloud SQL instance is created in another region, replicating data from the primary instance.
The read replica creation command depends directly on the active primary database specified via `--master-instance`.

Key Concept

Configuring Cloud SQL Private IP Connectivity and Cross-Region Read Replicas
Estimated Time:2m 0s
Question 846Question →

A DevOps engineer is deploying an updated version of a microservice named order-processor to Google Cloud Run. The team requires deploying the container image gcr.io/acme-ship/order-proc:v2 to create a new revision without directing any production traffic to it upon deployment. Furthermore, the new revision must be directly testable via a dedicated revision URL tag named canary while 100% of live traffic remains on the existing stable revision. Which gcloud command should the engineer execute to fulfill these requirements?

Show answer & explanation

Answer: gcloud run deploy order-processor --image=gcr.io/acme-ship/order-proc:v2 --no-traffic --tag=canary

Answer

Execute gcloud run deploy order-processor --image=gcr.io/acme-ship/order-proc:v2 --no-traffic --tag=canary
The correct command combines --no-traffic and --tag=canary during gcloud run deploy. The --no-traffic flag creates the new revision without routing any production traffic to it, keeping existing traffic on the current revision. The --tag flag creates a unique URL prefix (canary) pointing directly to the new revision so engineers can test it in isolation.

Step-by-Step Solution

1
Identify the service deployment mechanism and container source
Use gcloud run deploy with the specified container image gcr.io/acme-ship/order-proc:v2.
Cloud Run manages containerized web workloads and supports revision tagging.
2
Configure traffic suppression flags
Include the --no-traffic flag in the deployment command.
This prevents Cloud Run from automatically routing production traffic to the new revision.
3
Assign the testing URL tag
Include the --tag=canary flag.
This generates a tagged endpoint URL (e.g., canary---order-processor-xyz.a.run.app) for targeted testing before shifting production traffic.

Key Concept

Cloud Run Traffic Management and Revision Tagging
Question 847Question →

A cloud engineer manages a GKE Standard cluster hosting stateless containerized microservices. During periodic traffic spikes, several newly created Pods remain in a 'Pending' state for extended periods because the current worker nodes lack sufficient available CPU capacity to fulfill the Pod resource requests. The engineer wants the cluster infrastructure to automatically provision additional Compute Engine Virtual Machine nodes whenever Pods cannot be scheduled due to resource constraints. Which action should the engineer take to resolve this issue?

Show answer & explanation

Answer: Enable Cluster Autoscaler on the GKE cluster using the command `gcloud container clusters update [CLUSTER_NAME] --enable-autoscaling --min-nodes=2 --max-nodes=10 --zone=[ZONE]`.

Answer

Enable Cluster Autoscaler on the GKE cluster using `gcloud container clusters update [CLUSTER_NAME] --enable-autoscaling --min-nodes=2 --max-nodes=10 --zone=[ZONE]`.
The correct action is to enable Cluster Autoscaler on the GKE cluster. Cluster Autoscaler monitors for Pods that cannot be scheduled due to insufficient CPU or memory resources on existing nodes and automatically adds Compute Engine VM instances to the node pool within the specified minimum and maximum bounds.

Step-by-Step Solution

1
Identify the root cause of the issue
Pods are in a 'Pending' state because existing Compute Engine worker nodes do not have enough CPU capacity to satisfy the resource requests.
When nodes are fully allocated, Kubernetes scheduler cannot place pending Pods until extra node capacity is provisioned.
2
Select the appropriate scaling mechanism
Choose Cluster Autoscaler rather than Horizontal Pod Autoscaler.
Cluster Autoscaler adjusts the number of VM nodes in a node pool based on unschedulable Pods, whereas HPA adjusts the number of Pod replicas.
3
Execute the management command
Run `gcloud container clusters update` with the `--enable-autoscaling` flag specifying minimum and maximum node counts.
This enables automatic node provisioning in response to resource scarcity on GKE Standard clusters.

Key Concept

GKE Cluster Autoscaler vs. Horizontal Pod Autoscaler operational management
Estimated Time:1m 30s
Question 848Question →

A financial services organization is planning a Google Kubernetes Engine (GKE) cluster architecture to host two distinct workloads:

1. A high-throughput ledger ingestion service that requires custom sysctl kernel parameter tuning on the underlying node OS to optimize TCP socket buffers.
2. A stateless risk-analysis batch processing pipeline that is fault-tolerant and can handle unexpected node terminations.

The infrastructure team needs to ensure that node OS customizations are supported while minimizing compute expenses for the batch processing workload.

Which GKE cluster configuration should the team select?

Show answer & explanation

Answer: Deploy a GKE Standard cluster, configuring a standard node pool with custom sysctl settings for the ledger service, and a Spot VM node pool for the stateless batch processing pipeline.

Answer

Deploy a GKE Standard cluster with a node pool configured with custom sysctl settings for the ledger service, and a Spot VM node pool for the fault-tolerant batch processing workload.
GKE Standard is required when workloads demand underlying OS kernel tuning (such as custom sysctl settings). Combining a standard node pool for the critical ledger service with a Spot VM node pool for the stateless, fault-tolerant batch workload satisfies both the OS customization requirement and the cost-optimization objective.

Step-by-Step Solution

1
Evaluate operational mode requirements for OS customization.
GKE Autopilot locks down node configuration and does not support custom sysctl kernel parameter modifications on nodes. Therefore, a GKE Standard cluster is required.
Workloads requiring low-level Linux kernel parameter changes must run on GKE Standard node pools where node configurations can be customized.
2
Select the appropriate compute instance type for the stateless batch processing workload.
Spot VMs offer significant cost savings for stateless, fault-tolerant workloads that can tolerate preemption.
Batch processing can handle sudden termination and retries, making Spot VMs ideal for cost optimization.
3
Select the appropriate compute instance type for the ledger ingestion service.
Standard (on-demand) VM node pools ensure uninterrupted availability for latency-sensitive, critical ingestion tasks.
Critical ingestion workloads should not run on preemptible instances to avoid service disruption.

Key Concept

Selecting between GKE Standard and Autopilot based on OS kernel customization needs, alongside Spot VM integration for cost optimization.
Estimated Time:1m 30s
Question 849Question →

Match each Google Cloud database or persistent block storage service on the left with the workload architecture requirement on the right that it best satisfies.

Click a left item, then click its matching right item

Items

Cloud Spanner
Cloud Bigtable
Cloud SQL
Extreme Persistent Disk (pd-extreme)

Matches

Show answer & explanation

Answer

Cloud Spanner pairs with global multi-region relational ACID requirements; Cloud Bigtable pairs with high-throughput NoSQL time-series data; Cloud SQL pairs with managed regional relational SQL engines; Extreme Persistent Disk pairs with provisioned high-IOPS block storage for Compute Engine.
Each Google Cloud storage and database technology fulfills specific operational and architectural constraints: Cloud Spanner supports global multi-region relational consistency with horizontal scaling; Cloud Bigtable provides high-throughput NoSQL capabilities for heavy time-series analytics; Cloud SQL provides standard managed relational databases with regional high availability; and Extreme Persistent Disk (pd-extreme) supplies high-provisioned IOPS block storage directly to Compute Engine VMs.

Step-by-Step Solution

1
Evaluate multi-region relational transactional requirements
Match Cloud Spanner with global relational ACID consistency and horizontal scaling.
Cloud Spanner is the only fully managed GCP database that provides horizontal scaling combined with global multi-region ACID transactions.
2
Identify high-throughput analytics and ingestion requirements
Match Cloud Bigtable with high-throughput NoSQL time-series data.
Cloud Bigtable is optimized for heavy write throughput and real-time analytical workloads on NoSQL data structures.
3
Assess standard relational database engine needs within a single region
Match Cloud SQL with managed MySQL/PostgreSQL supporting regional failover.
Cloud SQL simplifies standard database management with turnkey regional high availability.
4
Determine high-performance block storage needs for VM-hosted databases
Match Extreme Persistent Disk (pd-extreme) with high provisioned IOPS requirements.
Extreme Persistent Disk allows provisioned IOPS up to top-tier thresholds specifically for heavy I/O workloads running directly on Compute Engine instances.

Key Concept

Planning GCP Database and Persistent Disk Types for Architectural Requirements
Question 850Question →

A cloud engineer needs to perform a safe canary release of an updated container image for an existing Cloud Run service named `billing-app`. What is the correct sequence of steps to execute this release from start to finish?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct deployment order is to first deploy the container image with the `--no-traffic` flag, second test the revision using its dedicated URL, third split a small percentage of production traffic to the revision for canary testing, and finally shift 100% of live traffic to the new revision.
A standard serverless canary deployment pattern on Cloud Run requires first staging the revision using `--no-traffic`, validating it directly via its unique URL, executing a partial traffic split for canary monitoring, and finally promoting the revision to 100% traffic.

Step-by-Step Solution

1
Deploy revision with `--no-traffic`
The revision is created safely in an isolated state receiving 0% of main service traffic.
Prevents unvalidated code from serving live production requests.
2
Perform revision-level testing
Sanity checks confirm proper revision initialization and endpoint responses.
Catches startup errors or broken endpoints early in isolation.
3
Configure partial traffic split
10% of production user traffic is routed to the new revision using `gcloud run services update-traffic`.
Allows real-world metric collection and canary testing with minimal impact.
4
Promote revision to 100% traffic
All incoming service traffic shifts to the new revision.
Completes the migration after stability and performance are verified.

Key Concept

Cloud Run Revision Deployment & Traffic Splitting Workflow
Question 851Question →

Your team is deploying a batch processing workload on Google Compute Engine and wants to optimize operational efficiency and costs while ensuring instances scale dynamically based on demand. Which two management actions should you perform? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the Managed Instance Group (MIG) to use Spot virtual machine instances for cost-effective batch processing.; Attach an autoscaling policy to the Managed Instance Group based on CPU utilization or custom queue metrics.

Answer

The correct actions are configuring the Managed Instance Group to use Spot VMs for batch workloads and attaching an autoscaling policy based on CPU or queue metrics.
Configuring a Managed Instance Group to use Spot VMs allows stateless batch processing tasks to run at lower costs, while configuring an autoscaling policy ensures instance capacity scales up or down automatically based on demand.

Step-by-Step Solution

1
Identify the workload requirements
The workload consists of fault-tolerant batch jobs that require dynamic scaling and cost reduction.
Batch workloads can tolerate instance interruptions and benefit from automated capacity adjustments.
2
Select the appropriate Compute Engine instance provision model and group scaling mechanism
Use Spot VMs for discounted pricing and attach an autoscaler to the MIG based on load indicators like CPU utilization.
Spot VMs provide significant cost savings for batch jobs, while MIG autoscaling adjusts compute resources based on real-time load.

Key Concept

Compute Engine Managed Instance Group (MIG) Management and Spot VM Workload Placement
Question 852Question →

An enterprise is deploying an internal backend microservice hosted on Compute Engine instances across multiple zones within a single Virtual Private Cloud (VPC) network. The microservice receives raw TCP RPC requests directly from other internal workloads. The network architecture requires an internal load balancing mechanism that provides high availability, supports TCP health checks, and preserves the original client IP addresses without proxying or performing Layer 7 inspection. Which Google Cloud load balancing solution should you choose?

Show answer & explanation

Answer: Internal Passthrough Network Load Balancer

Answer

The Internal Passthrough Network Load Balancer is the correct choice because it provides regional, Layer 4 internal load balancing for TCP/UDP traffic without proxying, preserving the original client source IP addresses.
The Internal Passthrough Network Load Balancer is built on Andromeda network virtualization. It distributes internal Layer 4 (TCP/UDP) traffic among instances in the same region within a VPC. Because it is non-proxied (passthrough), packets arrive at the backend virtual machines with the source client IP intact, matching all workload requirements.

Step-by-Step Solution

1
Analyze the network traffic requirements
Traffic is strictly internal within the VPC network, uses raw TCP RPC protocol, and requires client IP preservation without proxying.
Determines whether an internal or external, Layer 4 or Layer 7 load balancer is required.
2
Evaluate Google Cloud load balancer capabilities against the constraints
Layer 7 (Application) load balancers proxy HTTP/HTTPS traffic and terminate connections. External load balancers accept internet traffic. Internal Passthrough Network Load Balancers process regional internal Layer 4 TCP/UDP traffic directly to backends.
Selecting the passthrough L4 internal load balancer satisfies both the protocol requirement (raw TCP) and the architecture constraint (client IP preservation inside VPC).

Key Concept

Selecting GCP Load Balancers based on Traffic Scope (Internal vs External), OSI Layer (L4 vs L7), and Proxy Behavior (Passthrough vs Proxy)
Estimated Time:1m 30s
Question 853Question →

Your team stores application log files in a Google Cloud Storage bucket. These logs are accessed frequently during the first 30 days after creation. After 30 days, the logs are rarely accessed, but they must be retained for one year for compliance auditing. You want to automate moving these objects to a lower-cost storage class after 30 days to minimize storage expenses. What should you do?

Show answer & explanation

Answer: Configure an Object Lifecycle Management rule on the bucket to change the storage class of objects to Coldline when their age reaches 30 days.

Answer

Configure an Object Lifecycle Management rule on the bucket to change the storage class of objects to Coldline when their age reaches 30 days.
Configuring an Object Lifecycle Management rule to transition objects to Coldline Storage after 30 days automatically shifts rarely accessed logs into a cheaper storage class while satisfying the one-year retention requirement.

Step-by-Step Solution

1
Analyze data access patterns and compliance retention requirements
Log files are actively accessed for 30 days, then rarely accessed for the remainder of a one-year retention period.
Cloud Storage tiers are priced based on access frequency and data longevity.
2
Identify the appropriate target Cloud Storage class for infrequently accessed objects
Coldline Storage offers reduced monthly storage fees suitable for objects accessed at most once per 30 days.
Transitioning objects from Standard to Coldline reduces ongoing monthly storage expenses.
3
Automate class transitions using Object Lifecycle Management
Define a lifecycle rule specifying an Age condition of 30 days and a Set Storage Class action targeting Coldline.
Object Lifecycle Management enforces storage policies automatically without requiring custom scripts or manual intervention.

Key Concept

Cloud Storage Object Lifecycle Management for cost optimization
Estimated Time:45s
Question 854Question →

A financial analytics firm is configuring an automated deployment pipeline to provision Compute Engine instances for evening risk-modeling simulations. The workload consists of fault-tolerant, stateless processing jobs that can sustain abrupt instance terminations. Security policies require adhering to the principle of least privilege, using dedicated service account identities, and executing a boot-time bootstrap script stored in a private Cloud Storage bucket (`gs://finance-scripts-prod/bootstrap.sh`). Which TWO configuration flags must be included in the `gcloud compute instances create` command to satisfy these operational and security requirements?

Select all that apply

Show answer & explanation

Answer: --provisioning-model=SPOT to leverage excess compute capacity at significantly reduced costs for fault-tolerant batch workloads.; --metadata=startup-script-url=gs://finance-scripts-prod/bootstrap.sh to direct Compute Engine to download and run the script from Cloud Storage upon booting.

Answer

The correct flags are specifying `--provisioning-model=SPOT` to run cost-effective fault-tolerant workloads, and using `--metadata=startup-script-url=gs://finance-scripts-prod/bootstrap.sh` to execute the startup script hosted in Google Cloud Storage.
Specifying `--provisioning-model=SPOT` is the recommended GCP mechanism for provisioning low-cost, fault-tolerant compute capacity suitable for stateless batch workloads. Additionally, using `--metadata=startup-script-url=gs://finance-scripts-prod/bootstrap.sh` allows Compute Engine instances to automatically fetch and execute the boot script stored in Cloud Storage without requiring custom disk images or manually injected startup script code.

Step-by-Step Solution

1
Analyze the workload requirements for cost optimization and fault tolerance.
Stateless batch risk-modeling jobs can sustain terminations, making Spot VMs (`--provisioning-model=SPOT`) the ideal deployment choice for cost efficiency.
Spot instances offer up to 60-91% discounts compared to standard pricing for fault-tolerant jobs.
2
Determine the proper `gcloud` flag syntax for bootstrapping instances via a private Cloud Storage script.
The correct metadata key for GCS-hosted startup scripts is `--metadata=startup-script-url=gs://...`.
Compute Engine guest environment reads the `startup-script-url` key from instance metadata to fetch and execute remote scripts.
3
Identify wrong option flags and syntax misconceptions.
Passing a service account email to `--scopes` is invalid syntax (service accounts require `--service-account`), and setting `--maintenance-policy=MIGRATE` violates Spot instance constraints.
Spot VMs cannot be live-migrated and must terminate during host events.

Key Concept

Deploying Compute Engine Virtual Machines with Spot provisioning models and startup script metadata flags using the `gcloud` CLI.
Question 855Question →

Your enterprise organization has two Virtual Private Cloud (VPC) networks, `shared-services-vpc` and `application-vpc`, in the same Google Cloud project. You are deploying an Internal HTTP(S) Load Balancer in `application-vpc` to expose a microservice, and you need clients in both VPC networks to resolve the load balancer's internal IP address using a private DNS domain name (`internal.example.com`). Which of the following configuration steps are required to successfully deploy this solution? (Select TWO choices.)

Select all that apply

Show answer & explanation

Answer: Authorize both `application-vpc` and `shared-services-vpc` in the Cloud DNS private zone network visibility settings.; Reserve and allocate a dedicated proxy-only subnet in the region where the Internal HTTP(S) Load Balancer is deployed.

Answer

To successfully allow private DNS resolution across multiple VPCs and deploy an Internal HTTP(S) Load Balancer, you must authorize both VPC networks in the Cloud DNS private zone settings and create a regional proxy-only subnet for the load balancer's Envoy proxies.
Authorizing both VPC networks in the Cloud DNS private zone configuration ensures that VMs in both networks can query and resolve internal DNS records. Creating a regional proxy-only subnet is a strict prerequisite for deploying an Internal HTTP(S) Load Balancer because Envoy proxies require IP addresses allocated from this dedicated subnet to forward requests to backend services.

Step-by-Step Solution

1
Configure Cloud DNS Private Zone Network Visibility
Both `application-vpc` and `shared-services-vpc` are attached to the Cloud DNS private zone (`internal.example.com`).
By default, a private DNS zone is accessible only by authorized VPC networks in the project.
2
Allocate a Proxy-Only Subnet
A regional proxy-only subnet is created with an appropriate CIDR range (e.g., `/26` or larger) in the target region.
GCP regional Internal HTTP(S) Load Balancers require a proxy-only subnet to instantiate Envoy proxy instances that handle Layer 7 traffic routing.

Key Concept

Cloud DNS Private Zone Authorization and Internal HTTP(S) Load Balancing Subnet Requirements
Question 856Question →

A Cloud Engineer needs to modify an existing Google Cloud Deployment Manager deployment named `prod-network-deployment` to update firewall rules defined in `network_config.yaml`. To adhere to strict operational compliance, the engineer must stage and preview the proposed infrastructure changes, inspect the staged manifest to verify resource state, and then commit the updates to production. In what sequence should the engineer execute these tasks?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with updating the local `network_config.yaml` file, followed by staging the preview with `gcloud deployment-manager deployments update prod-network-deployment --config network_config.yaml --preview`, reviewing the staged manifest using `gcloud deployment-manager deployments describe prod-network-deployment`, and finally committing the previewed deployment using `gcloud deployment-manager deployments update prod-network-deployment`.
To preview and safely commit updates in Google Cloud Deployment Manager, configuration files must first be updated locally. Next, running `gcloud deployment-manager deployments update` with the `--preview` flag creates a staged manifest without applying changes to active infrastructure. Running `gcloud deployment-manager deployments describe` outputs the staged changes for audit and verification. Finally, executing `gcloud deployment-manager deployments update` without passing a config file applies the previously staged preview.

Step-by-Step Solution

1
Modify the local deployment configuration file (`network_config.yaml`).
The target state definition is updated locally.
Deployment Manager requires updated source files to evaluate schema changes.
2
Execute the preview command using `gcloud deployment-manager deployments update prod-network-deployment --config network_config.yaml --preview`.
The proposed deployment update is calculated and staged in preview mode.
The `--preview` flag allows reviewing changes safely without modifying active cloud resources.
3
Inspect the deployment state using `gcloud deployment-manager deployments describe prod-network-deployment`.
The detailed manifest of staged pending changes is displayed.
Verifying the manifest ensures no unintended resource modifications occur.
4
Commit the staged deployment changes using `gcloud deployment-manager deployments update prod-network-deployment`.
Deployment Manager applies the pending preview manifest to live GCP infrastructure.
Omitting `--config` applies the currently staged preview without re-parsing or overriding the input file.

Key Concept

Deployment Manager Preview and Update Lifecycle Execution
Question 857Question →

A cloud engineer needs to deploy a Cloud SQL for PostgreSQL database instance that is accessible exclusively using Private IP within an existing VPC network named `prod-vpc`. Arrange the operational steps in the correct sequential order to establish Private Service Access and provision the database instance.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: First, allocate an internal IP address range in the VPC network for private services. Second, establish a private connection (VPC peering) to the service producer. Third, provision the Cloud SQL instance with private IP enabled and public IP disabled. Fourth, create the initial database and configure database users.
To set up Cloud SQL with Private IP, you must first allocate an internal IP range in your VPC network. Next, you establish a VPC peering connection to `servicenetworking.googleapis.com` using that reserved range. Once private connectivity is established, you can create the Cloud SQL instance associated with the VPC network without assigning a public IP. Finally, you create the application database and user accounts inside the instance.

Step-by-Step Solution

1
Allocate internal IP address range in the VPC
Reserved IP range is available for private service allocation.
Private Service Access requires a dedicated internal IP address block in the host VPC network before connecting.
2
Create VPC peering with Service Networking API
Peering connection is established between the host VPC and Google's tenant VPC.
Cloud SQL Private IP relies on VPC Network Peering managed by the Service Networking API to connect the customer network to Google service infrastructure.
3
Provision Cloud SQL instance using `--network` and `--no-assign-ip`
Cloud SQL instance is deployed with an internal IP address within the peered range.
The database instance creation depends on the underlying private service connection already being established.
4
Create database user and application database
Database application environment is ready for application connections.
Administrative database user credentials and databases can only be configured once the instance is active.

Key Concept

Configuring Private Service Access for Cloud SQL Private IP connectivity
Question 858Question →

A cloud engineer needs to deploy a containerized web application to an existing Google Kubernetes Engine (GKE) cluster and make it accessible to external users via a Google Cloud Load Balancer. Place the operational steps in the correct sequence from start to finish.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with fetching cluster credentials using `gcloud container clusters get-credentials`, followed by drafting the Deployment YAML manifest, deploying the manifest with `kubectl apply`, exposing the deployment via a `LoadBalancer` Service, and concluding with `kubectl get service` to obtain the external IP address.
The canonical workflow for deploying GKE workloads requires authenticating `kubectl` via `gcloud container clusters get-credentials`, defining the workload manifest file, applying the manifest via `kubectl apply`, exposing the deployment to external users via a `LoadBalancer` Service, and finally inspecting the allocated IP using `kubectl get service`.

Step-by-Step Solution

1
Authenticate kubectl against the target GKE cluster
The local `kubeconfig` file is updated with cluster credentials and control plane endpoint data.
Authentication credentials are required for `kubectl` to execute API requests against GKE.
2
Draft the deployment specification
A valid declarative YAML configuration (`deployment.yaml`) is created.
Kubernetes resources require declarative definitions outlining desired state.
3
Apply the deployment manifest to GKE
The Kubernetes control plane creates the Deployment object and provisions application pods.
`kubectl apply` transmits the manifest specification to the Kubernetes API server.
4
Expose the application pods via a LoadBalancer Service
GCP provisions a Cloud Load Balancer pointing to the application pods.
Creating a Service of type LoadBalancer bridges external network traffic to internal pod endpoints.
5
Inspect the Service status for external IP assignment
The external IP address assigned by Google Cloud is displayed.
`kubectl get service` allows verification of external network ingress.

Key Concept

GKE Workload Deployment and Service Exposure Workflow
Estimated Time:1m 30s
Question 859Question →

Your organization operates a high-availability production application running on a Compute Engine Regional Managed Instance Group (MIG). You need to perform a seamless software update by deploying a new instance template named `template-v2`. The deployment process must guarantee zero application downtime and ensure that replacement instances are fully booted, initialized, and verified healthy before any existing instances are taken offline. Which two actions should you take to achieve this?

Select all that apply

Show answer & explanation

Answer: Perform a rolling update on the MIG referencing `template-v2` with the `maxUnavailable` parameter set to 0.; Configure a positive `minReadySec` value in the MIG update policy to enforce a delay after instance startup before marking the update of that instance as complete.

Answer

To perform a zero-downtime update that validates instance readiness, initiate a rolling update referencing the new template with `maxUnavailable` set to 0 and configure `minReadySec` in the update policy.
Performing a rolling update with `maxUnavailable` set to 0 ensures that Compute Engine creates new instances before taking old ones down, preserving total capacity. Additionally, configuring `minReadySec` enforces a mandatory wait time after an instance starts up and passes health checks, guaranteeing that the new instance is serving traffic cleanly before the system moves on to replace the next instance.

Step-by-Step Solution

1
Configure the rolling update policy with `maxUnavailable = 0`
Guarantees that full instance capacity is maintained throughout the rollout because no active instance is destroyed before a new replacement instance is online.
Setting `maxUnavailable` to 0 forces Compute Engine to create surplus (surge) instances first before terminating older instances.
2
Set `minReadySec` to an appropriate duration matching application initialization time
Prevents premature termination of healthy instances by waiting for new instances to pass health checks and run for the specified duration.
Ensures the application software inside the VM is fully booted and operational before the rolling update algorithm considers the instance update successful.

Key Concept

Compute Engine MIG Rolling Update Policy Configuration
Estimated Time:3m 0s
Question 860Question →

A site reliability engineering (SRE) team receives alerts that several replicas of a data processing service deployed on a Google Kubernetes Engine (GKE) Standard cluster are stuck in a Pending state. Running kubectl describe pod reveals the event condition 0/6 nodes are available: 6 Insufficient cpu. The existing node pool contains 6 compute instances and currently has autoscaling disabled. Resource requests and limits for the workload containers are properly defined in the Deployment manifest. Which operational action should the cloud engineer take to resolve the pending Pods and enable dynamic node scaling based on resource demand?

Show answer & explanation

Answer: Enable Cluster Autoscaler on the existing node pool by running gcloud container node-pools update with the --enable-autoscaling flag and defining --min-nodes and --max-nodes boundaries.

Answer

Enable Cluster Autoscaler on the existing node pool by running gcloud container node-pools update with the --enable-autoscaling flag and defining --min-nodes and --max-nodes boundaries.
Enabling Cluster Autoscaler on the node pool using gcloud container node-pools update --enable-autoscaling allows GKE to detect unschedulable Pods (caused by insufficient CPU) and automatically scale up the number of Compute Engine worker nodes within specified --min-nodes and --max-nodes limits.

Step-by-Step Solution

1
Analyze the error state from kubectl describe pod.
The message 0/6 nodes are available: 6 Insufficient cpu indicates that all 6 nodes in the cluster are at full CPU capacity, preventing new Pods from being scheduled.
Existing compute node resources are completely exhausted while Pod resource requests are valid.
2
Differentiate between workload scaling (HPA) and infrastructure scaling (Cluster Autoscaler).
HPA scales Pod count, whereas Cluster Autoscaler provisions additional Compute Engine VM instances in a GKE node pool when Pods are unschedulable due to resource constraints.
Creating more Pods via HPA will not help when the cluster lacks node CPU capacity; new nodes must be added.
3
Select the correct gcloud command to enable node autoscaling on the existing GKE node pool.
Running gcloud container node-pools update <pool-name> --cluster=<cluster-name> --enable-autoscaling --min-nodes=<min> --max-nodes=<max> enables the Cluster Autoscaler for that node pool.
This enables GKE to automatically scale the node count up to max-nodes when Pods are unschedulable.

Key Concept

GKE Cluster Autoscaler vs Horizontal Pod Autoscaler (HPA)
PreviousPage 43 / 80Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin