Examkin

All practice questions

262 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 241Question →

A cloud engineer needs to configure a Google Compute Engine VM instance to securely access objects in a Cloud Storage bucket following Google Cloud security best practices and least-privilege principles. Arrange the procedural 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 begins with creating the custom user-managed service account, followed by granting the specific storage IAM role to that service account, attaching the custom service account identity to the Compute Engine VM, and finally running the workload utilizing Application Default Credentials (ADC).
The correct operational order follows standard GCP security lifecycle practices: first, define the custom service account identity; second, delegate minimal resource-level IAM roles to that identity; third, attach the identity to the Compute Engine VM; and fourth, run the application using non-static Application Default Credentials (ADC) fetched from the metadata server.

Step-by-Step Solution

1
Create a custom user-managed service account identity using 'gcloud iam service-accounts create'.
A unique service account email identity is generated within the Google Cloud project.
Before permissions can be configured or assigned, the dedicated service account principal must exist.
2
Bind the predefined role 'roles/storage.objectViewer' to the service account email on the designated Cloud Storage bucket.
The service account gains read access to objects inside the target bucket according to the principle of least privilege.
Resource-level IAM permissions should be configured before attaching identity to running workloads.
3
Attach the custom service account to the Compute Engine VM instance during instance creation using '--service-account'.
The metadata server of the VM instance is configured to mint tokens for the custom service account instead of the default compute service account.
Attaching custom identities avoids using default service accounts that often carry overly permissive Editor roles.
4
Configure and execute the workload to authenticate using Google Application Default Credentials (ADC).
The application automatically queries the VM instance metadata server for short-lived access tokens without requiring exported JSON service account keys.
Google Cloud security best practices strongly discourage exporting and managing static service account keys.

Key Concept

Service Account Creation, Least Privilege Role Binding, and Compute Engine Attachment via Application Default Credentials
Estimated Time:2m 0s
Question 242Question →

A Cloud Engineer needs to restore a corrupted boot disk on a Compute Engine virtual machine instance named `app-server-1` using an existing disk snapshot named `app-boot-snapshot-v2`. In what sequence should the engineer execute the `gcloud` operations to replace the boot disk and restore the server?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence to restore the VM boot disk from a snapshot is: 1) Stop the `app-server-1` VM instance; 2) Create a new persistent disk from the snapshot; 3) Detach the corrupted boot disk; 4) Attach the new persistent disk with the `--boot` flag; 5) Start the VM instance.
To replace a boot disk on a Compute Engine instance using a snapshot, the engineer must follow a strict order: first, stop the instance because root disks cannot be detached while active; second, restore the snapshot to a new persistent disk; third, detach the broken boot disk; fourth, attach the newly restored disk using the `--boot` flag to declare it as the OS boot drive; and finally, start the VM instance.

Step-by-Step Solution

1
Stop the target VM instance
The instance transitions from `RUNNING` to `TERMINATED` state.
Compute Engine requires a virtual machine to be stopped before its boot disk can be detached or modified.
2
Provision a new persistent disk from the target snapshot
A standalone bootable persistent disk resource is generated containing data from the snapshot.
Snapshots represent point-in-time backups and must be instantiated into persistent disk objects before attachment.
3
Detach the failed boot disk volume from the VM
The VM instance metadata releases the existing boot disk reference.
Detaching the damaged volume clears the primary attachment interface for the replacement disk.
4
Attach the new persistent disk with boot priority
The restored disk is linked to the VM instance as index 0 (boot disk).
Including the `--boot` flag explicitly marks the volume as the bootable root disk rather than an additional data volume.
5
Start the repaired VM instance
The VM boots up using the restored operating system image.
Starting the instance executes the bootloader from the newly designated boot disk.

Key Concept

Compute Engine VM Boot Disk Replacement & Snapshot Recovery
Question 243Question →

A cloud security administrator needs to transition an enterprise Cloud Storage bucket containing financial audit data from legacy Access Control Lists (ACLs) to Uniform Bucket-Level Access. To ensure zero service disruption for automated workloads accessing the objects, what is the correct sequence of steps the administrator should execute?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: (1) Audit existing object ACL permissions and logs, (2) Grant equivalent predefined IAM roles at the bucket level, (3) Enable Uniform Bucket-Level Access on the bucket, and (4) Verify application workflows and monitor audit logs.
When transitioning a Cloud Storage bucket from fine-grained ACLs to Uniform Bucket-Level Access, you must first inspect current ACL usage to know which users require access. Second, you must grant those users equivalent bucket-level IAM roles (such as Storage Object Viewer or Creator) so their permissions remain valid under IAM. Third, you enable Uniform Bucket-Level Access on the bucket, which ignores ACLs and enforces IAM rules uniformly. Finally, you verify that all applications can still successfully access the bucket objects.

Step-by-Step Solution

1
Audit current access dependencies
Identified all accounts and service principals using object ACLs
Prevents accidental access loss by determining necessary access permissions prior to enforcement changes.
2
Assign IAM roles at the bucket level
Principals acquire bucket-level IAM authorization
Uniform Bucket-Level Access relies entirely on IAM policies; granting IAM roles first ensures uninterrupted authorization.
3
Activate Uniform Bucket-Level Access
Bucket access control is standardized to IAM; object ACLs are ignored
Enforces security compliance and uniform bucket management across all objects.
4
Validate application operations
Confirmed successful object read and write access under IAM control
Ensures post-migration stability and operational health.

Key Concept

Transitioning a bucket to Uniform Bucket-Level Access requires mapping ACL permissions to equivalent bucket-level IAM roles prior to enabling UBLA to prevent access disruption.
Question 244Question →

An Associate Cloud Engineer needs to deploy a new version of a stateless web application running on an existing regional Managed Instance Group (MIG) with zero downtime using the gcloud CLI. Order the steps required to execute this deployment correctly from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: first, create the updated Instance Template; second, assign the template to the Managed Instance Group; third, launch the rolling update action; and fourth, monitor instance health and deployment completion.
The Google Cloud recommended workflow for updating a Managed Instance Group requires creating an immutable Instance Template first, attaching that template to the target MIG, triggering the rolling update action to replace existing VMs, and finally verifying instance health.

Step-by-Step Solution

1
Run 'gcloud compute instance-templates create' with the new image tag/configuration.
A new instance template resource is created in the project.
Managed Instance Groups cannot update running VMs without a target instance template defining the desired state.
2
Run 'gcloud compute instance-groups managed set-instance-template' pointing to the new template.
The MIG metadata is updated to point to the new template.
The group manager needs to know which template to use when launching new VM instances.
3
Run 'gcloud compute instance-groups managed rolling-action start-update' with desired surge and availability parameters.
The MIG control plane begins replacing old instances with new instances in batches.
This initiates the actual rolling replacement process while preserving minimum operational capacity.
4
Run 'gcloud compute instance-groups managed list-instances' to observe instance status flags.
Confirms that all instances reach the RUNNING state and pass health checks.
Continuous verification ensures the update completed successfully without application degradation.

Key Concept

Managed Instance Group Rolling Updates via gcloud CLI
Question 245Question →

An infrastructure engineering team needs to set up a new isolated environment in Google Cloud using the `gcloud` CLI. Place the operational commands in the correct sequential order required to provision the custom VPC network, create a regional subnet, apply a targeted firewall rule, and launch a Compute Engine VM instance.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with initializing the custom-mode VPC network, followed by creating a regional subnet inside that network, defining a targeted ingress firewall rule on the network, and finally launching a Compute Engine VM instance attached to the subnet with matching network tags.
Provisioning Google Cloud networking resources requires adhering to strict infrastructure dependencies. A custom-mode VPC network must be instantiated first (`gcloud compute networks create --subnet-mode=custom`). Next, custom subnets must be provisioned inside that network (`gcloud compute networks subnets create`). Firewall rules bound to the VPC network must then be defined (`gcloud compute firewall-rules create`). Finally, Compute Engine VM instances can be deployed by binding them to the regional subnet and attaching network tags specified in the firewall rules (`gcloud compute instances create`).

Step-by-Step Solution

1
Execute `gcloud compute networks create enterprise-vpc --subnet-mode=custom` to create the custom-mode VPC network.
The VPC network `enterprise-vpc` is instantiated without default subnets.
Parent VPC network infrastructure must exist prior to defining subnets or network firewalls.
2
Execute `gcloud compute networks subnets create app-subnet-east --network=enterprise-vpc --region=us-east1 --range=10.1.0.0/24` to provision the subnet.
Subnet `app-subnet-east` is established within region `us-east1`.
In custom-mode VPC networks, virtual machine deployment requires pre-existing subnets in the target region.
3
Execute `gcloud compute firewall-rules create allow-app-ingress --network=enterprise-vpc --allow=tcp:8080 --source-ranges=10.1.0.0/24 --target-tags=app-backend` to apply firewall policies.
Ingress traffic on port 8080 is permitted for instances tagged `app-backend` on `enterprise-vpc`.
Firewall rules are associated directly with a VPC network and target specific instance tags.
4
Execute `gcloud compute instances create app-vm-1 --zone=us-east1-b --subnet=app-subnet-east --tags=app-backend` to deploy the VM instance.
Compute Engine instance `app-vm-1` is launched and receives an internal IP from `app-subnet-east`.
VM provisioning references the created subnet in the region and applies the network tag to inherit access rules.

Key Concept

Resource Dependency Order for Custom VPC Networks, Subnets, Firewalls, and Compute Instances
Question 246Question →

A DevOps engineer needs to grant an external automation pipeline short-lived authorization to upload build artifacts to a Google Cloud Storage bucket in project `proj-prod` without using long-lived service account key files. The engineer decides to implement service account impersonation. What is the correct sequence of steps to configure and execute this secure delegation workflow?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order begins with creating the dedicated service account, followed by granting object administration permissions to the service account on the Cloud Storage bucket, then delegating the Service Account Token Creator role on the service account to the calling principal, and finally running the gcloud command with the --impersonate-service-account flag.
The workflow follows logical identity management dependency. First, the service account identity must be created in the project (`[email protected]`). Second, resource permissions (`roles/storage.objectAdmin`) are granted to the service account so it possesses the necessary permissions. Third, impersonation privileges (`roles/iam.serviceAccountTokenCreator`) are granted on the service account resource to the external caller identity. Finally, the external caller executes the gcloud CLI command with `--impersonate-service-account` to generate short-lived tokens dynamically.

Step-by-Step Solution

1
Create the user-managed service account
Establishes a dedicated identity (`[email protected]`) in GCP IAM.
An identity must be instantiated in IAM before role bindings or delegation rules can target it.
2
Bind the target resource access role to the service account
Assigns `roles/storage.objectAdmin` on the destination bucket to the service account.
Defines what operations the service account is authorized to perform when active.
3
Grant Service Account Token Creator permission to the external caller
Binds `roles/iam.serviceAccountTokenCreator` on the service account resource to the principal initiating the workflow.
Allows the external caller identity to mint short-lived OAuth 2.0 access tokens for the target service account.
4
Invoke gcloud command with impersonation flag
The CLI automatically exchanges the caller's credentials for a temporary service account token and executes the storage upload operation.
Verifies end-to-end functionality using short-lived credentials without generating static private keys.

Key Concept

Service Account Creation, Permission Delegation, and Impersonation Sequence
Question 247Question →

An Associate Cloud Engineer needs to restore a corrupted secondary data disk attached to a standalone Compute Engine virtual machine named `prod-app-vm`. The engineer has an existing disk snapshot named `data-disk-snap-2026`. What is the correct sequence of steps to safely replace the corrupted disk with a restored disk from the snapshot?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Detach the corrupted persistent disk from the VM, 2) Create a new persistent disk from the specified snapshot, 3) Attach the newly created disk to the VM, and 4) Connect via SSH to mount the new disk inside the guest operating system.
Restoring data from a Compute Engine persistent disk snapshot requires first detaching the broken disk, creating a new persistent disk from the snapshot using the `--source-snapshot` flag, attaching that new persistent disk to the VM instance, and finally mounting the disk partition inside the guest OS via SSH.

Step-by-Step Solution

1
Detach the corrupted persistent disk from `prod-app-vm`
The corrupted disk is safely disconnected from the running virtual machine instance.
Detaching the damaged disk prevents resource conflicts and ensures the device location is cleared for replacement.
2
Provision a new disk using the snapshot source flag
A new GCP persistent disk is created containing the point-in-time snapshot data.
Disk snapshots cannot be attached directly to instances; they must first be restored into a persistent disk resource.
3
Attach the restored persistent disk to `prod-app-vm`
The virtual machine gains access to the restored block storage device.
The compute instance must have the new persistent disk attached at the infrastructure level.
4
SSH into `prod-app-vm` and mount the filesystem device
The file system on the restored disk becomes readable and writable by applications.
GCP infrastructure attachment makes the disk available as a device, but operating system mounting is required for application file access.

Key Concept

Compute Engine Persistent Disk Snapshot Restoration
Question 248Question →

A Cloud Engineer is tasked with migrating an enterprise Cloud Storage bucket containing legacy internal archives from fine-grained Access Control Lists (ACLs) to Uniform Bucket-Level Access (UBLA) to comply with organization security policies. Place the administrative steps in the correct sequential order to perform this migration safely without disrupting user access.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with auditing existing object ACL permissions, followed by assigning equivalent predefined IAM roles to affected principals, then enabling Uniform Bucket-Level Access on the bucket, and concluding with verifying object access and log monitoring.
The correct order follows GCP security best practices for migrating from ACLs to Uniform Bucket-Level Access: 1) Identify existing access requirements via an audit, 2) Provision equivalent IAM roles to prevent service disruption, 3) Turn on Uniform Bucket-Level Access on the bucket, and 4) Verify operation and monitor logs.

Step-by-Step Solution

1
Audit current access permissions
Identify all users, groups, and service accounts using per-object ACL access
Before revoking ACL evaluations, you must identify every principal relying on fine-grained object access to prevent unexpected outages.
2
Assign corresponding predefined IAM roles
Principals receive bucket-level or project-level IAM permissions (such as roles/storage.objectViewer)
Uniform Bucket-Level Access relies entirely on IAM policies; granting permissions via IAM prior to enabling UBLA maintains uninterrupted access.
3
Enable Uniform Bucket-Level Access
ACLs are disabled on the bucket and all contained objects
Executing the configuration update enforces uniform security across the entire bucket.
4
Validate and monitor access
Confirmed operational status via access tests and Cloud Audit Logs
Verification confirms that no applications or users experience authorization failures under the new IAM security model.

Key Concept

Uniform Bucket-Level Access (UBLA) migration workflow requires auditing legacy ACL access and granting IAM roles before disabling ACL processing on Cloud Storage buckets.
Question 249Question →

A cloud security engineer needs to configure Cloud Audit Logging to capture object-level read events in Google Cloud Storage for project `prod-data-vault`, stream these logs into a central BigQuery dataset for compliance auditing, and grant access to the security analysis team. Arrange the implementation steps in the correct logical and technical sequence from start to finish.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps is: 1. Enable DATA_READ Data Access audit logs for Google Cloud Storage in IAM & Admin. 2. Create a Cloud Logging sink filtering for storage Data Access audit logs targeted at BigQuery. 3. Grant the sink's generated writer service account the BigQuery Data Editor role on the destination dataset. 4. Grant security analysts the Private Logs Viewer IAM role.
First, DATA_READ logs for Google Cloud Storage must be enabled under IAM & Admin > Audit Logs because Data Access logging is disabled by default for Cloud Storage. Second, a Log Router sink must be created with the appropriate filter targeting the BigQuery dataset. Third, the unique writer service account created alongside the sink must be assigned BigQuery Data Editor permissions on the target dataset to allow writing logs. Fourth, security analysts must be granted the Private Logs Viewer role because standard Logs Viewer cannot access Data Access audit logs.

Step-by-Step Solution

1
Enable Cloud Storage Data Access Audit Logs
Google Cloud Storage starts writing DATA_READ access events to audit logs.
Data Access logs for most services are turned off by default. Enabling them in Audit Logs configuration is required before any downstream routing or analysis can occur.
2
Configure the Log Router Sink
A sink rule is established to catch storage Data Access audit logs and route them to BigQuery.
Creating the sink defines the export destination and log filter parameters.
3
Authorize the Sink Service Account
The sink service account is authorized to write log tables into BigQuery.
Log Router sinks use service accounts for authorization. The writer identity must have write access (`roles/bigquery.dataEditor`) to the target dataset.
4
Grant Analyst Read Access to Private Logs
Security analysts gain access to inspect Data Access log entries.
Because Data Access audit logs contain PII and sensitive data access details, Cloud IAM requires the specific `roles/logging.privateLogViewer` role rather than generic logging roles.

Key Concept

Configuring Cloud Audit Logging export workflows requires four core phases: log activation (Data Access logs are off by default), log sink creation, writer identity IAM authorization, and granular access control (Private Logs Viewer for Data Access logs).
Question 250Question →

An infrastructure engineer needs to set up an isolated enterprise application environment in Google Cloud using the `gcloud` CLI. The setup requires creating a custom VPC network, provisioning a subnet with Private Google Access enabled, establishing an ingress firewall rule targeting a specific network tag, and launching a Compute Engine instance configured with that network tag.

In what order should the engineer execute these operational steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: first create the custom VPC network, next create the subnet with Private Google Access enabled in that network, then create the ingress firewall rule with target tags on the network, and finally deploy the VM instance into the subnet with the matching network tag.
The correct order follows Google Cloud resource dependency requirements: the custom VPC network must be created first as the parent container, followed by creating the subnetwork within that network, establishing firewall rules attached to the network with target tags, and finally deploying the Compute Engine VM into the subnet with the matching target tag.

Step-by-Step Solution

1
Create the custom VPC network
Network `corp-vpc` is created without auto-generated subnets.
VPC networks serve as the top-level container for subnets and firewall rules in Google Cloud.
2
Create the custom subnetwork
Subnet `corp-app-subnet` is created in region `us-east4` with Private Google Access enabled.
Subnets define regional IP address ranges within a parent VPC network.
3
Configure the ingress firewall rule
Firewall rule `allow-corp-https` is created targeting tag `web-frontend`.
Defining network firewall rules before VM instantiation ensures immediate enforcement of access controls upon instance launch.
4
Deploy the VM instance
Instance `web-server-1` is instantiated in `corp-app-subnet` with tag `web-frontend`.
VM instances depend on existing subnetworks and network tags for IP allocation and security rule association.

Key Concept

Deployment dependency order for Google Cloud VPC networks, subnets, firewall rules, and Compute Engine instances.
Question 251Question →

An engineer needs to provision a dedicated Google Cloud service account for an internal reporting application running on a Compute Engine virtual machine instance. The application needs read-only access to objects in a specific Cloud Storage bucket. Place the following gcloud CLI operations in the correct chronological order required to create the service account, grant it the necessary IAM role, and attach it to the virtual machine instance during creation.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is to first create the service account identity, second bind the storage object viewer IAM role to the service account on the Cloud Storage bucket, and third create the Compute Engine VM attached to the configured service account.
To properly set up a non-human identity in Google Cloud, you must follow the lifecycle dependency order: first, define the service account principal (`gcloud iam service-accounts create`); second, grant it specific permissions via IAM bindings (`gcloud storage buckets add-iam-policy-binding`); and third, associate the fully configured identity with the compute infrastructure (`gcloud compute instances create --service-account=...`).

Step-by-Step Solution

1
Create the Service Account identity
The identity `[email protected]` is established in Cloud IAM.
You cannot grant roles to or attach a non-existent service account principal.
2
Grant Least-Privilege IAM Access
The service account is assigned `roles/storage.objectViewer` on the targeted Cloud Storage bucket.
Configuring access rules before launching the workload ensures the application has immediate authorization upon VM startup.
3
Attach the Service Account to Compute Engine VM
The Compute Engine VM boots up configured to authenticate as the custom service account with full `cloud-platform` access scopes.
Attaching the service account during VM creation binds the custom identity to the VM metadata server for automatic application default credential resolution.

Key Concept

Creating and binding a custom service account to a Compute Engine virtual machine instance following least-privilege security principles.
Question 252Question →

An Associate Cloud Engineer needs to update the container image running on a regional Managed Instance Group (MIG) without incurring downtime. Order the steps required to safely execute a rolling update of the MIG using the Google Cloud CLI.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Create a new instance template with the updated container image, 2) Update the Managed Instance Group to target the new instance template, 3) Issue the `gcloud compute instance-groups managed rolling-action start-update` command, and 4) Verify completion using `gcloud compute instance-groups managed wait-until --stable`.
To update a Managed Instance Group without downtime, you must first create a new instance template since templates are immutable. Next, update the MIG target template setting to point to the new version. Then, initiate the rolling update via `gcloud compute instance-groups managed rolling-action start-update`. Finally, execute `gcloud compute instance-groups managed wait-until --stable` to verify that all instances reach a healthy, updated state.

Step-by-Step Solution

1
Create a new Compute Engine instance template with the updated configuration.
A new immutable instance template resource is created in the GCP project.
Compute Engine instance templates cannot be edited once created.
2
Associate the new template with the Managed Instance Group.
The target instance template property of the MIG is updated.
The MIG manager requires an updated template reference before performing a rolling deployment.
3
Initiate the rolling update via gcloud CLI.
The MIG manager begins stopping and recreating instances according to the update policy.
Rolling updates replace instances systematically to preserve application availability.
4
Wait for the instance group to stabilize.
Confirmation that all instances in the group have been successfully updated and are passing health checks.
Verifying stability guarantees the update finished successfully without rolling back or stalling.

Key Concept

Managed Instance Group Rolling Updates and Instance Template Immutability
Question 253Question →

An engineer needs to configure a custom service account for an application running on a Google Compute Engine VM instance in project `prod-data-pipeline`. The application requires permission to write objects to Cloud Storage buckets within the project. What is the correct sequence of steps to configure least-privilege access and attach the service account to the VM instance?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: First, create the custom service account (`app-writer`). Second, grant the required IAM role (`roles/storage.objectAdmin`) to the service account email. Third, provision the Compute Engine VM instance with the service account attached and `cloud-platform` scope. Fourth, run application code on the VM to authenticate via Application Default Credentials (ADC).
The correct deployment order follows the GCP resource dependency lifecycle: First, create the service account resource to generate its unique email identifier. Second, grant the required predefined IAM role to the service account identity at the project level. Third, create the Compute Engine VM instance, attaching the custom service account with the `cloud-platform` scope so that IAM controls access. Fourth, launch the workload application which retrieves short-lived access tokens from the instance metadata server via Application Default Credentials.

Step-by-Step Solution

1
Create the service account identity in the target project.
Service account email `[email protected]` is generated.
An IAM identity must exist before IAM policy bindings or compute resource attachments can reference it.
2
Bind the required predefined IAM role to the service account identity.
The service account gains `roles/storage.objectAdmin` permissions on project `prod-data-pipeline`.
Permissions must be bound to the identity before compute workloads rely on it to perform storage operations.
3
Attach the service account during Compute Engine VM creation.
The Compute Engine VM `app-vm` is configured with the custom service account identity.
Attaching the service account at instance creation ensures the instance metadata server provides credentials for this identity.
4
Run application code leveraging metadata server ADC.
The application seamlessly authenticates without long-lived service account keys.
Application Default Credentials automatically query `http://metadata.google.internal` for short-lived access tokens.

Key Concept

Provisioning and attaching custom service accounts to Compute Engine instances using gcloud CLI and least-privilege IAM bindings.
Question 254Question →

A security engineer needs to configure a dedicated user-managed service account for an application that publishes telemetry data to Google Cloud Pub/Sub. To satisfy security policies prohibiting long-lived JSON keys, the developer group (`[email protected]`) must be granted access to test the application by impersonating the service account. Place the operational steps in the correct sequence to complete this configuration.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with creating the service account identity, assigning the Pub/Sub Publisher role to the service account, granting the Service Account Token Creator role to the developer group on the service account resource, and finally running test commands using the impersonation flag.
The logical and operational dependency order requires establishing the service account identity first. Second, functional workload access (`roles/pubsub.publisher`) is granted to the service account so it can interact with Pub/Sub. Third, security governance is enforced by granting the developer group the `roles/iam.serviceAccountTokenCreator` role specifically on the service account resource, enabling keyless short-lived credential generation. Fourth, developers can invoke commands using `--impersonate-service-account` to execute actions as the service account.

Step-by-Step Solution

1
Provision the service account identity
Service account `telemetry-pub-sa@<project-id>.iam.gserviceaccount.com` is registered in IAM.
An identity must exist in IAM before any IAM policies or role bindings can reference it.
2
Assign resource permissions to the service account
The service account holds `roles/pubsub.publisher` access.
The service account requires functional permissions to publish messages to the Google Cloud Pub/Sub topic.
3
Delegate impersonation permissions to the developer principal
Developers obtain `roles/iam.serviceAccountTokenCreator` on the service account resource.
Granting the Service Account Token Creator role on the specific service account allows developers to request short-lived credentials without exporting static JSON keys.
4
Run client tooling with impersonation
The CLI requests short-lived credentials and executes the Pub/Sub operations as the service account.
The `--impersonate-service-account` flag leverages the user's Token Creator role to automatically generate temporary tokens during execution.

Key Concept

Creating User-Managed Service Accounts and Configuring Impersonation via Service Account Token Creator
Estimated Time:1m 30s
Question 255Question →

A cloud security engineer needs to stream all Identity and Access Management (IAM) policy change audit logs from a Google Cloud project to a BigQuery dataset for long-term compliance analysis. In what sequential order should the engineer perform the steps to configure the Cloud Logging sink and grant the minimum necessary permissions for log streaming?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence requires creating the destination BigQuery dataset first, configuring the Cloud Logging sink to point to the dataset, retrieving the sink's generated writer identity service account, and finally granting that service account the BigQuery Data Editor role on the dataset.
Log export in GCP follows a strict dependency workflow. First, the destination resource (the BigQuery dataset) must exist. Second, creating the log sink produces a dedicated service account known as the writer identity. Third, the administrator must retrieve this identity string. Fourth, the administrator grants that writer identity permission (such as BigQuery Data Editor) directly on the target dataset. This ensures proper log routing under the principle of least privilege.

Step-by-Step Solution

1
Create the destination BigQuery dataset.
A target BigQuery dataset is created in the project to hold incoming log tables.
Log sinks require a pre-existing destination path upon creation.
2
Configure the Cloud Logging log sink targeting the BigQuery dataset.
The sink is established and Google Cloud automatically generates a unique service account (writer identity).
Creating the sink specifies what audit logs to filter and triggers identity generation.
3
Copy the generated writer identity service account identifier.
The exact service account email assigned to the sink is identified.
Permissions must be assigned to this specific identity to authorize log writing.
4
Grant the writer identity the BigQuery Data Editor role on the dataset.
Log entries begin streaming successfully from Cloud Logging into BigQuery.
Without dataset-level write permissions assigned to the sink's writer identity, log export attempts will fail due to access denied errors.

Key Concept

Cloud Logging Sinks and Service Account Writer Identity Authorization
Estimated Time:1m 30s
Question 256Question →

A cloud engineer needs to configure a running Compute Engine VM instance to securely read objects from a Cloud Storage bucket using a dedicated user-managed service account following Google Cloud security best practices. In what order should the engineer execute the following steps to complete this configuration using `gcloud` CLI tools?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps is: 1) Create the user-managed service account, 2) Grant the required IAM storage role on the bucket, 3) Stop the Compute Engine instance, 4) Attach the service account with the cloud-platform scope, and 5) Start the instance.
The proper sequence begins by provisioning the identity via IAM service-accounts create, binding the least-privilege predefined storage role to the bucket, stopping the VM instance, applying the new service account identity with full API access scopes using gcloud compute instances set-service-account, and finally starting the instance to enable metadata server token retrieval.

Step-by-Step Solution

1
Provision the service account identity
The service account `app-processor-sa` is created in IAM.
An identity must exist in IAM before permissions can be granted or attached to compute workloads.
2
Bind least privilege IAM roles to the service account
The service account gains read access specifically to objects within the target bucket.
Granting resource-level predefined roles ensures access control compliance prior to workload launch.
3
Stop the target Compute Engine instance
The VM instance transitions to the `TERMINATED` state.
Compute Engine service account association updates require the VM instance to be stopped.
4
Update VM configuration to assign the service account
The VM instance is configured with `app-processor-sa` and the `cloud-platform` access scope.
This configures the instance metadata server identity binding without embedding static keys.
5
Start the VM instance
The VM is running with the new service account identity.
Workloads running on the VM can now automatically query the metadata server for short-lived OAuth access tokens.

Key Concept

Creating and Attaching User-Managed Service Accounts to Compute Instances
Question 257Question →

A Security Operations analyst needs to enable tracking for sensitive bucket access and analyze the resulting Cloud Audit Logs for Google Cloud Storage within a specific GCP project. What is the correct sequence of steps to configure audit logging, assign necessary permissions, and retrieve the audit entries?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with configuring IAM & Admin Audit Logs to enable Data Access logging for Cloud Storage, followed by assigning the Private Logs Viewer role to the analyst. Next, open the Logs Explorer interface in the GCP Console, and finally execute the specific query filtering for Cloud Storage Data Access audit logs.
To inspect Data Access audit logs, the logs must first be generated by enabling them under IAM & Admin > Audit Logs. Second, security analysts must hold the Private Logs Viewer role because standard log viewing roles exclude sensitive Data Access payloads. Third, analysts navigate to Logs Explorer, and finally, they submit a filter expression pointing to the Cloud Storage service and the cloudaudit.googleapis.com/data_access log stream.

Step-by-Step Solution

1
Enable Cloud Storage Data Access Logs
GCP begins generating DATA_READ and DATA_WRITE audit events for Cloud Storage operations.
Data Access logs for Cloud Storage are not enabled by default.
2
Grant the Private Logs Viewer IAM Role
The analyst receives authorization to inspect Data Access audit log payloads.
Standard logging viewer permissions are insufficient for viewing sensitive Data Access audit payloads.
3
Access Logs Explorer
The Logs Explorer query builder opens for the project context.
Log viewing and analysis require accessing the log management interface.
4
Apply Search Filter
Matching Cloud Audit Log entries are displayed in the log results pane.
Filtering specifically for serviceName and logName isolates relevant Cloud Storage Data Access events.

Key Concept

Configuring, granting permissions for, and querying GCP Cloud Audit Logs (Data Access logs)
Question 258Question →

A cloud engineer needs to set up secure, keyless authentication for an external CI/CD pipeline to deploy containerized microservices to Google Cloud Run using Workload Identity Federation. In what order should the engineer perform the following steps to configure the service account identity and authorization according to GCP security best practices?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by creating the dedicated service account, granting it the required deployment roles, provisioning the Workload Identity Pool and Provider for external OIDC trust, and finally binding the Workload Identity User role on the service account to the external principal.
Establishing keyless deployment via Workload Identity Federation follows a clear dependency sequence: create the target GCP service account identity, grant it specific predefined permissions needed for the workload, set up the Workload Identity Pool/Provider to validate external OIDC tokens, and grant the external workload principal the Workload Identity User role on the service account to allow secure impersonation.

Step-by-Step Solution

1
Create the user-managed service account using `gcloud iam service-accounts create`.
A new service account resource is created in the project.
An explicit GCP service account identity is required before permissions can be assigned or external identities bound.
2
Assign required predefined IAM roles to the service account using `gcloud projects add-iam-policy-binding`.
The service account receives specific resource management permissions.
Following the principle of least privilege ensures the service account can only perform designated deployment actions.
3
Configure the Workload Identity Pool and Provider using `gcloud iam workload-identity-pools` commands.
GCP IAM establishes federated trust with the external OIDC identity provider.
The pool and provider define how external tokens are validated and mapped to GCP attributes.
4
Grant `roles/iam.workloadIdentityUser` on the service account to the external identity using `gcloud iam service-accounts add-iam-policy-binding`.
The external workload identity gains authorization to impersonate the service account.
This step enables keyless authentication without requiring exportable, long-lived JSON service account keys.

Key Concept

Workload Identity Federation Service Account Configuration Sequence
Question 259Question →

A security analyst must investigate object access patterns on a sensitive Google Cloud Storage bucket. Place the steps required to grant necessary access, configure audit logging, generate test events, and analyze the resulting logs in the correct sequential order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: 1) Grant the Private Logs Viewer role to the analyst, 2) Enable 'Data Read' Data Access audit logs for Cloud Storage under IAM & Admin Audit Logs, 3) Perform a read operation on the target bucket objects, 4) Execute the `gcloud logging read` command filtering for the data_access logName and bucket resource.
The workflow follows a logical security lifecycle: first establish least privilege permissions (Private Logs Viewer role), second activate the audit logging policy for Cloud Storage Data Read actions, third generate sample traffic by reading bucket objects, and finally retrieve the resulting Data Access audit log entries using gcloud CLI.

Step-by-Step Solution

1
Ensure IAM access permissions are configured.
The analyst receives permissions to view private audit logs via `roles/logging.privateLogViewer`.
Standard `roles/logging.viewer` cannot view Data Access audit logs containing PII/sensitive details.
2
Enable Data Access audit logging for Google Cloud Storage.
Cloud Storage begins writing DATA_READ audit log entries.
Except for BigQuery, Data Access audit logs are disabled by default in GCP to reduce log storage costs.
3
Trigger bucket access activity.
Cloud Storage generates a `cloudaudit.googleapis.com/data_access` log entry.
Audit events are created only when operations happen after the feature configuration is active.
4
Query the generated logs via gcloud CLI.
The analyst retrieves and reviews the structured JSON audit entries.
Running a filter targeted at `logName` and `resource.type` isolates the specific Cloud Storage Data Access logs.

Key Concept

Viewing and Analyzing Cloud Audit Logs
Estimated Time:1m 30s
Question 260Question →

A cloud engineer needs to configure a Compute Engine virtual machine to securely export application logs to Cloud Logging using a dedicated service account and least privilege access. What is the correct sequence of steps to establish this service account authentication flow?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins by creating the user-managed service account identity, binding the required least-privilege IAM role (`roles/logging.logWriter`) to that identity at the project level, attaching the service account to the target Compute Engine VM instance, and finally configuring application code to authenticate using Application Default Credentials (ADC).
Establishing a service account workflow follows a strict lifecycle: first, the identity must be created in IAM. Next, access permissions (the predefined `roles/logging.logWriter` role) are bound to the service account. After authorization is configured, the identity is attached to the virtual machine instance so the metadata server can issue tokens. Finally, the application consumes these tokens seamlessly via Application Default Credentials without downloading explicit key files.

Step-by-Step Solution

1
Create the Service Account
A unique service account identity email is generated within the Google Cloud project.
An identity must exist before IAM policy bindings or resource attachments can reference it.
2
Delegate IAM Roles
The service account is granted `roles/logging.logWriter` on the target project resource.
Least-privilege authorization must be established so the identity has permission to write logs when authenticated.
3
Attach to Compute Engine Instance
The VM instance metadata server is configured to provide access tokens for the dedicated service account.
Attaching the service account allows workloads running on the virtual machine to inherit its identity securely.
4
Leverage Application Default Credentials
Application code automatically retrieves short-lived OAuth 2.0 access tokens from the local instance metadata server.
Using ADC avoids exporting and managing persistent service account JSON keys.

Key Concept

Creating, granting permissions to, attaching, and consuming user-managed service accounts using Application Default Credentials on Compute Engine.
PreviousPage 13 / 14Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin