Examkin

All practice questions

262 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 201Question →

A Cloud Engineer needs to perform a manual blue-green node pool replacement in a Google Kubernetes Engine (GKE) cluster to move workloads from an old pool (pool-v1) to a newly configured pool (pool-v2) with zero application downtime. Arrange the operational steps below in the correct execution sequence.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins by creating the new node pool (pool-v2), cordoning nodes in the old pool (pool-v1) to prevent new pod assignments, draining pool-v1 to migrate existing pods to pool-v2, and finally deleting pool-v1.
Safe blue-green replacement of a GKE node pool requires establishing target capacity first (`gcloud container node-pools create`), marking old nodes unschedulable (`kubectl cordon`), evicting workloads cleanly to the new pool (`kubectl drain`), and finally removing the decommissioned compute resources (`gcloud container node-pools delete`).

Step-by-Step Solution

1
Provision pool-v2 using gcloud container node-pools create
The target node pool is created and joins the cluster in a Ready state.
New compute capacity must be available before evicting existing workloads to prevent pods from stalling in a Pending state.
2
Cordon pool-v1 nodes using kubectl cordon
Nodes in pool-v1 are marked Unschedulable.
This prevents the Kubernetes control plane from placing any new or rescheduled pods back onto the pool being decommissioned.
3
Drain pool-v1 nodes using kubectl drain
Pods on pool-v1 are gracefully evicted and rescheduled onto pool-v2.
Drain respects pod disruption budgets and termination grace periods, migrating workloads to the available pool-v2 capacity without outage.
4
Delete pool-v1 using gcloud container node-pools delete
The legacy node pool resources are released and removed from GCP.
Once all workloads are confirmed healthy on pool-v2, deleting pool-v1 cleans up legacy compute resources.

Key Concept

GKE Manual Node Pool Migration and Maintenance Procedure
Question 202Question →

An organization is migrating an existing Google Cloud Storage bucket from fine-grained Access Control Lists (ACLs) to Uniform Bucket-Level Access (UBLA) to meet security compliance standards. What is the correct sequence of steps to execute this migration safely without revoking required access?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational order is: 1) Audit existing object ACL permissions and identify principal access requirements, 2) Grant equivalent IAM roles at the bucket level, 3) Enable Uniform Bucket-Level Access on the bucket, 4) Verify access permissions using audit logging.
The correct sequence requires auditing existing fine-grained permissions first, granting corresponding IAM roles to ensure no access disruption, turning on Uniform Bucket-Level Access to enforce bucket-level IAM security, and finally verifying user access via audit logs.

Step-by-Step Solution

1
Inspect current object ACLs to evaluate existing access patterns.
Identified all users and service accounts relying on object-level ACL access.
Prevents unauthorized access loss during migration by mapping ACL permissions to IAM roles.
2
Assign IAM roles (e.g., Storage Object Viewer / Admin) to principals.
Principals hold bucket-level IAM permissions matching their previous ACL rights.
Uniform Bucket-Level Access relies exclusively on IAM rules; granting IAM permissions first ensures continuity of access.
3
Execute gcloud storage buckets update gs://BUCKET_NAME --uniform-bucket-level-access.
Uniform Bucket-Level Access is enabled on the bucket, overriding and disabling legacy ACLs.
Enforces unified security management across all objects in the bucket.
4
Validate access operations through application testing and Cloud Audit Logs.
Confirmed that all legitimate requests succeed via IAM authorization.
Validates the migration outcome under production-like conditions.

Key Concept

Migration workflow from legacy Cloud Storage ACLs to Uniform Bucket-Level Access (UBLA)
Question 203Question →

An engineer needs to set up secure, keyless access for an application running on a Google Compute Engine virtual machine to read data from BigQuery. Arrange the procedural steps in the correct chronological order to achieve this setup following Google Cloud best practices.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: 1) Create the user-managed service account using gcloud, 2) Grant the necessary BigQuery IAM role to the service account identity, 3) Attach the service account to the Compute Engine VM instance upon creation, and 4) Run the application to authenticate keylessly via Application Default Credentials.
The proper sequence requires initializing the service account identity first, granting least-privilege IAM roles to that identity second, attaching the service account identity to the VM instance during creation third, and finally letting the application authenticate keylessly via Application Default Credentials.

Step-by-Step Solution

1
Create the user-managed service account entity in IAM.
A unique service account identity email (SA_NAME@PROJECT_ID.iam.gserviceaccount.com) is established.
An identity must exist in IAM before policy bindings or resource attachments can reference it.
2
Bind the required IAM role (e.g., roles/bigquery.dataViewer) to the service account using `gcloud projects add-iam-policy-binding`.
The service account identity gains authorization to access BigQuery resources.
Granting least-privilege permissions to the service account ensures it has the necessary access once attached.
3
Attach the service account identity to the Compute Engine instance using `gcloud compute instances create` with the `--service-account` flag.
The instance metadata server is configured to issue OAuth 2.0 access tokens on behalf of the service account.
Associating the service account with the VM enables keyless authentication via the metadata server.
4
Execute the application workload using Application Default Credentials (ADC).
The application automatically retrieves tokens from the metadata server and accesses BigQuery securely.
This completes the secure lifecycle without exporting or managing static service account JSON keys.

Key Concept

Creating and Managing Service Accounts
Question 204Question →

A DevOps engineer needs to package a Python web application from local source code into a container image and deploy it to Google Cloud Run using the gcloud CLI. Place the following operational steps in the correct sequential order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: 1) Build and push the container image to Artifact Registry using gcloud builds submit, 2) Deploy the container image to Cloud Run using gcloud run deploy, 3) Update service environment variables using gcloud run services update, and 4) Verify live service response by making an HTTP request to the assigned service URL.
Deploying a containerized web application to Cloud Run follows a logical lifecycle: first, source code must be built into a container image and pushed to Artifact Registry using Cloud Build. Second, the container image is deployed to Cloud Run using gcloud run deploy to provision the service revision. Third, service-level configurations such as environment variables are updated using gcloud run services update. Finally, sending an HTTP request to the live Cloud Run endpoint verifies that the deployment is functional and accepting requests.

Step-by-Step Solution

1
Build and push container artifact
The application code is compiled into a container image stored in Artifact Registry.
Cloud Run requires an accessible container image artifact in a registry before deploying a service.
2
Deploy container to Cloud Run
A Cloud Run service and initial revision are provisioned with an assigned HTTPS endpoint.
Executing gcloud run deploy provisions serverless infrastructure hosting the specified container image.
3
Update service runtime configuration
The Cloud Run service specification is updated with environment variables.
Post-deployment configuration changes modify the service configuration to supply required application variables.
4
Verify service health
The service returns an HTTP 200 OK status from the HTTPS URL.
Issuing an HTTP GET request verifies that the container starts up and handles requests properly.

Key Concept

Deploying serverless containerized applications to Cloud Run using gcloud CLI build and deployment workflows
Question 205Question →

A security auditor requires your team to standardize security controls on an active production Cloud Storage bucket currently configured with fine-grained access control. You must transition this bucket to enforce Uniform Bucket-Level Access (UBLA) without causing access disruptions for authorized applications and service accounts. Arrange the operational steps in the correct chronological sequence to safely complete this security migration.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational order for migrating to Uniform Bucket-Level Access is: 1) Audit existing object and bucket ACLs, 2) Grant equivalent IAM roles at the bucket level, 3) Enable Uniform Bucket-Level Access using the CLI, 4) Monitor access logs during the grace period, and 5) Lock Uniform Bucket-Level Access permanently.
Safely transitioning a bucket from fine-grained ACLs to Uniform Bucket-Level Access requires a structured approach: auditing existing ACL access, mapping those permissions to appropriate Cloud IAM predefined roles at the bucket level, activating UBLA via gcloud, validating application behavior during the 90-day grace period, and finally locking the UBLA policy to enforce compliance permanently.

Step-by-Step Solution

1
Audit current ACL entries on the bucket and its objects.
Identified all users, groups, and service accounts relying on per-object fine-grained permissions.
You must understand current access permissions before replacing them with bucket-level IAM policies to avoid service disruption.
2
Assign corresponding IAM roles to principals at the bucket level.
Principals receive bucket-wide IAM permissions equivalent to their previous ACL permissions.
Enabling UBLA causes Google Cloud Storage to ignore ACLs; IAM roles must already be active before UBLA is turned on.
3
Execute `gcloud storage buckets update gs://[BUCKET_NAME] --uniform-bucket-level-access`.
Uniform Bucket-Level Access is enabled on the target bucket.
This configuration change shifts access evaluation exclusively to Cloud IAM roles.
4
Review audit logs and monitor workload access during the 90-day evaluation window.
Access validation confirms no authorized workloads are blocked.
The 90-day grace period allows administrators to revert UBLA if unmapped ACL permissions break critical workflows.
5
Lock Uniform Bucket-Level Access using `gcloud storage buckets update gs://[BUCKET_NAME] --lock-uniform-bucket-level-access`.
The bucket policy is locked and UBLA can no longer be disabled.
Locking ensures compliance with security regulations by permanently prohibiting fine-grained ACL access controls.

Key Concept

Migrating to Uniform Bucket-Level Access (UBLA)
Question 206Question →

A security engineer is tasked with migrating a legacy production Cloud Storage bucket containing financial records from fine-grained Access Control Lists (ACLs) to Uniform Bucket-Level Access (UBLA) in accordance with company security posture mandates. Arrange the migration and enforcement steps in the correct sequential order to prevent service disruption while ensuring strict security policy enforcement.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct procedural order is: 1) Analyze Cloud Audit Logs and grant equivalent Cloud IAM predefined roles; 2) Enable Uniform Bucket-Level Access on the Cloud Storage bucket; 3) Monitor metrics and audit logs for access denials during the grace period; 4) Apply the organization policy constraint for uniform bucket-level access.
Migrating to Uniform Bucket-Level Access requires a controlled sequence: first auditing and replacing object ACLs with equivalent IAM roles to preserve access; second enabling UBLA on the bucket to enforce IAM-only access; third monitoring audit logs and metrics during the 90-day window to catch unmapped edge cases; and finally locking security posture at the project/organization level using Organization Policy constraints.

Step-by-Step Solution

1
Audit current ACL utilization and map legacy object ACLs to IAM predefined roles.
Principals relying on object-level ACLs are granted bucket-level IAM roles (such as Storage Object Viewer or Storage Object Admin).
Once Uniform Bucket-Level Access is enabled, GCP ignores object ACLs entirely. IAM permissions must be present beforehand to avoid immediate access revocation.
2
Enable Uniform Bucket-Level Access on the target Cloud Storage bucket.
The bucket shifts permission evaluation strictly to Cloud IAM and starts a 90-day grace period.
Activating UBLA enforces IAM-only evaluation while retaining the technical safety net of reverting within 90 days if production workloads fail.
3
Perform runtime monitoring of audit logs and authorization telemetry.
Verification that zero 403 Forbidden errors occur due to unmapped object ACL dependencies.
Monitoring validates full operational stability under IAM before taking immutable or organization-wide enforcement steps.
4
Enforce the uniformBucketLevelAccess constraint via Organization Policy.
Fine-grained ACLs are completely disabled across the project scope.
Organization policies provide overarching governance to prevent policy regression or manual enabling of ACLs.

Key Concept

Uniform Bucket-Level Access Migration Workflow
Question 207Question →

A cloud engineer needs to deploy a secure web server workload using the Google Cloud CLI (`gcloud`). The architecture requires a dedicated custom-mode Virtual Private Cloud (VPC) network, a custom subnet in the `us-central1` region, an ingress firewall rule allowing HTTP traffic to instances with the network tag `web-server`, and a Compute Engine virtual machine instance provisioned inside the custom subnet. What is the correct sequence of operational steps to deploy this infrastructure from scratch?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts by creating the custom-mode VPC network, followed by creating the custom subnet in the target region, then creating the ingress firewall rule with target network tags, and finally provisioning the Compute Engine instance attached to the subnet with the matching network tag.
Google Cloud resource hierarchy and dependency constraints dictate that a parent custom VPC network must be created first (`--subnet-mode=custom`). Next, regional subnets must be defined within the network. Ingress firewall rules targeting specific network tags can then be associated with the network. Finally, Compute Engine instances are launched inside the provisioned subnet with matching network tags applied.

Step-by-Step Solution

1
Create custom-mode VPC network
Establishes the global network resource shell.
Parent VPC network resources must precede child subnet and firewall rule objects.
2
Create regional custom subnet
Allocates a dedicated CIDR block within the custom VPC network.
Instances in custom-mode networks require a pre-allocated subnet for network interface binding.
3
Configure ingress firewall rule
Applies network security rules filtering traffic by target tags.
Configuring security boundaries on the VPC network prepares the environment for safe instance placement.
4
Provision Compute Engine VM instance
Deploys the VM attached to the subnet and binds the `web-server` tag.
The VM relies on existing subnet infrastructure and inherits firewall policies matching its assigned tag.

Key Concept

Google Cloud infrastructure deployment order and resource dependencies for custom VPC networks, subnets, firewall rules, and tagged Compute Engine VMs.
Question 208Question →

What is the correct sequential order of steps required to configure GKE Workload Identity so that an application running in a Kubernetes namespace can access Google Cloud resources using a dedicated Google Service Account (GSA) without relying on static service account keys?

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, followed by creating and granting IAM roles to the Google Service Account (GSA). Next, create the Kubernetes Service Account (KSA), grant the `roles/iam.workloadIdentityUser` role on the GSA to the KSA identity URI, and finally annotate the KSA with the GSA's email address.
Configuring Workload Identity follows a logical top-down sequence: infrastructure setup, identity provisioning on both GCP and Kubernetes layers, authorization via IAM binding, and pod configuration via KSA annotation. First, the GKE cluster must have Workload Identity enabled to create the workload identity pool. Second, the Google Service Account (GSA) is created and assigned resource permissions. Third, the Kubernetes Service Account (KSA) is created in the target namespace. Fourth, the IAM role `roles/iam.workloadIdentityUser` is granted on the GSA to the formatted KSA member URI. Finally, the KSA is annotated with the GSA email so the GKE metadata server handles keyless token negotiation.

Step-by-Step Solution

1
Enable Workload Identity at the cluster level.
The GKE cluster establishes a workload identity pool (`PROJECT_ID.svc.id.goog`) and enables the GKE metadata server daemonset on cluster nodes.
Workload Identity infrastructure must be active before identity delegation can take place.
2
Configure the target Google Service Account (GSA).
A GSA is provisioned in Google Cloud IAM with resource access permissions following the principle of least privilege.
The GSA provides the Google Cloud identity that performs actual operations against GCP APIs.
3
Provision the Kubernetes Service Account (KSA).
A KSA object exists in the target Kubernetes namespace.
The KSA provides the pod-level workload identity within Kubernetes.
4
Bind the KSA identity to the GSA using IAM permissions.
The KSA identity string `serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]` receives the `roles/iam.workloadIdentityUser` role on the GSA.
This step grants permission for the specific Kubernetes service account to impersonate the target GSA.
5
Annotate the KSA with the GSA email address.
Pods using the KSA are automatically intercepted by the GKE metadata server to exchange Kubernetes tokens for short-lived GCP OAuth tokens.
The annotation completes the mapping between the Kubernetes workload and the GCP service account identity.

Key Concept

GKE Workload Identity Configuration Sequence
Question 209Question →

A security engineer must enable a developer to manage Cloud Storage buckets in a production project using service account impersonation, eliminating the need for long-lived service account keys. What is the correct sequence of steps to establish and verify this impersonated access?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order to establish service account impersonation begins by assigning resource permissions to the target service account, granting the Service Account Token Creator role on the service account to the user, authenticating the user identity, and executing gcloud commands with the impersonation flag.
To configure service account impersonation securely, the target service account must first be granted necessary resource access permissions (Storage Admin). Next, the user principal must be granted the Service Account Token Creator role directly on the target service account. The user then authenticates their identity via gcloud auth login, and finally passes the --impersonate-service-account flag when running CLI commands.

Step-by-Step Solution

1
Assign required resource-level IAM roles to the target service account.
The target service account acquires permission to manage Cloud Storage buckets.
Before impersonation can yield useful access, the target service account must possess the necessary resource privileges.
2
Grant roles/iam.serviceAccountTokenCreator on the service account to the developer user principal.
The developer account is authorized to mint short-lived credentials for the target service account.
Impersonation requires explicit delegation via the Service Account Token Creator role on the service account resource.
3
Run gcloud auth login with the developer user credentials.
Active user authentication token is established locally.
The CLI needs valid caller credentials to request short-lived impersonated tokens from IAM.
4
Append --impersonate-service-account to gcloud commands.
Commands execute under the permissions of the service account without requiring static key files.
Passing the impersonation flag requests Google Cloud IAM to issue short-lived credentials for the command duration.

Key Concept

Configuring Service Account Impersonation
Question 210Question →

A Cloud Engineer needs to replace a degraded secondary persistent disk attached to a production Compute Engine Virtual Machine (app-server-1) with a restored volume from a recent snapshot named app-data-snapshot-v2. The recovery process must follow Google Cloud recommended practices using gcloud CLI commands to minimize data corruption risk. What is the correct sequence of steps to replace and restore the persistent data disk?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins by safely unmounting and detaching the degraded disk from the VM instance, creating a replacement persistent disk from the source snapshot via gcloud compute disks create, attaching the newly created disk to the VM instance via gcloud compute instances attach-disk, and finally mounting the restored volume inside the guest operating system.
To safely restore a data disk onto a Compute Engine VM instance, the operational lifecycle requires disconnecting the old volume first to preserve data integrity, instantiating a new persistent disk resource from the Cloud Storage snapshot, attaching the created disk to the instance via gcloud, and mounting the restored file system within the guest OS.

Step-by-Step Solution

1
Unmount file system and detach old disk
Disk is cleanly disconnected from app-server-1 without active file locks or pending write operations.
Detaching an active disk while mounted can cause file system errors or prevent successful creation/attachment of replacement block devices.
2
Execute gcloud compute disks create with --source-snapshot
A new zonal persistent disk containing data from app-data-snapshot-v2 is provisioned.
Compute Engine persistent disks must be instantiated as independent block resources from snapshots before attachment.
3
Execute gcloud compute instances attach-disk
The new disk becomes available as a block device on app-server-1.
Attaching links the created persistent disk resource to the specific VM compute instance.
4
Mount the volume in the guest OS
Restored file system data is accessible to application workloads.
The guest OS kernel requires mounting the attached block device to expose the file hierarchy.

Key Concept

Restoring Persistent Disks from Snapshots using gcloud CLI
Question 211Question →

An operations engineer needs to export a production database from a Cloud SQL for MySQL instance to a Google Cloud Storage bucket using the gcloud CLI. The process must follow Google Cloud security best practices by granting the minimum required service account permissions. What is the correct sequence of steps to perform this export operation successfully?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins by retrieving the service account email of the Cloud SQL instance, granting that service account the Storage Object Admin role on the Cloud Storage destination bucket, running the gcloud sql export command, and finally verifying the completed operation status and bucket contents.
Exporting data from Cloud SQL to Cloud Storage requires proper delegation of authority. First, you must identify the Cloud SQL service account associated with the instance. Second, that service account must be granted write access (roles/storage.objectAdmin) on the destination Cloud Storage bucket. Third, you execute the gcloud sql export sql command. Fourth, you inspect the operation completion status to confirm successful export.

Step-by-Step Solution

1
Retrieve Cloud SQL Instance Identity
Obtained service account email (serviceAccountEmail field).
Cloud SQL uses its own service account to write data to Cloud Storage.
2
Configure IAM Access Control
Service account is authorized to create objects in the destination bucket.
Without explicit Object Admin/Creator access on the bucket, export operations fail with permission denied errors.
3
Initiate Export Command
Cloud SQL starts streaming the SQL dump to the Cloud Storage URI.
The export command relies on pre-configured permissions to run asynchronously.
4
Monitor and Validate Operation
Confirmed successful operation status and verified SQL file creation.
Operational auditing validates that database backups completed cleanly.

Key Concept

Cloud SQL Database Export Procedures and IAM Service Account Authorization
Question 212Question →

A cloud engineer needs to perform a canary deployment for an existing Cloud Run service named `inventory-api`. The deployment strategy requires deploying a new revision without immediately receiving production traffic, validating the isolated revision using a revision tag URL, sending 10% of live traffic to the canary, and finally shifting 100% of traffic to the new release. In what order should the engineer execute the following operational steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with deploying the new revision with the `--no-traffic` flag and tag `canary`, followed by testing the revision directly via its tag URL, then updating traffic to send 10% of live requests to the `canary` tag, and finally updating traffic to route 100% to the latest revision.
Safely deploying updates to Cloud Run requires isolating new revisions using `--no-traffic` and revision tags (`--tag`), testing through the dedicated tag URL, performing a partial traffic split using `gcloud run services update-traffic --to-tags`, and finally updating the service to route 100% of live traffic to the latest revision.

Step-by-Step Solution

1
Deploy revision with `--no-traffic` and `--tag` flags.
A new Cloud Run revision is deployed and assigned a dedicated URL tag without receiving main ingress traffic.
Prevents unverified code from handling production requests immediately upon deployment.
2
Perform smoke tests on the generated tag-specific endpoint.
Verification of basic functionality and deployment health on the specific revision.
Validates application readiness in the target GCP environment prior to opening production ingress.
3
Execute `gcloud run services update-traffic` allocating 10% to the `canary` tag.
Cloud Run load balancer splits live incoming requests so 10% go to the canary revision and 90% go to existing traffic targets.
Allows monitoring of production metrics, telemetry, and error rates with minimal customer exposure.
4
Execute `gcloud run services update-traffic` allocating 100% traffic `--to-latest`.
The new revision becomes the primary receiver of all production traffic.
Completes the canary release workflow once stability is confirmed.

Key Concept

Cloud Run Tagged Canary Deployment and Traffic Splitting Workflow
Estimated Time:1m 30s
Question 213Question →

A cloud engineer needs to deploy a Compute Engine virtual machine instance using a custom image stored in a central image repository project. The VM requires a reserved static internal IP address in a specific target subnet and must be assigned a custom service account. What is the correct sequence of steps to perform this deployment workflow?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of execution is: First, grant the target project service agent `roles/compute.imageUser` access on the central image. Second, reserve the static internal IP address in the target subnet. Third, execute `gcloud compute instances create` with the image URI, reserved internal IP, and custom service account. Fourth, verify the VM state and configuration using `gcloud compute instances describe`.
Cross-project image deployments require establishing IAM permissions prior to instance creation. Granting `roles/compute.imageUser` to the target project's Compute Engine Service Agent authorizes access to the custom image in the central project. Next, reserving the static internal IP in the target subnet ensures the network resource exists. Once these prerequisites are met, running `gcloud compute instances create` provisions the instance with the specified image, network IP, and service account. Finally, verifying with `gcloud compute instances describe` ensures proper deployment.

Step-by-Step Solution

1
Authorize cross-project image access
Target project service account receives read access to the custom disk image
Compute Engine cannot read disk images across project boundaries without explicit IAM role delegation.
2
Reserve static internal IP address
An internal IP address is allocated within the specified subnet
An existing reserved IP resource is required to attach a static IP during instance creation.
3
Provision the Compute Engine VM
The instance is created and boots from the cross-project image
All authorization and network prerequisites are in place to execute instance provisioning.
4
Inspect instance deployment status
Instance configuration and RUNNING status are confirmed
Executing a describe command validates successful initialization and correct network/IAM metadata attachment.

Key Concept

Cross-Project Image Provisioning and Static Network Allocation
Question 214Question →

Your organization plans to enforce uniform security policies across all Google Cloud Storage buckets. You need to transition a bucket currently using fine-grained access control to Uniform Bucket-Level Access without interrupting existing user access. In what sequence should you execute these migration steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by auditing existing object ACLs, granting equivalent IAM roles at the bucket level, enabling Uniform Bucket-Level Access on the bucket, and finally validating access through log audits and workflow testing.
The correct process mandates auditing existing ACLs first to determine access needs, granting equivalent IAM roles at the bucket level to prevent downtime, enabling Uniform Bucket-Level Access to enforce bucket-wide IAM controls, and verifying post-migration access using audit logs.

Step-by-Step Solution

1
Audit object ACL permissions on the existing bucket.
Identified all principals relying on fine-grained access control.
Prevents unauthorized access loss by establishing a baseline of required permissions before changing access control models.
2
Assign corresponding bucket-level IAM roles to identified principals.
IAM roles are configured at the bucket level prior to disabling ACLs.
Ensures continuous user access during the transition from ACLs to Uniform Bucket-Level Access.
3
Enable Uniform Bucket-Level Access on the target Cloud Storage bucket.
Fine-grained ACLs are disabled, and authorization relies strictly on IAM policies.
Enforces uniform security across all objects in the bucket as mandated by organizational governance.
4
Perform post-migration verification using logs and application tests.
Confirmed that all application workflows operate cleanly under IAM permissions.
Ensures no residual permission errors exist following the access model migration.

Key Concept

Migrating fine-grained ACLs to Uniform Bucket-Level Access in Google Cloud Storage
Question 215Question →

A cloud security engineer needs to transition a legacy Cloud Storage bucket containing audit logs from fine-grained Access Control Lists (ACLs) to Uniform Bucket-Level Access (UBLA) without disrupting active applications or causing permission denials. In what correct chronological sequence should the engineer execute the following operational steps to safely enforce bucket-level access control?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational order is: 1) Audit existing object-level and bucket-level ACLs to identify all access requirements, 2) Map discovered ACL permissions to equivalent Cloud Storage predefined IAM roles, 3) Apply the mapped IAM role bindings to the target bucket, and 4) Enable Uniform Bucket-Level Access (UBLA) on the Cloud Storage bucket.
The migration process requires discovering existing access rules, translating them into IAM role assignments, granting those IAM roles at the bucket level, and finally toggling Uniform Bucket-Level Access. This guarantees zero service interruption while enforcing uniform security governance.

Step-by-Step Solution

1
Inventory current bucket access requirements.
Identified all users, groups, and service accounts currently relying on ACL entries.
Without auditing first, enabling UBLA would immediately break access for principals who rely solely on object-level ACLs.
2
Translate object ACLs into bucket-level predefined IAM roles.
Created a deterministic mapping from legacy ACL permissions to GCP predefined storage roles.
UBLA ignores ACLs entirely, so permissions must be expressed via IAM role bindings.
3
Bind the IAM roles to the bucket's IAM policy.
Principals hold overlapping permissions via both ACLs and IAM roles.
Pre-granting IAM roles guarantees zero downtime or permission denied errors during the UBLA transition.
4
Execute command or update bucket metadata to set uniformBucketLevelAccess.enabled to true.
Bucket ACLs are ignored, and all access requests are evaluated strictly against IAM permissions.
Enabling UBLA finalizes the security posture mandate.

Key Concept

Migrating from Fine-Grained ACLs to Uniform Bucket-Level Access (UBLA)
Question 216Question →

A DevOps engineer needs to deploy a Cloud Functions (2nd gen) service from local source code to handle background file processing triggered by a Cloud Storage bucket event. The deployment must adhere to the principle of least privilege using a custom service account. What is the correct sequence of steps to perform this deployment?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: 1) Create a dedicated custom IAM service account for the function. 2) Grant the required IAM roles to the custom service account. 3) Run `gcloud functions deploy` specifying the Cloud Storage trigger and the `--service-account` flag. 4) Upload a test file to the Cloud Storage bucket to verify event delivery and function execution.
Deploying an event-driven Cloud Function following GCP security best practices requires creating the custom service account first. Next, IAM roles must be granted to that service account so it possesses the appropriate execution permissions. Third, executing `gcloud functions deploy` attaches the configured service account and sets up the Cloud Storage trigger. Finally, uploading a file to the bucket tests and verifies that the live function executes as expected.

Step-by-Step Solution

1
Create the custom service account
A unique service account identity is created within the Google Cloud project.
An identity must exist before IAM roles can be granted to it or attached to a Cloud Function.
2
Bind required IAM roles to the service account
The service account gains necessary authorization for runtime resources.
Least privilege access control requires configuring resource access permissions prior to runtime usage.
3
Deploy the function using the gcloud CLI
The serverless function is built, deployed, and linked to the Eventarc trigger and custom service account.
Cloud Functions deployment attaches the pre-configured service account identity.
4
Trigger the event by uploading a file
Eventarc delivers the event notification to the function, invoking the code.
Verification can only occur once the service is active and listening for storage events.

Key Concept

Order of operations for deploying event-driven Cloud Functions with custom service account identities
Question 217Question →

A security engineer needs to configure Cloud Audit Logging to monitor user activity on Google Cloud Storage buckets and then inspect the resulting audit records. What is the correct sequence of steps to enable Data Access audit logging and view these logs?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order is: 1. Navigate to IAM & Admin > Audit Logs in the Google Cloud Console. 2. Select Google Cloud Storage from the service list, enable Data Read and Data Write audit log types, and save. 3. Perform an object read or write operation in a Cloud Storage bucket within the project. 4. Open Logs Explorer and filter logs using the query logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access".
To inspect Data Access audit logs, an administrator must first navigate to IAM & Admin > Audit Logs and explicitly enable Data Read/Data Write logs for Cloud Storage, because Data Access audit logging is turned off by default. Once enabled, performing an operation generates log entries that are subsequently viewable in Logs Explorer under the cloudaudit.googleapis.com/data_access log stream.

Step-by-Step Solution

1
Open the central Audit Logs settings page
Accesses project-level audit log configuration options
Centralized audit log management for all GCP services is located under IAM & Admin > Audit Logs.
2
Enable Cloud Storage Data Access logging
Activates Data Read and Data Write audit record generation for Cloud Storage
Data Access logs are turned off by default to prevent unexpected log storage costs.
3
Generate audit log activity
Creates log events in the Cloud Logging ingestion stream
Audit logs only record events occurring after logging has been enabled.
4
Query the generated logs in Logs Explorer
Displays Data Access audit log entries matching the Cloud Storage operations
Data Access logs are written to the cloudaudit.googleapis.com/data_access log filter path.

Key Concept

Configuring and Analyzing Data Access Cloud Audit Logs
Estimated Time:1m 0s
Question 218Question →

A security engineer needs to enable a developer to manage Cloud Storage resources by impersonating a target service account from their local workstation using the Google Cloud CLI, without downloading long-lived service account keys. Arrange the steps required to configure and verify service account impersonation in the correct sequential order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct procedure begins by granting the developer the Service Account Token Creator role on the target service account. Next, the developer authenticates their user identity locally using `gcloud auth login`. Then, the developer sets the `auth/impersonate_service_account` CLI property. Finally, the developer runs resource management commands using automatically generated short-lived tokens.
To establish service account impersonation for local gcloud CLI operations, administrative permissions (`roles/iam.serviceAccountTokenCreator`) must first be granted to the developer on the target service account. The developer then authenticates locally using their user identity via `gcloud auth login`. Following successful login, the developer configures gcloud CLI to impersonate the service account using `gcloud config set auth/impersonate_service_account`. Finally, running GCP commands seamlessly uses short-lived tokens minted on demand.

Step-by-Step Solution

1
Grant `roles/iam.serviceAccountTokenCreator` on the target service account to the developer's user identity.
The developer gains authorization to create short-lived OAuth 2.0 access tokens for the service account.
Service account impersonation requires explicit IAM authorization on the service account resource before short-lived token generation is allowed.
2
Execute `gcloud auth login` on the local workstation.
The developer authenticates and stores local user credentials in gcloud CLI.
The gcloud CLI relies on an authenticated user identity to issue Google Cloud IAM credentials API calls.
3
Execute `gcloud config set auth/impersonate_service_account TARGET_SERVICE_ACCOUNT_EMAIL`.
The gcloud CLI updates its active configuration profile to append impersonation parameters.
Setting this configuration tells gcloud CLI to request short-lived tokens for the target service account rather than invoking APIs under the user's base identity.
4
Execute GCP commands such as `gcloud storage ls`.
The storage resources are listed under the context and permissions of the target service account.
With configuration complete, commands transparently fetch short-lived tokens and perform operations under the delegated service account identity.

Key Concept

Configuring Service Account Impersonation via Google Cloud CLI
Question 219Question →

A cloud engineer needs to deploy a custom enterprise environment in Google Cloud using the Google Cloud CLI (`gcloud`). The environment requires a custom VPC network, a dedicated subnet in `us-central1`, a restrictive ingress firewall rule for web application traffic, and a Compute Engine VM instance. Arrange the operational steps in the correct chronological sequence required to provision this infrastructure successfully.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of operations is: (1) Create the custom-mode VPC network 'prod-vpc', (2) Create the custom subnet 'prod-app-subnet' within the VPC, (3) Create the ingress firewall rule 'allow-app-ingress' targeting tag 'app-server', and (4) Deploy the Compute Engine VM instance 'app-vm-1' attached to 'prod-app-subnet' with tag 'app-server'.
In Google Cloud, infrastructure provisioning follows a strict dependency hierarchy. First, the custom VPC network container must be created (`gcloud compute networks create --subnet-mode=custom`). Second, regional subnets are created inside that VPC (`gcloud compute networks subnets create`). Third, firewall rules are established on the VPC network specifying target network tags (`gcloud compute firewall-rules create`). Finally, Compute Engine VM instances are deployed into the designated subnet and tagged appropriately (`gcloud compute instances create --subnet ... --tags ...`) so that network routing and firewall policies apply immediately.

Step-by-Step Solution

1
Initialize the parent custom VPC network
Network resource 'prod-vpc' exists with auto-subnet creation disabled.
Custom subnets cannot be created without a parent VPC network existing first.
2
Provision the custom subnet
Subnet 'prod-app-subnet' is established in region 'us-central1'.
VM instances require a specific subnet for IP allocation when operating in a custom mode network.
3
Configure network firewall ingress rule
Firewall rule 'allow-app-ingress' is created under network 'prod-vpc'.
Security controls should be defined on the VPC before launching instances to ensure traffic is governed properly upon boot.
4
Deploy Compute Engine VM instance with network tag
VM instance 'app-vm-1' is instantiated inside 'prod-app-subnet' with target tag 'app-server'.
The instance references both the subnet for connectivity and the network tag to inherit the firewall rule configuration.

Key Concept

Deployment dependency order for GCP VPC networks, subnets, firewall rules, and compute instances.
Question 220Question →

A DevOps engineer must configure keyless authentication for a microservice deployed in a Google Kubernetes Engine (GKE) cluster. The microservice runs in the `analytics` namespace and needs to read objects from a Cloud Storage bucket using a Google Service Account (GSA). What is the correct sequence of steps to establish 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 sequence of steps is: 1) Create the Google Service Account (GSA) and assign it the Storage Object Viewer role on the target bucket, 2) Create the Kubernetes Service Account (KSA) in the `analytics` namespace, 3) Grant the `roles/iam.workloadIdentityUser` role on the GSA to the principal member `serviceAccount:PROJECT_ID.svc.id.goog[analytics/KSA_NAME]`, and 4) Annotate the KSA with `iam.gke.io/gcp-service-account=GSA_EMAIL`.
Establishing Workload Identity requires provisioning the GCP IAM identity (GSA) and Kubernetes identity (KSA), granting `roles/iam.workloadIdentityUser` on the GSA to the KSA principal in the Workload Identity pool (`PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]`), and finally annotating the KSA with the GSA email so the GKE metadata server handles token exchanges.

Step-by-Step Solution

1
Provision the Google Service Account (GSA) and grant required GCP resource roles.
A GSA exists with permission to read objects from the target Cloud Storage bucket.
The GSA acts as the GCP IAM identity possessing the necessary permissions on GCP resources.
2
Provision the Kubernetes Service Account (KSA) in the application's GKE namespace.
A KSA identity is registered inside Kubernetes in the `analytics` namespace.
Pods running inside GKE require a local Kubernetes identity to map to GCP IAM.
3
Grant the `roles/iam.workloadIdentityUser` role on the GSA to the KSA member URI.
GCP IAM allows the specific `PROJECT_ID.svc.id.goog[analytics/KSA_NAME]` identity to impersonate the GSA.
This establishes authorization on the GCP side for the GKE Workload Identity pool principal.
4
Annotate the KSA with the metadata key `iam.gke.io/gcp-service-account=GSA_EMAIL`.
The GKE metadata server maps requests from pods using this KSA directly to the target GSA.
This completes the binding on the Kubernetes side so applications automatically acquire short-lived tokens for the GSA without managing JSON key files.

Key Concept

Configuring Workload Identity Binding between GKE KSAs and GCP GSAs
PreviousPage 11 / 14Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin