Examkin

All practice questions

1591 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 741Question →

A newly onboarded developer needs to administer workloads on a regional Google Kubernetes Engine (GKE) cluster named `ecommerce-app` located in `us-east1`. The developer has installed `kubectl` and the `gcloud` CLI, but running `kubectl` commands fails because the cluster context is not yet configured locally. Which TWO actions should the developer perform to authenticate `kubectl` to the cluster and deploy the workload manifest `deployment.yaml`?

Select all that apply

Show answer & explanation

Answer: Run gcloud container clusters get-credentials ecommerce-app --region us-east1 to generate the local kubeconfig context.; Execute kubectl apply -f deployment.yaml to deploy the workload to the target GKE cluster.

Answer

The developer must run gcloud container clusters get-credentials to populate local kubeconfig credentials, and then execute kubectl apply -f deployment.yaml to deploy the manifest.
To administer any GKE cluster with kubectl, developers must first run gcloud container clusters get-credentials with the cluster name and region or zone. This command retrieves authentication tokens and updates the local kubeconfig file. After credentials are updated, running kubectl apply -f deployment.yaml successfully communicates with the GKE control plane to create the specified workload.

Step-by-Step Solution

1
Fetch cluster credentials using the gcloud CLI
Local kubeconfig file is updated with cluster API endpoint and authentication entries
kubectl requires authentication tokens and endpoint certificates from GCP to communicate with the GKE control plane.
2
Deploy the application manifest using kubectl
The workload resources defined in deployment.yaml are created on the GKE cluster
With an active cluster context configured in kubeconfig, kubectl commands target the GKE cluster directly.

Key Concept

Fetching GKE cluster credentials using gcloud to configure local kubectl context
Question 742Question →

A cloud engineer at a financial institution needs to deploy a new Cloud Storage bucket named `fin-reconciliation-vault` in the `us-east4` region. The bucket deployment must satisfy two key administrative requirements:
1. Prevent object-level Access Control Lists (ACLs) by enforcing Uniform Bucket-Level Access across all contained objects.
2. Protect records against accidental overwrites or deletions by enabling Object Versioning on the bucket.

Which of the following CLI commands should be executed to accomplish these deployment requirements? (Select TWO answers.)

Select all that apply

Show answer & explanation

Answer: Run `gcloud storage buckets create gs://fin-reconciliation-vault --location=us-east4 --uniform-bucket-level-access`; Run `gcloud storage buckets update gs://fin-reconciliation-vault --versioning`

Answer

Creating the bucket using `gcloud storage buckets create gs://fin-reconciliation-vault --location=us-east4 --uniform-bucket-level-access` and enabling object versioning using `gcloud storage buckets update gs://fin-reconciliation-vault --versioning`.
Executing `gcloud storage buckets create gs://fin-reconciliation-vault --location=us-east4 --uniform-bucket-level-access` provisions the bucket in the requested region while establishing uniform IAM permissions. Subsequently, running `gcloud storage buckets update gs://fin-reconciliation-vault --versioning` successfully enables Object Versioning to protect against file overwrites.

Step-by-Step Solution

1
Provision the Cloud Storage bucket with uniform access controls
Bucket is created in region `us-east4` with uniform bucket-level access enabled, disabling legacy per-object ACLs.
The `gcloud storage buckets create` command accepts the `--uniform-bucket-level-access` flag to enforce IAM-only access policies upon bucket creation.
2
Enable Object Versioning on the bucket
Object Versioning is activated for the target bucket.
Using `gcloud storage buckets update --versioning` ensures that historical versions of uploaded files are preserved against accidental deletion or modification.

Key Concept

Cloud Storage bucket deployment options and Object Versioning configuration using gcloud storage CLI
Question 743Question →

A cloud infrastructure engineer is tasked with deploying a new managed Cloud SQL database instance within a custom Virtual Private Cloud (VPC) named `internal-vpc`. Organizational security policy dictates that the database must not be assigned a public IP address and must only be reachable internally via private IP addresses from workloads inside `internal-vpc`. The network team has not yet configured Private Service Access for `internal-vpc`.

Which TWO steps must the cloud engineer perform to provision this database securely? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Allocate an IP address range in `internal-vpc` and create a private connection between `internal-vpc` and the Google Service Networking service producer network.; Execute `gcloud sql instances create` specifying the `--network=internal-vpc` and `--no-assign-ip` flags.

Answer

To deploy a Cloud SQL instance with exclusive Private IP connectivity in a custom VPC, the engineer must first allocate an IP address range and set up a private service access connection to Google Service Networking within the VPC, and then deploy the instance specifying `--network=internal-vpc` alongside `--no-assign-ip`.
Deploying Cloud SQL with Private IP requires establishing a Private Service Access connection in the target VPC network (allocating an IP range and peering with service networking). When running `gcloud sql instances create`, specifying `--network` links the instance to that peered network, and `--no-assign-ip` ensures no public IP is attached to the database.

Step-by-Step Solution

1
Establish Private Service Access in the VPC
An allocated IP range is peered with the Service Networking tenant project hosting Google managed database instances.
Cloud SQL managed instances reside in a Google-managed VPC. Private IP connectivity requires VPC Network Peering established via Service Networking API.
2
Create the Cloud SQL Instance using gcloud CLI flags for Private IP
The Cloud SQL instance is provisioned with a private IP inside the allocated range and without a public IPv4 address assigned.
The `--network` flag connects the instance to the private peering connection, while `--no-assign-ip` disables public IP assignment.

Key Concept

Private Service Access and Private IP provisioning for Google Cloud SQL instances
Estimated Time:2m 0s
Question 744Question →

A DevOps engineer needs to deploy an event-driven Python microservice to Cloud Functions (2nd gen) that processes real-time telemetry published to a Cloud Pub/Sub topic in Google Cloud. The deployment must enforce least-privilege security by using a custom service account for function execution and Eventarc event handling. What is the correct sequence of steps to configure, deploy, and verify this serverless application using the gcloud CLI?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by creating the Pub/Sub topic (item 1), creating and granting roles to the custom service account (item 2), deploying the Cloud Function 2nd gen with the appropriate gcloud flags (item 3), binding the Cloud Run Invoker IAM role to the Eventarc trigger (item 4), and finally testing and inspecting execution in Cloud Logging (item 5).
Deploying a 2nd generation Cloud Function with event triggers requires setting up dependent resources first (Pub/Sub topic and IAM execution service account), running the deployment command specifying 2nd gen architecture, ensuring the Eventarc trigger identity has Cloud Run Invoker permissions on the underlying service, and finally testing execution by publishing a message and checking Cloud Logging.

Step-by-Step Solution

1
Provision the Pub/Sub event source
Cloud Pub/Sub topic is available to receive message streams.
Cloud Functions 2nd gen event triggers depend on pre-existing Pub/Sub topics or Eventarc sources.
2
Configure identity and IAM permissions
A custom service account exists with `roles/eventarc.eventReceiver` granted.
Least-privilege security mandates dedicated execution identities over default compute service accounts.
3
Deploy the 2nd gen function
Cloud Functions provisions the container image on Cloud Run and sets up Eventarc routing.
The `gcloud functions deploy` CLI command compiles and deploys the function infrastructure.
4
Authorize trigger invocation
Eventarc is granted `roles/run.invoker` on the provisioned service.
2nd gen Cloud Functions execute as Cloud Run services; event triggers fail if the invoking service account lacks invoker rights.
5
Validate deployment in Cloud Logging
Event consumption and execution log entries appear in Log Explorer.
Publishing a test message confirms end-to-end functionality from trigger source to serverless application handler.

Key Concept

Deploying Cloud Functions (2nd gen) with Cloud Pub/Sub triggers and IAM service accounts
Question 745Question →

A cloud engineer is automating multi-tier network provisioning across separated environment projects using Google Cloud Deployment Manager templates. The deployment script runs from a central administrative project named `admin-cicd-runner`. When executing `gcloud deployment-manager deployments create network-prod --config vpc-mesh.yaml --project=prod-vpc-host-1029`, the deployment fails with an error stating that `deploymentmanager.googleapis.com` is disabled. The engineer verifies that the Deployment Manager API is already enabled inside `admin-cicd-runner`. Which statement accurately identifies the root cause of this failure and the necessary corrective action?

Show answer & explanation

Answer: The Deployment Manager API must be enabled inside the target project (`prod-vpc-host-1029`) where resources are being provisioned, not just in the initiating administrative project.

Answer

Enable the Deployment Manager API (`deploymentmanager.googleapis.com`) directly within the target project (`prod-vpc-host-1029`) where the infrastructure resources are designated to be built.
In Google Cloud, API enablements are project-specific. When using infrastructure deployment tools like Cloud Deployment Manager or Terraform from a centralized management project, the target project where infrastructure resources are created must have the relevant API services enabled (`deploymentmanager.googleapis.com` as well as any resource-specific APIs such as `compute.googleapis.com`). Enabling the API only in the administrative project where the CLI command originates does not enable API endpoints in the target project.

Step-by-Step Solution

1
Identify the target project context of the deployment command.
The target project specified in the execution flag is `prod-vpc-host-1029`.
Infrastructure resources declared in Deployment Manager configuration templates are created within the target project scope.
2
Evaluate API enablement scoping rules in Google Cloud.
Realized that service APIs (including `deploymentmanager.googleapis.com` and underlying resource provider APIs like `compute.googleapis.com`) must be enabled on the target host project.
Enabling APIs on a central caller or CI/CD project does not satisfy API activation requirements for remote target projects.
3
Formulate the resolution command.
Execute `gcloud services enable deploymentmanager.googleapis.com --project=prod-vpc-host-1029`.
This directly enables the required API service on the target project where the deployment will reside.

Key Concept

API Enablement Scoping for Multi-Project Infrastructure Deployments
Question 746Question →

A Cloud Engineer needs to establish automated cost controls by configuring a Cloud Billing budget to publish programmatic threshold notifications to a Cloud Pub/Sub topic. What is the correct sequence of steps to perform this configuration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: 1) Create the Cloud Pub/Sub topic, 2) Grant the Pub/Sub Publisher role to the Cloud Billing service account, 3) Open Budgets & alerts in the Cloud Billing console, 4) Configure the budget scope, target amount, and threshold rules, and 5) Enable programmatic notifications and select the Pub/Sub topic under budget Actions.
Configuring programmatic billing notifications requires establishing the messaging infrastructure before linking it to budget rules. First, the Cloud Pub/Sub topic must be created. Next, the Cloud Billing service account must be granted `roles/pubsub.publisher` access so it has permission to publish messages. Once infrastructure authorization is ready, the engineer opens the Budgets & alerts interface in Cloud Billing, defines the budget limits and threshold rules, and finally connects the budget to the target Pub/Sub topic under Actions.

Step-by-Step Solution

1
Provision the Pub/Sub notification endpoint.
A Cloud Pub/Sub topic is established in the project.
Creating the Pub/Sub topic first ensures that a valid target resource exists before configuring access policies or budget actions.
2
Authorize the Cloud Billing backend service.
The Cloud Billing service account is assigned the Pub/Sub Publisher role on the newly created topic.
Without explicit publisher permissions on the target topic, Cloud Billing cannot deliver automated notification messages when thresholds are reached.
3
Open billing management tools.
The engineer accesses the Budgets & alerts section within Cloud Billing.
This console location provides the controls required to create and manage billing budget alerting rules.
4
Define budget targets and alert triggers.
Budget scope, spending limit, and percentage thresholds (e.g., 50%, 90%, 100%) are set up.
Establishing threshold rules specifies the exact spending conditions under which notification events will fire.
5
Connect the budget to the programmatic Pub/Sub endpoint.
The budget is linked to the Pub/Sub topic under the Actions configuration panel.
This final binding enables programmatic notification messages to be published to the topic upon threshold breaches.

Key Concept

Programmatic Cloud Billing budget notifications with Cloud Pub/Sub integration
Question 747Question →

A DevOps engineer is configuring an automated script to deploy a fault-tolerant batch processing Virtual Machine on Compute Engine using the gcloud CLI. The instance must run as a Spot VM to reduce compute costs, automatically terminate during host maintenance events, attach an existing custom service account named [email protected] with full Cloud Storage permissions, and execute a local shell script located at /scripts/setup.sh upon startup. Which gcloud compute instances create command correctly fulfills all these requirements?

Show answer & explanation

Answer: gcloud compute instances create batch-node-01 --zone=us-central1-a --provisioning-model=SPOT --on-host-maintenance=TERMINATE --service-account=batch-processor@my-project.iam.gserviceaccount.com --scopes=https://www.googleapis.com/auth/devstorage.full_control --metadata-from-file=startup-script=/scripts/setup.sh

Answer

The command specifying `--provisioning-model=SPOT`, `--on-host-maintenance=TERMINATE`, `--service-account=batch-processor@my-project.iam.gserviceaccount.com`, `--scopes=https://www.googleapis.com/auth/devstorage.full_control`, and `--metadata-from-file=startup-script=/scripts/setup.sh` correctly provisions the instance.
The correct option specifies `--provisioning-model=SPOT` combined with `--on-host-maintenance=TERMINATE`, as Spot instances cannot be live-migrated during infrastructure maintenance. It uses `--service-account` to assign the custom IAM service account email and `--scopes` for API permissions. Lastly, it utilizes `--metadata-from-file=startup-script=...` to properly read and upload the local file contents as the VM startup script.

Step-by-Step Solution

1
Configure the VM provisioning model and host maintenance behavior.
Set `--provisioning-model=SPOT`. Compute Engine requires Spot instances to use `--on-host-maintenance=TERMINATE` because live migration is not supported for Spot or preemptible instances.
Spot instances are transient and cannot undergo live migration during host infrastructure maintenance.
2
Attach the custom IAM service account identity and define access scopes.
Pass the service account email using `--service-account=batch-processor@my-project.iam.gserviceaccount.com` and define storage permissions using `--scopes=https://www.googleapis.com/auth/devstorage.full_control`.
The `--service-account` flag attaches the identity, while `--scopes` defines the maximum allowed API access level for legacy scope filtering.
3
Supply the startup script from a local file path.
Use `--metadata-from-file=startup-script=/scripts/setup.sh`.
`--metadata-from-file` reads the actual contents of the local file and populates the `startup-script` metadata key, whereas `--metadata` only assigns literal string values.

Key Concept

Deploying Compute Engine instances with custom service accounts, Spot VM availability policies, and startup script file metadata via gcloud CLI.
Question 748Question →

A cloud administrator needs to grant an operations engineer the ability to create, update, and delete custom IAM roles within a specific Google Cloud project. The engineer must not be granted permissions to modify project IAM access policies or manage other project resources. To adhere to the principle of least privilege, which IAM role should be granted to the engineer?

Show answer & explanation

Answer: Role Administrator (roles/iam.roleAdmin)

Answer

The Role Administrator role (roles/iam.roleAdmin) should be granted to the engineer.
The Role Administrator role (`roles/iam.roleAdmin`) grants permissions to create, update, and delete custom IAM roles (`iam.roles.create`, `iam.roles.update`, `iam.roles.delete`, `iam.roles.get`, `iam.roles.list`) without conferring permissions to modify resource IAM policies (`resourcemanager.projects.setIamPolicy`) or manage other service resources. This aligns strictly with Google Cloud best practices for least privilege access.

Step-by-Step Solution

1
Analyze the access requirement
The user needs to create, update, and delete custom IAM roles within a specific GCP project.
Identifying the minimal set of required permissions is the first step in applying least privilege.
2
Evaluate role permissions against the principle of least privilege
The predefined Role Administrator role (roles/iam.roleAdmin) contains iam.roles.* permissions necessary to manage role definitions without granting access to modify IAM policy bindings or project data.
Predefined roles are preferred over primitive roles (Owner, Editor, Viewer) or overly permissive security roles.
3
Select the optimal role
Granting Role Administrator (roles/iam.roleAdmin) fulfills the requirement with minimal necessary permissions.
This prevents unnecessary administrative elevation or access to underlying project resources.

Key Concept

Selecting predefined IAM roles based on least privilege for role management
Estimated Time:1m 30s
Question 749Question →

A cloud administrator needs to upgrade the machine type of a node pool in a production Google Kubernetes Engine (GKE) Standard cluster to handle increased resource demands without incurring workload downtime. What is the correct sequence of steps to perform this node pool migration safely?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with provisioning the new node pool (`pool-v2`), followed by cordoning nodes in the old pool (`pool-v1`), draining the old pool to migrate pods, and finally deleting the old node pool once migration completes.
In GKE node pool migrations, zero-downtime is achieved by following a structured blue-green workflow. First, provision new capacity (`pool-v2`). Second, cordon the original nodes (`pool-v1`) to prevent new pod assignments. Third, drain the original nodes to gracefully evict running pods so Kubernetes deployment controllers recreate them on `pool-v2`. Fourth, delete `pool-v1` after verifying all pods are running successfully on the new nodes.

Step-by-Step Solution

1
Execute `gcloud container node-pools create pool-v2 ...` to add target capacity.
A new GKE node pool with the larger machine type is created and joins the cluster.
Destination nodes must exist so that evicted pods have available capacity to be rescheduled onto immediately.
2
Execute `kubectl cordon` targeting nodes in `pool-v1`.
Old nodes are marked as unschedulable (`SchedulingDisabled`).
Cordoning prevents new pods from landing on the legacy nodes while preparing for eviction.
3
Execute `kubectl drain` targeting nodes in `pool-v1`.
Pods on `pool-v1` nodes are gracefully evicted and rescheduled by Kubernetes on `pool-v2`.
Draining triggers orderly pod termination and rescheduling without causing service downtime.
4
Execute `gcloud container node-pools delete pool-v1 ...`.
The legacy node pool and its associated Compute Engine VM instances are deleted.
Deleting empty legacy nodes frees up project resources after verifying workload health on the new pool.

Key Concept

GKE Blue-Green Node Pool Migration Sequence
Question 750Question →

An online event-analytics organization is planning a Google Kubernetes Engine (GKE) cluster architecture. The environment will host web ingestion APIs alongside stateless, fault-tolerant background data transformation workloads. The engineering team requires an architecture that minimizes cluster node management overhead while significantly reducing compute costs for the stateless background workloads. Which TWO architectural decisions should you select to fulfill these requirements?

Select all that apply

Show answer & explanation

Answer: Provision a GKE Autopilot cluster to eliminate manual node provisioning, scaling, and infrastructure maintenance overhead.; Configure Spot Pod specifications for the stateless background processing workloads to run on spare GCP capacity at reduced rates.

Answer

Deploying a GKE Autopilot cluster and configuring Spot Pod specifications for stateless background processing workloads.
GKE Autopilot delegates node and cluster infrastructure management to Google Cloud, satisfying the requirement to minimize operational overhead. Configuring Spot Pods allows fault-tolerant, stateless background workloads to run on discounted, preemptible compute resources, satisfying the requirement to reduce compute costs.

Step-by-Step Solution

1
Evaluate cluster operational management requirements
GKE Autopilot is selected because Google manages node provisioning, security updates, and node maintenance, meeting the zero-node-management requirement.
GKE Standard requires manual node pool configuration and node maintenance, which adds operational overhead.
2
Evaluate cost-optimization options for stateless, fault-tolerant workloads
Spot Pods (or Spot VM node pools) are selected for the background processing workloads to leverage discounted compute rates.
Stateless background workloads can withstand pod preemption and rescheduling without data loss.

Key Concept

GKE Autopilot Architecture and Spot Workload Provisioning
Estimated Time:1m 30s
Question 751Question →

A Kubernetes administrator needs to migrate production workloads from an existing node pool (`pool-v1`) to a newly provisioned node pool (`pool-v2`) in a Google Kubernetes Engine (GKE) Standard cluster without incurring application downtime. Sequence the operational commands in the correct execution order to complete this migration safely.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Provision target node pool `pool-v2` using `gcloud container node-pools create`, 2) Cordon all nodes in `pool-v1` using `kubectl cordon`, 3) Drain nodes in `pool-v1` using `kubectl drain`, and 4) Delete `pool-v1` using `gcloud container node-pools delete`.
To migrate GKE workloads safely without downtime, you must first create target compute capacity (`gcloud container node-pools create`), prevent new pods from landing on old nodes (`kubectl cordon`), gracefully evict existing pods to trigger rescheduling onto new nodes (`kubectl drain`), and finally decommission old infrastructure (`gcloud container node-pools delete`).

Step-by-Step Solution

1
Provision `pool-v2` using `gcloud container node-pools create`.
A new node pool is created and enters the READY state to accept workloads.
Target compute capacity must exist before evicting workloads from existing nodes to prevent service disruption.
2
Mark nodes in `pool-v1` as unschedulable using `kubectl cordon`.
Existing pods remain running on `pool-v1`, but new pods will not be scheduled onto these nodes.
Cordoning ensures that evicted pods or new replica pods are forced to schedule onto the newly provisioned `pool-v2` nodes.
3
Evict pods from `pool-v1` using `kubectl drain`.
Pods on `pool-v1` nodes are gracefully evicted and rescheduled by Kubernetes onto `pool-v2`.
Draining triggers controlled eviction while respecting PodDisruptionBudgets.
4
Decommission `pool-v1` using `gcloud container node-pools delete`.
The old node pool and underlying Compute Engine instances are deleted.
Once `pool-v1` is empty and workloads are fully running on `pool-v2`, removing the old node pool stops unnecessary resource billing.

Key Concept

GKE Blue-Green Node Pool Migration Sequence
Question 752Question →

An organization is designing a high-traffic web application deployed across Compute Engine instances in multiple Google Cloud regions. The application serves global users over HTTPS and requires low-latency delivery of static assets using edge caching, as well as automatic routing of user requests to the nearest healthy backend region. Which TWO architectural components should the cloud engineer include in the design to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Configure a Global External Application Load Balancer to route HTTPS traffic to the closest healthy backend instance group.; Enable Cloud CDN on the backend service of the Global External Application Load Balancer to cache static content at edge locations.

Answer

The application architecture requires a Global External Application Load Balancer to handle multi-region HTTPS traffic and routing, along with enabling Cloud CDN on its backend service to cache static assets at edge locations.
The Global External Application Load Balancer acts as a Layer 7 reverse proxy using a single global anycast IP address, distributing HTTPS requests across instance groups in multiple regions based on proximity and health. Enabling Cloud CDN directly on the backend service of this load balancer caches HTTP(S) static assets at edge POPs, minimizing latency for global clients.

Step-by-Step Solution

1
Identify the application protocol and scope requirements.
The application serves global internet users over HTTPS across multiple regions.
Global HTTPS routing requires a Layer 7 global proxy load balancer, specifically the Global External Application Load Balancer.
2
Determine the edge caching requirement for low-latency static content delivery.
Cloud CDN must be enabled on the HTTP(S) load balancer backend service.
Cloud CDN caches HTTP(S) content at Google's global network edge POPs, which reduces latency and backend load.
3
Evaluate alternative load balancing options.
Layer 4 passthrough network load balancers (internal or external) are ruled out.
Layer 4 passthrough load balancers do not terminate HTTP(S) requests or support Cloud CDN integration.

Key Concept

Global External Application Load Balancing and Cloud CDN Integration
Estimated Time:1m 30s
Question 753Question →

Your team needs to deploy a Global External Application Load Balancer using the `gcloud` CLI to serve traffic for a newly created Compute Engine instance group. Arrange the following deployment steps in the correct sequential order from initial backend configuration to final frontend entry point creation.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of deployment steps is: 1) Create a health check and backend service, then add the instance group; 2) Create a URL map referencing the backend service; 3) Create a target HTTP proxy referencing the URL map; 4) Create a global forwarding rule referencing the target HTTP proxy.
Google Cloud Load Balancer resources follow a strict bottom-up dependency model. You must create the backend infrastructure (health check and backend service with instance group backends) first, followed by the URL map which points to the backend service, then the target proxy pointing to the URL map, and finally the forwarding rule which directs external IP traffic to the target proxy.

Step-by-Step Solution

1
Configure backend service infrastructure and attach instance group
The backend service and health check are ready to accept traffic.
Higher-level HTTP routing objects depend on an existing backend service target.
2
Create URL map to direct request paths to the backend service
URL routing logic is established.
URL maps require a default backend service parameter.
3
Create target HTTP proxy referencing the URL map
Target proxy is configured to route HTTP requests according to URL map rules.
Target proxies require an existing URL map.
4
Create global forwarding rule binding an external IP/port to the target proxy
Frontend IP receives external traffic and forwards it to the target proxy.
Forwarding rules require a target proxy parameter as their destination.

Key Concept

GCP Load Balancer Component Dependency Architecture
Question 754Question →

A cloud engineer needs to ensure that a stateless application running on a Google Kubernetes Engine (GKE) cluster can handle traffic spikes. The requirement is to automatically scale up the container instances during high demand, and to automatically add compute nodes to the cluster if existing nodes run out of capacity to host those pods. Which TWO actions should the engineer perform to fulfill these requirements?

Select all that apply

Show answer & explanation

Answer: Configure a Horizontal Pod Autoscaler (HPA) for the deployment to scale the pod replica count based on CPU utilization.; Enable Cluster Autoscaler on the GKE cluster node pool to add worker nodes when pending pods cannot be scheduled due to insufficient resources.

Answer

The correct actions are configuring a Horizontal Pod Autoscaler (HPA) to scale the pod replica count based on workload demand, and enabling GKE Cluster Autoscaler on the node pool to add nodes when pending pods require additional compute capacity.
To manage scaling at both the application tier and the underlying cluster infrastructure tier in GKE, two distinct features must be configured. Horizontal Pod Autoscaler (HPA) dynamically adjusts the deployment's pod replica count based on metric thresholds like CPU usage. When the increase in pod count exceeds current cluster compute resources, Cluster Autoscaler automatically adds new worker nodes to the node pool so pending pods can be scheduled.

Step-by-Step Solution

1
Determine the application-level scaling requirement.
Identify that scaling the number of container instances (pods) in response to CPU demand requires a Horizontal Pod Autoscaler (HPA).
HPA targets workload-level scaling by increasing or decreasing pod replicas based on resource metrics.
2
Determine the cluster-level infrastructure scaling requirement.
Identify that adding node capacity when pods cannot fit on current nodes requires GKE Cluster Autoscaler.
Cluster Autoscaler monitors unschedulable (pending) pods and automatically provisions additional GKE worker nodes.

Key Concept

Managing GKE resource scaling requires combining Horizontal Pod Autoscaler (HPA) for pod workload elasticity with Cluster Autoscaler for underlying compute node capacity.
Question 755Question →

You need to increase the vCPU and memory allocated to an existing standalone Compute Engine virtual machine (VM) instance by changing its machine type. Which action must be taken on the VM instance before its machine type can be updated?

Show answer & explanation

Answer: Stop the VM instance.

Answer

Stop the VM instance prior to modifying its machine type attribute.
To modify the machine type of a standalone Compute Engine instance, the instance must be shut down and placed in the STOPPED (TERMINATED) state. Once stopped, the vCPU and memory configuration can be modified using the Cloud Console or gcloud compute instances set-machine-type, after which the instance can be restarted.

Step-by-Step Solution

1
Identify the current execution state of the Compute Engine instance.
The instance is determined to be in the RUNNING state.
Machine type modifications cannot be applied to an active, running virtual machine.
2
Stop the Compute Engine instance using the gcloud command or Cloud Console.
The instance transitions to the TERMINATED state.
Compute Engine requires the instance resources to be halted so the underlying host hardware allocation can be reconfigured.
3
Update the machine type attribute and restart the instance.
The instance boots with the newly specified vCPU and memory resources.
Once stopped, configuration changes take effect upon the next instance launch.

Key Concept

Modifying Compute Engine Instance Attributes
Question 756Question →

An organization is deploying a custom VPC network environment in Google Cloud for a multi-tier application stack. A cloud engineer must create a custom subnet named `prod-app-subnet` in the `us-central1` region that includes a primary IPv4 range for Compute Engine Virtual Machines and a secondary IPv4 range reserved for GKE Pod alias IPs. Additionally, ingress TCP traffic on port 5432 (PostgreSQL) must be restricted specifically to target instances operating under a dedicated service account `[email protected]`. Which TWO actions or parameters are required to properly implement this configuration using Google Cloud best practices? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Execute `gcloud compute networks subnets create prod-app-subnet` specifying `--range` for the primary internal IP allocation and `--secondary-range` to define the named subnetwork range for Pod alias IPs.; Configure the VPC ingress firewall rule with `--target-service-accounts=db-client-sa@proj-id.iam.gserviceaccount.com` to enforce strict identity-based access control rather than relying on network tags.

Answer

The correct configuration requires provisioning the subnet with both primary (`--range`) and secondary (`--secondary-range`) IP allocation flags, and applying `--target-service-accounts` on the ingress firewall rule to enforce identity-targeted network access.
Deploying custom VPC subnets with secondary IP allocations requires using `--range` for the main CIDR and `--secondary-range` for alias IP ranges. Restricting access based on instance identity requires using `--target-service-accounts` on the firewall rule rather than network tags.

Step-by-Step Solution

1
Analyze subnet provisioning flags for primary and secondary IPv4 range allocations.
Creating a custom subnet supporting secondary ranges requires the `--range` parameter for primary VM allocations and `--secondary-range` for alias IP ranges.
Google Cloud VPC subnets require explicit distinction between primary subnetwork ranges and secondary ranges intended for containers and alias IPs.
2
Evaluate ingress firewall rule parameters for service account targeting.
Using `--target-service-accounts` restricts firewall ingress strictly to instances associated with the designated IAM service account.
Service account targeting provides secure identity-based network access control that cannot be altered by modifying instance network tags.
3
Evaluate the firewall rule priority evaluation order.
A priority of 65535 is the lowest precedence rule value in GCP VPC firewalls.
Firewall rules are evaluated in ascending numerical order starting from 0 (highest precedence) to 65535 (lowest precedence).
4
Evaluate IAM role assignment in relation to network firewall filtering.
IAM roles do not grant implicit bypass permissions for network-layer firewall evaluation.
IAM authorization and VPC firewall filtering operate on separate control plane and data plane boundaries.

Key Concept

Provisioning custom VPC subnets with secondary IP ranges and defining identity-based firewall rules using service accounts.
Question 757Question →

Your organization operates a proprietary backend service running on Compute Engine instances distributed across two regions: `us-central1` and `europe-west1`. The service communicates over raw TCP on port 8443 and does not use HTTP or HTTPS. To meet security requirements, incoming client connections from around the globe must have SSL/TLS terminated at the Google Cloud edge before traffic is routed to the backend instances. Which load balancer configuration should you deploy?

Show answer & explanation

Answer: Configure an External TCP Proxy Load Balancer with a Target SSL Proxy and a SSL certificate resource assigned to the frontend forwarding rule.

Answer

The correct architecture requires an External TCP Proxy Load Balancer configured with a Target SSL Proxy and an SSL certificate, which handles global IPv4/IPv6 client traffic, offloads SSL/TLS encryption at the Google Cloud edge for non-HTTP TCP traffic, and balances backend load across multiple regions.
For non-HTTP traffic requiring global load balancing and SSL/TLS termination at the Google Cloud edge, the correct solution is an External TCP Proxy Load Balancer using a Target SSL Proxy. This configuration offloads cryptographic overhead from backend instances and distributes traffic across multi-region Compute Engine backends.

Step-by-Step Solution

1
Analyze protocol requirements
The application uses non-HTTP raw TCP on port 8443.
Application Load Balancers (HTTP/HTTPS) parse HTTP headers and are unsuitable for raw TCP payloads.
2
Analyze security and edge termination requirements
SSL/TLS offloading must occur at the GCP network edge.
Passthrough load balancers do not terminate SSL/TLS; proxy load balancers are required to offload encryption at the edge.
3
Select the appropriate proxy load balancer type
Use an External TCP Proxy Load Balancer with a Target SSL Proxy.
Target SSL Proxy handles global external non-HTTP TCP traffic with edge SSL termination and cross-region backend routing.

Key Concept

Selecting GCP Load Balancers based on traffic protocol (HTTP vs non-HTTP TCP) and proxy/termination behavior.
Question 758Question →

An organization is deploying a custom VPC network named `prod-vpc` containing two regional subnets: `subnet-us` (10.10.0.0/2410.10.0.0/24) and `subnet-eu` (10.20.0.0/2410.20.0.0/24). A Cloud Engineer must restrict SSH access (TCP port 22) so that Compute Engine instances tagged with `admin-workload` in `subnet-us` can only accept SSH connections coming from a management host residing in `subnet-eu` (10.20.0.15/3210.20.0.15/32). Additionally, all other inbound SSH traffic to any instance across the VPC must be blocked. The engineer creates Rule 1 with action ALLOW, direction INGRESS, protocol/port `tcp:22`, source IP `10.20.0.15/32`, target tag `admin-workload`, and priority 100. They also create Rule 2 with action DENY, direction INGRESS, protocol/port `tcp:22`, source IP `0.0.0.0/0`, targets specified as all instances in the network, and priority 50. Which outcome will occur when the management host at 10.20.0.1510.20.0.15 attempts an SSH connection to an instance tagged `admin-workload` in `subnet-us`?

Show answer & explanation

Answer: The SSH connection will be denied because Rule 2 has a lower priority number (50) than Rule 1 (100), causing the DENY rule to take precedence over the ALLOW rule regardless of IP specificity or target tags.

Answer

The SSH connection will be denied because Rule 2 has a lower priority number (50) than Rule 1 (100), causing the DENY rule to take precedence over the ALLOW rule regardless of IP specificity or target tags.
Google Cloud VPC firewall rule evaluation follows strict priority ordering from 0 to 65535, where lower integer values denote higher precedence. Rule 2 has a priority of 50, which takes precedence over Rule 1's priority of 100. When traffic from 10.20.0.15/32 arrives on TCP port 22, it matches Rule 2's source CIDR of 0.0.0.0/0 and target scope of all instances. Because Rule 2 is evaluated first and specifies DENY, the packet is immediately dropped before Rule 1 can be evaluated.

Step-by-Step Solution

1
Analyze GCP firewall priority ordering rules.
GCP VPC firewall rules are processed in strict ascending numerical priority order (0 to 65535). A lower priority number indicates higher precedence.
When a packet matches a rule during evaluation, processing stops immediately and that rule's action is applied.
2
Compare priority numbers between Rule 1 and Rule 2.
Rule 2 has priority 50, whereas Rule 1 has priority 100. Thus, Rule 2 is evaluated first.
Priority 50 is numerically smaller than 100, granting Rule 2 evaluation precedence.
3
Evaluate the packet against Rule 2 parameters.
The packet originating from 10.20.0.15/32 on port 22 matches Rule 2 (source range 0.0.0.0/0, protocol tcp:22, target: all instances).
Since 10.20.0.15 falls within 0.0.0.0/0 and Rule 2 applies to all network instances, the DENY action is enforced immediately.

Key Concept

GCP VPC Firewall Rule Priority Evaluation Order
Estimated Time:2m 0s
Question 759Question →

A cloud engineer is using the Google Cloud Pricing Calculator to model the net monthly infrastructure expense for an internal microservice running for a 30-day month (730 hours730\text{ hours}). The workload requires:

1. Compute Engine: 44 standard VM instances running continuously for the entire month at a base rate of $0.10\$0.10 per instance-hour. A 20%20\% Sustained Use Discount (SUD) applies automatically to all compute instance hours.
2. Storage: 200 GB200\text{ GB} of Standard Persistent Disk at $0.04\$0.04 per GB per month (storage is not eligible for SUD).
3. Network Egress: 500 GB500\text{ GB} of internet egress per month. The first 100 GB100\text{ GB} per month is free under the GCP Free Tier, and all remaining egress is billed at $0.12\$0.12 per GB.

What is the estimated net total monthly cost in USD for this workload?

Show answer & explanation

Answer: 289.6

Answer

The estimated net total monthly cost for the workload is $289.60 USD.
The net monthly cost is calculated by taking 4 continuous compute instances running for 730 hours at 0.10/hour(0.10/hour ( 292.00 baseline), applying a 20% Sustained Use Discount to compute (233.60),adding200GBstandardpersistentdiskat233.60), adding 200 GB standard persistent disk at 0.04/GB (8.00),andadding400GBofbillableegress(500GBtotalminus100GBfreetier)at8.00), and adding 400 GB of billable egress (500 GB total minus 100 GB free tier) at 0.12/GB (48.00),resultinginatotalof48.00), resulting in a total of 289.60 USD.

Step-by-Step Solution

1
Calculate the un-discounted Compute Engine cost for all instances.
4 instances×730 hours×$0.10/hour=$292.004 \text{ instances} \times 730 \text{ hours} \times \$0.10/\text{hour} = \$292.00
Establish baseline VM compute charges over the 30-day period.
2
Apply the Sustained Use Discount (SUD) to eligible compute hours.
$292.00×(1−0.20)=$233.60\$292.00 \times (1 - 0.20) = \$233.60
SUD applies automatically to compute instance execution hours that run for continuous portions of the month.
3
Calculate monthly Persistent Disk storage charges.
200 GB×$0.04/GB=$8.00200 \text{ GB} \times \$0.04/\text{GB} = \$8.00
Persistent disk pricing applies to total provisioned capacity and does not receive sustained use discounts.
4
Calculate billable network egress taking the GCP Free Tier allowance into account.
(500 GB−100 GB free tier)×$0.12/GB=400 GB×$0.12=$48.00(500 \text{ GB} - 100 \text{ GB free tier}) \times \$0.12/\text{GB} = 400 \text{ GB} \times \$0.12 = \$48.00
The first 100 GB of internet egress per month is covered by the GCP Free Tier, leaving 400 GB subject to standard egress rates.
5
Sum all net component costs.
$233.60+$8.00+$48.00=$289.60\$233.60 + \$8.00 + \$48.00 = \$289.60
Combine net compute, persistent disk, and network egress charges to arrive at the total monthly estimate.

Key Concept

Calculating GCP cost estimates incorporating Sustained Use Discounts (SUD), storage pricing rules, and internet egress free tier allowances.
Question 760Question →

A company manages a workload on Google Cloud with an established monthly budget of 10,000.Thefinancialoperationsteamrequiresnotificationsundertwospecificconditions:whenactualcumulativemonthlycostsreach10,000. The financial operations team requires notifications under two specific conditions: when actual cumulative monthly costs reach 7,000, and as soon as spending trends indicate that total costs will exceed $10,000 by the end of the current billing cycle. How should a Cloud Engineer configure the budget alert rules in Cloud Billing to meet these requirements?

Show answer & explanation

Answer: Create one threshold rule set to 70% of Actual spend, and a second threshold rule set to 100% of Forecasted spend.

Answer

Configure two threshold rules in the Cloud Billing budget: one rule set to 70% based on Actual spend and another rule set to 100% based on Forecasted spend.
Google Cloud Billing budgets permit defining multiple threshold rules per budget based on either 'Actual' spend or 'Forecasted' spend. A threshold of 70% Actual triggers when accrued spend hits 7,000,whileathresholdof1007,000, while a threshold of 100% Forecasted triggers as soon as Google Cloud's predictive algorithm determines that total spend by the end of the calendar month will reach or exceed 10,000.

Step-by-Step Solution

1
Identify the two required notification conditions.
Condition 1 is 7,000actualspendoutof7,000 actual spend out of 10,000 (70% Actual). Condition 2 is projected spend reaching $10,000 by month-end (100% Forecasted).
Cloud Billing budget thresholds can evaluate against either actual cumulative spend or predicted end-of-month spend.
2
Configure the threshold basis for each condition in the Cloud Billing Console budget creator.
Add a threshold of 70% with trigger type 'Actual', and add a threshold of 100% with trigger type 'Forecasted'.
Combining actual and forecasted triggers allows proactive alerts before overruns occur as well as accurate milestones during the billing period.

Key Concept

Cloud Billing Budget Threshold Triggers (Actual vs. Forecasted)
PreviousPage 38 / 80Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin