All practice questions

262 questions

All types1,591 Multiple choice816 Multiple select491 Numeric12 Matching10 Ordering262

What is the correct sequence of steps to configure a Kubernetes Service Account (KSA) to impersonate a Google Cloud Service Account (GSA) using GKE Workload Identity?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with creating the Google Cloud Service Account with required permissions, followed by creating the Kubernetes Service Account in GKE, binding the Workload Identity User IAM role on the GSA to the KSA, and finally annotating the KSA with the GSA email address.

Configuring Workload Identity follows a logical top-down sequence: first provision the GCP-side Service Account with appropriate permissions, next create the GKE Kubernetes Service Account, then grant the roles/iam.workloadIdentityUser IAM role on the GSA to the KSA, and lastly annotate the KSA with the GSA email address so the GKE metadata server can exchange Kubernetes tokens for Google Cloud credentials.

Step-by-Step Solution

Provision the target Google Cloud Service Account (GSA)

GSA is created with the required GCP IAM permissions for backend resource access.

Before identity delegation can occur, the cloud-level service account with target permissions must exist.

Provision the Kubernetes Service Account (KSA)

KSA is available inside the GKE namespace.

Workloads in GKE execute under a Kubernetes identity, which requires a KSA manifest.

Configure the IAM Workload Identity binding

The GSA trusts the KSA principal under roles/iam.workloadIdentityUser.

This establishes the GCP security boundary permission allowing the GKE pod identity to act as the cloud service account.

Annotate the KSA manifest

The KSA metadata includes key iam.gke.io/gcp-service-account set to the GSA email.

The GKE metadata server reads this annotation to issue short-lived GCP tokens to pods running under this KSA.

Key Concept

GKE Workload Identity Configuration Sequence

Question 182Question →

An engineering team is deploying an application to Google Kubernetes Engine (GKE) that requires access to a Google Cloud Storage bucket. To adhere to security best practices, the team decides to use Workload Identity instead of exporting static service account keys. What is the correct sequence of steps to configure Workload Identity binding between the Kubernetes Service Account (KSA) and the GCP Service Account (GSA)?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order to configure Workload Identity is: First, create the GCP Service Account with resource permissions. Second, create the Kubernetes Service Account in the cluster namespace. Third, bind the Workload Identity User role on the GCP Service Account to the Kubernetes Service Account principal. Fourth, annotate the Kubernetes Service Account with the GCP Service Account email. Fifth, configure and deploy the Pod using the annotated Kubernetes Service Account.

The configuration of Workload Identity requires creating the GCP Service Account with access permissions and the Kubernetes Service Account in the cluster, granting the roles/iam.workloadIdentityUser IAM role on the GCP Service Account to the Kubernetes Service Account member URI, annotating the Kubernetes Service Account with the GCP Service Account email, and finally attaching the annotated Kubernetes Service Account to the Pod definition.

Step-by-Step Solution

Provision GCP Service Account

GCP Service Account exists with IAM bucket permissions.

Resource permissions must belong to a Google Cloud identity that will be impersonated.

Provision Kubernetes Service Account

KSA created in GKE namespace.

Workload Identity maps a specific Kubernetes Service Account to a GCP Service Account.

Allow KSA to impersonate GSA via IAM

roles/iam.workloadIdentityUser assigned to serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME].

Without this IAM role assignment, GCP IAM blocks the Workload Identity impersonation attempt.

Annotate KSA with GSA email

KSA includes annotation iam.gke.io/gcp-service-account=GSA_EMAIL.

The annotation tells the GKE Metadata Server which GSA tokens to issue when the workload requests credentials.

Deploy Pod with KSA reference

Pod runs using the annotated service account and obtains GCP access transparently.

Setting serviceAccountName in the Pod spec ties the pod execution to the configured Workload Identity mapping.

Key Concept

Workload Identity allows GKE workloads to impersonate a GCP Service Account by binding the roles/iam.workloadIdentityUser role to the Kubernetes Service Account identity string and annotating the KSA.

Question 183Question →

A Cloud Engineer needs to migrate a local Terraform state file to a Google Cloud Storage (GCS) remote backend for a production deployment. Place the steps required to complete this migration in the correct execution order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To migrate local Terraform state to a GCS remote backend, first provision the GCS bucket with versioning enabled, then define the backend "gcs" block in the Terraform code, run `terraform init` to reconfigure the backend, and lastly confirm the prompt to copy local state to GCS.

The correct sequence starts by provisioning the GCS storage bucket with object versioning enabled. Next, the engineer updates the Terraform code with a `backend "gcs"` block pointing to the bucket. Then, running `terraform init` prompts Terraform to recognize the new remote backend. Finally, confirming the migration prompt transfers existing local state into the GCS bucket.

Step-by-Step Solution

Create the GCS bucket with Object Versioning enabled.

A destination GCS bucket is ready to safely store state files with historical recovery capability.

Terraform cannot auto-create the remote backend bucket during backend initialization.

Define the backend "gcs" block in the Terraform configuration.

The Terraform root module is configured to point to the created GCS bucket.

Terraform requires explicit backend parameters to locate where state should be persisted.

Execute `terraform init`.

Terraform detects the change from local backend to GCS backend.

Re-initialization triggers the backend reconfiguration workflow in Terraform CLI.

Approve the state migration prompt.

Existing local state is securely uploaded to the GCS bucket and local state is updated.

Confirming ensures state continuity so existing managed infrastructure resources are not lost or re-created.

Key Concept

Terraform Remote State Migration to Google Cloud Storage Backend

Question 184Question →

A Cloud Engineer needs to import data into a Cloud SQL for MySQL instance from a SQL dump file stored in a Google Cloud Storage bucket using the gcloud command-line interface. Which sequence of steps represents the correct procedure to execute this operation successfully?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins by retrieving the Cloud SQL instance service account identity, granting that service account the Storage Object Viewer IAM role on the GCS bucket, running the gcloud sql import sql command, and finally verifying the asynchronous operation status.

To import data into Cloud SQL from Cloud Storage, the Cloud SQL instance's managed service account must first be retrieved and granted read permissions on the bucket. Only after IAM permissions are in place can the gcloud sql import sql command succeed, followed by checking operation status for completion.

Step-by-Step Solution

Retrieve Cloud SQL Service Account Identity

Obtained the auto-generated service account email address for the Cloud SQL instance.

Cloud SQL accesses Google Cloud Storage using its own dedicated service account identity rather than user credentials.

Assign IAM Bucket Permissions

Assigned roles/storage.objectViewer to the Cloud SQL service account on the destination Cloud Storage bucket.

Cloud SQL requires read access to the GCS object to process the SQL dump during import.

Run Database Import Command

Initiated the import job via gcloud sql import sql INSTANCE_NAME gs://BUCKET_NAME/DUMP_FILE.sql.

This tells Cloud SQL to read the dump file from GCS and load the data into the database instance.

Verify Operation Status

Confirmed that the import operation reached DONE status without errors.

Import operations run asynchronously in GCP, so verification confirms the database state is updated.

Key Concept

Cloud SQL Data Import Procedures and IAM Authorization

Question 185Question →

A Cloud Engineer needs to add an additional non-boot persistent disk to an existing running Linux Compute Engine VM instance named `analytics-vm`. The persistent disk `log-data-disk` has already been created in the same zone. Arrange the administrative steps in the correct chronological sequence to attach, format, mount, and configure persistent mounting across reboots for this disk.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with attaching the disk via gcloud, SSHing into the instance to identify the OS device path, formatting the raw disk with ext4, creating a directory to mount the filesystem, and appending an entry with the disk's UUID to /etc/fstab for reboot persistence.

To successfully provision and mount a secondary persistent disk on Compute Engine, infrastructure-level attachment (`gcloud compute instances attach-disk`) must happen first. Once attached, an SSH session allows inspecting device paths inside the Linux kernel, formatting the raw device with `mkfs.ext4`, mounting it to a newly created mount point directory, and lastly obtaining its UUID via `blkid` to update `/etc/fstab` so the mount configuration persists across VM reboots.

Step-by-Step Solution

Attach the persistent disk to the VM instance using gcloud

The block storage device `log-data-disk` is connected to the `analytics-vm` virtual machine.

Infrastructure level attachment must occur before the VM operating system can detect or manage the disk.

SSH into the VM instance and identify the attached disk device node

The block device identifier (such as `/dev/disk/by-id/google-log-data-disk`) is determined inside Linux.

Operating system utilities require the exact device node path to perform formatting and mounting operations.

Format the raw disk device with the ext4 filesystem

An ext4 filesystem structure is initialized on the raw block device.

Unformatted block storage must be initialized with a supported filesystem structure before storing files.

Create a target directory and mount the filesystem

The disk is mounted and becomes accessible at `/mnt/disks/log-data`.

Mounting attaches the formatted filesystem to a directory point in the Linux file system hierarchy.

Retrieve the UUID with blkid and update /etc/fstab

An `/etc/fstab` entry is added referencing the disk's UUID.

Manual mount commands are non-persistent; configuring `/etc/fstab` ensures the operating system automatically mounts the volume after a reboot.

Key Concept

Attaching, formatting, mounting, and configuring reboot persistence for secondary Compute Engine disks

Question 186Question →

A cluster administrator needs to perform a manual control plane and worker node version upgrade on a Google Kubernetes Engine (GKE) Standard cluster named `prod-analytics-cluster` located in region `us-central1`. Automatic node upgrades are disabled for this cluster due to customized maintenance windows. What is the correct sequence of operational steps to upgrade the control plane first, verify stability, and then safely upgrade the node pool?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins by checking available cluster versions with `gcloud container get-server-config`, upgrading the control plane master using `gcloud container clusters upgrade` with the `--master-only` flag, verifying control plane health, upgrading the node pool using `gcloud container node-pools upgrade`, and finally verifying node readiness using `kubectl get nodes`.

The correct order follows GCP best practices for manual GKE cluster maintenance: first query valid versions (`gcloud container get-server-config`), then upgrade the control plane (`gcloud container clusters upgrade --master-only`), confirm control plane health, upgrade worker node pools (`gcloud container node-pools upgrade`), and verify node health with `kubectl get nodes`.

Step-by-Step Solution

Query available GKE server versions

Identified valid target Kubernetes versions supported in `us-central1`

Before triggering upgrades, valid target versions must be verified against regional GKE availability.

Initiate control plane upgrade

Control plane upgraded using `--master-only`

Kubernetes version compatibility rules mandate that GKE control planes must be upgraded before worker node pools.

Verify control plane status

Control plane state confirmed as `RUNNING`

Ensures API server availability and control plane health before starting rolling updates on worker nodes.

Upgrade worker node pool

Node pool upgraded to target version using `gcloud container node-pools upgrade`

Node pools are upgraded after the master control plane is stable.

Validate cluster node health

All nodes return `Ready` status on the updated version via `kubectl get nodes`

Final validation ensures all workloads transitioned cleanly and all nodes operate correctly on the new release.

Key Concept

GKE Cluster and Node Pool Manual Upgrade Order

Question 187Question →

A Cloud Engineer needs to deploy a custom microservice from local source code to Google Cloud Run and secure it so that only a specific client service account can invoke it. Arrange the steps in the correct sequential order from initial image creation to post-deployment verification.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: 1. Build and push the container image to Artifact Registry using gcloud builds submit. 2. Deploy the container image to Cloud Run with unauthenticated access disabled. 3. Bind the Cloud Run Invoker role (roles/run.invoker) to the client service account. 4. Verify access by invoking the service endpoint with an identity token.

Deployment workflow follows a strict chronological order: First, the container image must be built from source code and pushed to Artifact Registry so that Cloud Run can access the container bits. Second, the Cloud Run service is created from this container image with unauthenticated invocations disabled. Third, once the service resource exists, an IAM policy binding is attached to grant the specific client service account the `roles/run.invoker` role. Fourth, the deployment is validated by sending an authenticated request using an identity token.

Step-by-Step Solution

Package and register the deployment artifact

A container image stored in Artifact Registry

Cloud Run requires a pre-built container image in a reachable container registry before deployment can commence.

Instantiate the Cloud Run service resource

A running, private Cloud Run service with a designated HTTPS URL

Deploying the service creates the target resource needed to attach service-specific IAM access policies.

Apply IAM invoker permissions

The client service account is explicitly authorized to invoke the endpoint

Adding the `roles/run.invoker` role via `gcloud run services add-iam-policy-binding` restricts invocation to the authorized identity.

Perform end-to-end verification

HTTP 200 OK response from the Cloud Run service endpoint

Sending an HTTP request with an identity token generated for the authorized service account confirms that authentication and authorization function properly.

Key Concept

Deploying containerized microservices to Cloud Run and managing service-level IAM authentication and invoker roles.

Question 188Question →

A cloud engineer needs to deploy a Cloud SQL PostgreSQL instance named 'prod-db' in a custom Virtual Private Cloud (VPC) named 'app-vpc'. Security policies require that the database is accessible strictly using a Private IP address without any public IP assigned. What is the correct sequence of steps required to set up Private Services Access and provision the instance?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps is: 1) Reserve an internal IP range in the VPC using the VPC_PEERING purpose flag, 2) Establish a private connection to Google services via service peering, 3) Provision the Cloud SQL instance specifying the VPC network and disabling public IP assignment, and 4) Connect from an internal VM within the VPC to initialize database schemas.

To deploy a Cloud SQL instance with Private IP, Google Cloud requires setting up Private Services Access first. This involves reserving an internal IP address block in the VPC network (using purpose=VPC_PEERING), creating a VPC peering connection to the service producer network using gcloud services peered-connections create, provisioning the database instance with the --network and --no-assign-ip flags, and finally accessing the database from internal compute instances within the same VPC.

Step-by-Step Solution

Allocate an IP range for VPC peering.

A dedicated IP range is reserved for Private Services Access in 'app-vpc'.

Google Cloud requires an allocated IP range before a VPC peering connection can be configured for managed services.

Create the private services connection.

Peering is established between 'app-vpc' and Google's service producer VPC network.

Cloud SQL Private IP relies on VPC Network Peering established through the Service Networking API.

Create the Cloud SQL instance with private IP only.

The Cloud SQL instance is provisioned into the peered service network with an IP from the allocated range.

The --network flag binds the instance to the VPC, while --no-assign-ip prevents public IP exposure.

Access and configure the database from an internal compute resource.

Database schemas and users are configured securely over private IP connectivity.

Post-provisioning configuration can only occur once the database instance is fully deployed and accessible on the VPC.

Key Concept

Configuring Private IP Connectivity for Cloud SQL using Private Services Access

Question 189Question →

Your enterprise security policy strictly forbids downloading exportable service account keys. You are tasked with provisioning a Compute Engine virtual machine instance in `prod-app-project` that requires read access to a BigQuery dataset located in `prod-analytics-project`. Arrange the administrative actions in the correct chronological sequence to configure and attach a custom service account under least-privilege best practices.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins by creating the custom service account in the source project, granting cross-project dataset access to that identity, assigning the Service Account User role to the provisioning principal, and finally attaching the service account during VM creation.

Establishing a keyless cross-project workload identity requires sequential execution: creating the service account identity in the home project, granting the service account resource-level access in the destination project, delegating Service Account User permissions to the deployment principal, and finally binding the service account to the Compute Engine instance.

Step-by-Step Solution

Create the service account in the local project using gcloud IAM service-accounts create.

A unique service account identity (email ID) is established in `prod-app-project`.

You cannot grant roles or delegate attachment privileges to an identity before creating it.

Bind the target dataset access role in the remote project to the new service account email.

The service account gains granular permission (`roles/bigquery.dataViewer`) on the resource in `prod-analytics-project`.

Configuring access prior to workload deployment ensures immediate operational readiness upon instance startup.

Grant `roles/iam.serviceAccountUser` on the service account to the deploying user or pipeline identity.

The deployment principal receives explicit permission to impersonate/attach the service account to Compute Engine resources.

Without `roles/iam.serviceAccountUser`, Compute Engine instance creation specifying this service account will be blocked by IAM authorization checks.

Deploy the Compute Engine instance specifying the `--service-account` flag in `prod-app-project`.

The virtual machine runs under the credentials of the dedicated custom service account keylessly via metadata server integration.

Attaching the service account at instance creation ensures keyless identity metadata propagation to the workload.

Key Concept

Cross-Project Service Account Management and Compute Engine IAM Attachment

Question 190Question →

A system administrator needs to recover a Compute Engine VM instance whose primary boot disk has suffered operating system corruption. The administrator has access to a recent, uncorrupted disk snapshot. What is the correct sequence of steps to restore the instance to operational status using the gcloud CLI while preserving the VM instance identity and IP configurations?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence requires stopping the instance, creating a persistent disk from the snapshot, detaching the corrupted boot disk, attaching the newly created disk with the --boot flag, and finally starting the instance.

To successfully replace a corrupted boot disk on an existing Compute Engine VM instance, the instance must first be stopped to allow disk modification. Next, a persistent disk must be instantiated from the snapshot because snapshots cannot be mounted directly. The corrupted disk is then detached, the restored disk is attached with the --boot flag, and the instance is started.

Step-by-Step Solution

Stop the affected Compute Engine VM instance.

The instance state transitions to TERMINATED.

Compute Engine requires the instance to be stopped before modifying or detaching its root boot disk.

Provision a new persistent disk from the snapshot.

A new persistent disk is populated with data from the target snapshot.

Snapshots cannot be attached directly to instances; they must first be converted into a Persistent Disk resource.

Detach the corrupted persistent boot disk.

The corrupted disk is disassociated from the VM instance.

A VM instance can only have one primary boot disk attached at any given time.

Attach the new persistent disk as the boot disk.

The new persistent disk becomes the designated boot disk for the VM.

Specifying the --boot flag tells Compute Engine to configure BIOS/UEFI boot properties for this attached disk.

Start the Compute Engine VM instance.

The VM boots successfully into the restored operating system state.

Powering on the VM initiates the boot sequence using the newly attached boot disk.

Key Concept

Compute Engine Boot Disk Recovery and Lifecycle Management

Question 191Question →

You need to provision a Compute Engine virtual machine that requires access to Cloud Storage, following Google Cloud identity best practices. Arrange the administrative steps in the correct logical sequence to create, grant permissions to, and assign a custom service account to the instance.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order is: 1) Create the dedicated service account, 2) Grant the required resource IAM roles to the service account, 3) Grant the deployment identity the Service Account User role, 4) Create the Compute Engine instance with the service account attached.

The correct workflow begins by creating the service account identity, defining its resource access permissions next, delegating usage rights to the deployer third, and attaching the service account to the VM instance during creation fourth.

Step-by-Step Solution

Create the Service Account identity

The service account identity is established in the project.

You must create the service account identity before granting roles or attaching it to resources.

Assign IAM roles to the Service Account

Service account gains specific resource permissions.

Following least privilege, assign predefined roles directly to the service account before running workloads.

Grant Service Account User role to the deployer identity

Deployer receives authorization to bind the service account to resources.

Attaching a service account to a compute resource requires the roles/iam.serviceAccountUser role on the target service account.

Attach the Service Account during Compute Engine VM creation

VM instance runs using the identity of the custom service account.

The compute instance consumes the credentials of the assigned service account without requiring exported static JSON keys.

Key Concept

Sequential lifecycle of creating, granting permissions to, delegating use of, and attaching service accounts in Google Cloud.

Question 192Question →

A Kubernetes application running on a Google Kubernetes Engine (GKE) cluster requires secure access to objects in a Google Cloud Storage bucket. To follow security best practices and avoid using downloadable service account key files, an engineer must configure Workload Identity. In what sequence should the engineer execute the configuration steps to enable identity delegation for the application?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is to create the Google Cloud Service Account with bucket access permissions first, grant the Workload Identity User role to the Kubernetes Service Account on the GCP Service Account next, annotate the Kubernetes Service Account with the GCP Service Account email third, and finally deploy the Pod configured with the annotated Kubernetes Service Account.

The proper administrative sequence requires provisioning the GCP service account and assigning target bucket access, granting the `roles/iam.workloadIdentityUser` role to the KSA member on that GCP service account, annotating the Kubernetes service account with the GCP service account email, and finally binding the pod spec to the annotated Kubernetes service account.

Step-by-Step Solution

Provision the Google Cloud Service Account (GSA) and assign resource-level IAM roles.

A dedicated GCP identity exists with permissions to access Cloud Storage.

Before delegating identity, the destination GCP service account must exist and hold the required permissions.

Bind the Kubernetes Service Account (KSA) identity to the GSA via the `roles/iam.workloadIdentityUser` role.

GCP IAM trusts the specific KSA principal in the GKE Workload Identity pool to impersonate the GSA.

Impersonation requires explicit permission on the GSA resource granted to the KSA member string.

Annotate the KSA resource in Kubernetes with `iam.gke.io/gcp-service-account=GSA_EMAIL`.

The GKE control plane and metadata server link the KSA to the GSA email.

The GKE cluster must know which GSA email address to negotiate short-lived tokens for when the pod communicates with GCP APIs.

Specify `serviceAccountName: KSA_NAME` in the Pod deployment manifest.

The running pod assumes the annotated KSA identity and seamlessly authenticates to GCP.

The application container relies on the attached KSA to leverage the GKE Metadata Server for keyless authentication.

Key Concept

GKE Workload Identity configuration sequence

Question 193Question →

What is the correct sequential order of administrative steps to configure GKE Workload Identity so that a Pod running in a Kubernetes namespace can access Google Cloud APIs using a dedicated Google Service Account?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by creating the Google Service Account (GSA) with required GCP resource permissions, followed by creating the Kubernetes Service Account (KSA) in the cluster namespace, then adding the IAM policy binding to grant roles/iam.workloadIdentityUser to the KSA on the GSA, and finally annotating the KSA with the GSA email address.

To successfully establish GKE Workload Identity, the GCP service account (GSA) and Kubernetes service account (KSA) must first exist. The GSA must be configured with an IAM binding granting roles/iam.workloadIdentityUser to the KSA principal (`serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]`). Lastly, the KSA in Kubernetes must be annotated with `iam.gke.io/gcp-service-account=GSA_EMAIL` so the GKE metadata server injects short-lived credentials into Pods running with that KSA.

Step-by-Step Solution

Provision target Google Service Account (GSA)

GSA is created in Google Cloud IAM and assigned resource-level roles (e.g., storage.objectViewer).

The GSA provides the Google Cloud permissions needed by the application.

Provision Kubernetes Service Account (KSA)

KSA is defined in the target Kubernetes namespace within the GKE cluster.

The KSA establishes the in-cluster identity for the running workload.

Establish IAM binding for Workload Identity

The GSA allows the KSA member principal to assume its identity via the roles/iam.workloadIdentityUser IAM role.

Without this IAM binding, Kubernetes service accounts are not authorized to impersonate the GCP service account.

Annotate the KSA

The metadata annotation iam.gke.io/gcp-service-account is set on the KSA pointing to the GSA email.

The GKE metadata server reads this annotation to issue temporary GCP identity tokens to Pods using this KSA.

Key Concept

Configuring GKE Workload Identity requires creating both Google and Kubernetes service accounts, granting roles/iam.workloadIdentityUser to link the KSA to the GSA, and annotating the KSA with the GSA email address.

Question 194Question →

A systems administrator needs to deploy a secure workload in Google Cloud Platform using the `gcloud` CLI. The design requires a custom-mode Virtual Private Cloud network named `prod-vpc`, a dedicated regional subnet named `prod-subnet-uscentral1` ( $10.2.0.0/24$ ), an ingress firewall rule permitting SSH traffic to instances with a specific network tag, and a Compute Engine VM instance associated with this configuration. In what chronological order must these administrative commands be executed?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with creating the custom VPC network (`prod-vpc`), followed by provisioning the custom subnet (`prod-subnet-uscentral1`) within that network. Next, the ingress firewall rule (`allow-prod-ssh`) is created on the VPC network targeting the `ssh-enabled` tag. Finally, the VM instance (`prod-app-vm`) is created referencing the subnet and applying the target tag.

Google Cloud infrastructure management follows strict parent-child resource dependencies. A custom VPC network must be created first to act as the parent container. Next, regional subnets must be allocated within that network to provide IP addresses. Ingress firewall rules are defined at the VPC network level using target tags. Finally, Compute Engine instances are launched into the existing subnet and tagged to inherit the firewall rules.

Step-by-Step Solution

Create the custom-mode VPC network.

Instantiates `prod-vpc` without automatically generating default subnets across regions.

In custom-mode VPCs, subnets cannot be created until the parent VPC network exists.

Create the regional custom subnet.

Allocates IP range

10.2.0.0/24

in `us-central1` associated with `prod-vpc`.

Compute Engine instances in a custom VPC require an active subnet in their deployment zone/region to receive IP configuration.

Configure the VPC ingress firewall rule with target tags.

Applies a network rule to `prod-vpc` allowing TCP port 22 ingress for instances carrying the `ssh-enabled` tag.

Firewall rules are associated with the VPC network and should be established prior to or alongside VM deployment so security parameters are defined.

Deploy the Compute Engine virtual machine instance.

Launches `prod-app-vm` in `us-central1-a`, attached to `prod-subnet-uscentral1` and tagged with `ssh-enabled`.

The instance command explicitly references both the pre-existing subnet name and the network tag evaluated by the firewall rule.

Key Concept

Resource dependencies and execution ordering when provisioning custom VPC networks, subnets, firewall rules, and instances via gcloud CLI.

Question 195Question →

A Cloud Engineer is tasked with establishing passwordless, keyless authentication for a pod running in a Google Kubernetes Engine (GKE) cluster to query BigQuery tables. The team has mandated using GKE Workload Identity following Google Cloud best practices. In what precise sequence should the engineer execute the configuration steps to enable this access?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with enabling Workload Identity on the GKE cluster, creating and granting permissions to the Google Service Account (GSA), creating the Kubernetes Service Account (KSA) in the namespace, granting the Workload Identity User role on the GSA to the KSA member URI, and finally annotating the KSA with the GSA email.

The proper deployment flow for GKE Workload Identity requires infrastructure enablement first (enabling Workload Identity on the cluster), establishing both identity endpoints (GSA with BigQuery permissions and KSA in the namespace), authorizing the relationship in IAM (granting roles/iam.workloadIdentityUser on the GSA to the KSA principal URI), and completing the in-cluster mapping (annotating the KSA with the GSA email).

Step-by-Step Solution

Enable cluster Workload Identity pool

GKE configures the Workload Identity pool URI (PROJECT_ID.svc.id.goog) for pod identity translation.

Without enabling the feature on the cluster, GKE Metadata Server cannot intercept token requests.

Provision GSA with target IAM roles

The GSA possesses GCP resource access rights (BigQuery Data Viewer).

Identity delegation requires an existing target GCP identity that holds the necessary workload permissions.

Provision KSA within the Kubernetes namespace

A namespace-scoped KSA object is available in Kubernetes.

The KSA forms the subject reference in the Workload Identity pool URI.

Bind roles/iam.workloadIdentityUser on GSA to KSA identity URI

GCP IAM authorizes the KSA principal (serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA]) to impersonate the GSA.

IAM policy must explicitly allow the external Kubernetes service account identity to assume the GSA identity.

Annotate KSA with iam.gke.io/gcp-service-account key

Pods using this KSA automatically receive GSA tokens from the GKE Metadata Server.

The annotation triggers the cluster metadata service to map pod calls to the designated GSA.

Key Concept

GKE Workload Identity binding procedure

Question 196Question →

A cloud engineer needs to safely transition an existing Google Cloud Storage bucket from fine-grained access control to Uniform Bucket-Level Access. What is the correct sequence of steps to complete this transition without disrupting user access?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: first audit existing object ACLs, next grant equivalent IAM roles to those principals, and finally enable Uniform Bucket-Level Access on the bucket.

Migrating to Uniform Bucket-Level Access requires discovering existing ACL dependencies first, provisioning equivalent IAM permissions to affected users next, and lastly enabling Uniform Bucket-Level Access on the bucket to enforce IAM-only access control.

Step-by-Step Solution

Audit current permissions

Identify all principals dependent on object ACLs.

Prevents accidental access loss when ACL support is removed.

Assign IAM roles

Ensure principals have required access via Cloud IAM.

Uniform Bucket-Level Access relies entirely on IAM permissions for authorization.

Enforce Uniform Bucket-Level Access

Disables legacy ACL evaluation for all objects in the bucket.

Enforces unified security management across all bucket objects.

Key Concept

Migration workflow from legacy ACLs to Uniform Bucket-Level Access (UBLA)

Question 197Question →

An administrator needs to perform scheduled offline maintenance on a standalone Compute Engine instance named `app-server-1`. The administrator must upgrade its machine type to `e2-standard-4` and attach a newly provisioned persistent disk named `log-disk-1` for additional log storage using the `gcloud` CLI. What is the correct sequence of steps to perform this maintenance operation?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: 1) Stop the VM instance (`gcloud compute instances stop`), 2) Update the machine type (`gcloud compute instances set-machine-type`), 3) Create the persistent disk (`gcloud compute disks create`), 4) Attach the persistent disk (`gcloud compute instances attach-disk`), and 5) Start the VM instance (`gcloud compute instances start`).

Changing a Compute Engine VM instance's machine type requires the instance to be in the STOPPED/TERMINATED state. Therefore, stopping the VM is the mandatory first step. Once stopped, the machine type is reconfigured. Next, creating the persistent disk resource must occur before attaching it to the instance. Finally, attaching the disk and starting the VM instance completes the maintenance workflow cleanly.

Step-by-Step Solution

Stop the VM instance.

The VM enters the TERMINATED state, releasing hardware resources and allowing hardware property changes like machine type.

Machine types cannot be modified on running Compute Engine instances.

Execute gcloud compute instances set-machine-type.

The VM configuration is updated to e2-standard-4.

Reconfiguring instance specs must occur while the VM is stopped.

Create the persistent disk resource.

The persistent disk log-disk-1 is created in the target zone.

The disk must exist in GCP before it can be attached to an instance.

Attach the disk using gcloud compute instances attach-disk.

The disk log-disk-1 is mapped to app-server-1.

The disk attachment must be configured before launching the application workload.

Start the VM instance.

The instance boots up with 4 vCPUs and the secondary persistent disk attached.

Brings the application back online following maintenance.

Key Concept

Managing Compute Engine VM Instance Lifecycle and Disk Operations via gcloud CLI

Estimated Time:1m 30s

Question 198Question →

An organization wants to configure a GitHub Actions CI/CD pipeline to deploy Cloud Run services without exporting long-lived service account JSON keys. What is the correct sequential order of steps to establish Workload Identity Federation and service account impersonation for this setup?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with creating the Workload Identity Pool and Provider, followed by creating the target GCP Service Account, granting the `roles/iam.workloadIdentityUser` role to the GitHub repository identity on that service account, and lastly updating the workflow step to request short-lived credentials.

Establishing Workload Identity Federation requires creating the federated infrastructure (Pool & Provider), defining the target GCP identity (Service Account), binding the `roles/iam.workloadIdentityUser` role to the external identity principal, and lastly referencing these resources in the pipeline execution workflow.

Step-by-Step Solution

Set up the Workload Identity Pool and Provider in GCP

Establishes federated trust between Google Cloud IAM and GitHub's OpenID Connect (OIDC) issuer.

Google Cloud needs a registered pool and provider to validate incoming OIDC assertion tokens from external workloads.

Provision the target GCP Service Account with Cloud Run deployment roles

Creates the GCP identity holding minimal privileges required for the deployment.

The external workload cannot execute GCP commands without an authorized target service account to impersonate.

Bind `roles/iam.workloadIdentityUser` on the Service Account to the GitHub repository principal

Authorizes the specific external repository identity to assume the target service account.

Impersonation via Workload Identity Federation requires explicit authorization using the Workload Identity User role on the target service account.

Configure the GitHub Actions workflow to exchange OIDC tokens for GCP credentials

Enables keyless, short-lived authentication for deployment steps.

The pipeline workflow step uses the official auth action to exchange GitHub tokens for temporary Google Cloud access tokens.

Key Concept

Configuring Workload Identity Federation for keyless service account impersonation from external CI/CD pipelines.

Question 199Question →

A Cloud Engineer needs to perform a Point-in-Time Recovery (PITR) for a Cloud SQL instance after a developer accidentally dropped a critical database table. What is the correct operational sequence of steps to safely restore the database state and transition application traffic to the restored instance?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts by identifying the exact pre-corruption timestamp, followed by cloning to a new instance at that timestamp, verifying data integrity on the new instance, and finally updating application connection strings to target the restored instance.

Point-in-Time Recovery (PITR) for Cloud SQL requires first determining the exact point in time prior to data loss. Running the recovery/clone command provisions a new Cloud SQL instance containing data up to that specified moment. Best practice requires verifying data and schema integrity on the newly created instance before updating application connection settings to complete the operational cutover.

Step-by-Step Solution

Identify the target recovery timestamp

Retrieved the exact UTC timestamp prior to the table drop.

PITR requires a specific timestamp boundary to roll back transactional logs.

Restore data to a new Cloud SQL instance using point-in-time cloning

Created a new running Cloud SQL instance with data restored up to the specified moment.

Cloud SQL PITR creates a distinct new target instance, preventing accidental overwrites of existing instance configurations.

Perform database integrity checks

Confirmed that the dropped table exists and contains expected records.

Validation ensures the restored instance is complete and healthy prior to cutover.

Update application database endpoints

Application traffic is successfully redirected to the restored instance.

Modifying connection settings points application services to the verified database endpoint.

Key Concept

Cloud SQL Point-in-Time Recovery (PITR) Operational Workflow

Estimated Time:1m 30s

Question 200Question →

A cloud administration team needs to securely provision a Compute Engine virtual machine instance that automatically executes a startup script stored in a private Google Cloud Storage bucket. Place the operational steps in the correct order to successfully deploy and verify this virtual machine workload.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts by establishing the dedicated IAM service account, storing the startup script in Cloud Storage, binding the Storage Object Viewer role to the service account, provisioning the VM instance configured with the service account and startup-script-url metadata flag, and finally auditing serial port output for execution status.

Securing VM initialization requires setting up identity and access prerequisites before launching compute resources. Creating the service account, staging the script in Cloud Storage, and granting Storage Object Viewer permissions ensures that when `gcloud compute instances create` is run with `--metadata=startup-script-url`, the VM guest environment can successfully authenticate to GCS and download the script during startup. Serial port output inspection completes the workflow by verifying execution logs.

Step-by-Step Solution

Create the custom IAM service account.

Establishes a non-primitive identity for instance authentication following the least privilege principle.

Permissions cannot be bound until the service account identity exists.

Upload the initialization script to Cloud Storage.

Places the script executable in a secure GCS bucket.

Provides a centralized GCS URI path required by the Compute Engine metadata server.

Assign the Storage Object Viewer (roles/storage.objectViewer) role to the service account for the GCS bucket.

Grants read access to the script storage object.

If permissions are granted after VM instantiation, the startup script downloader daemon will fail with a 403 Access Denied error during boot.

Provision the VM using gcloud with the --service-account and --metadata=startup-script-url flags.

Launches the Compute Engine VM instance attached to the custom identity and boot metadata configuration.

Tells Compute Engine startup scripts agent to retrieve and run the script from GCS using the attached service account scope.

Review startup execution via gcloud compute instances get-serial-port-output.

Validates that the startup script completed successfully.

Serial console output captures stdout/stderr of Linux daemon boot scripts for troubleshooting.

Key Concept

Provisioning Compute Engine VMs with custom service accounts and GCS-hosted startup scripts

PreviousPage 10 / 14Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept