Examkin

All practice questions

262 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 161Question →

A cloud engineer needs to configure a fine-grained custom IAM role for a service account using the gcloud CLI to enforce least privilege access in a Google Cloud project. What is the correct sequence of steps to create the custom role, provision the service account, and apply the required access permissions?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational order is to draft the custom role YAML definition file, run `gcloud iam roles create` to create the role resource, run `gcloud iam service-accounts create` to provision the service account identity, and finally execute `gcloud projects add-iam-policy-binding` to assign the role to the service account.
The sequence follows mandatory resource dependencies: permissions are defined in a specification file, the custom role is registered in GCP IAM, the target service account identity is provisioned, and finally the role is bound to the identity using project policy bindings.

Step-by-Step Solution

1
Prepare the custom IAM role definition locally in YAML format.
A structured YAML file containing title, description, stage, and allowed permissions.
The gcloud CLI requires a YAML or JSON definition file to specify custom permission sets.
2
Create the custom IAM role resource in the GCP project.
The custom role is registered and assigned a unique role ID within the project.
IAM roles must exist in the target hierarchy before policy bindings can reference them.
3
Create the service account identity.
A service account principal is initialized with a generated email identifier.
A valid principal identity must exist before IAM roles can be granted to it.
4
Bind the custom role to the service account on the project resource.
The project's IAM policy is updated to grant the specified role permissions to the service account.
Adding an IAM policy binding completes the access configuration by attaching the role to the identity.

Key Concept

Managing IAM Roles and Resource Access Permissions via gcloud CLI
Estimated Time:1m 30s
Question 162Question →

An operator accidentally deleted a critical customer table from a production Cloud SQL for PostgreSQL instance at 14:15 UTC. Automated daily backups and transaction logging (point-in-time recovery) are enabled on the instance. You must restore the database to a new instance to recover the missing data and resume normal operations. Sequence the correct order of steps to complete this recovery process.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Identify the exact timestamp prior to deletion, 2) Execute the point-in-time restore to a new Cloud SQL instance, 3) Verify data integrity on the restored instance, and 4) Update application connection parameters to point to the new instance.
The proper administrative workflow begins by determining the target timestamp immediately prior to data corruption. Next, a point-in-time restoration is executed targeting a new instance. Once provisioned, the database contents are validated for completeness, and finally the application connection parameters are updated to route traffic to the restored instance.

Step-by-Step Solution

1
Locate the precise restore target timestamp.
Obtained a timestamp (e.g., 14:14 UTC) immediately prior to the table drop event.
Restoring to a timestamp after the drop event would still result in missing data.
2
Provision and populate a new Cloud SQL instance using point-in-time recovery.
A new Cloud SQL instance is created containing the state of the database up to the designated timestamp.
Cloud SQL PITR requires specifying a target instance to prevent accidental overwrites of live production instances.
3
Inspect the restored database instance.
Confirmed that the deleted table exists and all data is present and uncorrupted.
Operational best practices require verification before switching application connections.
4
Reconfigure application connection endpoints.
Application workloads now communicate with the newly verified Cloud SQL instance.
Updating connection strings or Secret Manager references directs live traffic to the recovered instance.

Key Concept

Cloud SQL Point-in-Time Recovery (PITR) and Instance Management
Question 163Question →

A DevOps engineer needs to safely migrate running workloads from an existing GKE node pool named `old-pool` to a newly created node pool named `new-pool` in a GKE Standard cluster without incurring unexpected downtime. Arrange the operational steps in the correct order to safely migrate the workloads and decommission the old node pool.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of operations is: first cordon the nodes in `old-pool` to prevent new pod assignments, then drain `old-pool` to evict existing pods, next verify workload readiness on `new-pool`, and finally delete `old-pool` using gcloud.
To perform a zero-downtime workload migration between GKE node pools, the existing nodes must first be cordoned (`kubectl cordon`) so Kubernetes marks them unschedulable. Next, nodes are drained (`kubectl drain`) to evict existing pods, forcing them to reschedule onto the new node pool. After verifying that the pods are healthy and running on the new node pool, the old node pool can be safely deleted using `gcloud container node-pools delete`.

Step-by-Step Solution

1
Mark nodes in `old-pool` as unschedulable using `kubectl cordon`.
Prevents new pod replicas from being scheduled on `old-pool` nodes.
Cordoning first ensures that evicted pods are directed to `new-pool` instead of being rescheduled back onto `old-pool`.
2
Gracefully evict workloads using `kubectl drain <node-name> --ignore-daemonsets` on nodes in `old-pool`.
Safely terminates pods on `old-pool` so Kubernetes recreates them on `new-pool`.
Draining ensures pods are evicted cleanly while ignoring system DaemonSets.
3
Inspect workload pod status and service health on `new-pool`.
Confirms all pods are in the `Running` state and ready to handle user requests.
Verification prevents deleting infrastructure while workloads might be failing to schedule or start.
4
Execute `gcloud container node-pools delete old-pool` to delete the old node pool.
Decommissions the compute instances associated with `old-pool` in GCP.
Deletes obsolete GCP compute resources after successful workload migration.

Key Concept

Safely migrating workloads between GKE node pools using cordon, drain, health verification, and node pool deletion commands.
Question 164Question →

A cloud engineer is tasked with executing a zero-downtime canary rollout of a newly built container revision `v2` for an existing production Cloud Run service named `inventory-api` currently serving all traffic from revision `v1`. The engineering policy mandates testing the isolated new revision via a dedicated endpoint prior to exposing any production users, followed by a staged traffic migration. In what chronological sequence should the engineer execute these operational steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Deploy the new container image with `--no-traffic` and assign a URL tag named `green`; 2) Send test HTTP requests directly to the tagged revision URL; 3) Run `gcloud run services update-traffic inventory-api --to-revisions=v1=90,v2=10`; 4) Run `gcloud run services update-traffic inventory-api --to-revisions=v2=100`.
The proper sequence for a safe Cloud Run rollout requires isolating the new revision upon creation by supplying `--no-traffic` and `--tag=green`, testing the isolated revision endpoint directly, initiating a canary traffic allocation using `gcloud run services update-traffic`, and finally completing the 100% traffic cutover after canary telemetry is validated.

Step-by-Step Solution

1
Deploy revision `v2` without routing live traffic and attach a revision tag
Revision `v2` is created and accessible strictly via its tag-specific URL endpoint, receiving 0% of main service traffic.
Using `--no-traffic` prevents automatic 100% traffic assignment upon deployment.
2
Validate revision behavior against the tagged URL endpoint
Functionality and health checks pass without exposing live users to potential defects.
Revision tags provide isolated subdomains to test specific revisions before production exposure.
3
Configure canary traffic allocation
10% of main service endpoint requests are handled by `v2` while 90% remain on `v1`.
Canary deployments allow monitoring real user traffic telemetry at reduced risk.
4
Migrate remaining production traffic to the new revision
Revision `v2` handles 100% of live production traffic for `inventory-api`.
Completing the traffic split completes the rollout cycle after canary verification.

Key Concept

Cloud Run Tagged Canary Deployment and Traffic Splitting Workflow
Question 165Question →

An operations engineer needs to restore a PostgreSQL database backup file stored in a Google Cloud Storage bucket into a target Cloud SQL for PostgreSQL instance using the gcloud CLI. Place the following operational steps in the correct chronological sequence to perform this restoration.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Retrieve the service account email of the Cloud SQL instance, 2) Grant the service account the Storage Object Viewer role on the Cloud Storage bucket, 3) Execute the gcloud sql import sql command with the Cloud Storage URI, and 4) Monitor the operation status using gcloud sql operations list until DONE.
To perform a Cloud SQL import from Cloud Storage, the instance service account must first be retrieved and granted read permissions (Storage Object Viewer) on the bucket containing the dump file. Only after permission propagation can the `gcloud sql import sql` command be executed, followed by monitoring the operation status via `gcloud sql operations list` to confirm successful completion.

Step-by-Step Solution

1
Identify Instance Service Account
Obtain the unique serviceAccountEmailAddress associated with the Cloud SQL instance.
Cloud SQL accesses Google Cloud Storage using its own system-generated service account, not the user's personal credentials.
2
Configure Bucket IAM Permissions
Grant the Storage Object Viewer (roles/storage.objectViewer) role to the Cloud SQL service account on the bucket.
Without explicit bucket-level read access, Cloud SQL will return permission errors when attempting to read the dump file.
3
Trigger SQL Import
Run gcloud sql import sql <INSTANCE> gs://<BUCKET>/<FILE>.
Initiates the import task using the authenticated Cloud SQL instance service account.
4
Track Operation Completion
Query gcloud sql operations list --instance=<INSTANCE> to verify the status.
Import operations run asynchronously; verifying DONE status confirms data has been loaded successfully.

Key Concept

Cloud SQL Database Import IAM Prerequisites and CLI Execution Sequence
Question 166Question →

A cloud engineer is deploying a custom-mode Virtual Private Cloud (VPC) network named `prod-vpc` to host a secure tier of web application instances in Google Cloud. The deployment specification requires creating a custom subnet named `prod-subnet-us`, defining an ingress firewall rule named `allow-prod-web` restricted to target network tag `web-frontend`, and launching a Compute Engine VM instance named `app-server-1` attached to the new subnet with the matching target tag. What is the correct chronological sequence of gcloud CLI commands to successfully provision this complete network infrastructure from scratch?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with creating the custom-mode VPC network, followed by creating the custom subnet within that network, configuring the VPC ingress firewall rule with target tags, and finally launching the Compute Engine instance bound to the custom subnet and tag.
Google Cloud resource dependencies dictate that higher-level network structures must exist before lower-level components. First, the custom VPC network (`prod-vpc`) must be created without default subnets. Second, the regional subnet (`prod-subnet-us`) must be created inside `prod-vpc`. Third, firewall rules targeting `prod-vpc` and specific tags (`web-frontend`) must be created to enforce ingress policy. Finally, the virtual machine (`app-server-1`) is created, referencing both the existing subnet for IP allocation and the network tag for firewall rule matching.

Step-by-Step Solution

1
Execute `gcloud compute networks create prod-vpc --subnet-mode=custom`
Creates the top-level custom VPC network entity in the GCP project without auto-generated subnets.
GCP resource hierarchy requires the parent VPC network to exist before subnets or network-scoped firewall policies can be defined.
2
Execute `gcloud compute networks subnets create prod-subnet-us --network=prod-vpc --region=us-central1 --range=10.130.0.0/20`
Provisions a regional custom subnet associated with `prod-vpc`.
Subnets require an existing parent VPC network (`--network=prod-vpc`) to define regional IP address ranges.
3
Execute `gcloud compute firewall-rules create allow-prod-web --network=prod-vpc --allow=tcp:80,tcp:443 --target-tags=web-frontend`
Establishes network security controls for incoming HTTP/HTTPS traffic targeting instances with tag `web-frontend`.
Firewall rules belong to a specific network (`prod-vpc`) and must be defined before or alongside instances to ensure immediate perimeter protection upon VM startup.
4
Execute `gcloud compute instances create app-server-1 --zone=us-central1-a --subnet=prod-subnet-us --tags=web-frontend`
Deploys the Compute Engine virtual machine into `prod-subnet-us` with `web-frontend` tag applied.
Instantiating a Compute Engine VM requires valid, pre-existing subnets (`--subnet`) to allocate internal IP addresses successfully.

Key Concept

GCP VPC and Compute Provisioning Dependency Order
Question 167Question →

A Cloud Engineer is tasked with deploying a containerized microservice to Google Cloud Run from local source code while enforcing security best practices and least privilege. Place 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 deployment sequence is: 1) Enable the Cloud Run and Cloud Build APIs, 2) Create a dedicated user-managed service account with minimal IAM roles, 3) Build and push the container image to Artifact Registry using gcloud builds submit, 4) Deploy the image to Cloud Run attaching the custom service account.
Deploying a containerized application to Cloud Run from source code follows a dependency-driven workflow. First, the required API endpoints (Cloud Run and Cloud Build) must be enabled in the project. Second, a custom service account with least-privilege permissions must be created so it can be assigned during service instantiation. Third, the container image must be built and stored in Artifact Registry using `gcloud builds submit`. Finally, `gcloud run deploy` is executed to launch the revision using the container image and custom service account.

Step-by-Step Solution

1
Enable required Cloud Service APIs
Cloud Run and Cloud Build APIs are active and ready to accept API calls.
Google Cloud service endpoints must be enabled in the project before managing or invoking resource builds.
2
Configure runtime IAM service account
A least-privilege service account is provisioned for the microservice.
Attaching the default Compute Engine service account violates security best practices; custom service accounts should be prepared prior to deployment.
3
Build and push container image to Artifact Registry
A fully compiled container image URI is available in Artifact Registry.
Cloud Run requires a container image hosted in a registry like Artifact Registry before a revision can be deployed.
4
Deploy revision to Cloud Run
The Cloud Run service is active and running with the specified container image and service account identity.
Deploying the container image with gcloud run deploy is the final execution step in the release workflow.

Key Concept

Cloud Run Source-to-Deployment Pipeline & Least-Privilege Identity Management
Question 168Question →

A Cloud Engineer needs to migrate an existing standalone, stateful Compute Engine VM instance named 'prod-db-node' and its boot persistent disk from zone us-central1-a to zone us-central1-b due to a planned zone retirement. The database engine requires complete data consistency prior to taking storage backups. Which sequence of gcloud CLI actions correctly performs this zonal migration while ensuring data integrity?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence to migrate a stateful Compute Engine instance to a new zone is: 1) Stop the source instance in us-central1-a to ensure disk consistency. 2) Take a snapshot of the boot persistent disk. 3) Provision a new persistent disk in target zone us-central1-b using the snapshot as source. 4) Launch a new Compute Engine instance in us-central1-b attached to the restored persistent disk as its boot disk.
Because Compute Engine Persistent Disks are bound to a single zone, migrating a stateful VM to another zone requires creating a new persistent disk in the target zone. The proper workflow starts with stopping the VM instance to guarantee data consistency, capturing a project-wide persistent disk snapshot, instantiating a new persistent disk in target zone us-central1-b using the snapshot as a source, and finally launching a new Compute Engine VM in us-central1-b referencing the new disk as its boot disk.

Step-by-Step Solution

1
Execute `gcloud compute instances stop prod-db-node --zone=us-central1-a`
The virtual machine transitions to the TERMINATED state, stopping all write operations to the persistent disk.
Stopping the database VM ensures unwritten data in buffer cache is flushed, avoiding data corruption in the snapshot.
2
Execute `gcloud compute disks snapshot prod-db-node-disk --zone=us-central1-a --snapshot-names=prod-db-snapshot`
A project-level persistent disk snapshot is generated from the consistent disk state.
Persistent Disks are zonal resources, but disk snapshots are available project-wide across all zones.
3
Execute `gcloud compute disks create prod-db-node-disk-b --zone=us-central1-b --source-snapshot=prod-db-snapshot`
A new zonal persistent disk containing the source data is created in us-central1-b.
Disks cannot be directly moved or re-attached across zones without recreating them in the target zone from a snapshot.
4
Execute `gcloud compute instances create prod-db-node --zone=us-central1-b --disk=name=prod-db-node-disk-b,boot=yes`
The newly provisioned instance boots up in us-central1-b with all original data intact.
Attaching the new zonal disk as the primary boot device restores the workload in the target zone.

Key Concept

Cross-Zone Compute Engine Persistent Disk Migration
Estimated Time:2m 0s
Question 169Question →

A cloud engineer needs to configure Private Service Access and deploy a Cloud SQL PostgreSQL database instance with Private IP connectivity in a custom Virtual Private Cloud (VPC) network using the `gcloud` command-line interface. Sequence the required 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 of steps is: 1) Allocate an internal IP address range in the VPC network, 2) Establish a private connection (VPC Network Peering) to Google services, 3) Provision the Cloud SQL PostgreSQL instance with `--network` and `--no-assign-ip`, and 4) Create an initial database user account on the instance.
To provision a Cloud SQL database instance exclusively on Private IP, Google Cloud requires establishing Private Service Access beforehand. The deployment workflow strictly requires: first reserving an internal IP block in the target VPC, second creating the VPC network peering connection to servicenetworking.googleapis.com, third executing `gcloud sql instances create` with `--network` and `--no-assign-ip`, and finally managing database resources such as creating initial database users.

Step-by-Step Solution

1
Allocate an internal IP range
A named internal IP address allocation is created within the custom VPC network.
Google Cloud requires dedicated private IP space allocated within your VPC before connecting to managed services.
2
Connect the VPC network to Service Networking
A Private Service Access peering connection is created between the VPC and Google's internal service network.
Cloud SQL Private IP instances communicate with client VPCs over this private peering connection.
3
Deploy the Cloud SQL instance with Private IP
The Cloud SQL PostgreSQL instance is provisioned with a private IP address and no public IP assigned.
Passing `--network` attaches the instance to the peered VPC, while `--no-assign-ip` disables public endpoint exposure.
4
Configure database user credentials
A user credential account is created within the provisioned PostgreSQL instance.
Administrative database entities can only be instantiated after the underlying database engine is fully running.

Key Concept

Provisioning Cloud SQL Private IP via Private Service Access
Question 170Question →

A Cloud Engineer needs to migrate an existing local Terraform state file to a Google Cloud Storage (GCS) remote backend to allow team collaboration and state locking. What is the correct sequence of steps to safely execute this backend migration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with creating the GCS storage bucket, adding the backend block to the HCL configuration, running terraform init, and confirming the state migration prompt.
To migrate state securely to GCS, the target GCS bucket must first exist. Next, the backend "gcs" configuration block is defined in HCL code. Running `terraform init` detects the new backend configuration and initiates the migration. Finally, confirming the migration prompt copies the existing local state file to the remote GCS bucket.

Step-by-Step Solution

1
Provision the GCS bucket
A destination storage location is ready to accept the Terraform state file.
Terraform cannot automatically create the GCS bucket specified in its backend block during initialization.
2
Configure the GCS backend in HCL
The Terraform code defines the remote backend location.
Terraform needs the backend provider block configured in code before it can change state storage locations.
3
Execute terraform init
Terraform detects the backend change from local to GCS.
The init command reconfigures working directory backends and initiates the state copy workflow.
4
Approve the state migration prompt
Local state is uploaded to the GCS bucket and local state file is updated.
Terraform asks for explicit user confirmation before transferring existing local state to remote storage.

Key Concept

Migrating Terraform Local State to GCS Remote Backend
Estimated Time:1m 0s
Question 171Question →

A Systems Administrator needs to create a standardized golden image from an existing, configured Compute Engine instance named `web-template-vm` located in GCP project `corp-base-images`. The administrator must then use this custom image to provision a new production Compute Engine instance in a separate project named `corp-prod-apps`. In what correct chronological order should the administrator perform the steps to complete this cross-project image creation and VM deployment workflow?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: First, stop the reference Compute Engine instance to ensure disk consistency. Second, create the custom image from the boot disk. Third, grant the Compute Image User role on the image/project to the target project's identity. Fourth, execute the gcloud instance creation command in the target project referencing the image and image-project flags.
To deploy a Compute Engine VM from a custom image in a separate project, the source instance must first be stopped to guarantee disk state consistency. Next, the custom image is created from the source boot disk. Then, cross-project access must be configured by granting the Compute Image User role (roles/compute.imageUser) to the deploying identity or service account in the target project. Finally, the VM can be provisioned in the target project using the gcloud command with --image and --image-project specified.

Step-by-Step Solution

1
Prepare source disk state
Reference VM instance is powered off safely.
Creating an image from a running VM can lead to inconsistent state or file corruption.
2
Generate custom image resource
Custom image object created in the base images project.
The custom image bundles the OS, configuration, and software stack required for deployment.
3
Configure cross-project IAM permissions
Target project service account is authorized to consume the image.
Compute Engine denies image access across projects by default unless roles/compute.imageUser is granted.
4
Deploy new VM instance
New VM is provisioned in target project using the cross-project custom image.
Passing --image and --image-project parameters instructs Compute Engine to fetch the boot disk image from the central project.

Key Concept

Cross-Project Custom Image Creation and VM Provisioning
Question 172Question →

A Cloud Engineer needs to create a project-level custom IAM role from a definition file (`custom-role.yaml`) and assign it to a service account (`[email protected]`) in the project `my-project`. Place the required command line operations and configuration steps in the correct chronological order from first to last to enforce least privilege access securely.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts by authoring the `custom-role.yaml` permissions file, followed by creating the custom role in the project with `gcloud iam roles create`, binding the custom role to the service account using `gcloud projects add-iam-policy-binding`, and finally verifying the policy update with `gcloud projects get-iam-policy`.
Creating and granting custom IAM permissions in Google Cloud requires defining the role specification file first, creating the role in the project hierarchy, attaching the role binding to the service account member, and finally auditing the updated IAM policy.

Step-by-Step Solution

1
Define the role manifest (`custom-role.yaml`) with necessary permissions such as `storage.objects.get`.
Local YAML file ready for gcloud role creation input.
gcloud requires a valid configuration manifest or parameter list to establish custom role definitions.
2
Execute `gcloud iam roles create` targeting the specific project with `--file=custom-role.yaml`.
The custom IAM role is created under `projects/my-project/roles/CustomRoleID`.
The role must exist before IAM policy bindings can reference its full resource name.
3
Execute `gcloud projects add-iam-policy-binding` with the `--member` and `--role` flags.
The principal is granted access permissions defined in the custom role.
Assigning roles to principals at the resource level establishes access control rules.
4
Execute `gcloud projects get-iam-policy` to inspect current project permissions.
Confirmation that the service account member is bound to the new role.
Auditing and verifying IAM bindings ensures compliance and confirms least privilege implementation.

Key Concept

Managing IAM Roles and Resource Access Permissions
Question 173Question →

A cloud administrator needs to promote an existing Cloud SQL read replica to an independent, standalone database instance to complete a planned regional workload separation. Arrange the operational steps in the correct chronological order to execute this promotion safely without data loss.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Stop incoming write operations from application workloads to the primary Cloud SQL instance, 2) Monitor Cloud SQL metrics to confirm that replication lag on the read replica has reached zero, 3) Execute the command `gcloud sql instances promote-replica` for the target instance, and 4) Reconfigure application database connection strings to point to the IP address of the newly promoted standalone instance.
To safely promote a Cloud SQL read replica without data loss, write operations to the primary instance must first be stopped. Next, administrators must verify that replication lag has dropped to zero so all committed transactions are reflected on the replica. Once synchronized, the promotion command is executed to convert the replica into a standalone instance. Finally, application configurations are updated to direct traffic to the new database endpoint.

Step-by-Step Solution

1
Quiesce write operations on the primary database
The primary Cloud SQL instance ceases accepting new write transactions.
Prevents state divergence between the primary instance and the replica prior to promotion.
2
Verify replication synchronization
Replication lag metric drops to zero seconds.
Guarantees zero data loss by ensuring all queued write-ahead logs are fully processed by the replica.
3
Execute the promotion operation
The read replica transitions into an independent read/write instance.
Severing the replication topology enables the target database instance to process independent write operations.
4
Update application connection endpoints
Application connections are redirected to the new standalone Cloud SQL instance.
Restores full application connectivity to the newly independent database.

Key Concept

Cloud SQL Read Replica Promotion Procedure
Question 174Question →

A cloud operations engineer needs to safely isolate a malfunctioning node in a Google Kubernetes Engine (GKE) cluster for maintenance while ensuring high application availability. In which correct sequential order should the engineer execute these operational steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is to first mark the node unschedulable (`kubectl cordon`), then gracefully evict workloads (`kubectl drain`), next verify that evicted pods are healthy on remaining cluster nodes (`kubectl get pods`), and finally perform maintenance or deletion on the underlying VM instance (`gcloud compute instances delete`).
Cordoning must be performed first to set the node to unschedulable state, preventing Kubernetes from scheduling new pods onto it during maintenance. Next, draining evicts existing non-DaemonSet workloads so they can be recreated on other healthy nodes. After draining, engineers must verify that all pods have resumed normal execution on alternative nodes before taking destructive or maintenance actions against the underlying VM instance.

Step-by-Step Solution

1
Run `kubectl cordon <node-name>`
The target node status changes to `SchedulingDisabled`.
This prevents new pods from being scheduled onto the node while preparing for eviction.
2
Run `kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data`
Running pods are evicted and rescheduled on remaining healthy nodes in the cluster.
This gracefully vacates the node without causing unnecessary workload disruption.
3
Run `kubectl get pods -o wide`
Confirms all application replicas have transitioned to `Running` state on active nodes.
Ensures service availability before taking the host node offline.
4
Execute maintenance or delete the VM via `gcloud compute instances delete`
The physical/virtual node instance is safely removed or rebooted.
Node maintenance can now take place without impacting running applications.

Key Concept

GKE Node Maintenance and Pod Eviction Sequence
Estimated Time:1m 30s
Question 175Question →

You need to update an existing regional Managed Instance Group named `frontend-mig` to use a new instance template named `frontend-v2` without incurring application downtime. Which sequence represents the correct chronological order of `gcloud` operations to execute this update and verify system stability?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Create the new instance template (`frontend-v2`), 2) Associate the template with the Managed Instance Group (`frontend-mig`), 3) Initiate the rolling update action, and 4) Confirm the instance group has returned to a stable state (`isStable: true`).
The standard operational lifecycle for updating a GCP Managed Instance Group requires creating a new instance template first, as instance templates are immutable. Next, the target Managed Instance Group must be updated to reference this new template. After updating the group's template assignment, the engineer starts a rolling update to replace running VM instances gradually. Finally, running a describe command allows the engineer to confirm that the group has reached a stable status (`isStable: true`) and all instances pass health checks.

Step-by-Step Solution

1
Create a new instance template containing the updated machine specs and boot image.
A new instance template resource named `frontend-v2` is registered in the project.
Compute Engine instance templates are immutable; modifying configuration requires creating a new template.
2
Update the Managed Instance Group configuration to point to the new instance template.
The target instance template for `frontend-mig` becomes `frontend-v2`.
The group controller needs the new template binding so it knows what specification to apply during rolling updates.
3
Execute the rolling update action on the group.
The group manager begins replacing instances in batches according to surge/unavailable settings.
This command actively initiates the replacement rollout without interrupting overall service availability.
4
Inspect the state of the Managed Instance Group.
The output confirms `isStable: true` once all VM instances are fully provisioned and healthy.
Verifying group stability ensures the deployment completed successfully and all instances passed autohealing checks.

Key Concept

Sequence of operations for updating Managed Instance Group (MIG) templates and performing rolling updates.
Question 176Question →

A Cloud Engineer notices elevated 5xx error rates following a recent deployment to a production Cloud Run service. To restore stability, the engineer must immediately route all live traffic back to the previous stable revision, reconfigure operational instance limits to handle expected traffic spikes, and clean up the broken revision. Arrange the operational steps in the correct logical sequence to execute this remediation workflow.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) List revisions to identify the stable revision ID, 2) Shift 100% of production traffic to the stable revision using `gcloud run services update-traffic`, 3) Update service instance scaling limits using `gcloud run services update`, and 4) Delete the faulty revision using `gcloud run revisions delete`.
Remediating a failing release requires identifying the target revision first, shifting 100% of live traffic to that healthy revision to resolve user-facing errors, modifying operational parameters (min/max instances) on the service configuration, and finally purging the inactive faulty revision.

Step-by-Step Solution

1
Inspect current service revisions
Obtained the precise revision names for both the degraded deployment and the prior stable revision.
Traffic management commands require accurate revision identifiers.
2
Re-route production traffic to the stable revision
Live traffic is immediately redirected away from the failing container revision.
Restoring end-user availability is the immediate priority during a production outage.
3
Reconfigure service autoscaling constraints
Minimum and maximum instance limits are applied to the active service deployment.
Updating service settings ensures cold starts are mitigated while protecting against runaway container creation.
4
Decommission the degraded revision
The faulty revision is safely removed from Google Cloud.
Revisions receiving zero traffic can be safely deleted to maintain clean operational state.

Key Concept

Cloud Run Traffic Management and Revision Lifecycle Operations
Question 177Question →

A Cloud Engineer is conducting a disaster recovery drill for a production regional Cloud SQL for PostgreSQL instance configured for High Availability (HA). The operational objective is to test manual failover from the primary zone to the standby zone, verify application stability, and safely failback to the original primary zone. Place the following operational steps in the correct chronological sequence required to execute this failover test.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Initiate the manual failover command via gcloud; 2) Poll and confirm that the operation state reaches DONE; 3) Validate application connectivity and write operations in the failover zone; 4) Execute a second failover command to perform failback to the primary zone.
Testing High Availability (HA) failover in Cloud SQL requires a controlled sequence: initiating the failover using `gcloud sql instances failover`, monitoring the operation status until `DONE` using `gcloud sql operations describe`, validating application database operations in the failover zone, and finally triggering a second failover command to return the instance back to its original primary zone.

Step-by-Step Solution

1
Issue manual failover trigger
Cloud SQL initiates an explicit failover operation from the primary zone to the secondary standby zone.
The failover command `gcloud sql instances failover` explicitly commands GCP to serve traffic from the standby replica.
2
Monitor operational status
Operation status transitions from RUNNING to DONE.
Cloud SQL operations are asynchronous. Verification prevents testing against an instance during DNS propagation or state transition.
3
Perform application validation
Database health, read/write workloads, and connection pools are confirmed operational.
The core objective of a disaster recovery drill is to verify application resilience under secondary zone conditions.
4
Execute failback operation
The instance transitions back to its original primary zone.
To complete the drill cleanly, traffic must be returned to the designated default primary location.

Key Concept

Cloud SQL High Availability Manual Failover and Failback Testing
Question 178Question →

A cloud engineer needs to deploy a custom Virtual Private Cloud (VPC) environment in Google Cloud to host a secure internal application service. Arrange the following deployment steps in the correct logical sequence required to provision the infrastructure, set up IP addressing, enforce access security, and instantiate the workload.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps is: 1) Create the custom-mode VPC network, 2) Provision the custom subnet within the network and region, 3) Configure the ingress firewall rule targeting the specific network tag, and 4) Launch the Compute Engine instance attached to the subnet with the designated network tag.
The deployment sequence follows infrastructure dependency requirements in GCP: top-level VPC networks must be created first, followed by regional subnets within that VPC. Firewall rules belong to the VPC network and reference target network tags. Compute instances are created last because they reference both the subnet (for IP configuration) and network tags (for firewall rule binding).

Step-by-Step Solution

1
Create custom VPC network
The top-level container network `prod-vpc` is created without default subnets.
GCP resource hierarchy requires a parent VPC network to exist before subnets or firewall rules can be attached.
2
Provision custom regional subnet
`backend-subnet` is created inside `prod-vpc` with primary CIDR `10.240.10.0/24` in `us-east4`.
Compute instances require a regional subnet within the VPC to allocate network interface internal IP addresses.
3
Create firewall rule with target tags
Ingress firewall rule `allow-backend-internal` is established in `prod-vpc` bound to tag `backend-app`.
Defining network security controls prior to instance creation enforces zero-trust best practices and prevents unauthorized exposure during boot.
4
Deploy VM instance with subnet binding and network tags
Instance `backend-vm-1` is launched in `us-east4-a` connected to `backend-subnet` with tag `backend-app`.
The instance depends on the existing subnet for IP assignment and inherits ingress permissions via its applied network tag.

Key Concept

Dependency ordering for GCP VPC custom networking, regional subnet allocation, tag-based firewall policies, and VM provisioning.
Estimated Time:2m 0s
Question 179Question →

A cloud engineer needs to deploy a Python microservice as a Cloud Functions (2nd gen) function triggered by messages published to a Cloud Pub/Sub topic. The deployment must adhere to least-privilege security by utilizing a dedicated user-managed service account instead of the default compute service account. Arrange the following deployment tasks in the correct chronological order from start to finish.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with enabling required GCP service APIs, followed by creating the custom service account, binding the necessary IAM roles to that service account, executing the `gcloud functions deploy` command with the Pub/Sub trigger and service account flags, and finally publishing a test message to the Pub/Sub topic to verify execution.
The correct order follows the standard Cloud GCP resource dependency lifecycle: baseline API enablement must precede resource creation. Next, the execution identity (service account) must be created and granted necessary permissions prior to deployment so that the runtime environment is properly secured. The `gcloud functions deploy` command attaches the custom service account and provisions the Eventarc Pub/Sub trigger. Finally, triggering a test Pub/Sub message verifies that the deployed architecture functions end-to-end.

Step-by-Step Solution

1
Enable required project APIs
Cloud Functions, Cloud Build, Eventarc, and Pub/Sub APIs are active in the project.
Resource creation and deployment commands will fail if underlying service APIs are disabled.
2
Create user-managed Service Account
A dedicated identity is created for function runtime execution.
Enforces least-privilege identity instead of relying on default primitive service accounts.
3
Assign IAM roles to the Service Account
The identity receives specific required permissions for downstream service integration.
Permissions must exist before the function attempts to execute code requiring access.
4
Deploy Cloud Function (2nd gen) with flags
The Cloud Function and Eventarc Pub/Sub trigger subscription are provisioned.
`gcloud functions deploy` links the code, trigger topic, and execution identity.
5
Publish test event to Pub/Sub topic
Cloud Function execution is triggered and validated via logs.
End-to-end event pipeline testing can only take place after infrastructure provisioning is complete.

Key Concept

Deploying 2nd gen Cloud Functions with Pub/Sub Event Triggers and Custom Service Accounts
Question 180Question →

A cloud engineer needs to deploy a primary Cloud SQL for MySQL database instance with private IP connectivity in a custom VPC network, enable binary logging, and provision a cross-region read replica in a secondary region. Arrange the steps in the correct operational sequence to complete this deployment.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: 1) Reserve an internal IP address range for private services in the custom VPC network, 2) Establish a VPC peering connection to Google Services, 3) Create the primary Cloud SQL instance with private IP and binary logging enabled, and 4) Provision the cross-region read replica referencing the primary instance.
The correct deployment sequence starts by allocating an internal IP range in the custom VPC network for Google Services, followed by establishing VPC peering via Service Networking. Next, the primary Cloud SQL instance is created with private IP (--no-assign-ip and --network) and binary logging enabled (--enable-bin-log). Finally, the cross-region read replica is created by specifying the primary instance as its master.

Step-by-Step Solution

1
Allocate a named IP range in the custom VPC network using gcloud compute addresses create.
An IP block is allocated for Service Networking inside the VPC.
Private Service Access requires a dedicated internal IP address block allocated prior to establishing the peering connection.
2
Create the private connection using gcloud services vpc-peerings connect.
VPC peering is established between the custom VPC and the Google Service Producer network.
Cloud SQL private instances communicate with the VPC via this VPC peering connection.
3
Deploy the primary Cloud SQL MySQL instance using gcloud sql instances create with --network, --no-assign-ip, and --enable-bin-log.
The primary Cloud SQL instance is provisioned with private IP in the primary region.
Binary logging on the master instance is mandatory to enable point-in-time recovery and replication to read replicas.
4
Create the read replica using gcloud sql instances create specifying --master-instance-name and the target secondary --region.
The read replica is provisioned in the secondary region and begins replicating data from the primary instance.
Replicas require an existing active primary database instance that supports replication.

Key Concept

Deploying Cloud SQL Instances with Private IP and Cross-Region Read Replicas
PreviousPage 9 / 14Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin