Examkin

All practice questions

1591 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 721Question →

Your organization maintains a central Cloud DNS private zone named `corp.internal` that was initially associated with a Virtual Private Cloud (VPC) network named `mgmt-vpc`. You have created a new application network named `prod-vpc` within the same Google Cloud project. Virtual machines in `prod-vpc` need to resolve private domain names defined in `corp.internal` without exposing the DNS zone publicly or deploying dedicated proxy virtual machines. Which TWO actions must you perform to allow VMs in `prod-vpc` to resolve private hostnames in `corp.internal`? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Edit the `corp.internal` Cloud DNS private zone configuration to add `prod-vpc` to the list of authorized VPC networks.; Ensure that instance operating systems in `prod-vpc` send internal DNS queries to the default Google Cloud internal metadata DNS server address (`169.254.169.254`).

Answer

The correct actions are to add the new VPC network to the authorized networks list of the existing Cloud DNS private zone, and to ensure that VMs in the network route internal DNS queries to the internal metadata DNS server address at 169.254.169.254.
To allow virtual machines in a new VPC to resolve records hosted in an existing Cloud DNS private zone, you must add the new VPC network to the zone's list of authorized networks. Additionally, workloads must use the standard Google Cloud metadata DNS resolver at 169.254.169.254, which handles lookup requests for all private zones authorized for that network.

Step-by-Step Solution

1
Identify how Cloud DNS private zones manage multi-VPC access within a single project.
Recognize that adding a VPC network to the authorized networks list of a private zone allows instances in that VPC to resolve the zone's DNS records.
Private zone records are accessible only to networks explicitly authorized on the zone.
2
Verify how Compute Engine VMs query Cloud DNS private zones.
Confirm that instances direct internal name queries to the default internal metadata server at 169.254.169.254.
The internal metadata server acts as the local recursive resolver for all authorized Cloud DNS zones.

Key Concept

Cloud DNS Private Zone Multi-VPC Authorization
Question 722Question →

A mobile gaming software development team stores daily automated crash log bundles in a Google Cloud Storage bucket. Developers frequently inspect and analyze these crash logs during the first 14 days following an application release. After 14 days, the logs are rarely accessed, but company compliance requires preserving them for 365 days before permanent deletion. The team wants to minimize storage and access costs without manual administration. Which bucket configuration should you implement?

Show answer & explanation

Answer: Set the default bucket storage class to Standard. Add an Object Lifecycle Management rule to set the storage class to Nearline after 14 days, and another rule to delete objects after 365 days.

Answer

Set the default bucket storage class to Standard, configure an Object Lifecycle Management rule to transition objects to Nearline storage after 14 days, and add a rule to delete objects after 365 days.
The correct strategy starts with Standard storage class to avoid data retrieval charges while engineers actively inspect log files during the first two weeks. Using an Object Lifecycle Management rule to transition files to Nearline storage after 14 days optimizes storage costs for the remaining period, and setting a deletion rule at 365 days enforces compliance automatically.

Step-by-Step Solution

1
Analyze access patterns for the initial lifecycle phase.
Crash log bundles are accessed frequently during the first 14 days.
Standard storage is optimized for frequent access with zero retrieval fees.
2
Analyze access patterns for the secondary lifecycle phase.
Data is accessed less than once a month after 14 days, up to day 365.
Nearline storage offers lower monthly storage costs for data accessed infrequently (typically once a month or less).
3
Determine the lifecycle management transition and deletion rules.
Transition to Nearline at age 14 days, and delete at age 365 days.
Object Lifecycle Management automates cost optimization and retention policies without operational overhead.

Key Concept

Selecting Cloud Storage classes based on data access frequency and configuring Object Lifecycle Management transition rules.
Estimated Time:1m 30s
Question 723Question →

A DevOps engineer at an e-commerce platform needs to create a new Google Cloud Storage bucket in the europe-west3 region to archive generated end-of-day customer invoice documents. The documents are accessed occasionally during the first 30 days after generation and must have access rights controlled strictly via IAM permissions across the entire bucket, preventing any individual object-level ACL assignments. Which gcloud CLI command meets these requirements using current Google Cloud recommended practices?

Show answer & explanation

Answer: gcloud storage buckets create gs://invoice-archive-bucket --location=europe-west3 --default-storage-class=nearline --uniform-bucket-level-access

Answer

Execute 'gcloud storage buckets create gs://invoice-archive-bucket --location=europe-west3 --default-storage-class=nearline --uniform-bucket-level-access'.
The correct command utilizes the current Google Cloud CLI interface ('gcloud storage buckets create') to provision the bucket in the specified region ('europe-west3'), sets Nearline as the default storage class for monthly accessed files, and enforces Uniform Bucket-Level Access to delegate all permission management to IAM policies.

Step-by-Step Solution

1
Identify the recommended CLI tool suite for Cloud Storage management.
Use 'gcloud storage' commands instead of legacy 'gsutil' commands.
Google Cloud recommends 'gcloud storage' CLI for improved performance and unified gcloud user experience.
2
Determine the appropriate storage class for occasionally accessed invoice archives.
Select Nearline storage class using '--default-storage-class=nearline'.
Nearline storage is optimized for data accessed at most once a month, offering lower storage costs compared to Standard storage.
3
Configure bucket access control enforcement.
Include the '--uniform-bucket-level-access' flag.
Uniform Bucket-Level Access disables ACLs and ensures access is governed exclusively through IAM permissions across all objects in the bucket.

Key Concept

Deploying Cloud Storage Buckets with gcloud storage CLI and Uniform Bucket-Level Access
Question 724Question →

A cloud engineer has prepared a set of Terraform configuration files to provision Google Cloud infrastructure. Before applying any changes to the environment, the engineer wants to preview the execution plan and verify which resources will be created or modified. Which command should the cloud engineer run?

Show answer & explanation

Answer: terraform plan

Answer

The command 'terraform plan' should be run to preview resource changes before applying them.
Executing 'terraform plan' parses the local configuration files, compares them against the current Terraform state file and live GCP infrastructure, and outputs the detailed set of additions, modifications, or deletions that would occur upon deployment without altering any resources.

Step-by-Step Solution

1
Identify the goal of the cloud engineer
The engineer needs to inspect planned infrastructure changes prior to deployment.
Previewing state changes prevents unintended modification or destruction of cloud infrastructure.
2
Match the requirement with standard Terraform CLI commands
The command 'terraform plan' reads the current state and configuration to output a detailed execution delta.
'terraform plan' is the designated Terraform command for speculative execution planning.

Key Concept

Terraform Execution Plan Generation
Estimated Time:45s
Question 725Question →

A DevOps team needs to set up a Google Cloud Storage bucket named `iot-log-repository` in the `europe-west1` region to hold daily application logs. The team has prepared a local configuration file named `lifecycle.json` containing lifecycle rules to transition objects to Nearline storage after 30 days and delete them after 365 days. Which set of commands represents the Google-recommended approach using the modern Google Cloud CLI to provision the bucket and apply this lifecycle policy?

Show answer & explanation

Answer: Run `gcloud storage buckets create gs://iot-log-repository --location=europe-west1` followed by `gcloud storage buckets update gs://iot-log-repository --lifecycle-file=lifecycle.json`.

Answer

Execute `gcloud storage buckets create gs://iot-log-repository --location=europe-west1` to provision the bucket, then execute `gcloud storage buckets update gs://iot-log-repository --lifecycle-file=lifecycle.json` to assign the lifecycle policy.
The standard Google-recommended command for provisioning a Cloud Storage bucket is `gcloud storage buckets create`. Modifying bucket properties, including setting lifecycle management rules from a JSON specification file, is accomplished via `gcloud storage buckets update --lifecycle-file=FILENAME`.

Step-by-Step Solution

1
Provision the Cloud Storage bucket using modern CLI tools.
Bucket `gs://iot-log-repository` is created in `europe-west1` using `gcloud storage buckets create`.
Google Cloud recommends `gcloud storage` over `gsutil` for improved performance and unified CLI experience.
2
Apply the lifecycle rule configuration.
The bucket lifecycle configuration is updated via `gcloud storage buckets update --lifecycle-file=lifecycle.json`.
Lifecycle rules govern object retention and storage class transitions at the bucket resource level.

Key Concept

Cloud Storage Bucket Provisioning and Lifecycle Management with gcloud storage CLI
Question 726Question →

A Cloud Engineer is tasked with bringing an existing, manually created Compute Engine VM instance named `legacy-app-vm` under Terraform management. The infrastructure state must be maintained in a remote Google Cloud Storage (GCS) backend. In what sequence should the engineer execute the following steps to safely import the VM instance without causing resource recreation or downtime?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct deployment sequence is: 1) Configure the GCS backend and run `terraform init`, 2) Declare a skeleton resource block in HCL, 3) Execute `terraform import` using the GCP resource identifier, 4) Update the HCL resource arguments to match live attributes, and 5) Run `terraform plan` to confirm zero pending changes.
Importing existing GCP infrastructure into Terraform requires initializing the remote backend first, declaring an empty resource block in code to anchor the import command, pulling live state via `terraform import`, updating the HCL code to match the state, and validating zero plan diffs with `terraform plan`.

Step-by-Step Solution

1
Initialize Remote Backend
State storage is linked to the designated GCS bucket.
Initializing the GCS backend ensures state locking and guarantees that imported resource metadata persists directly to remote state.
2
Declare Skeleton Resource Identifier
Terraform recognizes `google_compute_instance.legacy_vm` as a valid target address.
The `terraform import` CLI command fails if the target resource address is missing from configuration files.
3
Import Existing GCP Resource
Live VM metadata is written to the GCS remote state.
This binds the actual GCP instance object to the Terraform resource address without modifying live infrastructure.
4
Align HCL Code with Live Attributes
HCL definitions match all imported properties such as machine type, disk settings, and network interfaces.
Terraform state holds the imported values, but code files must be manually matched to prevent drift.
5
Validate Parity with `terraform plan`
Terraform reports 'No changes. Your infrastructure matches the configuration.'
Running plan verifies that future execution of `terraform apply` will not attempt to update or recreate the imported instance.

Key Concept

Terraform Resource Import & GCS State Synchronization
Question 727Question →

An organization runs a production application on an existing Standard Google Kubernetes Engine (GKE) cluster. The data science team needs to deploy a batch data processing job that is stateless, fault-tolerant, and designed to handle sudden instance terminations gracefully. To minimize compute expenses, management requests running this batch job on cost-optimized infrastructure without risking the availability of existing critical stateful workloads running on standard nodes. Which deployment strategy should the Cloud Engineer execute to satisfy these requirements?

Show answer & explanation

Answer: Create a dedicated node pool configured with Spot VMs using gcloud container node-pools create with the --spot flag, apply node taints to the pool, and add corresponding tolerations in the batch job manifest.

Answer

Create a dedicated node pool configured with Spot VMs using gcloud container node-pools create with the --spot flag, apply node taints to the pool, and add corresponding tolerations in the batch job manifest.
Spot VMs are designed for fault-tolerant and stateless batch processing. Provisioning a dedicated Spot node pool with node taints ensures cost minimization for the batch processing job while protecting critical stateful workloads from being scheduled on preemptible nodes.

Step-by-Step Solution

1
Identify workload characteristics and compute requirements.
The batch job is stateless and fault-tolerant, making it an ideal candidate for GKE Spot VMs to lower compute costs.
Spot VMs offer steep discounts in exchange for preemptibility, which fits stateless, restartable batch jobs.
2
Provision a dedicated Spot node pool using gcloud CLI.
Execute `gcloud container node-pools create <pool-name> --cluster=<cluster-name> --spot --node-taints=workload=batch:NoSchedule`.
Creating a separate node pool ensures compute isolation, while the `--spot` flag provisions preemptible capacity.
3
Configure scheduling restrictions to isolate stateful workloads.
Taint the Spot node pool so regular pods without tolerations avoid it, and add matching tolerations/nodeAffinity to the batch Pod specification.
This guarantees that critical stateful workloads remain safely on standard nodes while batch pods schedule onto the Spot nodes.

Key Concept

GKE Spot Node Pools and Workload Scheduling Isolation
Question 728Question →

A developer packaged a Node.js REST API into a container image where the application server strictly listens on internal TCP port 8000 without reading the PORT environment variable. When deploying this container image to Google Cloud Run using the standard gcloud CLI command, deployment fails because startup health checks time out. How should the developer configure the deployment to successfully serve traffic on Cloud Run without modifying the application source code?

Show answer & explanation

Answer: Include the `--port=8000` flag during the `gcloud run deploy` command execution.

Answer

Include the `--port=8000` flag during the `gcloud run deploy` command execution.
Cloud Run defaults to sending ingress traffic to port 8080 inside the container. When an application hardcodes listening on port 8000 and ignores the PORT environment variable, specifying `--port=8000` in `gcloud run deploy` configures Cloud Run to route traffic to port 8000, resolving health check timeouts.

Step-by-Step Solution

1
Identify the container contract requirement for Cloud Run.
By default, Cloud Run sends HTTP requests to port 8080 inside the container and populates the PORT environment variable with 8080.
If an application does not consume the PORT environment variable and listens on a non-standard port like 8000, Cloud Run health checks targeting 8080 will time out.
2
Select the correct gcloud deployment flag to override default container port routing.
Passing `--port=8000` configures Cloud Run's ingress routing to direct requests directly to port 8000.
This allows custom legacy or third-party container images to run on Cloud Run without needing source code modifications.

Key Concept

Cloud Run Custom Container Port Binding
Question 729Question →

A cloud engineer manages a production Google Kubernetes Engine (GKE) Standard cluster hosting both latency-sensitive microservices and fault-tolerant background batch workloads. To reduce compute expenditures, the engineer needs to provision a secondary node pool using GCP Spot VMs for the batch workloads. The implementation must ensure that Cluster Autoscaler dynamically adjusts node counts based on pending pod demand, while strictly preventing latency-sensitive web pods from being scheduled onto Spot instances. Which strategy correctly configures the GKE node pool and workload specifications to satisfy these requirements?

Show answer & explanation

Answer: Create the new node pool using gcloud container node-pools create with the flags --spot, --enable-autoscaling, and --node-taints=cloud.google.com/gke-spot=true:NoSchedule, then add matching tolerations and node affinity to the batch workload Deployment manifests.

Answer

Create the node pool with Spot instances, Cluster Autoscaler enabled, and a node taint of cloud.google.com/gke-spot=true:NoSchedule via gcloud, while configuring corresponding tolerations and node affinity in the batch workload specifications.
Combining `--spot`, `--enable-autoscaling`, and `--node-taints` during node pool provisioning ensures that nodes scale automatically when unschedulable pods are queued, while guaranteeing that untolerated latency-sensitive workloads are never scheduled on Spot VMs. Adding tolerations and node affinity to the batch workloads enables them to run on the tainted Spot nodes.

Step-by-Step Solution

1
Identify the node pool creation flags required for Spot VM usage and cluster scaling.
Use `gcloud container node-pools create` with `--spot` for Spot VM pricing and `--enable-autoscaling` to allow Cluster Autoscaler to provision nodes when pods are unschedulable.
Cluster Autoscaler manages node pool scaling based on pending pod resource constraints, while `--spot` requests Spot instances.
2
Enforce node isolation for latency-sensitive workloads.
Apply `--node-taints=cloud.google.com/gke-spot=true:NoSchedule` during node pool creation.
Taints prevent default pods (such as latency-sensitive services) from landing on Spot nodes unless explicit tolerations exist.
3
Configure batch workload specifications to target the Spot node pool.
Add matching tolerations for `cloud.google.com/gke-spot=true:NoSchedule` and node affinity/selectors for Spot nodes to the batch Deployment manifests.
Tolerations permit the batch pods to schedule on tainted Spot nodes, while node affinity directs them specifically to those nodes.

Key Concept

Managing GKE Node Pools with Spot VMs, Cluster Autoscaler, and Taints/Tolerations
Estimated Time:3m 0s
Question 730Question →

A cloud engineer needs to deploy a Compute Engine virtual machine instance that automatically executes a bash initialization script stored in a private Cloud Storage bucket upon booting. The VM must adhere to the principle of least privilege using a custom service account. Arrange the required administrative steps in the correct chronological sequence from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: 1) Create the custom service account, 2) Grant the service account Storage Object Viewer permissions on the script bucket, 3) Upload the initialization script to Cloud Storage, 4) Deploy the VM with gcloud using the service account and startup-script-url metadata flags, and 5) Verify script execution logs via the serial port output.
The correct procedural order ensures identity creation and resource authorization occur before instance provisioning. First, creating the custom service account establishes a dedicated identity. Second, assigning the Storage Object Viewer IAM role on the bucket grants the necessary read permission. Third, staging the script file in Cloud Storage ensures the asset exists. Fourth, invoking gcloud compute instances create attaches the service account with --scopes=cloud-platform and supplies the --metadata=startup-script-url flag. Finally, retrieving serial port output validates that the startup script completed without error.

Step-by-Step Solution

1
Define workload identity
Custom service account created without default editor privileges.
Following the principle of least privilege requires establishing a specific non-default service account identity first.
2
Configure IAM access control
Service account authorized with Storage Object Viewer on the target bucket.
The startup script fetching mechanism runs under the instance service account identity during boot, requiring read access to Cloud Storage.
3
Stage application artifacts
Initialization script file uploaded to the GCS bucket path.
The file resource must exist at the specified gs:// URI prior to triggering the instance provisioning workflow.
4
Provision the Compute Engine VM
Instance created with custom service account identity and metadata key pointing to GCS URI.
Passing startup-script-url via metadata tells the Compute Engine startup agent to fetch and run the script automatically on boot.
5
Validate deployment
Serial console log stream inspected for successful script execution.
Serial port output records startup script stdout/stderr, providing positive empirical proof of successful initialization.

Key Concept

Deploying Compute Engine VMs with Custom Service Accounts and Cloud Storage Startup Scripts
Estimated Time:2m 0s
Question 731Question →

A DevOps engineer needs to prevent unexpected cost overruns in a development environment. The engineering lead requests that when monthly spend reaches $5,000, all non-essential Compute Engine instances in the project must immediately stop. The engineer plans to configure a Cloud Billing budget threshold at 100%. Which configuration approach will achieve this automated outcome?

Show answer & explanation

Answer: Connect the Cloud Billing budget to a Cloud Pub/Sub topic and deploy a Cloud Function that processes the budget notification to programmatically stop the VM instances.

Answer

Connect the Cloud Billing budget to a Cloud Pub/Sub topic and deploy a Cloud Function that processes the budget notification to programmatically stop the VM instances.
Cloud Billing budgets provide visibility into spending by sending threshold notification emails and publishing messages to Cloud Pub/Sub topics. Because budgets do not automatically shut down GCP services or stop billing, achieving automated resource shutdown requires linking the budget to a Cloud Pub/Sub topic and implementing a Cloud Function (or Cloud Run service) to programmatically stop Compute Engine VM instances upon receiving an over-budget message payload.

Step-by-Step Solution

1
Understand Cloud Billing budget capabilities
Recognize that Cloud Billing budgets are alerting mechanisms that generate emails or Pub/Sub messages, but do not natively restrict or shut down GCP resources.
Google Cloud prevents unexpected workload termination by keeping budget alerts informational by default.
2
Design automated remediation architecture
Link the billing budget to a Cloud Pub/Sub topic so JSON notifications are published asynchronously when threshold percentages are breached.
Pub/Sub acts as the event bus for budget status payload messages.
3
Implement programmatic shutdown logic
Subscribe a Cloud Function or Cloud Run service to the Pub/Sub topic to parse the cost payload and call the Compute Engine API to stop target VM instances when spend reaches 100%.
Custom code execution is required to perform operational actions like stopping instances or disabling billing.

Key Concept

Cloud Billing budgets do not automatically shut down resources or disable billing; automated enforcement requires connecting budget alerts to Cloud Pub/Sub and triggering serverless code (Cloud Functions/Cloud Run) to modify infrastructure state.
Question 732Question →

A system administrator is managing a web application running on a Google Kubernetes Engine (GKE) cluster. The administrator needs to ensure that the number of running Pod replicas automatically increases when application CPU utilization rises and scales down when traffic drops. Which GKE or Kubernetes feature should the administrator configure?

Show answer & explanation

Answer: Horizontal Pod Autoscaler (HPA)

Answer

The administrator should configure the Horizontal Pod Autoscaler (HPA) to automatically scale the number of Pod replicas based on CPU utilization.
Configuring a Horizontal Pod Autoscaler (HPA) allows GKE to automatically scale the number of Pod replicas up or down depending on metric thresholds like CPU utilization.

Step-by-Step Solution

1
Identify the workload scaling target
The goal is to scale the number of running Pod instances (workload replicas) in response to CPU load changes.
Scaling application instances horizontally requires managing the Deployment's replica count.
2
Evaluate Kubernetes scaling mechanisms
The Horizontal Pod Autoscaler (HPA) monitors metrics like target CPU utilization and increases or decreases replica count automatically.
HPA is specifically designed for workload-level horizontal scaling in GKE.

Key Concept

Horizontal Pod Autoscaler (HPA) vs Cluster Autoscaler
Question 733Question →

An infrastructure engineer manages a Google Kubernetes Engine (GKE) Standard cluster hosting a memory-intensive data processing workload in a node pool named `analytics-pool`. The current nodes using `e2-standard-4` machine types are consistently running out of memory. The engineer must upgrade `analytics-pool` to use `e2-standard-8` machine types with minimal disruption to running pods. Which operational procedure should the engineer perform?

Show answer & explanation

Answer: Create a new node pool with the `e2-standard-8` machine type, cordon and drain the nodes in `analytics-pool`, and then delete `analytics-pool` once workloads migrate.

Answer

Create a new node pool with the required machine type, cordon and drain the existing node pool nodes, and delete the original node pool after workloads successfully migrate.
Because node VM machine types in GKE node pools are immutable once created, changing node hardware specifications requires creating a new node pool with the desired machine type (`e2-standard-8`), safely draining workloads off the old nodes using `kubectl cordon` and `kubectl drain`, and deleting the old node pool once migration completes.

Step-by-Step Solution

1
Provision a new node pool in the existing GKE cluster using `gcloud container node-pools create` with `--machine-type=e2-standard-8`.
New nodes with the larger memory footprint become ready to accept pods.
GKE node pool machine types are immutable after creation.
2
Cordon the old nodes in `analytics-pool` using `kubectl cordon` to prevent new pod scheduling, then execute `kubectl drain` to evict running pods.
Pods are gracefully terminated on old nodes and rescheduled onto the new `e2-standard-8` nodes.
Draining ensures workload continuity without unexpected downtime.
3
Delete the original `analytics-pool` using `gcloud container node-pools delete` after all pods migrate successfully.
Unused compute resources are removed, preventing unnecessary billing.
Cleans up deprecated cluster infrastructure.

Key Concept

GKE Node Pool Migration & Machine Type Immutability
Estimated Time:2m 0s
Question 734Question →

A cloud engineer needs to deploy a custom Virtual Private Cloud (VPC) infrastructure in Google Cloud to host secure internal applications. The requirements specify creating a VPC network without automatic subnet creation, provisioning a regional subnet, launching a Compute Engine VM with a specific network tag in that subnet, and enforcing an ingress firewall rule that allows SSH traffic (TCP port 22) exclusively to instances carrying that network tag. In what order should the engineer execute the following `gcloud` CLI commands to ensure all resource dependencies are satisfied without errors?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with provisioning the parent VPC network in custom subnet mode (`gcloud compute networks create --subnet-mode=custom`), followed by creating the regional custom subnet inside that network (`gcloud compute networks subnets create`), then launching the Compute Engine VM instance attached to the subnet with the designated network tag (`gcloud compute instances create --tags`), and finally creating the ingress firewall rule configured with matching target tags on the VPC network (`gcloud compute firewall-rules create --target-tags`).
Resource creation in Google Cloud networking strictly follows a hierarchical dependency structure: Network → Subnet → Compute Instance with Tags → Firewall Rule targeting Tags. Creating the VPC network with `--subnet-mode=custom` establishes the network container. Next, explicit creation of the regional subnet defines the IP address space. The VM instance is then provisioned into that subnet and assigned network tags. Finally, the firewall rule targeting those network tags is created on the network.

Step-by-Step Solution

1
Create the custom VPC network
The VPC network `enterprise-vpc` is created in custom mode with no default regional subnets.
VPC subnets, compute instances, and firewall rules depend on a pre-existing VPC network resource.
2
Create the regional custom subnet within the VPC network
The subnet `prod-subnet-us-central1` with CIDR `10.10.0.0/24` is created in `us-central1`.
In custom mode VPCs, subnets are not created automatically; instances cannot be provisioned without specifying an existing subnet.
3
Provision the Compute Engine VM instance in the custom subnet with the network tag
The instance `app-vm-1` receives an IP in `10.10.0.0/24` and is labeled with the tag `bastion-ssh-target`.
Target network tags must be present on instance metadata for tag-based firewall filtering to evaluate and route traffic to the intended host.
4
Deploy the ingress firewall rule filtering by target network tag
An ingress rule allowing TCP port 22 is attached to `enterprise-vpc`, targeting only instances tagged `bastion-ssh-target`.
Firewall rules reference the VPC network and filter traffic directed to tagged compute workloads.

Key Concept

GCP VPC Resource Dependency Hierarchy and Deployment Sequencing
Estimated Time:2m 30s
Question 735Question →

An enterprise operations team requires access to inspect Cloud Logging logs and view Cloud Monitoring metrics for resources in a specific project without permission to modify infrastructure or view underlying application datasets. To adhere to Google Cloud best practices for least privilege, which TWO predefined IAM roles should you grant to the operations team members? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Logs Viewer (`roles/logging.viewer`) granted at the project level; Monitoring Viewer (`roles/monitoring.viewer`) granted at the project level

Answer

To allow the operations team to view logs and monitoring metrics under the principle of least privilege, grant the Logs Viewer (`roles/logging.viewer`) and Monitoring Viewer (`roles/monitoring.viewer`) predefined roles at the project level.
Granting Logs Viewer (`roles/logging.viewer`) and Monitoring Viewer (`roles/monitoring.viewer`) enforces least privilege by restricting access specifically to log entries and monitoring metrics without granting broad access to underlying datasets or infrastructure configuration.

Step-by-Step Solution

1
Identify the specific operational access requirements
The operations team needs read-only access to log entries in Cloud Logging and performance metrics in Cloud Monitoring.
Least privilege mandates granting only the specific roles necessary to complete the required operational tasks.
2
Select fine-grained predefined roles over broad primitive roles
Select Logs Viewer (`roles/logging.viewer`) and Monitoring Viewer (`roles/monitoring.viewer`).
Predefined roles restrict permissions to specific services, whereas the primitive Project Viewer role grants excessive read access across all project resources.
3
Determine correct IAM resource hierarchy placement
Apply role bindings directly at the project level.
IAM permissions are additive and inherit down the hierarchy (Organization > Folder > Project). Granting roles higher up does not restrict lower-level access.

Key Concept

Selecting predefined IAM roles for Cloud Logging and Cloud Monitoring to enforce the principle of least privilege.
Question 736Question →

A financial company is designing the network architecture for an internal analytics microservice hosted on Compute Engine instances across multiple subnets within a single Google Cloud region. The service receives HTTPS traffic strictly from other internal VPC workloads and on-premises hosts connected via Dedicated Interconnect. The architecture requires Layer 7 path-based request routing and internal SSL/TLS termination without allocating any public IP addresses. Which load balancer type should you plan to implement?

Show answer & explanation

Answer: Regional Internal Application Load Balancer

Answer

Regional Internal Application Load Balancer
The Regional Internal Application Load Balancer is a regional Layer 7 proxy load balancer. It assigns internal IP addresses within your VPC network, enabling path-based HTTP routing and TLS termination for private microservices accessible from internal VPCs and Cloud Interconnect endpoints.

Step-by-Step Solution

1
Evaluate the reachability and IP allocation requirements
The load balancer must use internal IP addresses accessible only from the local VPC and connected on-premises networks.
Security policies forbid using external public IP addresses for strictly internal microservices.
2
Evaluate protocol processing and traffic routing requirements
The solution requires Layer 7 functionality including TLS offloading and URL path-based routing.
Layer 4 passthrough load balancers pass raw TCP streams without offloading TLS or inspecting HTTP request paths.
3
Identify the matching GCP load balancing service
Select the Regional Internal Application Load Balancer.
It fulfills all regional Layer 7 requirements entirely within private network scopes.

Key Concept

Distinguishing between GCP Layer 4 vs Layer 7 load balancers and internal vs external deployment scopes.
Question 737Question →

You are deploying a Global External Application Load Balancer to serve HTTPS traffic for a web application. You have already created a Google-managed SSL certificate and a URL map for your domain. Which action must you perform next to finish configuring the load balancer frontend?

Show answer & explanation

Answer: Create a target HTTPS proxy that references both the URL map and the SSL certificate, and create a global forwarding rule targeting the proxy on port 443.

Answer

Create a target HTTPS proxy that references both the URL map and the SSL certificate, and create a global forwarding rule targeting the proxy on port 443.
For a Global External Application Load Balancer, HTTPS termination requires associating the SSL certificate and the URL map with a Target HTTPS Proxy. Then, a global forwarding rule must be created to route incoming traffic on port 443 to that Target HTTPS Proxy.

Step-by-Step Solution

1
Understand the architecture of a Global External Application Load Balancer frontend.
Identify that frontend HTTPS traffic requires a Target HTTPS Proxy and a Global Forwarding Rule.
Traffic routing for HTTP(S) load balancers flows from Forwarding Rule -> Target Proxy -> URL Map -> Backend Service.
2
Associate the Google-managed SSL certificate and URL map with the target proxy.
The target HTTPS proxy uses the URL map for routing decisions and the SSL certificate for TLS termination.
Target proxies bind SSL certificates to handle incoming encrypted client connections.
3
Bind a global forwarding rule on port 443 to the target HTTPS proxy.
The frontend is fully configured to accept HTTPS requests on an external IP address.
Forwarding rules direct external IP traffic on specific ports to the appropriate target proxy.

Key Concept

Global External Application Load Balancer Frontend Component Architecture
Estimated Time:1m 30s
Question 738Question →

Your organization is deploying an internal microservices application in Google Cloud VPC network `prod-vpc`. The application backend runs on Compute Engine instances in region `us-central1`. You need to set up a Regional Internal HTTP(S) Load Balancer to distribute internal HTTP traffic across your backend instances, and enable internal clients to reach the service using the domain name `app.internal.corp`. Which TWO configuration actions must you perform? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Reserve and allocate a proxy-only subnet in the `us-central1` region of the VPC network.; Create a Cloud DNS private zone for `internal.corp`, authorize `prod-vpc` access, and add an 'A' record pointing `app.internal.corp` to the load balancer forwarding rule internal IP address.

Answer

To successfully deploy a Regional Internal HTTP(S) Load Balancer with private DNS resolution, you must allocate a proxy-only subnet in the target region (`us-central1`) for Envoy proxy instances and create a Cloud DNS Private Zone authorized for `prod-vpc` containing an 'A' record that points to the load balancer's internal forwarding rule IP address.
Regional Internal HTTP(S) Load Balancers rely on Envoy proxies running in a proxy-only subnet specific to the region where the load balancer is deployed. For domain name resolution inside the VPC, a Cloud DNS private zone must be created and linked to the VPC network with an 'A' record pointing to the load balancer's internal forwarding rule IP address.

Step-by-Step Solution

1
Reserve a proxy-only subnet in the VPC network.
Enables Google Cloud to provision Envoy proxies in region `us-central1` required for regional internal HTTP(S) load balancing.
Internal HTTP(S) Load Balancers use Envoy proxy instances located in a designated proxy-only subnet.
2
Configure backend service, URL map, target proxy, and forwarding rule.
Creates the internal load balancer frontend and assigns a private internal IP address from the VPC subnet.
The internal forwarding rule exposes the load balancer to the VPC network.
3
Create a Cloud DNS private managed zone authorized for `prod-vpc` and add an 'A' record.
Maps `app.internal.corp` to the forwarding rule internal IP address.
Internal VPC clients query Cloud DNS to resolve custom private domain names to private IP addresses.

Key Concept

Deployment of Regional Internal HTTP(S) Load Balancers requires a proxy-only subnet in the deployment region and Cloud DNS private zones authorized for the VPC network for private name resolution.
Question 739Question →

A Cloud Engineer is initializing a new infrastructure environment on Google Cloud using Terraform. The working directory contains valid `.tf` configuration files. What is the correct chronological sequence of Terraform CLI commands to initialize the working directory, preview proposed infrastructure changes, provision the GCP resources, and finally decommission the resources when no longer needed?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with workspace initialization using `terraform init`, followed by generating an execution preview with `terraform plan`, executing infrastructure creation with `terraform apply`, and ending with resource teardown via `terraform destroy`.
The standard Terraform workflow requires preparing the environment (`init`), validating proposed actions (`plan`), executing provisioning calls (`apply`), and lastly performing cleanup (`destroy`).

Step-by-Step Solution

1
Initialize working directory
`terraform init` downloads provider plugins and configures state backend.
Terraform requires initialization before it can recognize provider definitions and execute any downstream commands.
2
Generate execution preview
`terraform plan` outputs proposed resource changes.
Planning ensures that unexpected modifications or syntax errors are identified prior to altering live cloud infrastructure.
3
Apply infrastructure updates
`terraform apply` calls GCP APIs to create and update resources.
This step turns the defined configuration code into active Google Cloud infrastructure components.
4
Decommission environment
`terraform destroy` removes all tracked state resources.
Destruction is the final step in the lifecycle, removing resources when they are no longer required.

Key Concept

Terraform Deployment Lifecycle Command Sequence
Question 740Question →

A cloud engineer is utilizing the Google Cloud Pricing Calculator to model monthly infrastructure costs for a baseline web service running continuous 24/724/7 workloads on five `n2-standard-4` Compute Engine virtual machines in the `us-central1` region. The organization plans to run this workload uninterrupted for the next three years. Which configuration approach in the Pricing Calculator will yield the most accurate and cost-effective monthly estimate for these instances?

Show answer & explanation

Answer: Select a 3-Year Committed Use Discount (CUD) for the N2 compute instances, because committed use discounts offer deeper savings than automatic sustained use discounts for long-term continuous workloads.

Answer

Selecting a 3-Year Committed Use Discount for the N2 instances in the GCP Pricing Calculator yields the accurate baseline cost estimate because CUDs provide the maximum available discount for predictable 24/7 workloads over long durations.
For continuous 24/7 Compute Engine workloads planned over a three-year horizon, selecting a 3-Year Committed Use Discount in the pricing calculator provides the highest percentage savings. Committed Use Discounts apply to predictable resource demands and supersede Sustained Use Discounts.

Step-by-Step Solution

1
Analyze workload continuity and commitment duration requirements
The workload runs continuous 24/7 operations for a planned three-year timeline.
Understanding usage patterns determines whether On-Demand, Sustained Use Discounts (SUD), Committed Use Discounts (CUD), or Spot instances apply.
2
Evaluate discount compatibility and suitability in the Google Cloud Pricing Calculator
A 3-Year Committed Use Discount offers the highest price reduction for predictable Compute Engine workloads and cannot be stacked with Sustained Use Discounts.
CUDs require a 1-year or 3-year commitment in exchange for significantly lower hourly rates compared to SUDs.

Key Concept

Google Cloud Pricing Calculator Committed Use Discounts vs Sustained Use Discounts
Estimated Time:1m 30s
PreviousPage 37 / 80Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin