Examkin

All practice questions

262 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 221Question →

A Cloud Engineer is tasked with performing a canary release for an updated container image on an existing Cloud Run service named `orders-api`. The objective is to deploy the updated revision without exposing it to live production traffic immediately, perform validation on the revision's dedicated URL, gradually shift 10% of production traffic to the new revision, and monitor its operational metrics. Sequence the following deployment and traffic management steps in the correct order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps for a Cloud Run canary deployment is: 1) Deploy the new container image using `gcloud run deploy` with the `--no-traffic` flag, 2) Test the new revision using its direct revision-specific URL, 3) Update the traffic distribution using `gcloud run services update-traffic` to route 10% of traffic to the new revision, and 4) Monitor service logs and metrics in Cloud Operations to verify operational health.
The deployment workflow requires creating the revision safely without live traffic (`--no-traffic`), verifying its health via direct revision URL targeting, applying a 10% canary traffic split with `gcloud run services update-traffic`, and finally inspecting metrics in Cloud Operations to ensure baseline operational stability.

Step-by-Step Solution

1
Deploy the updated container image to Cloud Run ensuring live traffic is not impacted.
A new Cloud Run revision is instantiated, but 100% of production traffic continues to serve from the existing revision due to `--no-traffic`.
Deploying with `--no-traffic` prevents unverified code from immediately receiving live production requests.
2
Perform direct revision testing.
The engineer confirms that the revision responds correctly without risking impact on end users.
Cloud Run automatically assigns a unique URL (or tag-based URL) to each revision for targeted testing.
3
Configure traffic splitting via CLI.
10% of inbound service requests are routed to the new revision and 90% to the previous revision.
The command `gcloud run services update-traffic` adjusts traffic percentages across active revisions.
4
Observe performance and error metrics.
Metrics confirm whether the canary revision operates stably under real traffic conditions.
Monitoring latency and HTTP error rates provides empirical proof of success before rolling out 100% of traffic.

Key Concept

Canary Deployments and Traffic Splitting in Cloud Run
Question 222Question →

A cloud engineering team needs to standardize a base environment for auto-scaling a web application currently running on a standalone Compute Engine instance. The team plans to capture the configuration of the existing instance's boot disk, package it into a custom image, and use that image to generate an instance template for a new Managed Instance Group (MIG). In what sequential order should the engineer perform these gcloud CLI operations to ensure data consistency and proper resource dependency?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct execution sequence is: 1) Stop the source Compute Engine instance to flush disk caches and guarantee data consistency. 2) Create a persistent disk snapshot from the stopped VM's boot disk. 3) Create a custom image with the snapshot specified as its source. 4) Create an instance template referencing the newly created custom image.
The correct order follows dependency and data-integrity requirements: stopping the VM ensures disk consistency, creating a disk snapshot captures that state, building a custom image from the snapshot provides a reusable boot resource, and defining the instance template uses the finished custom image.

Step-by-Step Solution

1
Halt file system writes on the source virtual machine.
The VM enters the TERMINATED state, ensuring disk integrity.
Creating snapshots from a running instance without stopping it or unmounting the file system can lead to crash-inconsistent snapshots.
2
Execute `gcloud compute disks snapshot` against the instance boot disk.
A consistent persistent disk snapshot resource is created.
Snapshots store point-in-time data required to build portable, versioned images.
3
Execute `gcloud compute images create` pointing to the snapshot as the source.
A custom image resource is added to the project's image family/catalog.
Instance templates require a boot image reference, which is constructed from the snapshot asset.
4
Execute `gcloud compute instance-templates create` with the `--image` flag set to the custom image.
An instance template is established for deployment into Managed Instance Groups.
Instance templates are immutable specifications that require all underlying image dependencies to already exist.

Key Concept

Compute Engine Image and Template Lifecycle Management
Question 223Question →

A cloud security administrator must set up audit logging to track and analyze user access to Cloud SQL databases across all projects within an organization. The solution requires enabling Cloud SQL Data Access audit logging, aggregating and routing these logs to a central BigQuery dataset in a security project, and granting a security analyst least-privilege permissions to inspect these logs in both Logs Explorer and BigQuery. What is the correct sequence of steps to configure log generation, export routing, writer authorization, and analyst access?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by enabling Data Access audit logging for Cloud SQL, creating an aggregated organization log sink targeting BigQuery, granting the sink service account write access to the dataset, assigning the Private Logs Viewer role to the analyst for Cloud Logging, and finally granting BigQuery Data Viewer permissions for SQL analysis.
The workflow follows logical and administrative dependencies: log generation must first be enabled for the service; log collection and destination routing must then be established at the organization level; the sink's unique service account must be authorized to write to the destination dataset; and finally, least-privilege IAM permissions must be granted to the analyst for inspecting logs in both Logs Explorer (Private Logs Viewer) and BigQuery (BigQuery Data Viewer).

Step-by-Step Solution

1
Enable Audit Log Generation
Cloud SQL Admin API generates DATA_READ and DATA_WRITE audit events.
Data Access audit logs are disabled by default for most GCP services (except BigQuery). Enabling them in the IAM Audit Logs interface is mandatory to begin producing log entries.
2
Configure Aggregated Log Sink
Organization-wide audit entries are directed to the central BigQuery dataset.
An aggregated sink at the organization node ensures that logs across all child folders and projects are collected into one sink destination.
3
Authorize Writer Identity
The log sink service account receives write authorization on BigQuery.
GCP log sinks use dedicated writer service accounts. Without assigning roles/bigquery.dataEditor on the target dataset, exported logs will be dropped.
4
Grant Cloud Logging IAM Permissions
The security analyst gains permission to inspect private audit logs in Cloud Logging.
Standard roles/logging.viewer permissions do not grant access to Data Access logs. The roles/logging.privateLogViewer role is required.
5
Grant BigQuery Query Permissions
The security analyst can execute SQL queries against the audit log tables in BigQuery.
Permissions in Cloud Logging do not transfer to BigQuery; explicit roles/bigquery.dataViewer access on the sink dataset is required.

Key Concept

Configuring Cloud Audit Log Enablement, Sink Routing, Writer Service Account Authorization, and Private Log Access Control
Question 224Question →

An enterprise cloud security architect is standardizing access controls on a Cloud Storage bucket named `enterprise-data-repository` by transitioning from legacy Access Control Lists (ACLs) to Uniform Bucket-Level Access (UBLA). Arrange the following administrative actions in the correct chronological sequence to complete this migration without causing access disruption for existing service accounts.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for transitioning to Uniform Bucket-Level Access is: 1) Identify ACL dependencies by reviewing Cloud Audit Logs; 2) Assign equivalent bucket-level IAM roles to affected principals; 3) Enable Uniform Bucket-Level Access using the gcloud storage tool; 4) Confirm that access operates strictly via IAM and ACL modification attempts are blocked.
The correct sequence ensures uninterrupted application access during a UBLA migration. First, inspecting audit logs identifies which accounts rely on object ACLs. Second, mapping those permissions to IAM roles at the bucket level guarantees access continuity. Third, enabling Uniform Bucket-Level Access via gcloud centralizes access control. Fourth, validating bucket behavior confirms that legacy ACL requests are properly rejected while IAM access functions as expected.

Step-by-Step Solution

1
Audit current object ACL usage.
Identified list of service accounts and user identities currently depending on object-level ACLs.
Understanding active access patterns prevents accidental revocation of access when ACLs are disabled.
2
Assign corresponding Cloud Storage IAM roles.
Principals receive bucket-level predefined roles such as Storage Object Viewer or Storage Object User.
Uniform Bucket-Level Access ignores object ACLs and relies solely on IAM; pre-granting IAM roles ensures continuous access.
3
Activate Uniform Bucket-Level Access on the bucket.
Fine-grained ACLs are deactivated, and access control is centralized under IAM.
Executing the gcloud storage update command applies UBLA, standardizing permission checks at the bucket boundary.
4
Validate permission enforcement and workflow continuity.
Verified that read/write operations succeed via IAM and ACL assignment calls fail as expected.
Testing confirms that the security migration met compliance standards without introducing unintended operational failures.

Key Concept

Uniform Bucket-Level Access (UBLA) migration workflow and IAM role assignment
Question 225Question →

A cloud engineer needs to deploy a new Compute Engine virtual machine instance into a specific VPC subnet using a pre-reserved static internal IP address. Additionally, the instance requires a secondary persistent disk populated from an existing disk snapshot. What is the correct sequence of steps to execute this deployment using the Google Cloud CLI?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: 1) Reserve a static internal IP address in the target subnet using gcloud compute addresses create; 2) Create a secondary persistent disk from the disk snapshot using gcloud compute disks create --source-snapshot; 3) Provision the Compute Engine VM instance using gcloud compute instances create --private-network-ip; 4) Attach the secondary persistent disk to the VM instance using gcloud compute instances attach-disk.
Provisioning a Compute Engine instance with dependent network and storage resources requires creating prerequisite assets before referencing them. First, the static internal IP must be reserved in the subnet. Second, the persistent disk must be generated from the snapshot. Third, the instance is provisioned using the reserved private IP. Finally, the secondary persistent disk is attached to the newly created VM instance.

Step-by-Step Solution

1
Reserve the static internal IP address in the target subnet.
A static internal IP address resource is created and held in the target subnet.
Assigning a specific internal IP during VM creation requires reserving the address beforehand.
2
Create the secondary persistent disk using the source snapshot.
A zonal persistent disk containing data from the snapshot is created.
The disk must exist as an independent GCP resource before attaching it to a VM instance.
3
Deploy the Compute Engine VM instance specifying the reserved private IP address.
The primary VM instance boots attached to the subnet with the designated static internal IP address.
The instance creation command references the static internal IP reserved in Step 1.
4
Attach the secondary persistent disk to the running VM instance.
The secondary disk is successfully attached to the VM instance for mounting and use.
Attaching a disk requires both the target VM instance and the persistent disk resource to be present in the same zone.

Key Concept

Compute Engine VM Provisioning with Static Internal IP and Secondary Persistent Disks
Estimated Time:1m 30s
Question 226Question →

An Associate Cloud Engineer needs to perform a controlled canary rollout of a new application revision across an existing Managed Instance Group (MIG) named `frontend-mig`. The deployment strategy requires testing the updated software on a fraction of the instances before fully updating the entire group. In what order should the engineer execute the following `gcloud` operations to complete this canary deployment safely?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of operations is: 1) Create the new instance template (`frontend-template-v2`), 2) Initiate the canary update by specifying `--canary-version` with a restricted target size, 3) Verify canary instance health using `list-instances`, and 4) Promote `frontend-template-v2` to the primary version for full deployment across all instances in the group.
The proper administrative workflow for a canary update on Compute Engine Managed Instance Groups requires creating the new instance template first. Next, the engineer initiates a rolling update using canary flags to deploy the template to a minor subset of instances. After verifying instance state and application health, the engineer promotes the new template to cover 100% of the MIG.

Step-by-Step Solution

1
Define the target configuration.
A new instance template (`frontend-template-v2`) is created in Google Cloud.
Managed Instance Groups deploy VMs based on instance templates; any software or OS update requires a new template object.
2
Start canary update on MIG.
A subset of instances in `frontend-mig` are replaced with VMs running `frontend-template-v2`.
Using `rolling-action start-update` with `--canary-version` limits risk by updating only a specified portion of the fleet.
3
Validate canary instance health.
Instance status and autohealing health checks confirm the canary instances are running correctly.
Canary testing requires operational verification before scaling the change to production capacity.
4
Complete rolling update across the entire group.
All instances in `frontend-mig` are updated to `frontend-template-v2`.
Setting the new template as the primary version completes the deployment process.

Key Concept

Managed Instance Group Rolling Updates and Canary Deployments
Question 227Question →

A cloud engineer needs to deploy a new Compute Engine virtual machine instance that relies on a custom OS image stored in a separate centralized image-repository project. The VM must be assigned a reserved static internal IP address within a specific subnet and execute an automated initialization script upon first boot. What is the correct sequence of steps required to prepare resources, deploy the instance, and verify startup execution?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct workflow requires establishing cross-project IAM permissions (granting compute.imageUser on the source project), reserving the static internal IP address in the target subnet, executing the instance creation command with the specified parameters, and finally verifying startup script execution via the serial port output.
Deploying a Compute Engine instance with cross-project dependencies and reserved networking requires completing IAM authorization and network resource allocation first. Granting roles/compute.imageUser on the source image project ensures permission to read the image. Reserving the static internal IP address in the target subnet ensures the network resource is allocated. After these prerequisites are met, running gcloud compute instances create provisions the VM with the reserved IP and startup script. Finally, checking serial port output allows post-boot verification of the initialization process.

Step-by-Step Solution

1
Grant cross-project IAM permissions
The deploying identity gains authorization to pull the disk image from the central image repository project.
Without roles/compute.imageUser granted on the source project, instance creation will fail due to access denied errors.
2
Reserve the static internal IP address
A specific internal IP address within the target subnet is allocated for the VM.
The static IP must exist in Compute Engine before it can be assigned via the --private-network-ip flag during instance creation.
3
Run gcloud compute instances create
The VM instance is provisioned using the reserved IP, custom image, and startup script.
This command provisions the instance using all configured resources and metadata.
4
Verify execution using get-serial-port-output
Console output logs generated by the guest OS and startup script are retrieved.
Startup script output is streamed to the serial console, providing empirical verification of script completion.

Key Concept

Cross-Project Compute Engine VM Provisioning and Initialization Workflow
Question 228Question →

A cloud engineer needs to deploy a containerized web application to Google Cloud Run from local application source code in a newly created Google Cloud project. Place the operational steps in the correct execution sequence from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct execution sequence is: 1. Enable the Cloud Run API and Cloud Build API. 2. Package and push the container image to Artifact Registry using gcloud builds submit. 3. Deploy the container image to Cloud Run using gcloud run deploy. 4. Grant the roles/run.invoker IAM role using gcloud run services add-iam-policy-binding.
The correct order follows the lifecycle dependencies of serverless container deployments on GCP. First, API enablement enables project capabilities. Second, Cloud Build compiles local code into a stored container artifact in Artifact Registry. Third, Cloud Run references that artifact to create a revision and endpoint. Fourth, IAM policy binding sets invoker access permissions on the created Cloud Run service.

Step-by-Step Solution

1
Enable required Google Cloud Service APIs
Cloud Run and Cloud Build APIs are active in the project
Google Cloud service endpoints must be enabled prior to invoking build and deployment commands.
2
Execute `gcloud builds submit --tag LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE:TAG`
Container image is compiled and pushed to Artifact Registry
Cloud Run requires an existing container image hosted in Artifact Registry or Container Registry.
3
Execute `gcloud run deploy SERVICE_NAME --image LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE:TAG`
Cloud Run revision is created and assigned an HTTPS endpoint
Deploys the packaged container workload to the managed serverless infrastructure.
4
Execute `gcloud run services add-iam-policy-binding SERVICE_NAME --member=... --role=roles/run.invoker`
IAM invoker permissions are assigned to the deployed service
Secures or exposes the active service endpoint to specified identities.

Key Concept

Cloud Run deployment workflow from source code using gcloud CLI and Artifact Registry
Question 229Question →

A DevOps engineer needs to safely roll out a new version of a Cloud Run service named `billing-api` in the `us-central1` region by creating a tagged revision, sending a small percentage of test traffic to it, and finally shifting all production traffic to the new revision once verified. Place the following `gcloud` CLI steps in the correct chronological order to complete this canary release workflow.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence to perform a tagged canary rollout on Cloud Run is: 1) Deploy the new revision with `--no-traffic` and `--tag=canary`, 2) Test the revision via its dedicated tag URL, 3) Update traffic to route 10% of production traffic to the `canary` tag, and 4) Route 100% of traffic to the new revision using `--to-latest`.
A standard zero-downtime canary deployment sequence in Cloud Run requires deploying the new code revision with no initial traffic allocation using `--no-traffic` while assigning a revision tag (`--tag`). Next, the engineer tests the container using the generated tag-specific URL. After successful direct verification, a small percentage of live production traffic is assigned to the tag using `gcloud run services update-traffic --to-tags`. Finally, after monitoring stability, 100% of live traffic is shifted to the latest revision.

Step-by-Step Solution

1
Deploy the updated container container with `--no-traffic` and `--tag=canary`.
The revision is created and receives a uniqueURL prefix (`canary---...`), but receives 0% of the main service URL's incoming traffic.
This allows safe deployment to production infrastructure without exposing live users to unverified code.
2
Perform smoke tests directly against the tagged URL.
Validation of service responses and health checks in the live environment.
Verifies that the revision initializes correctly without risking production traffic.
3
Execute `gcloud run services update-traffic billing-api --region=us-central1 --to-tags=canary=10`.
10% of live traffic hitting the main service URL is diverted to the canary revision.
Gradually introduces production load to monitor error rates and latency metrics.
4
Execute `gcloud run services update-traffic billing-api --region=us-central1 --to-latest`.
100% of main service URL traffic is directed to the newest revision.
Completes the canary release once stability is confirmed.

Key Concept

Cloud Run Traffic Splitting & Revision Tagging Workflow
Question 230Question →

An Associate Cloud Engineer needs to increase the available disk space for a stateful application running on a Linux Compute Engine VM without restarting or replacing the existing Persistent Disk. Sequence the steps required to safely expand the disk capacity and make the additional storage space usable by the operating system.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with expanding the Persistent Disk capacity in GCP (`gcloud compute disks resize`), followed by connecting to the VM via SSH (`gcloud compute ssh`), extending the disk partition table (`growpart`), and finally expanding the guest filesystem (`resize2fs` or `xfs_growfs`).
Expanding persistent storage on a live Compute Engine VM requires a top-down layer approach: provision additional raw block storage at the GCP control plane (`gcloud compute disks resize`), gain access to the OS (`gcloud compute ssh`), update the partition table to encompass the new space (`growpart`), and finally resize the filesystem layer (`resize2fs` or `xfs_growfs`).

Step-by-Step Solution

1
Resize the Persistent Disk resource via GCP infrastructure.
GCP provisions additional raw block storage for the disk attached to the VM.
The hypervisor must present larger physical disk space before the VM guest OS can recognize added capacity.
2
SSH into the VM instance CLI.
An active interactive terminal session inside the guest OS is opened.
Resizing the GCP disk resource does not automatically reconfigure guest OS partitions or filesystems.
3
Run partition expansion tools (`growpart`).
The target partition boundary is grown to encompass the unallocated blocks on the raw disk device.
Filesystems reside within partition boundaries; expanding the partition table must precede filesystem expansion.
4
Run filesystem growth utilities (`resize2fs` or `xfs_growfs`).
The filesystem expands to consume the newly enlarged partition space.
The filesystem layer manages block allocation tables and must be explicitly resized to make storage usable by applications.

Key Concept

Compute Engine Persistent Disk Resizing Procedure
Estimated Time:1m 30s
Question 231Question →

A cloud engineer needs to deploy an isolated enterprise application environment in Google Cloud using the Google Cloud CLI (`gcloud`). Arrange the administrative steps in the correct operational order to provision the networking infrastructure and deploy the application instance safely.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The operational sequence requires first creating the custom VPC network, next adding the custom subnet, followed by establishing the ingress firewall rule with target tags, and finally creating the Compute Engine instance bound to the subnet and network tag.
In Google Cloud Platform networking, resources must be created following structural dependencies. First, a custom-mode VPC network must exist to act as the parent object. Second, a subnet within that VPC must be created to define regional CIDR IP blocks. Third, firewall rules are attached to the VPC network with target tags so traffic rules are active. Finally, the Compute Engine VM instance is created referencing the custom subnet and network tags.

Step-by-Step Solution

1
Create the custom-mode VPC network
The VPC container is initialized with no automatically generated subnets.
Subnets and firewall rules require a host VPC network to exist before they can be configured.
2
Create the custom subnet within the designated region
An IP CIDR allocation is bound to the target region under the custom VPC.
Compute instances in a custom VPC require an explicit subnet reference upon creation.
3
Configure firewall rules for incoming traffic
Traffic filters and target network tags are registered within the VPC network.
Security policies should be established before instance deployment to ensure instances are immediately protected.
4
Provision the Compute Engine virtual machine instance
The VM starts with an internal IP assigned from the subnet and traffic controlled by the firewall rule.
Creating the instance depends on both the active subnet for IP allocation and network tags for firewall policy matching.

Key Concept

Deployment dependency order for GCP Virtual Private Cloud (VPC) networks, custom subnets, firewall rules, and compute workloads.
Question 232Question →

A cloud engineer must deploy a Compute Engine virtual machine instance that automatically executes a startup script to read files from a secure Cloud Storage bucket. To ensure least-privilege security, the VM must authenticate using a dedicated custom service account rather than the default Compute Engine service account. Place the operational steps in the correct chronological order required to set up and deploy this VM instance.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational order is: 1) Create the custom IAM service account, 2) Grant the Storage Object Viewer IAM role to the service account, 3) Execute the gcloud compute instances create command with the service account and startup script metadata flags, and 4) Verify VM startup and inspect logs.
Proper GCP infrastructure deployment dictates creating identity resources (service accounts) first, granting them specific role permissions second, instantiating compute resources with those identities and metadata scripts third, and verifying log execution fourth.

Step-by-Step Solution

1
Identity Creation
A custom service account is created in the project.
An identity must exist before access permissions can be granted or assigned to resources.
2
Role Binding
The service account receives the Storage Object Viewer role on the bucket.
Granting least-privilege access prior to VM creation ensures the VM's workload can immediately access required resources upon initialization.
3
Instance Provisioning
The VM is created via gcloud CLI with the identity and script attached.
Specifying `--service-account` and `--metadata-from-file` during provisioning binds the identity and startup script to the instance.
4
Validation
Logs confirm the startup script successfully read from the bucket.
Post-deployment validation ensures the identity credentials and startup script operated as expected.

Key Concept

Compute Engine Service Account Provisioning & Startup Configuration
Question 233Question →

A Cloud Engineer needs to execute a safe canary rollout of a updated container image for an existing Cloud Run service named `order-processor`. Arrange the operational steps in the correct order from first to last to complete the canary deployment and traffic transition without risking immediate full-production downtime.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for a Cloud Run canary rollout is: 1) Deploy the new image using `--no-traffic` and assign a revision tag. 2) Direct verification requests to the tag-specific URL. 3) Route a small percentage of live traffic to the tagged revision. 4) Shift 100% of live production traffic to the latest revision.
A safe canary deployment in Cloud Run follows a distinct lifecycle: first creating the new revision isolated with `--no-traffic` and a dedicated tag, testing the tag-specific URL directly, initiating a partial live traffic split using `gcloud run services update-traffic --to-tags`, and finally updating the service traffic to 100% (`--to-latest`) once stability is verified.

Step-by-Step Solution

1
Deploy revision with traffic suppression and a revision tag
A new revision is instantiated without receiving traffic from the primary service URL.
The `--no-traffic` flag prevents automatic 100% traffic assignment to new deployments.
2
Validate revision via tag-specific endpoint URL
Functionality is verified on `https://canary---order-processor-REGION.a.run.app`.
Revision tags provide isolated subdomains for pre-release validation.
3
Apply canary traffic split using CLI
10% of incoming live traffic is routed to the `canary` tag, while 90% remains on the previous stable revision.
`gcloud run services update-traffic --to-tags` manages granular percentage traffic allocation.
4
Promote latest revision to receive full traffic load
100% of production traffic is routed to the new revision.
Using `--to-latest` completes the canary deployment once stability is confirmed under live load.

Key Concept

Cloud Run Revision Tagging and Traffic Splitting Sequence
Question 234Question →

An Associate Cloud Engineer needs to add an additional non-boot persistent disk to an existing Compute Engine Linux VM instance and prepare it for application data storage. What is the correct sequence of steps to provision, attach, and configure this storage resource?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Create the Persistent Disk via gcloud compute disks create, 2) Attach the disk to the VM instance via gcloud compute instances attach-disk, 3) SSH into the VM and format the raw device using sudo mkfs.ext4, and 4) Create a target directory and mount the formatted disk using sudo mount.
The correct workflow follows a standard infrastructure provisioning and operating system administration pattern. First, the cloud resource must be provisioned in GCP using the `gcloud compute disks create` command. Second, the newly created disk resource is attached to the VM instance via `gcloud compute instances attach-disk`. Third, within the VM's SSH session, the Linux operating system formats the newly recognized raw block device with an `ext4` filesystem using `sudo mkfs.ext4`. Finally, the formatted filesystem is mounted to a designated local directory using `sudo mount`.

Step-by-Step Solution

1
Provision the zonal Persistent Disk in Google Cloud.
A new block storage disk is allocated within the target zone.
Storage resources must exist in the cloud control plane prior to attachment.
2
Attach the disk resource to the Compute Engine VM instance.
The block device becomes accessible to the guest operating system hardware controller.
Attaching exposes the raw block device (e.g., /dev/sdb or google-disk-name) to the Linux kernel.
3
Format the raw block device inside the VM guest OS.
An ext4 file system structure is written to the block device.
Operating systems cannot write or read files on unformatted raw block devices.
4
Mount the filesystem to a target directory in Linux.
The persistent storage becomes active and usable at the specified directory path.
Linux requires mounting formatted storage devices into the OS directory tree for application access.

Key Concept

Compute Engine Persistent Disk provisioning, attachment, formatting, and mounting lifecycle.
Estimated Time:1m 30s
Question 235Question →

A cloud administrator needs to deploy a custom Virtual Private Cloud (VPC) environment in Google Cloud using the gcloud CLI. The environment must host a web application and include a custom network, a region-specific subnet, an ingress firewall rule restricted by network target tags, and a virtual machine instance. Arrange the following administrative steps in the correct chronological execution order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct execution order is: 1) Create the custom VPC network (`prod-vpc`), 2) Provision the regional subnet (`prod-subnet-uscentral1`), 3) Create the ingress firewall rule (`allow-prod-https`), 4) Deploy the Compute Engine instance (`web-vm-1`).
In Google Cloud networking, resource creation follows a strict strict dependency hierarchy. First, the custom VPC network (`prod-vpc`) must be initialized using `--subnet-mode=custom` so that default subnets are not created. Next, a specific regional subnet (`prod-subnet-uscentral1`) must be created within that network to define the primary internal CIDR range. Third, the ingress firewall rule (`allow-prod-https`) is added to the network to allow HTTPS traffic on TCP port 443 targeted to the tag `web-server`. Finally, the Compute Engine virtual machine (`web-vm-1`) is created inside the subnet and assigned the `web-server` tag, completing the deployment.

Step-by-Step Solution

1
Create the custom-mode VPC network using `gcloud compute networks create prod-vpc --subnet-mode=custom`.
An empty custom VPC network container without auto-generated subnets is created.
Google Cloud requires a VPC network to exist before subnets or firewall rules can be attached to it.
2
Provision a regional subnet using `gcloud compute networks subnets create prod-subnet-uscentral1 --network=prod-vpc --region=us-central1 --range=10.100.0.0/24`.
A custom IP range (`10.100.0.0/24`) is allocated in `us-central1` under `prod-vpc`.
Compute Engine virtual machines in custom-mode networks require an existing subnet in their target region to bind their primary internal IP.
3
Define the ingress firewall rule using `gcloud compute firewall-rules create allow-prod-https --network=prod-vpc --allow=tcp:443 --target-tags=web-server`.
Firewall policy is attached to `prod-vpc` to permit HTTPS traffic to instances tagged `web-server`.
Establishing security policies on the network before instance creation ensures incoming traffic is properly controlled as soon as the instance provisions.
4
Deploy the Compute Engine instance using `gcloud compute instances create web-vm-1 --zone=us-central1-a --subnet=prod-subnet-uscentral1 --tags=web-server`.
The VM instance boots up attached to `prod-subnet-uscentral1` with the `web-server` network tag applied.
Instance creation requires both the target subnet and the target tags specified in previous steps.

Key Concept

Resource dependency hierarchy in GCP VPC network provisioning (VPC Network → Subnet → Firewall Rule → VM Instance).
Question 236Question →

A cloud engineer needs to create a standardized custom boot image from an existing baseline Compute Engine VM instance named `web-base-vm` and deploy a new instance named `web-prod-1` in zone `us-central1-b` using this custom image. Arrange the administrative steps required to complete this VM cloning and deployment workflow in the correct chronological order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by stopping the source VM instance, creating a persistent disk snapshot, generating a custom image from that snapshot, deploying the new VM instance using the custom image flag, and finally restarting the original source VM instance.
To create a clean, consistent boot image and deploy a new Compute Engine VM from it, the engineer must first stop the source VM to prevent uncommitted disk writes. Next, a snapshot of the boot disk is created. That snapshot is then used as the source to build a custom Compute Engine image. With the image ready, the new VM instance (`web-prod-1`) is created using the `--image` parameter. Finally, the source VM can be restarted.

Step-by-Step Solution

1
Stop the baseline VM instance.
The VM enters the TERMINATED state, locking persistent disk writes.
Capturing a snapshot from a stopped instance avoids disk corruption and guarantees a consistent image state.
2
Create a disk snapshot from the boot disk.
A persistent disk snapshot is generated in Google Cloud Storage.
Snapshots store point-in-time byte data required to build image resources.
3
Create a custom image from the snapshot.
A custom Compute Engine disk image resource is registered in the project.
Custom images allow cross-zone and cross-region provisioning of standardized VM boot disks.
4
Execute `gcloud compute instances create web-prod-1 --zone=us-central1-b --image=web-custom-image-v1`.
The new VM instance boots up with the pre-configured OS and environment.
Specifying the custom image provisions a new instance initialized with the exact baseline software stack.
5
Start the baseline VM instance `web-base-vm`.
The source instance resumes RUNNING state.
The image capturing dependency chain is complete, so baseline operations can resume.

Key Concept

Compute Engine Custom Image Deployment Workflow
Question 237Question →

A cloud administrator needs to replace the default Compute Engine service account on an existing virtual machine with a newly created custom user-managed service account. The application running on the instance requires read-only access to objects inside a specific Google Cloud Storage bucket. Following Google Cloud security best practices, in what correct sequential order should the administrator perform the steps to configure and attach the identity?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Create the custom user-managed service account, 2) Grant the roles/storage.objectViewer role to the service account on the target bucket, 3) Grant the roles/iam.serviceAccountUser role to the administrator on the service account, and 4) Stop the instance and update its service account assignment using gcloud compute instances set-service-account.
The correct logical sequence follows dependency order in GCP identity management: first create the identity, second define what resources the identity can access (bucket-level Object Viewer), third grant the deploying user permission to use the identity (roles/iam.serviceAccountUser), and finally update the workload configuration to bind the identity to the Compute Engine virtual machine.

Step-by-Step Solution

1
Provision the new service account resource using gcloud CLI.
Generates a unique service account email address (e.g., [email protected]).
An identity must exist before permissions can be bound or assigned.
2
Bind the granular IAM role roles/storage.objectViewer to the service account email on the specific bucket.
Configures resource-level permissions following the principle of least privilege.
Configuring resource permissions before attaching identity prevents permission gap windows upon workload startup.
3
Assign roles/iam.serviceAccountUser on the service account to the identity performing the VM update.
Authorizes the administrator to attach the service account to compute workloads.
Without the Service Account User role, Compute Engine prevents users from attaching service accounts to instances.
4
Stop the Compute Engine instance and reassign its identity with gcloud compute instances set-service-account.
The VM replaces its default service account identity with the custom user-managed service account.
Changing a running VM's service account requires stopping the instance or using the set-service-account command with appropriate flags.

Key Concept

Lifecycle and delegation pattern for user-managed service account creation, IAM role assignment, and Compute Engine attachment.
Estimated Time:2m 0s
Question 238Question →

You need to configure Cloud Pub/Sub to trigger a Cloud Run microservice named `event-processor` using a secure push subscription. The Cloud Run service must reject any direct unauthenticated HTTP traffic from the public internet. Arrange the operational steps in the correct order to set up this secure integration.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts by creating a dedicated service account for the Pub/Sub push identity, deploying the target Cloud Run service with unauthenticated access disabled, binding the `roles/run.invoker` role on the Cloud Run service to the service account, and finally creating the Pub/Sub push subscription configured with the service endpoint and identity.
To build a secure push integration between Pub/Sub and Cloud Run, the identity components and service perimeter must be established in logical order: first create the principal (service account), then provision the resource and endpoint (`--no-allow-unauthenticated`), assign authorization (`roles/run.invoker`), and lastly create the integration object (Pub/Sub push subscription).

Step-by-Step Solution

1
Create the service account identity using `gcloud iam service-accounts create`.
A service account email address is provisioned to represent the Pub/Sub push mechanism.
You need a dedicated principal identity to receive invoker permissions and sign authentication tokens.
2
Deploy the Cloud Run service with `gcloud run deploy event-processor --no-allow-unauthenticated`.
The Cloud Run service is instantiated with access restricted to authenticated invokers, returning a HTTPS service URL.
Enforcing private access ensures public requests are blocked and provides the target endpoint URL.
3
Add the IAM policy binding to the Cloud Run service using `gcloud run services add-iam-policy-binding event-processor --member=serviceAccount:... --role=roles/run.invoker`.
The push service account is authorized to invoke the private Cloud Run service.
Pub/Sub authentication relies on the service account possessing the specific `roles/run.invoker` predefined role.
4
Create the push subscription using `gcloud pubsub subscriptions create --topic=... --push-endpoint=... --push-auth-service-account=...`.
Pub/Sub automatically attaches OAuth/OIDC tokens signed by the service account when pushing messages to Cloud Run.
This final step connects the message queue to the verified, secure endpoint.

Key Concept

Securing Cloud Run Services with Pub/Sub Push Authentication and IAM Roles
Question 239Question →

A security engineer needs to configure short-lived credential access for a developer working from a local terminal. The developer must deploy Cloud Storage resources by impersonating a dedicated service account named `[email protected]` without exporting service account JSON keys. Arrange the steps in the correct order to configure and enable service account impersonation using the gcloud CLI.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order begins with granting resource permissions to the target service account, followed by assigning the Service Account Token Creator role on the target service account to the developer, authenticating the user identity with `gcloud auth login`, and finally setting `gcloud config set auth/impersonate_service_account`.
To establish secure, keyless service account impersonation for local gcloud CLI execution, the workflow follows a precise logical sequence. First, the target service account must be granted the necessary workload permissions on target GCP resources. Second, the user identity must be granted the `Service Account Token Creator` role (`roles/iam.serviceAccountTokenCreator`) on the target service account to authorize short-lived token generation. Third, the user logs into gcloud using `gcloud auth login` to authenticate their user principal. Finally, running `gcloud config set auth/impersonate_service_account` configures the local gcloud environment to transparently request short-lived tokens for the specified target service account during resource operations.

Step-by-Step Solution

1
Assign resource management roles to the target service account.
The service account `[email protected]` is granted the necessary Cloud Storage permissions.
Service account impersonation delegates authority, meaning the target service account itself must hold the permissions to perform actions.
2
Grant the developer the Service Account Token Creator role on the target service account resource.
The user identity is authorized to call the IAM credentials API to generate short-lived tokens for `[email protected]`.
Without `roles/iam.serviceAccountTokenCreator`, GCP IAM blocks attempts by the user principal to impersonate the service account.
3
Authenticate the developer's user identity in the local environment.
User credentials are established locally via `gcloud auth login`.
User authentication provides the underlying principal identity required to request impersonated tokens from GCP IAM.
4
Set the CLI authentication configuration to impersonate the target service account.
The gcloud CLI property `auth/impersonate_service_account` is configured.
This setting instructs gcloud to automatically mint and refresh short-lived tokens for the target service account for all gcloud operations.

Key Concept

Configuring Service Account Impersonation via gcloud CLI
Question 240Question →

A Cloud Engineer needs to establish secure outbound internet connectivity for internal workload instances without assigning public IP addresses. The engineer must build a custom Virtual Private Cloud (VPC) network and enable Cloud NAT for a subnet in region `us-central1` using the `gcloud` CLI.

What is the correct logical sequence of steps to provision this networking architecture?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps to deploy a private subnet with Cloud NAT outbound connectivity is: 1. Create the custom mode VPC network (`corp-vpc`), 2. Create the subnet (`backend-subnet`), 3. Create the Cloud Router (`nat-router`), and 4. Configure the Cloud NAT gateway on the Cloud Router (`nat-gateway`).
The correct order follows GCP resource dependency hierarchy: creating the parent VPC network first, followed by the regional subnet, then initializing the Cloud Router within that network/region, and finally attaching the Cloud NAT gateway configuration to the Cloud Router.

Step-by-Step Solution

1
Create the custom VPC network
Establishes the global network shell without automatically creating regional subnets.
Networking resources such as subnets, routers, and firewalls depend on the parent VPC network object.
2
Deploy the regional subnet
Allocates a CIDR prefix (`10.10.1.0/24`) in region `us-central1` attached to `corp-vpc`.
Cloud Router and Cloud NAT require an existing regional subnet to route outbound traffic.
3
Provision the regional Cloud Router
Initializes `nat-router` in `us-central1` linked to `corp-vpc`.
Cloud NAT operates as a regional service managed by a Cloud Router instance in the same region and network.
4
Add the Cloud NAT gateway service
Enables NAT service on `nat-router` for all primary subnets in the region.
Configures outward translation rules and external IP allocation on the operational Cloud Router.

Key Concept

Provisioning Cloud NAT Egress Architecture in Custom VPC Networks
PreviousPage 12 / 14Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin