Examkin

All practice questions

262 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 141Question →

You need to export a Cloud SQL for MySQL database instance to a Cloud Storage bucket for offline archiving using Google Cloud CLI tools. In what order should you execute the steps to complete this operation?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of operations is: first, create the target Cloud Storage bucket; second, grant the Cloud SQL instance service account write permissions on the bucket; third, execute the `gcloud sql export sql` command.
Exporting data from Cloud SQL to Cloud Storage requires preparing the storage destination prior to initiating the export command. First, the destination bucket must exist. Second, because Cloud SQL performs exports using the instance service account identity, that account must be granted Storage Object Admin permissions on the target bucket. Finally, the user runs `gcloud sql export sql` to execute the export.

Step-by-Step Solution

1
Create the destination Cloud Storage bucket.
A Cloud Storage bucket URI is available for storing the database dump file.
The export command requires a valid destination bucket URI.
2
Assign write permissions on the bucket to the Cloud SQL service account.
The Cloud SQL instance's service account is authorized to write objects to the destination bucket.
Cloud SQL executes export operations asynchronously under its own service account identity, not the identity of the user running gcloud.
3
Execute `gcloud sql export sql`.
The export job is submitted and database contents are written to the specified Cloud Storage object path.
Running the gcloud command initiates the export process after prerequisites are satisfied.

Key Concept

Cloud SQL data export procedures and IAM authorization requirements
Question 142Question →

A Cloud Engineer needs to update an existing Compute Engine Managed Instance Group (MIG) to use a new VM configuration. In which sequence should the engineer execute the administrative steps to perform a zero-downtime rolling update?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence to perform a rolling update on a Managed Instance Group is: 1) Create a new instance template, 2) Update the Managed Instance Group to point to the new template, 3) Initiate a rolling update on the group, and 4) Monitor the update process until completion.
Updating a Managed Instance Group with new software or configurations requires creating a new immutable instance template first. Once the template is created, the Managed Instance Group must be updated to reference the new template. Initiating a rolling update then systematically replaces existing running instances with new instances built from the updated template. Finally, monitoring confirms all instances are successfully updated and passing health checks.

Step-by-Step Solution

1
Create the new instance template
A new Compute Engine instance template resource with the required updates is provisioned in Google Cloud.
Compute Engine Managed Instance Groups rely on immutable templates; any change requires defining a new template.
2
Assign the template to the Managed Instance Group
The target instance template property of the Managed Instance Group is updated.
The group configuration must be updated to specify which template should be used for replacement VMs.
3
Initiate the rolling update
Compute Engine starts replacing existing VM instances with instances created from the new template.
Changing the target template does not automatically replace existing instances; an explicit rolling update must be initiated.
4
Monitor rollout progress
All instances in the group transition to the new version and pass health checks.
Monitoring verifies that the update completed successfully without causing service failure.

Key Concept

Compute Engine Managed Instance Group Rolling Updates
Estimated Time:1m 0s
Question 143Question →

A cloud administrator needs to securely provision a Compute Engine virtual machine instance that uses a Customer-Managed Encryption Key (CMEK) for its boot disk and runs a startup script retrieved from a private Cloud Storage bucket. In what sequence should the administrator execute the administrative tasks to ensure successful VM provisioning and execution under least privilege?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct deployment sequence is: 1) Grant the Compute Engine Service Agent the Cloud KMS Encrypter/Decrypter role. 2) Create a custom service account and assign Storage Object Viewer access to the bucket. 3) Upload the script to the private Cloud Storage bucket. 4) Run 'gcloud compute instances create' passing the CMEK key, custom service account, cloud-platform scope, and metadata URL. 5) Inspect serial port output to verify startup script completion.
The proper administrative workflow follows a logical dependency chain: Infrastructure access permissions must be granted to the service agent for CMEK disk creation first. Next, identity and access for the application payload must be established by creating a dedicated service account and granting storage read access. The payload (startup script) is then uploaded to Cloud Storage. Once prerequisites are in place, the VM instance is created with gcloud referencing the KMS key, service account, and metadata URL. Finally, serial console logs are reviewed to confirm startup script execution.

Step-by-Step Solution

1
Configure KMS access for Compute Engine
Compute Engine service agent gains cryptoKeyEncrypterDecrypter privileges on the specified Cloud KMS key.
Before Google Cloud can create disks encrypted with CMEK, the Google-managed Compute Engine Service Agent must have explicit permission to encrypt and decrypt using the specified KMS key.
2
Configure VM identity and storage permissions
Custom service account is created and granted roles/storage.objectViewer on the target bucket.
The VM instance needs identity credentials capable of downloading objects from the private Cloud Storage bucket.
3
Stage the startup script
Script file is uploaded and accessible at a gs:// URL.
The artifact must exist in Cloud Storage prior to VM creation so the metadata URL points to a valid file.
4
Provision the Compute Engine VM instance
VM instance is created with an encrypted CMEK boot disk and assigned identity.
The gcloud compute instances create command ties together the KMS key, service account, cloud-platform access scope, and startup-script-url metadata.
5
Validate deployment
Startup script logs are verified via serial console output.
Checking serial port 1 output allows administrators to confirm the startup script successfully downloaded and executed without errors.

Key Concept

Compute Engine CMEK disk encryption and secure startup script provisioning sequence
Question 144Question →

An administrator needs to configure a continuous BigQuery billing export for detailed cost analysis across an organization. Arrange the following steps in the correct order to set up the BigQuery billing export from start to finish.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequential order begins with enabling the BigQuery API in the destination project, creating a destination BigQuery dataset, opening the Cloud Billing section for the target billing account, and finally specifying the destination project and dataset under Detailed Cost Export settings.
To set up a BigQuery Billing Export correctly, the destination environment must be prepared first: enable the BigQuery API, create a destination dataset, navigate to Cloud Billing for the target billing account, and finally link the export to the project and dataset.

Step-by-Step Solution

1
Enable the BigQuery API in the target destination project.
The destination project is prepared to manage BigQuery resources.
BigQuery dataset creation and table ingestion require the BigQuery API to be active in the target project.
2
Create a BigQuery dataset in the target project.
A destination container is created to hold incoming daily billing export tables.
Cloud Billing export configuration requires an existing BigQuery dataset as its target.
3
Access Cloud Billing in the Google Cloud console and select the target billing account.
The billing account management interface and export options become accessible.
Billing exports are scoped to the billing account level rather than an individual project.
4
Navigate to Billing export, select the created project and dataset for Detailed Cost Export, and save.
Continuous export of billing records into BigQuery is established.
This final step binds the billing account export pipeline to the prepared BigQuery dataset.

Key Concept

BigQuery Billing Export Setup Workflow
Question 145Question →

Your organization needs to configure Google Cloud DNS to resolve internal service hostnames to private IP addresses within a Virtual Private Cloud (VPC) network. In what order should an engineer perform the administrative steps to establish and validate internal DNS resolution?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: 1) Create the Cloud DNS private managed zone, 2) Authorize the target VPC network, 3) Add the A record set mapping the hostname to the private IP address, and 4) Perform a DNS lookup test from a VM within the authorized VPC network.
The deployment workflow follows a logical dependency chain: First, create the private managed zone to establish the internal DNS namespace. Second, authorize the specific VPC network so instances in that network have permission to query the zone. Third, populate the zone by adding A records mapping service names to internal IP addresses. Fourth, test and verify resolution from a VM located inside the authorized network.

Step-by-Step Solution

1
Initialize the Private Managed Zone
Creates the DNS namespace with private visibility scope in Cloud DNS.
You cannot add DNS records or authorize networks without an existing managed zone.
2
Bind Network Authorization
Associates the VPC network with the private managed zone.
Private DNS zones are invisible and inaccessible to VPC networks until explicitly authorized.
3
Add Resource Record Sets
Maps specific domain hostnames to their corresponding internal IPv4 addresses.
The zone container and authorization must exist before inserting resource records.
4
Validate DNS Resolution
Confirms successful name resolution from internal compute resources.
End-to-end testing requires both the record configuration and authorized network access to be active.

Key Concept

Cloud DNS Private Zone Creation and VPC Network Authorization Sequence
Estimated Time:1m 30s
Question 146Question →

A cloud engineer needs to update a containerized workload deployed on a Google Kubernetes Engine (GKE) cluster. During the deployment image update, the new container version fails readiness checks, causing the rollout to stall. Arrange the operational steps in the correct chronological sequence to update the deployment, monitor the rollout, diagnose the failure, and revert the deployment to its previous healthy state.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Update the deployment image using `kubectl set image`, 2) Monitor the deployment update using `kubectl rollout status`, 3) Inspect pod details and logs using `kubectl describe pod` and `kubectl logs`, and 4) Revert the deployment to its previous revision using `kubectl rollout undo`.
The proper GKE workload management lifecycle requires first applying the image change (`kubectl set image`), tracking the deployment status (`kubectl rollout status`), inspecting errors when the rollout stalls (`kubectl describe pod` / `kubectl logs`), and finally executing a rollback (`kubectl rollout undo`) to restore service availability.

Step-by-Step Solution

1
Trigger the workload update.
The GKE cluster updates the deployment spec and begins creating new ReplicaSet pods with the updated container image.
Applying the updated image tag with `kubectl set image` is the initial action required to start a GKE deployment update.
2
Track rollout progress.
The engineer observes that the deployment rollout is stuck awaiting pod readiness.
Executing `kubectl rollout status` provides real-time feedback on whether new pods successfully pass readiness probes.
3
Diagnose pod failure details.
The error root cause (such as a missing configuration parameter or failing readiness probe) is revealed.
Running `kubectl describe pod` inspects lifecycle events while `kubectl logs` retrieves standard output streams from crashing or unready containers.
4
Execute deployment rollback.
GKE terminates unready pods and restores the prior stable ReplicaSet.
Issuing `kubectl rollout undo` safely restores workload availability without needing manual manifest modifications.

Key Concept

Managing GKE Workload Rollouts and Troubleshooting
Question 147Question →

A Cloud Engineer is tasked with deploying a secure Python microservice to Google Cloud Run using the gcloud CLI. The deployment must adhere to least-privilege security practices by using a custom execution service account, building and storing the container image in Artifact Registry, blocking public unauthenticated HTTP access, and granting invocation permissions to a specific caller service account. Arrange the following deployment and configuration steps in the correct chronological sequence from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: 1) Create the dedicated custom IAM service account, 2) Build and push the container image to Artifact Registry using gcloud builds submit, 3) Deploy the container image to Cloud Run specifying the custom service account and disabling unauthenticated access, and 4) Grant the Cloud Run Invoker role (roles/run.invoker) on the deployed service to the authorized caller principal.
The correct order follows the lifecycle dependencies of GCP resource creation and deployment. First, the runtime execution identity (service account) must be created so it is available for reference. Second, the container image must be built and pushed to Artifact Registry using Cloud Build. Third, Cloud Run deploys the image while attaching the runtime service account and blocking unauthenticated access. Finally, after the service resource is deployed, resource-level IAM policy bindings (Cloud Run Invoker) can be added to allow access to the designated caller.

Step-by-Step Solution

1
Create the custom execution service account
An IAM service account principal is created in Google Cloud Identity/IAM.
Cloud Run deployment flags require an existing service account email address when binding execution identity during service creation.
2
Build and push the container image to Artifact Registry
The container artifact URI is generated and ready for deployment.
Cloud Run requires a valid container image location in Container Registry or Artifact Registry to instantiate revisions.
3
Execute gcloud run deploy with security flags
The Cloud Run service resource is instantiated with unauthenticated access blocked.
Deploying the service instantiates the resource and configures runtime settings like the execution service account and ingress authentication requirement.
4
Bind roles/run.invoker to the caller principal on the Cloud Run service
The caller principal is granted permission to invoke the private HTTP endpoint.
IAM policy bindings targeting specific Cloud Run service resources require the service to already exist in the project.

Key Concept

Deploying Cloud Run services with custom execution identities, Artifact Registry builds, and resource-level IAM invoker permissions
Question 148Question →

An application engineer accidentally deleted critical database tables in a production Cloud SQL for MySQL instance named `prod-db`. You need to perform a Point-in-Time Recovery (PITR) to restore the database to its state exactly 30 minutes prior to the deletion into a new instance named `prod-db-restored`, verify the data, and switch application traffic. In what order should you execute these operational recovery steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: first, identify the target timestamp from Cloud Audit Logs; second, execute `gcloud sql instances clone` with the `--point-in-time` parameter; third, connect to the new instance to validate recovered data; and fourth, update application database connection configurations to point to the restored instance.
The correct recovery procedure starts by identifying the exact timestamp of the event using Cloud Audit Logs. Next, `gcloud sql instances clone` is executed with the `--point-in-time` flag to create a new instance initialized to that timestamp. Once the instance is provisions, data integrity is verified. Finally, application configurations are updated to point to the newly restored instance.

Step-by-Step Solution

1
Determine the exact historical timestamp from Cloud Audit Logs or database event logs.
Obtained a precise ISO 8601 timestamp prior to the accidental table drop.
Point-in-time recovery requires a specific timestamp to replay binary logs up to that exact moment.
2
Execute the point-in-time clone command via the Google Cloud CLI.
Cloud SQL creates `prod-db-restored` using the latest base backup and replays transaction logs up to the specified point in time.
In GCP Cloud SQL, point-in-time recovery to a new instance is performed using the `gcloud sql instances clone` command with the `--point-in-time` flag.
3
Query the restored database instance `prod-db-restored`.
Verified that all deleted tables exist and data consistency is confirmed.
Verification ensures that the chosen recovery timestamp was correct and that data is intact before sending live traffic.
4
Reconfigure application connection parameters.
Applications seamlessly connect to `prod-db-restored` and resume normal operation.
Traffic must be redirected to the restored instance to restore service functionality.

Key Concept

Cloud SQL Point-in-Time Recovery (PITR) using gcloud instances clone
Question 149Question →

An enterprise application utilizing Cloud SQL for PostgreSQL experienced data corruption due to an accidental table deletion at 14:15:00 UTC. Point-in-time recovery (PITR) via write-ahead logging is active on the instance `db-main`. You must restore the database to its exact state at 14:14:00 UTC into a new instance and cut over production traffic while retaining the original instance for post-mortem inspection.

In what order should you execute these operational recovery steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of operations is: 1) Identify the target pre-corruption timestamp (14:14:00 UTC), 2) Clone the instance to `db-recovery` at that point in time using the `gcloud sql instances clone` command with the `--point-in-time` flag, 3) Perform data integrity validation on `db-recovery`, and 4) Update application connection parameters to redirect production traffic to `db-recovery`.
Point-in-Time Recovery (PITR) in Cloud SQL for PostgreSQL is performed by cloning the source instance into a new target instance using `gcloud sql instances clone` with the `--point-in-time` parameter. The workflow requires identifying the timestamp prior to corruption first, running the clone command second, validating data integrity on the new instance third, and updating application connection strings fourth.

Step-by-Step Solution

1
Determine target timestamp
Target timestamp identified as 14:14:00 UTC.
PITR requires specifying a precise timestamp prior to the failure event.
2
Provision cloned instance using gcloud CLI
Created new instance `db-recovery` containing the state at 14:14:00 UTC.
In Cloud SQL, PITR is accomplished by executing `gcloud sql instances clone` with the `--point-in-time` parameter.
3
Validate restored data integrity
Confirmed the deleted table and records are intact on `db-recovery`.
Validation prevents switching application traffic to an incomplete or flawed database state.
4
Cut over application traffic
Production workloads successfully connect to `db-recovery`.
Finalizes the recovery process by restoring active service functionality.

Key Concept

Cloud SQL Point-in-Time Recovery (PITR) and Instance Cloning Workflow
Question 150Question →

A cloud engineer must migrate non-critical batch processing workloads on a Google Kubernetes Engine (GKE) Standard cluster named `prod-cluster` to a dedicated Spot VM node pool to lower compute expenses. The engineer must prevent general workloads from being scheduled onto the Spot nodes while ensuring existing batch pods transition smoothly without resource contention. In what chronological sequence should the engineer perform the following operational steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Provision the new Spot VM node pool with a `NoSchedule` taint using `gcloud container node-pools create`; 2) Update the batch deployment manifest with matching tolerations and Spot node selectors; 3) Apply the manifest using `kubectl apply` to launch pods on the Spot pool; 4) Delete the legacy standard node pool using `gcloud container node-pools delete` after verifying migration success.
Order requires establishing the tainted infrastructure first, configuring workload specifications to tolerate the taint, applying those specifications to migrate running pods, and finally deleting the legacy node pool once migration is complete.

Step-by-Step Solution

1
Provision the new Spot node pool with node taints
The GKE cluster receives new Spot VM nodes configured with a `workload=batch:NoSchedule` taint.
Infrastructure must be provisioned and tainted first so that general cluster workloads cannot accidentally schedule on Spot instances.
2
Configure workload manifests with tolerations and selectors
The batch deployment YAML is prepared to allow scheduling past the taint and target the Spot node pool.
Without explicit tolerations in the pod template, Kubernetes scheduler will reject scheduling pods on tainted nodes.
3
Apply updated deployment configuration to the cluster
Kubernetes triggers a rolling update, scheduling batch pods onto the active Spot VM nodes.
Deploying the configuration updates the running workloads without causing downtime.
4
Decommission the redundant standard node pool
The standard node pool is removed and resources are released, preventing unnecessary compute costs.
Legacy nodes should only be decommissioned once all workloads have successfully migrated and verified.

Key Concept

GKE Node Pool Migration and Workload Isolation using Spot VMs, Taints, and Tolerations
Question 151Question →

A cloud engineer needs to configure least-privilege access by creating a custom IAM role for specific virtual machine operations and assigning it to an operator in a Google Cloud project using the gcloud CLI. Place the following operational steps in the correct sequential order from start to finish.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of operations is: first, create the local YAML role definition file specifying the required permissions; second, run 'gcloud iam roles create' to instantiate the custom role in the project; third, run 'gcloud projects add-iam-policy-binding' to bind the custom role to the user; and fourth, run 'gcloud projects get-iam-policy' to audit and confirm the binding.
The workflow follows standard Google Cloud IAM administration procedures: defining role permissions in a configuration file, creating the custom role resource in the target project, binding the created role to the desired user identity, and verifying the policy change via policy retrieval commands.

Step-by-Step Solution

1
Draft the custom role specification file containing the required permissions.
A local YAML configuration file ready for CLI creation commands.
Permissions must be defined prior to registering the custom role resource in Google Cloud.
2
Run 'gcloud iam roles create' referencing the YAML definition file.
The custom role is registered under the project's IAM role scope.
A role must exist in GCP IAM before any principal can be bound to it.
3
Run 'gcloud projects add-iam-policy-binding' to assign the custom role to the user.
The IAM policy binding links the user principal to the custom role resource.
Granting permissions requires binding the identity member to the role path at the appropriate hierarchy level.
4
Run 'gcloud projects get-iam-policy' to inspect the updated project policy.
An output listing current policy bindings confirming successful role assignment.
Verifying policy state ensures security compliance and confirms administrative changes were committed.

Key Concept

Custom IAM Role Creation and Policy Binding Lifecycle via gcloud CLI
Estimated Time:1m 30s
Question 152Question →

A Cloud Engineer needs to safely deploy an OS image update to a production Managed Instance Group (MIG) serving critical web application traffic. To minimize operational risk, the engineer must execute a canary rollout using the gcloud command-line interface, testing the updated configuration on a subset of 10% of the instances before initiating a full deployment. In which sequential order should the engineer execute these steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for conducting a canary rollout on a Managed Instance Group is: 1) Create a new instance template with the updated disk image, 2) Configure the MIG to target 10% size for the new template version, 3) Start the rolling update action to replace canary instances, 4) Monitor application logs and metrics on the canary subset, and 5) Promote the new instance template to 100% target size to complete the full update.
The correct operational sequence adheres to Google Cloud best practices for risk-mitigated deployments. A new instance template must be created first before it can be referenced. The group configuration is then updated to assign a 10% target size to the new template. Executing the rolling action replaces only the instances necessary to meet the 10% canary threshold. Monitoring telemetry validates that the new image performs reliably. Finally, assigning 100% target size to the new template rolls out the update to all remaining instances.

Step-by-Step Solution

1
Define the target configuration by creating a new Compute Engine instance template.
A new versioned template resource becomes available in the project for instance creation.
Managed Instance Groups instantiate virtual machines based on instance templates; changes cannot be applied directly to running instances without a template update.
2
Set the MIG update policy to include the new template as a canary version targeting 10% of total instances.
The MIG metadata is updated to maintain two versions (original version at 90%, canary version at 10%).
Canary deployments require specifying a target size or percentage so that GCP knows how many instances to transition initially.
3
Execute the gcloud rolling action update command.
Compute Engine automatically terminates old instances and provisions new instances using the canary template until 10% capacity is reached.
The rolling update action triggers the actual infrastructure replacement process in accordance with the specified update policy.
4
Inspect Cloud Monitoring metrics and application log streams for canary instances.
Verification data confirms whether the updated OS image operates cleanly under live conditions without unhandled exceptions or performance degradation.
Testing in production with limited exposure ensures bugs are detected prior to impacting all users.
5
Update the MIG version configuration to assign 100% target size to the new template.
The MIG replaces all remaining instances with the new template, completing the update cycle.
Once the canary passes validation, promoting the template brings the entire instance group to the latest configuration.

Key Concept

Managed Instance Group Canary Updates
Question 153Question →

A cloud engineer needs to execute a gradual canary rollout of a new container image for an existing Cloud Run service named `order-processor`. The rollout must first direct 10% of live traffic to the new revision using a revision tag for testing, verify stability, and finally route 100% of traffic to the new revision. Arrange the following deployment and traffic management steps in the correct operational sequence.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Deploy the container image with `--no-traffic` and `--tag canary-v2`, 2) Split 10% of production traffic to `canary-v2` using `gcloud run services update-traffic`, 3) Analyze metrics and error rates in Cloud Logging for `canary-v2`, 4) Shift 100% of traffic to the verified revision using `--to-latest`.
The deployment sequence begins by isolating the new revision using `gcloud run deploy` with `--no-traffic` and `--tag canary-v2`. Next, a canary split is established with `gcloud run services update-traffic --to-tags canary-v2=10`. Telemetry and error logs are then monitored in Cloud Logging specifically for the canary revision. Once stability is verified, all live production traffic is promoted to the new revision using `--to-latest`.

Step-by-Step Solution

1
Deploy container image with traffic suppression and revision tagging
A new Cloud Run revision is created receiving 0% of production traffic, exposed via a dedicated revision tag `canary-v2`.
Deploying with `--no-traffic` prevents unvalidated code from serving main production requests immediately.
2
Configure canary traffic split via gcloud CLI
The Cloud Run service routes 10% of incoming production requests to the revision tagged `canary-v2`.
`gcloud run services update-traffic` with `--to-tags` sets explicit percentage allocations for specific revision tags.
3
Analyze revision telemetry in Cloud Operations
Container instance behavior, HTTP 5xx rates, and request latencies for the canary revision are verified.
Empirical log verification ensures the revision can sustain production load without errors before full promotion.
4
Promote the verified revision to serve 100% of traffic
The service updates its main endpoint to direct 100% of live traffic to the latest fully-validated revision.
Using `--to-latest` completes the canary deployment by promoting the tested revision to full production.

Key Concept

Cloud Run revision tagging, traffic splitting, and canary release workflows
Question 154Question →

A cloud engineer needs to configure a Google Kubernetes Engine (GKE) workload to securely access Google Cloud Storage using Workload Identity. Arrange the administrative and deployment steps in the correct sequential order from start to finish.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with creating the Google Service Account (GSA) and assigning GCP IAM permissions, followed by creating the Kubernetes Service Account (KSA) in GKE. Next, grant the Workload Identity User IAM role to allow the KSA to impersonate the GSA. Then, annotate the KSA with the GSA email address. Finally, deploy the application manifest referencing the annotated KSA.
To configure Workload Identity correctly, you must first provision the Google Service Account (GSA) and grant it GCP IAM roles. Next, create the Kubernetes Service Account (KSA) in the cluster namespace. Then, grant the Workload Identity User role on the GSA to the KSA so GCP permits token impersonation. Fourth, annotate the KSA with the GSA's email address so GKE metadata server routes authentication requests properly. Finally, deploy the application manifest configured to use the annotated KSA.

Step-by-Step Solution

1
Create a Google Service Account (GSA) and assign required GCP IAM roles.
A GCP-level identity with Cloud Storage permissions is provisioned.
Workload Identity bridges Kubernetes identities to GCP Service Accounts, which hold actual GCP IAM permissions.
2
Create a Kubernetes Service Account (KSA) in the cluster namespace.
An in-cluster identity is defined for the workload.
Pods run under a KSA identity inside the Kubernetes cluster namespace.
3
Add an IAM policy binding granting `roles/iam.workloadIdentityUser` on the GSA to the KSA.
The GSA authorizes the KSA member `PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]` to act on its behalf.
Without this IAM binding, token exchange between GKE and GCP IAM will be rejected.
4
Annotate the KSA with the GSA email address.
The annotation `iam.gke.io/gcp-service-account` instructs GKE metadata server to issue tokens for the GSA.
The annotation tells GKE which GSA identity should be associated with pods using this KSA.
5
Deploy the application Pod or Deployment specifying `serviceAccountName` as the KSA.
The workload runs under the annotated KSA and securely authenticates to Google Cloud APIs.
When the application pod starts, its SDK calls the local GKE metadata server to obtain short-lived GSA credentials.

Key Concept

Configuring Workload Identity for GKE workloads
Question 155Question →

A cloud engineer needs to configure Private Service Access within a custom Virtual Private Cloud (VPC) network named `corp-vpc` and provision a high-availability Cloud SQL for MySQL instance hosting an application database named `sales_db`. What is the correct sequence of `gcloud` CLI operations required to successfully complete this deployment?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct deployment sequence is: 1) Allocate an internal IP address range in the VPC network (`gcloud compute addresses create`), 2) Establish a VPC peering connection to Google services (`gcloud services vpc-peerings connect`), 3) Deploy the Cloud SQL instance configured with private IP (`gcloud sql instances create`), and 4) Create the logical database inside the provisioned instance (`gcloud sql databases create`).
Setting up a private Cloud SQL instance using Private Service Access requires four dependent steps in precise order: first, reserve a named IP address range inside the customer VPC network (`gcloud compute addresses create`); second, establish a peering connection between the VPC and `servicenetworking.googleapis.com` (`gcloud services vpc-peerings connect`); third, provision the Cloud SQL instance linked to that network while suppressing public IP (`gcloud sql instances create`); and finally, create the target database schema inside the active instance (`gcloud sql databases create`).

Step-by-Step Solution

1
Allocate an IP range for VPC Peering
An IP range with purpose VPC_PEERING is reserved in corp-vpc.
Google Private Service Access requires an allocated IP range to assign private IP addresses to managed service instances.
2
Establish VPC Peering Connection
The VPC network is connected to Google's Service Networking tenant project.
Private Service Access uses VPC Peering between the customer VPC and Google's internal service network.
3
Provision the Cloud SQL Instance
The Cloud SQL instance is deployed without a public IP address.
The instance configuration references the peered VPC network and uses an IP address from the allocated range.
4
Create the Application Database
The sales_db database is initialized on the instance.
Database resources can only be created within an existing, fully provisioned Cloud SQL instance.

Key Concept

Sequence of steps for establishing Private Service Access and deploying private Cloud SQL instances
Question 156Question →

A Cloud Engineer is tasked with provisioning a Cloud SQL for MySQL database instance that must communicate exclusively using a Private IP address within an existing custom VPC network named `prod-vpc`. Security policy strictly prohibits assigning public IP addresses. In what order should the engineer execute the configuration and deployment steps to establish Private Service Access and successfully create the database instance?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with allocating an IP address range for VPC peering, followed by establishing the private service connection, then creating the Cloud SQL instance with `--no-assign-ip`, and finally creating the database on the instance.
Configuring Cloud SQL with Private IP requires establishing a Private Service Access connection first. This is a prerequisite two-step process: allocating an IP range (`gcloud compute addresses create ... --purpose=VPC_PEERING`) and creating the peering connection (`gcloud services vpc-peerings connect`). Only after this network foundation is in place can the instance be created with `--network` and `--no-assign-ip`. Logical database creation follows instance provisioning.

Step-by-Step Solution

1
Reserve internal IP allocation
A named IP block is allocated for VPC Peering within the target VPC network.
Cloud SQL Private IP relies on Service Networking, which requires an explicit IP allocation before establishing the peering connection.
2
Connect the VPC network to Service Networking
VPC Network Peering is configured between the user's VPC and Google's service producer VPC.
This step provisions the underlying network routing infrastructure necessary for Google-managed database instances to receive internal IP addresses.
3
Provision the Cloud SQL instance
The Cloud SQL instance is deployed with a private IP address and no public IP.
The Cloud SQL instance deployment command verifies that Private Service Access has been configured for the specified VPC network.
4
Create the database inside the instance
The target database schema is instantiated within the active Cloud SQL instance.
Databases are logical objects housed within a database instance and can only be created after instance deployment completes.

Key Concept

Deploying Cloud SQL with Private IP via Private Service Access
Question 157Question →

A Cloud Engineer needs to manually export a Cloud SQL for PostgreSQL database to a Cloud Storage bucket for offline archiving using the Google Cloud CLI. Arrange the steps in the correct procedural order to successfully complete this export operation.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: 1) Create a destination Cloud Storage bucket, 2) Grant the Cloud SQL instance service account storage write permissions on the bucket, 3) Execute the gcloud sql export sql command, and 4) Verify that the exported dump file exists in the target bucket.
To export a Cloud SQL database to Google Cloud Storage, you must first ensure the target bucket exists. Next, you must grant the Cloud SQL instance's automatically created service account appropriate IAM write permissions on that bucket. After IAM permissions are established, you issue the `gcloud sql export sql` command. Finally, you confirm the operation's success by checking for the exported file in the Cloud Storage bucket.

Step-by-Step Solution

1
Create the destination Cloud Storage bucket.
A target Cloud Storage bucket is available to store the exported file.
The export target URI must point to an existing Cloud Storage location.
2
Grant write access to the Cloud SQL service account.
The Cloud SQL instance service account has permission to write objects to the bucket.
Without IAM permissions (such as Storage Object Admin or Storage Object Creator) assigned to the service account, the export operation will fail with a permission denied error.
3
Run the export command via gcloud CLI.
Cloud SQL dumps the database content and uploads it to the specified Cloud Storage URI.
Executing the `gcloud sql export sql` command starts the official export operation.
4
Verify file existence in Cloud Storage.
Confirmation that the export completed and the file was written to GCS.
Operational management requires validating that backup and export artifacts are intact.

Key Concept

Exporting Cloud SQL Databases to Cloud Storage
Question 158Question →

Your organization requires a cloud engineer to export a production Cloud SQL for PostgreSQL instance to a Cloud Storage bucket for long-term compliance archiving. The destination bucket has restricted access, and the export operation must execute successfully without permission errors. What is the correct sequence of steps to perform and verify this database export using the gcloud CLI?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of operations is: First, retrieve the Cloud SQL instance's managed service account email. Second, grant that service account the Storage Object Admin role on the destination bucket. Third, run `gcloud sql export sql` to start the export job. Fourth, monitor the operation using `gcloud sql operations list` or `describe` until it completes.
Exporting data from Cloud SQL to Cloud Storage requires proper IAM authorization for the instance's managed service account. The process must begin by describing the Cloud SQL instance to extract its automatically generated service account email. Next, that service account must be granted write access (`roles/storage.objectAdmin`) on the destination GCS bucket. After IAM permissions are active, executing `gcloud sql export sql` starts the asynchronous dump process. Finally, executing `gcloud sql operations list` or `describe` confirms that the asynchronous task finished without errors.

Step-by-Step Solution

1
Identify Cloud SQL Service Account
Obtained the unique Cloud SQL instance service account email address.
Cloud SQL background processes run under the instance's unique service account rather than the identity of the user invoking the CLI command.
2
Configure Storage IAM Permissions
Granted `roles/storage.objectAdmin` on the destination Cloud Storage bucket to the Cloud SQL service account.
Without explicit bucket-level write permissions, the Cloud SQL service account will fail to write the SQL dump file to the bucket.
3
Execute the SQL Export Command
Started the asynchronous export job sending data to `gs://<bucket-name>/<filename>.sql`.
Once authorization is in place, `gcloud sql export sql` triggers the actual database dump generation.
4
Verify Operation Completion
Confirmed that the operational status of the export job transitioned to `DONE`.
Because export commands return an operation ID and run asynchronously, verifying operation state via `gcloud sql operations` is necessary to ensure success.

Key Concept

Cloud SQL Instance Service Account Authorization and Data Export Lifecycle
Question 159Question →

A cloud engineer must provision a Compute Engine virtual machine instance that automatically retrieves and executes a startup script stored in a private Cloud Storage bucket (`gs://corp-scripts-prod/init.sh`). The environment mandates strict adherence to the principle of least privilege using custom identities. Arrange the operational steps in the correct sequential order to properly configure permissions, deploy the VM instance via `gcloud`, and validate deployment success.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: 1) Create the dedicated custom service account, 2) Grant the Storage Object Viewer role to the service account on the Cloud Storage bucket, 3) Run `gcloud compute instances create` referencing the custom service account and setting `startup-script-url`, and 4) Execute `gcloud compute instances get-serial-port-output` to verify script execution.
Proper deployment order requires establishing the service account identity first, authorizing that identity to read the target Cloud Storage object second, deploying the instance with the appropriate gcloud flags pointing to the identity and script metadata third, and finally querying the serial port output to confirm successful script execution.

Step-by-Step Solution

1
Create a dedicated custom service account for the VM workload.
A specific service account identity is established in IAM.
Least privilege mandates avoiding default service accounts with broad primitive roles.
2
Assign the `roles/storage.objectViewer` role to the custom service account for the bucket containing the script.
The identity gains read access to objects inside `gs://corp-scripts-prod`.
Compute Engine startup script fetching uses the VM instance's attached service account credentials.
3
Provision the instance with `gcloud compute instances create` using `--service-account` and `--metadata=startup-script-url=...`.
The instance launches, binds the service account, and fetches the startup script on first boot.
Flags must specify both identity bindings and startup script location.
4
Inspect serial port output logs using `gcloud compute instances get-serial-port-output`.
The engineer confirms that `startup-script` completed without exit code failures.
Serial output provides runtime confirmation of startup script execution on Linux Compute Engine images.

Key Concept

Deploying Compute Engine VMs with custom service accounts and GCS startup scripts
Question 160Question →

A Cloud Engineer has a local Terraform configuration managing Google Cloud infrastructure. The engineer wants to migrate the existing local state file (`terraform.tfstate`) to a remote Google Cloud Storage (GCS) backend for team collaboration and state locking. What is the correct sequence of steps to complete this state migration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence requires creating the Cloud Storage bucket with object versioning first, adding the `backend "gcs"` block to the Terraform configuration, running `terraform init` to initialize the backend, and confirming the prompt by typing `yes` to transfer the local state file to the remote bucket.
Migrating a local Terraform state file to a GCS remote backend follows a strict dependency order: the target Cloud Storage bucket must be created first in GCP because Terraform initialization does not provision the backend bucket automatically. Next, the `backend "gcs"` code block must be declared in the Terraform configuration. Executing `terraform init` causes Terraform to detect the new backend configuration and prompt the user to transfer the state file. Finally, typing `yes` confirms the copy action and migrates the local state file to Cloud Storage.

Step-by-Step Solution

1
Provision a Google Cloud Storage bucket with object versioning enabled.
A secure destination bucket is created to hold the remote state.
Terraform cannot automatically create the state bucket during backend initialization; it must already exist in GCP.
2
Define the `backend "gcs"` configuration block inside the `terraform` block in the HCL file.
The Terraform code now references the remote GCS bucket destination.
Terraform needs explicit backend attributes (such as `bucket` and `prefix`) to determine where state data belongs.
3
Execute `terraform init` in the terminal.
Terraform parses the backend change and initiates the state migration routine.
The initialization command recognizes that the backend changed from local to GCS and triggers state copying.
4
Approve the state migration prompt by typing `yes`.
The local state data is uploaded to Cloud Storage, and local state file references are updated.
User confirmation ensures that existing infrastructure state is safely copied to the remote backend without data loss.

Key Concept

Terraform Remote Backend Migration to Cloud Storage (GCS)
PreviousPage 8 / 14Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin