Examkin

All practice questions

262 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 121Question →

A site reliability engineer needs to perform a manual blue-green node pool upgrade on a production Google Kubernetes Engine (GKE) Standard cluster to migrate workload Pods from node pool `pool-v1` to a newly provisioned node pool `pool-v2` with minimal application disruption. Sequence the required administrative steps in the correct operational order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence for a manual GKE blue-green node pool migration is: 1) Provision the target node pool `pool-v2`, 2) Cordon the nodes in `pool-v1`, 3) Drain the nodes in `pool-v1`, and 4) Delete the original node pool `pool-v1` after validating workload stability.
In a manual GKE blue-green node pool update, new capacity (`pool-v2`) must be created first. The old nodes (`pool-v1`) are then cordoned to block new Pod assignments, followed by draining the old nodes to safely relocate running workloads to `pool-v2`. Once all workloads are confirmed operational on `pool-v2`, `pool-v1` can be safely deleted.

Step-by-Step Solution

1
Create target node pool
Node pool `pool-v2` is created and nodes enter the Ready state.
Sufficient ready capacity must exist in the cluster before evicting workloads from existing nodes.
2
Cordon source nodes
Nodes in `pool-v1` are marked Unschedulable.
Ensures no new Pods are scheduled onto nodes targeted for decommissioning.
3
Drain source nodes
Pods on `pool-v1` nodes are safely evicted and rescheduled onto `pool-v2` nodes.
Gracefully migrates workload traffic to the newly created node pool in accordance with PodDisruptionBudgets.
4
Delete source node pool
Node pool `pool-v1` is deleted via gcloud CLI.
Decommissions legacy infrastructure to avoid duplicate node charges once migration is verified successful.

Key Concept

Manual Blue-Green GKE Node Pool Migration Workflow
Question 122Question →

You are tasked with deploying a Global External Application Load Balancer in Google Cloud using the `gcloud` CLI to route HTTP traffic to an existing unmanaged instance group `web-ig-us` in `us-central1`. To ensure dependencies are created before their dependent resources, what is the correct sequential order of `gcloud` commands required to provision this infrastructure from the backend up to the global frontend forwarding rule?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of deployment commands from backend dependencies to frontend entry point is: 1) Create global HTTP health check, 2) Create global backend service with health check, 3) Add instance group backend to backend service, 4) Create URL map referencing default backend service, 5) Create target HTTP proxy referencing URL map, and 6) Create global forwarding rule pointing to target proxy.
Deploying a GCP Global External Application Load Balancer via the command-line interface requires a strict bottom-up dependency ordering. First, independent health checks must be provisioned (`gcloud compute health-checks create http`). Second, the global backend service must be created referencing the health check (`gcloud compute backend-services create`). Third, workload backends are added to the service (`gcloud compute backend-services add-backend`). Fourth, the URL map is created to route requests to the backend service (`gcloud compute url-maps create`). Fifth, the target proxy is created referencing the URL map (`gcloud compute target-http-proxies create`). Finally, the global forwarding rule is created pointing public traffic on port 80 to the target HTTP proxy (`gcloud compute forwarding-rules create`).

Step-by-Step Solution

1
Identify resource dependencies for Global External Application Load Balancers
Lower-level components (health checks, backend services) must exist before higher-level routing objects (URL maps, proxies, forwarding rules).
Google Cloud resource creation calls validate referenced resource URIs; creating dependent resources before their targets results in command failure.
2
Order backend foundation deployment
Health check is created first, followed by the backend service linked to that health check, followed by adding the instance group.
Backend services cannot be created without referencing a health check, and backends cannot be added until the backend service container exists.
3
Order frontend routing deployment
URL map points to backend service -> Target Proxy points to URL map -> Forwarding Rule points to Target Proxy.
Each traffic handling layer encapsulates the layer beneath it, culminating in the global forwarding rule receiving incoming requests.

Key Concept

Bottom-up CLI deployment ordering for GCP Global External Application Load Balancers
Question 123Question →

You need to provision a secure Cloud SQL for PostgreSQL instance that communicates exclusively via Private IP within an existing custom Virtual Private Cloud (VPC) network named `prod-vpc`. Sequence the following deployment steps in the correct chronological order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: 1. Reserve internal IP address range in prod-vpc -> 2. Establish Private Service Access connection -> 3. Deploy Cloud SQL instance with --network=prod-vpc and --no-assign-ip -> 4. Configure database user accounts.
Provisioning a Private IP Cloud SQL instance requires a specific prerequisite chain: first allocating an internal IP range in the VPC network (`gcloud compute addresses create`), second establishing a Private Service Access peering connection (`gcloud services vpc-peerings connect`), third creating the instance linked to the VPC network with public IP disabled (`gcloud sql instances create`), and finally setting up database users on the running instance (`gcloud sql users create`).

Step-by-Step Solution

1
Allocate an IP range for Private Service Access
A named IP range is reserved within the VPC for Google service producer peering.
Cloud SQL Private IP relies on Private Service Access, which requires a pre-allocated IP range.
2
Create VPC Peering connection
The customer VPC network is peered with Google's Service Networking tenant network.
Without active VPC Peering to servicenetworking.googleapis.com, Cloud SQL cannot attach internal IP endpoints.
3
Create Cloud SQL instance attached to VPC
The instance is provisioned with a private IP address and no public IP assigned.
The flags --network=prod-vpc and --no-assign-ip enforce private network attachment and prevent public Internet exposure.
4
Create database user accounts
Application user accounts are initialized on the running instance.
Database user configuration requires an active, running Cloud SQL instance target.

Key Concept

Sequence of setup tasks for Cloud SQL Private IP provisioning via Private Service Access
Question 124Question →

A Cloud Engineer is tasked with deploying a microservice workload manifest to a newly created regional GKE Autopilot cluster named `analytics-prod-cluster` located in the `europe-west1` region. Which sequence of steps correctly describes the process of establishing cluster credentials, verifying cluster connectivity, deploying the workload manifest, and confirming the rollout status?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational order is: 1) Fetch cluster credentials using `gcloud container clusters get-credentials analytics-prod-cluster --region europe-west1`, 2) Verify cluster node availability using `kubectl get nodes`, 3) Apply the deployment manifest using `kubectl apply -f analytics-deployment.yaml`, and 4) Monitor rollout completion using `kubectl rollout status deployment/analytics-service`.
Deploying workloads to a GKE cluster follows a logical lifecycle: first, authentication credentials and cluster endpoint details must be written to the local `kubeconfig` file using `gcloud container clusters get-credentials`. Second, cluster readiness is verified using `kubectl get nodes`. Third, the workload manifest is submitted using `kubectl apply -f`. Finally, workload instantiation is verified using `kubectl rollout status`.

Step-by-Step Solution

1
Execute `gcloud container clusters get-credentials analytics-prod-cluster --region europe-west1`.
Local `kubeconfig` file is updated with cluster authentication tokens and API server endpoint entries.
kubectl commands will fail due to lack of authentication or invalid context without fetching cluster credentials first.
2
Run `kubectl get nodes` to inspect node status.
The control plane returns the list of worker nodes and their current readiness status.
Confirming cluster connectivity ensures the API server is reachable before submitting resource specifications.
3
Run `kubectl apply -f analytics-deployment.yaml`.
The Kubernetes API server accepts and creates the specified Deployment object.
Workload resources can only be declared after authentication and connectivity validation.
4
Execute `kubectl rollout status deployment/analytics-service`.
The CLI tracks pod creation and displays rollout success once all replicas pass readiness probes.
Verifying rollout completion guarantees that the deployment succeeded without crashing or stalling.

Key Concept

GKE Cluster Credential Fetching and Workload Deployment Workflow
Question 125Question →

An infrastructure team is setting up a production Cloud SQL PostgreSQL instance that must communicate exclusively via Private IP inside an existing custom Virtual Private Cloud network named `prod-vpc`. Arrange the following administrative commands and procedures in the correct sequential order to establish Private Service Access and deploy the database instance.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Allocate an internal IP range using gcloud compute addresses create, 2) Create the private service peering connection using gcloud services peered-connections create, 3) Create the Cloud SQL instance with gcloud sql instances create --network=prod-vpc --no-assign-ip, and 4) Provision database users using gcloud sql users create.
To deploy a Cloud SQL instance with Private IP connectivity, Google Cloud requires an established Private Service Access connection. The mandatory sequence begins with reserving an internal IP block (`gcloud compute addresses create`), followed by peering the VPC to Google managed services (`gcloud services peered-connections create`), then creating the instance attached to the VPC without a public IP (`gcloud sql instances create --network=prod-vpc --no-assign-ip`), and finally configuring database user credentials (`gcloud sql users create`).

Step-by-Step Solution

1
Reserve an internal IP address block in the VPC network.
An IP address range with purpose VPC_PEERING is allocated in prod-vpc.
Private Service Access requires a dedicated IP address range to be allocated in the user VPC prior to peering.
2
Create the VPC Network Peering connection to servicenetworking.googleapis.com.
The VPC network is peered with the service producer network managed by Google.
Cloud SQL private instances reside inside a Google-managed tenant VPC, requiring network peering to route traffic.
3
Provision the Cloud SQL instance with --network and --no-assign-ip parameters.
Cloud SQL instance is deployed and assigned a private IP from the peered service range.
Attempting to create a Cloud SQL instance with --network before creating the peered connection results in execution failure.
4
Configure database user credentials.
Application user account is created on the deployed database instance.
User management commands require an active database instance target.

Key Concept

Sequential provisioning of GCP Private Service Access and Private IP Cloud SQL instances
Question 126Question →

A cloud engineer needs to manually scale a running GKE Deployment named 'web-app' to 5 replicas and verify the deployment status using command-line tools. Arrange the operational steps in the correct chronological order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Retrieve cluster credentials via gcloud, 2) Inspect current deployment status using kubectl get deployment, 3) Scale the deployment to 5 replicas using kubectl scale, and 4) Verify new pod creation using kubectl get pods.
To manage Kubernetes resources from a local terminal, an engineer must first authenticate and obtain cluster credentials using gcloud. Next, inspecting the current deployment state establishes a baseline. Executing the scale command updates the Deployment manifest in the GKE control plane. Finally, querying pod status verifies successful scheduling and pod startup.

Step-by-Step Solution

1
Authenticate and set context
Local kubeconfig is populated with cluster endpoint and authentication details.
kubectl commands cannot communicate with the GKE control plane without valid cluster credentials.
2
Inspect workload baseline
Current deployment specifications and active replica counts are displayed.
Verifying current workload state confirms target deployment existence and establishes a baseline.
3
Scale workload replicas
Deployment spec desired replica count is updated to 5.
The scale command modifies the deployment spec to trigger Kubernetes controller reconciliation.
4
Verify pod status
All 5 pod instances are listed with Status: Running.
Operational verification ensures cluster nodes have successfully provisioned and started the requested pods.

Key Concept

Manual scaling and status verification of GKE Deployments using gcloud and kubectl CLI tools
Question 127Question →

A cloud engineer needs to migrate workloads from an existing GKE Standard node pool to a new node pool configured with larger machine types without causing application downtime. In what sequence should the engineer execute these operational steps to perform the migration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: first, provision the new node pool; second, cordon the old nodes to block new Pod assignments; third, drain the old nodes to migrate running Pods to the new pool; and fourth, delete the old node pool.
To migrate GKE workloads seamlessly to a new node pool without downtime, the target infrastructure must exist first (`gcloud container node-pools create`). Next, cordoning the old nodes (`kubectl cordon`) ensures that no new Pods land on nodes scheduled for removal. Draining the old nodes (`kubectl drain`) then gracefully terminates existing Pods so Kubernetes reschedules them on the newly available nodes. Finally, after all Pods are running healthily on the new node pool, the old node pool can be safely deleted (`gcloud container node-pools delete`).

Step-by-Step Solution

1
Create the destination node pool
Additional compute capacity is added to the cluster to receive workloads.
You cannot migrate running Pods off existing nodes unless replacement node capacity already exists.
2
Mark old nodes as unschedulable (cordon)
Old nodes stop accepting new Pod assignments.
Cordoning prevents new or rescheduled Pods from placing themselves back onto the nodes slated for removal.
3
Evict Pods gracefully (drain)
Pods are safely terminated and recreated on the new node pool by their controller deployments.
Draining respects PodDisruptionBudgets and allows graceful termination of application processes.
4
Decommission the old node pool
Unused compute resources are removed from Google Cloud, stopping billing for the old nodes.
Deleting the node pool is the final step after verifying all workloads are running in the new pool.

Key Concept

Zero-downtime GKE Node Pool Migration using Cordon and Drain
Question 128Question →

Your organization needs to perform a zero-downtime update of a production stateless web application hosted on a Compute Engine Managed Instance Group (MIG). Place the operational steps in the correct sequential order to deploy the new application version according to Google Cloud best practices.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for updating the Managed Instance Group with zero downtime is: 1) Create a new instance template containing the updated configuration, 2) Set the MIG target instance template to the new template, 3) Execute a rolling replace command with surge and unavailability constraints, and 4) Monitor instance health checks until all instances reach the UPDATED state.
Because Compute Engine instance templates are immutable, updating a Managed Instance Group (MIG) requires creating a new instance template first. Once created, the MIG target instance template reference must be updated to point to this new template. After updating the target reference, running a `rolling-action replace` command with defined `max-surge` and `max-unavailable` parameters starts the automated rollout while preserving application capacity. Finally, monitoring instance health checks ensures all new instances successfully serve traffic and transition to the `UPDATED` state.

Step-by-Step Solution

1
Create a new Compute Engine instance template
A new immutable template object is created containing the updated image and configuration.
Instance templates in Google Cloud are immutable and cannot be edited after creation.
2
Assign the new template to the Managed Instance Group
The MIG configuration points to the new template as its target resource.
The group must be explicitly configured to point to the new template before initiating rolling replacements.
3
Initiate rolling-action replace with surge controls
The MIG controller begins replacing old instances with new instances in batches.
Configuring max-surge and max-unavailable parameters ensures service capacity is maintained during the rollout.
4
Validate rollout completion via health status monitoring
All group instances complete transition to the target template and pass health checks.
Verifying instance health ensures application readiness before concluding the maintenance procedure.

Key Concept

Managed Instance Group (MIG) Rolling Updates and Instance Template Lifecycle Management
Question 129Question →

You need to migrate a standalone application's stateful data from a persistent disk located in zone us-central1-a to a newly created Compute Engine VM instance in zone us-central1-b. What is the correct sequence of steps to accomplish this cross-zone disk data migration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps is: First, create a persistent disk snapshot from the source disk in us-central1-a. Second, create a new zonal persistent disk in us-central1-b using the snapshot as the source. Third, create a new Compute Engine instance in us-central1-b and attach the newly created persistent disk.
The correct sequence requires creating a snapshot first because snapshots are global resources available across all zones in a project. Next, a new zonal persistent disk must be initialized in the target zone (us-central1-b) from that global snapshot. Finally, the Compute Engine instance is launched in us-central1-b with the new disk attached, satisfying the GCP requirement that VMs and persistent disks must reside in the same zone.

Step-by-Step Solution

1
Take a snapshot of the source persistent disk in us-central1-a.
A point-in-time global snapshot of the persistent disk data is stored.
Persistent disk snapshots are project-level global resources, allowing them to cross zone boundaries.
2
Provision a new persistent disk in us-central1-b sourced from the snapshot.
A new persistent disk containing the original data is created in us-central1-b.
Persistent disks are single-zone resources and cannot be directly attached across different zones.
3
Deploy the Compute Engine instance in us-central1-b attaching the new disk.
The target instance in us-central1-b boots or mounts the restored disk data.
VM instances and their attached persistent disks must reside within the identical Google Cloud zone.

Key Concept

Compute Engine Persistent Disk Snapshots and Cross-Zone Migration
Estimated Time:1m 0s
Question 130Question →

A cloud engineer needs to deploy a Compute Engine virtual machine instance that automatically executes an initialization script stored in a private Google Cloud Storage bucket upon booting. What is the correct sequence of steps to configure access, provision the VM instance, and verify deployment execution?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by uploading the bash initialization script to the target Cloud Storage bucket, followed by granting the Storage Object Viewer IAM role to the VM's custom service account on that bucket. Next, the VM instance is created using gcloud with the attached service account, cloud-platform scope, and startup-script-url metadata key. Finally, serial port output logs are retrieved using gcloud to verify script completion.
To successfully deploy a VM configured with a startup script located in Cloud Storage, the file must first exist in the bucket. Second, the custom service account assigned to the VM must be granted `roles/storage.objectViewer` on that bucket so the boot agent can read the file. Third, running `gcloud compute instances create` with `--service-account`, `--scopes=cloud-platform`, and `--metadata=startup-script-url` provisions the VM and initiates execution. Fourth, running `gcloud compute instances get-serial-port-output` provides verification that the initialization script executed properly.

Step-by-Step Solution

1
Upload the script artifact to Google Cloud Storage.
The file `startup.sh` is stored at `gs://prod-init-scripts-bucket/startup.sh`.
The startup script resource must be uploaded to Cloud Storage before it can be referenced in metadata.
2
Configure IAM access permissions on the bucket.
Service account `[email protected]` receives `roles/storage.objectViewer`.
Applying least-privilege IAM roles ensures the VM identity is authorized to access the private bucket when fetching the script.
3
Provision the Compute Engine VM via gcloud CLI.
Instance `app-vm` starts up with custom identity and startup script metadata.
Combining `--service-account`, `--scopes=cloud-platform`, and `--metadata=startup-script-url` allows the instance startup agent to retrieve and execute the script at boot.
4
Inspect serial port output logs.
Console output confirms the initialization script finished without errors.
Retrieving serial port output is the standard method for validating startup script execution status post-deployment.

Key Concept

Provisioning Compute Engine VMs with GCS-based Startup Scripts and Custom Service Accounts
Question 131Question →

A cloud engineer is tasked with deploying an event-driven Go microservice using Google Cloud Functions (2nd gen). The function must execute whenever a new object is created in a Cloud Storage bucket in the project. To adhere to security best practices and ensure successful event delivery, several setup and deployment tasks must be performed in sequence. Arrange the operational steps below in the correct logical execution sequence from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of deployment steps is: 1) Enable the required Google Cloud APIs (Cloud Functions, Cloud Build, Artifact Registry, Eventarc, Cloud Run); 2) Create a dedicated user-managed service account for runtime execution; 3) Grant the Pub/Sub Publisher role (roles/pubsub.publisher) to the Cloud Storage system service account; 4) Execute the gcloud functions deploy command specifying the 2nd gen environment, event filters, storage bucket, and runtime service account.
The correct order follows fundamental GCP infrastructure dependency rules. First, project-level APIs (Cloud Functions, Cloud Build, Artifact Registry, Eventarc, Cloud Run) must be enabled. Second, the user-managed runtime service account must be created so it can be referenced in configurations. Third, IAM permissions permitting the Cloud Storage service account to publish events (`roles/pubsub.publisher`) must be granted so Eventarc event delivery functions properly. Finally, the function is deployed using `gcloud functions deploy --gen2` referencing the bucket event filters and runtime service account.

Step-by-Step Solution

1
Enable requisite Google Cloud APIs
Cloud Functions, Cloud Build, Artifact Registry, Eventarc, and Cloud Run APIs are active.
Cloud Functions (2nd gen) builds container images via Cloud Build, stores them in Artifact Registry, and runs them on Cloud Run while listening to events through Eventarc. Enabling these APIs is the mandatory prerequisite.
2
Provision a dedicated user-managed service account
A specific service account identity is created.
Following the principle of least privilege, a dedicated identity is needed so the function does not fall back to the default Compute Engine service account.
3
Authorize the Cloud Storage system service account
The Cloud Storage service account gains the roles/pubsub.publisher role.
Cloud Storage relies on Pub/Sub to push audit and storage events to Eventarc triggers. Without granting roles/pubsub.publisher to the Cloud Storage service account (`service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com`), event notifications will fail to deliver.
4
Deploy the 2nd gen Cloud Function
The Cloud Function is compiled, built into a container image, and deployed to Cloud Run with an active Eventarc trigger.
With APIs enabled, identities created, and event publisher permissions granted, running `gcloud functions deploy` with `--gen2` completes the build and deployment pipeline.

Key Concept

Deployment lifecycle and IAM prerequisites for Cloud Functions (2nd gen) with Cloud Storage Eventarc triggers
Estimated Time:2m 0s
Question 132Question →

You are deploying a Global External Application Load Balancer using the gcloud CLI to serve traffic for a Web application running on Compute Engine instance groups. In what sequence must you configure and link the load balancing components from backend to frontend?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for deploying a Global External Application Load Balancer from backend to frontend is: 1) Create the health check and backend service and attach the instance group, 2) Create the URL map referencing the default backend service, 3) Create the target HTTP proxy pointing to the URL map, and 4) Create the global forwarding rule directing external traffic to the target HTTP proxy.
Google Cloud Global External Application Load Balancers follow a strict bottom-up dependencies configuration sequence when deployed via gcloud CLI. First, the health check and backend service are created, and instance groups are added as backends. Second, a URL map is created referencing the backend service. Third, a target HTTP proxy is created referencing the URL map. Finally, a global forwarding rule is created specifying the external IP address and port while targeting the HTTP proxy.

Step-by-Step Solution

1
Configure backend service and health check
Backend service created with attached health check and instance group.
Higher-level HTTP routing components cannot be instantiated without specifying an existing target backend service.
2
Define URL routing rules
URL map created pointing to the backend service as default.
URL maps require existing backend services to designate host and path routing destinations.
3
Create the target HTTP proxy
Target HTTP proxy bound to the URL map.
Target proxies require an existing URL map to know how to route incoming HTTP traffic.
4
Configure global forwarding rule (Frontend)
Global forwarding rule established with external IP and port binding to the target proxy.
The forwarding rule routes external client traffic to the target proxy and represents the final frontend configuration step.

Key Concept

GCP Global External Application Load Balancer gcloud bottom-up deployment sequence
Estimated Time:1m 30s
Question 133Question →

A cloud engineer is tasked with establishing a secure, isolated Virtual Private Cloud (VPC) environment in Google Cloud for processing sensitive financial analytics. The solution must completely block general internet egress from internal instances while allowing compute instances without external IP addresses to securely access Cloud Storage using Private Google Access. Administrative SSH management must be strictly restricted to Google Identity-Aware Proxy (IAP).

What is the correct sequential order of operational steps to provision the custom VPC infrastructure, configure regional subnetwork connectivity with Private Google Access, enforce high-priority egress allow rules for restricted Google APIs, implement fallback zero-trust egress blocking, and secure administrative ingress access?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins by creating the custom VPC network (`finance-analytics-vpc`), followed by creating the regional subnet (`finance-subnet-us-east1`) with Private Google Access enabled. Next, the specific high-priority egress allow firewall rule for restricted Google APIs (199.36.153.4/30199.36.153.4/30) with priority 100100 is created. Then, the low-priority fallback egress deny firewall rule (0.0.0.0/00.0.0.0/0) with priority 10001000 is added. Finally, the ingress firewall rule for Identity-Aware Proxy (IAP) SSH access (35.235.240.0/2035.235.240.0/20) on port 2222 is applied.
The correct sequence ensures structural dependencies are satisfied first (VPC network creation, followed by subnetwork provisioning with Private Google Access). Next, egress firewall rules are established following GCP priority evaluation logic: the specific egress ALLOW rule for restricted Google APIs (199.36.153.4/30199.36.153.4/30) uses a lower numerical priority value (100100) so it is evaluated before the general egress DENY rule (0.0.0.0/00.0.0.0/0) which carries a higher numerical priority value (10001000). Finally, the IAP administrative ingress rule is applied to allow remote SSH access to internal instances.

Step-by-Step Solution

1
Provision custom VPC network baseline
Created `finance-analytics-vpc` using `--subnet-mode=custom`.
VPC networks act as the parent container. Subnets and network-scoped firewall rules cannot be instantiated until the target VPC network resource exists.
2
Provision regional subnetwork with Private Google Access
Subnet `finance-subnet-us-east1` created in `us-east1` with flag `--enable-private-ip-google-access`.
Private Google Access must be enabled at the subnet level to allow internal VMs (which lack public IPv4 addresses) to resolve and route traffic to Google APIs and Cloud Storage.
3
Configure high-priority Google API egress rule
Created egress ALLOW firewall rule with priority 100100 for destination 199.36.153.4/30199.36.153.4/30 on port 443443.
GCP evaluates firewall rules starting from the lowest numerical priority integer. Priority 100100 takes precedence over lower-priority rules such as priority 10001000.
4
Configure catch-all egress block firewall rule
Created egress DENY firewall rule with priority 10001000 targeting destination 0.0.0.0/00.0.0.0/0.
To block standard internet access while permitting Google API access, the broad 0.0.0.0/00.0.0.0/0 deny rule must possess a higher numerical priority value (e.g., 10001000) than the API allow rule (priority 100100).
5
Configure restricted administrative IAP ingress rule
Created ingress ALLOW firewall rule for TCP port 2222 sourced from 35.235.240.0/2035.235.240.0/20 targeting instances tagged `iap-ssh-target`.
Instances without public IP addresses rely on Google IAP CIDR 35.235.240.0/2035.235.240.0/20 for SSH connectivity. Defining this ingress rule secures administrative access after establishing the egress security posture.

Key Concept

Deployment sequence for custom VPC networks, Private Google Access subnet configuration, and rule priority evaluation order for GCP Firewalls.
Estimated Time:3m 0s
Question 134Question →

An enterprise operations team is preparing to enable dynamic workload scaling for a microservice deployed on a Google Kubernetes Engine (GKE) cluster. To ensure accurate autoscaling metric calculations and maintain application availability during scaling events, arrange the following CLI management steps in the correct operational sequence from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: first, set container resource requests using `kubectl set resources`; second, establish a PodDisruptionBudget using `kubectl create poddisruptionbudget`; third, configure the Horizontal Pod Autoscaler using `kubectl autoscale deployment`; fourth, monitor HPA performance using `kubectl get hpa --watch`.
The sequence must start by defining container resource requests via `kubectl set resources` because target utilization percentages in HPA rely on requested CPU/memory values. Next, creating a PodDisruptionBudget ensures availability guards are in place before dynamic scaling occurs. Executing `kubectl autoscale deployment` then creates the HPA controller object. Finally, checking `kubectl get hpa --watch` validates metric ingestion and replica control.

Step-by-Step Solution

1
Set container resource requests using `kubectl set resources deployment/web-app --requests=cpu=250m,memory=512Mi`.
The Deployment specification includes explicit container resource request baselines.
The Horizontal Pod Autoscaler requires resource requests to calculate CPU and memory utilization percentages.
2
Create a PodDisruptionBudget using `kubectl create poddisruptionbudget`.
The cluster enforces minimum ready replica constraints during voluntary node drains and scaling events.
Protects workload availability before automated replica adjustments begin.
3
Configure autoscaling using `kubectl autoscale deployment web-app --min=3 --max=15 --cpu-percent=80`.
A HorizontalPodAutoscaler resource is created and begins monitoring pod workload metrics.
Initializes the HPA controller to scale deployment replicas dynamically.
4
Observe HPA controller status using `kubectl get hpa web-app --watch`.
Verifies that current metric values are fetched and target replica counts update correctly.
Confirms proper metric pipeline operation and prevents silent scaling failures.

Key Concept

GKE Workload Resource Allocation and Autoscaling Sequence
Question 135Question →

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 136Question →

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 137Question →

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 138Question →

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 139Question →

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 140Question →

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
PreviousPage 7 / 14Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin