Examkin

All practice questions

1591 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 1341Question →

A cloud engineer needs to grant a specific service account named `[email protected]` permission to invoke an existing internal Cloud Run service named `payment-processor`. Following Google Cloud best practices and the principle of least privilege, which `gcloud` command should the engineer execute?

Show answer & explanation

Answer: gcloud run services add-iam-policy-binding payment-processor --member="serviceAccount:[email protected]" --role="roles/run.invoker"

Answer

Execute `gcloud run services add-iam-policy-binding payment-processor --member="serviceAccount:[email protected]" --role="roles/run.invoker"` to grant the specific Cloud Run Invoker role to the service account.
The correct command uses `gcloud run services add-iam-policy-binding` with the target Cloud Run service name (`payment-processor`), specifies the full service account identifier in the `--member` flag, and assigns the predefined least-privilege role `roles/run.invoker`.

Step-by-Step Solution

1
Identify the target resource and required operational task.
The target is an existing Cloud Run service named `payment-processor`, and the task is to grant invocation access.
Cloud Run resource management requires using `gcloud run services` CLI subcommands.
2
Determine the least-privilege IAM role required for invoking Cloud Run services.
The required predefined role is Cloud Run Invoker (`roles/run.invoker`).
Primitive roles like Editor or Owner provide excessive administrative rights across the resource.
3
Construct the exact IAM policy binding command.
Run `gcloud run services add-iam-policy-binding payment-processor --member="serviceAccount:[email protected]" --role="roles/run.invoker"`.
This command binds the specific role to the specified member on the target service resource.

Key Concept

Cloud Run Service Access Management using IAM Policy Bindings
Question 1342Question →

An operations engineer needs to expand the primary IPv4 address range of an existing custom subnet named `prod-subnet-us-east` located in region `us-east1` from 10.1.0.0/2410.1.0.0/24 to 10.1.0.0/2310.1.0.0/23 without disrupting existing workloads running in the Virtual Private Cloud (VPC). Which `gcloud` command should the engineer execute to perform this operation?

Show answer & explanation

Answer: `gcloud compute networks subnets expand-ip-range prod-subnet-us-east --prefix-length=23 --region=us-east1`

Answer

The command `gcloud compute networks subnets expand-ip-range prod-subnet-us-east --prefix-length=23 --region=us-east1` expands the IP address range of an existing subnet dynamically.
To expand the IP address range of an existing Google Cloud VPC subnet, you use the command `gcloud compute networks subnets expand-ip-range [SUBNET_NAME]` with the `--prefix-length` flag indicating the new (smaller numerical prefix) subnet mask. This operation is non-disruptive and allows expanding a subnet range (e.g., from /24/24 to /23/23).

Step-by-Step Solution

1
Identify the required networking resource and operational task.
The target resource is a VPC subnet named `prod-subnet-us-east` in region `us-east1`, and the objective is to expand its primary IP address range.
Expanding an existing subnet CIDR block requires modifying the subnet resource without recreating it or affecting running VMs.
2
Determine the appropriate `gcloud` CLI command structure.
The command group for subnet operations is `gcloud compute networks subnets` and the specific subcommand for increasing IP capacity is `expand-ip-range`.
`expand-ip-range` modifies the existing subnet's netmask without altering deployed resources.
3
Specify the required flags for prefix length and region.
The `--prefix-length=23` flag specifies the target netmask (2323 bits), and `--region=us-east1` specifies the subnet location.
Subnet ranges can only be expanded (prefix length decreased), not shrunk.

Key Concept

VPC Subnet IP Address Expansion
Estimated Time:1m 15s
Question 1343Question →

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 1344Question →

A system administrator needs to restrict outbound network connections from Compute Engine instances with the network tag `database-node` in a custom Virtual Private Cloud (VPC) named `production-vpc`. The requirement specifies blocking all egress traffic originating from these instances to a legacy external IP address `198.51.100.50/32`, while taking precedence over standard default rules. Which `gcloud` command correctly implements this security requirement?

Show answer & explanation

Answer: gcloud compute firewall-rules create deny-db-outbound --network=production-vpc --direction=EGRESS --action=DENY --rules=all --destination-ranges=198.51.100.50/32 --target-tags=database-node --priority=500

Answer

The correct command executes `gcloud compute firewall-rules create deny-db-outbound --network=production-vpc --direction=EGRESS --action=DENY --rules=all --destination-ranges=198.51.100.50/32 --target-tags=database-node --priority=500`.
The correct command uses `--direction=EGRESS` with `--destination-ranges=198.51.100.50/32` to block outbound connections from instances matching `--target-tags=database-node`. Choosing `--priority=500` ensures this custom rule takes precedence over default rules because GCP evaluates lower priority numbers first.

Step-by-Step Solution

1
Identify traffic direction and destination parameters
Since traffic originates from VM instances bound for an external target IP address, the firewall rule must be configured for EGRESS direction using `--destination-ranges`.
Egress rules filter outbound packets leaving Compute Engine instances toward specified target destination IP ranges.
2
Select target instances and rule action
Use `--target-tags=database-node` to scope the rule specifically to database VMs, and `--action=DENY` with `--rules=all` to block all protocol traffic.
Target tags constrain firewall rule evaluation strictly to Compute Engine instances with matching tags.
3
Evaluate rule priority requirements
Assign a priority number such as 500 (lower integers represent higher priority in Google Cloud VPC firewall evaluation).
Lower numerical priority values take precedence over higher numbers (such as default egress allow rules evaluated at priority 65535).

Key Concept

GCP VPC Egress Firewall Rules and Priority Precedence
Question 1345Question →

A cloud administrator manages a stateless batch data processing application running on Compute Engine virtual machines. The workload is fault-tolerant and can easily tolerate intermittent node terminations. To minimize compute costs, the administrator plans to transition the workload to Spot VMs. Which approach recommended by Google Cloud best practices should the administrator implement to ensure terminated instances are automatically recreated while maintaining the desired pool capacity?

Show answer & explanation

Answer: Define an Instance Template that specifies Spot VMs, and deploy the workload inside a Managed Instance Group (MIG) configured to maintain the target number of instances.

Answer

Define an Instance Template that specifies Spot VMs, and deploy the workload inside a Managed Instance Group (MIG) configured to maintain the target number of instances.
Deploying Spot VMs within a Managed Instance Group (MIG) using a defined Instance Template is the Google-recommended approach. The MIG automatically detects when Spot instances are reclaimed by Google Cloud and provisions replacement instances to sustain the target capacity.

Step-by-Step Solution

1
Analyze workload characteristics
The application is stateless, fault-tolerant, and well-suited for cost-effective Spot VMs.
Spot VMs provide significant cost savings for workloads capable of handling sudden instance interruptions.
2
Select the appropriate Compute Engine resource management model
Use an Instance Template configured with the Spot VM provisioning model within a Managed Instance Group (MIG).
MIGs actively monitor instance health and availability, automatically provisioning replacement instances whenever Spot VMs are preempted to maintain desired cluster capacity.

Key Concept

Managing Spot VMs using Managed Instance Groups (MIGs)
Estimated Time:1m 30s
Question 1346Question →

An infrastructure engineer is configuring VPC firewall rules for web workloads running on Compute Engine instances tagged `web-tier`. An existing ingress firewall rule named `allow-web` allows TCP traffic on port 8080 from `0.0.0.0/0` with a priority of 1000. To meet security requirements, incoming traffic on port 8080 from the external subnet `198.51.100.0/24` must be blocked, while continuing to allow port 8080 traffic from all other external IP addresses. Which configuration will successfully achieve this requirement?

Show answer & explanation

Answer: Create an ingress deny rule for TCP port 8080 targeting `web-tier` from source IP range `198.51.100.0/24` with a priority of 900.

Answer

Create an ingress deny rule for TCP port 8080 targeting `web-tier` from source IP range `198.51.100.0/24` with a priority of 900.
In Google Cloud VPC firewall rule processing, lower numerical priority values take precedence over higher numerical values. To override an existing allow rule at priority 1000 for a specific CIDR block, an explicit ingress deny rule must be assigned a lower numerical priority (such as 900) so that it is evaluated first. Traffic from the specified subnet will match the deny rule, while all other traffic will bypass the deny rule and match the existing allow rule.

Step-by-Step Solution

1
Determine the firewall direction required for incoming client requests.
Identified that incoming connections require an ingress rule.
Traffic originating outside the VPC network and sent to backend instances is ingress traffic.
2
Evaluate rule action and priority order relative to existing rules.
Selected an ingress deny rule with a lower numerical priority value than 1000 (such as 900).
GCP evaluates VPC firewall rules starting at priority 0 up to 65535. Lower numbers represent higher precedence. Placing a deny rule at priority 900 ensures it is evaluated before the priority 1000 allow rule.

Key Concept

VPC Firewall Priority and Evaluation Precedence
Estimated Time:1m 30s
Question 1347Question →

During a security incident investigation, a Cloud Operations Security Analyst needs to review Google Cloud Audit Logs to identify every instance where a user or service account read secret payloads from Secret Manager within project `prod-sec-vault`. The analyst wants to run a `gcloud logging read` command that strictly filters for Data Access audit logs generated by Secret Manager payload access methods, excluding Admin Activity logs and unrelated services. Which filter expression should the analyst pass to the command?

Show answer & explanation

Answer: logName="projects/prod-sec-vault/logs/cloudaudit.googleapis.com%2Fdata_access" AND protoPayload.serviceName="secretmanager.googleapis.com" AND protoPayload.methodName="google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion"

Answer

The correct filter uses logName="projects/prod-sec-vault/logs/cloudaudit.googleapis.com%2Fdata_access" combined with protoPayload.serviceName="secretmanager.googleapis.com" and protoPayload.methodName="google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion".
The correct option targets the `cloudaudit.googleapis.com%2Fdata_access` log stream while specifying both the target API service (`secretmanager.googleapis.com`) and the specific RPC method (`...AccessSecretVersion`). In Google Cloud Observability, reading secret data triggers Data Access (DATA_READ) audit entries. Querying this precise log path and method provides an exact, noise-free result set of payload read operations.

Step-by-Step Solution

1
Identify the audit log classification required for reading secret values.
Accessing payload data (such as calling AccessSecretVersion) produces a DATA_READ Data Access log entry, stored under the log ID `cloudaudit.googleapis.com/data_access` (URL-encoded in filter strings as `cloudaudit.googleapis.com%2Fdata_access`).
Admin Activity logs only track configuration changes (e.g., creating or modifying secret metadata), while System Event logs record automated GCP system operations.
2
Evaluate the protoPayload fields for service and method identification.
The audit payload contains `protoPayload.serviceName` set to `secretmanager.googleapis.com` and `protoPayload.methodName` set to `google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion`.
Filtering specifically on these fields isolates secret reading operations from other Secret Manager API calls such as IAM policy queries or secret metadata updates.
3
Verify proper logName formatting for gcloud logging read filters.
The full log resource path must follow `projects/[PROJECT_ID]/logs/cloudaudit.googleapis.com%2F[LOG_TYPE]`.
Omitting the `cloudaudit.googleapis.com%2F` prefix causes Cloud Logging filter queries to return empty or invalid log matching sets.

Key Concept

Cloud Audit Logs Filtering and Log Stream Taxonomy
Estimated Time:2m 0s
Question 1348Question →

An organization requires developers to run local database migration scripts against a Cloud SQL instance by assuming the identity of a dedicated service account `[email protected]`. In accordance with Google Cloud security best practices, static service account key creation is strictly disabled by organizational policy. Which configuration allows the developers to authenticate as the service account while adhering to the security policy?

Show answer & explanation

Answer: Grant the developers the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) on the target service account resource to enable IAM service account impersonation.

Answer

Grant the developers the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) on the target service account resource to enable IAM service account impersonation.
The Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) granted on the specific service account resource allows users to impersonate the service account and obtain short-lived OAuth 2.0 access tokens. This meets the requirement of authenticating as the service account while following security best practices that prohibit long-lived static key exports.

Step-by-Step Solution

1
Identify the authentication requirement and security constraint
Developers must act as the service account db-migrator without using long-lived JSON keys.
Security best practices recommend short-lived credentials over persistent credential keys.
2
Select the appropriate IAM mechanism for short-lived credentials
Service account impersonation using roles/iam.serviceAccountTokenCreator.
Impersonation allows principals to generate short-lived OAuth 2.0 access tokens or ID tokens on demand.
3
Apply the role at the correct resource scope
Bind roles/iam.serviceAccountTokenCreator on the service account resource itself.
Granting permissions directly on the target service account enforces least privilege.

Key Concept

Service Account Impersonation vs. Static Key Management
Question 1349Question →

An application developer needs to deploy a stateless HTTP web service named report-generator packaged as a container image to Google Cloud Run in the us-east1 region. The containerized application is built to listen on the port defined by the standard PORT environment variable injected by the Cloud Run container runtime at startup. Which command should the developer execute to deploy this container image from Artifact Registry to Cloud Run while adhering to Google Cloud serverless best practices?

Show answer & explanation

Answer: gcloud run deploy report-generator --image=us-east1-docker.pkg.dev/my-project/apps/report-generator:v1 --region=us-east1

Answer

Execute the standard gcloud run deploy command specifying the service name, container image path in Artifact Registry, and target region.
The correct command uses `gcloud run deploy` to specify the service name, container image from Artifact Registry, and target region. Cloud Run automatically injects the `PORT` environment variable (defaulting to 8080) into the container container environment, allowing the application to start receiving HTTP requests cleanly without requiring custom port environment variable overrides.

Step-by-Step Solution

1
Identify the proper target serverless compute platform for pre-packaged container images.
Google Cloud Run is the appropriate serverless service for deploying container images.
Cloud Run natively supports any stateless container image that listens for web requests on the injected PORT environment variable.
2
Construct the gcloud CLI command with required deployment flags.
gcloud run deploy report-generator --image=us-east1-docker.pkg.dev/my-project/apps/report-generator:v1 --region=us-east1
Specifying the service name, container image location, and deployment region creates a revision of the Cloud Run service without modifying port environment variables or using improper deployment tools.

Key Concept

Cloud Run Container Deployment and Port Binding Rules
Question 1350Question →

A cloud engineer needs to update an existing running Compute Engine virtual machine instance named `app-worker-1` to use a custom IAM service account named `[email protected]` instead of the default Compute Engine service account. The configuration update must be completed using the Google Cloud CLI (`gcloud`) without deleting the instance or losing disk state. Which sequence of actions should the cloud engineer execute?

Show answer & explanation

Answer: Stop instance `app-worker-1`, run `gcloud compute instances set-service-account app-worker-1 [email protected] --scopes=cloud-platform`, and start instance `app-worker-1`.

Answer

Stop instance `app-worker-1`, run `gcloud compute instances set-service-account app-worker-1 [email protected] --scopes=cloud-platform`, and start instance `app-worker-1`.
To modify the IAM service account attached to an existing Compute Engine VM instance, the instance must first be stopped. Once stopped, running `gcloud compute instances set-service-account` with the `--service-account` flag successfully updates the attached service account. Restarting the instance completes the deployment without losing persistent data.

Step-by-Step Solution

1
Identify the requirement for modifying a Compute Engine VM's service account.
Recognize that updating an instance's service account identity cannot be performed while the VM is in the RUNNING state.
Compute Engine enforces that instances must be stopped before changing attached service accounts or access scopes.
2
Select the correct `gcloud compute instances` command sub-group.
Use `gcloud compute instances set-service-account` with the `--service-account` flag specifying the target service account email address.
The `set-service-account` command updates the VM's identity configuration without requiring instance re-creation.
3
Assemble the operational order of commands.
Stop the instance, execute the `set-service-account` command, and then start the instance.
This workflow safely updates the VM configuration while preserving all attached persistent disks and data.

Key Concept

Modifying Compute Engine VM Service Account Identity
Question 1351Question →

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 1352Question →

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 1353Question →

A cloud engineer is deploying a Compute Engine virtual machine instance named `web-app-frontend` in zone `us-east1-b`. The engineer has written a setup shell script stored on their local workstation at `./scripts/install-web.sh` that must execute automatically whenever the instance boots up for the first time. Which `gcloud` command correctly creates the virtual machine instance and passes the local script file as a startup script?

Show answer & explanation

Answer: gcloud compute instances create web-app-frontend --zone=us-east1-b --metadata-from-file=startup-script=./scripts/install-web.sh

Answer

The command using `gcloud compute instances create web-app-frontend --zone=us-east1-b --metadata-from-file=startup-script=./scripts/install-web.sh` is correct.
To pass the contents of a local file as custom instance metadata (such as a startup script), Google Cloud CLI requires the `--metadata-from-file` flag with the key-value pair `startup-script=<path-to-file>`. Additionally, Compute Engine instances are zonal resources and must specify `--zone`.

Step-by-Step Solution

1
Identify the resource scope required for VM creation.
Compute Engine instances are zonal resources requiring `--zone=us-east1-b`.
Passing `--region` instead of `--zone` causes a flag syntax error.
2
Determine how local file contents are passed to Compute Engine instance metadata.
The `gcloud` CLI uses the `--metadata-from-file` flag to read local files.
The standard `--metadata` flag only accepts direct key-value literal string inputs, while `--metadata-from-file` reads the local file contents into the specified metadata key.
3
Specify the exact metadata key for startup scripts.
The key must be `startup-script` passed as `--metadata-from-file=startup-script=./scripts/install-web.sh`.
This guarantees that Compute Engine's guest environment runs the script content during instance boot.

Key Concept

Compute Engine startup script configuration using gcloud metadata flags
Question 1354Question →

A cloud engineer needs to execute a gcloud CLI command to deploy a new Compute Engine VM instance named batch-processor. The instance must execute initialization tasks on startup using a shell script located on the local workstation at ./scripts/init.sh. Additionally, the instance must run under a custom user-managed service account named [email protected]. Which flags must be included in the gcloud compute instances create command to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: --metadata-from-file=startup-script=./scripts/init.sh; [email protected]

Answer

The correct options are the flags using metadata from file for the startup script (--metadata-from-file=startup-script=./scripts/init.sh) and assigning the custom service account email ([email protected]).
To load a local script file as a startup script on a Compute Engine VM instance during provisioning, gcloud compute instances create requires the --metadata-from-file=startup-script=./scripts/init.sh flag. To assign a specific IAM service account identity to the VM instance, the --service-account flag must be passed with the service account's email address.

Step-by-Step Solution

1
Identify the flag required to pass a local file script to VM startup metadata.
The gcloud CLI uses --metadata-from-file=startup-script=<path> to upload the contents of a local script file into instance metadata.
Direct startup script strings are set via standard metadata, but reading directly from a local shell file requires the --metadata-from-file flag syntax.
2
Identify the flag required to specify the attached IAM service account identity.
The gcloud CLI uses --service-account=<email> to assign identity to the Compute Engine VM.
The service account flag specifies the service account identity, whereas the --scopes flag only defines API access scopes for that identity.

Key Concept

Compute Engine gcloud CLI VM creation flags for startup scripts and service account attachment
Question 1355Question →

A cloud architecture team requires a newly deployed Compute Engine virtual machine instance named analytics-node in zone us-central1-a to connect directly to two isolated Virtual Private Cloud (VPC) subnets: subnet-analytics and subnet-management. Which gcloud command correctly provisions the virtual machine with multiple network interfaces?

Show answer & explanation

Answer: gcloud compute instances create analytics-node --zone=us-central1-a --network-interface=subnet=subnet-analytics --network-interface=subnet=subnet-management

Answer

The command that repeats the `--network-interface` flag once for `subnet=subnet-analytics` and once for `subnet=subnet-management` correctly provisions the instance with dual network interfaces.
In Google Cloud Compute Engine, creating a virtual machine with multiple network interfaces requires repeating the `--network-interface` flag for each connection. The command passing `--network-interface=subnet=subnet-analytics` followed by `--network-interface=subnet=subnet-management` properly creates nic0 and nic1 on the instance.

Step-by-Step Solution

1
Identify the requirement for multi-homed VM network provisioning in Compute Engine.
Each network connection requires its own Virtual Network Interface (nic0, nic1, etc.).
Compute Engine instances cannot share a single network interface across multiple subnets.
2
Review the gcloud CLI flag structure for attaching multiple network interfaces.
The `--network-interface` flag must be repeated for each interface to be attached.
The gcloud CLI parses each occurrence of `--network-interface` as a distinct interface configuration object.
3
Select the option that correctly repeats `--network-interface=subnet=...` for both subnets.
The command specifying two `--network-interface` parameters provisions the VM with nic0 connected to subnet-analytics and nic1 connected to subnet-management.
This matches Google Cloud's syntax rules for multi-network VM creation.

Key Concept

Deploying Compute Engine instances with multiple network interfaces using repeated gcloud CLI flags.
Estimated Time:1m 30s
Question 1356Question →

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 1357Question →

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 1358Question →

A solutions team is building an automated file processing solution on Google Cloud. Every time a JPEG file is created in a Cloud Storage bucket named `raw-image-uploads`, a lightweight Node.js routine must run to create a thumbnail. The team chooses Cloud Functions (2nd gen) because of its native Eventarc integration and event-driven execution model. Which `gcloud` CLI command should the team run to correctly deploy this function triggered by file uploads?

Show answer & explanation

Answer: gcloud functions deploy thumbnail-generator --gen2 --runtime=nodejs20 --entry-point=createThumbnail --source=. --trigger-event-filters="type=google.cloud.storage.object.v1.finalized" --trigger-event-filters="bucket=raw-image-uploads" --region=us-central1

Answer

The command starting with `gcloud functions deploy thumbnail-generator --gen2` using `--trigger-event-filters` for `google.cloud.storage.object.v1.finalized` and specifying the `bucket=raw-image-uploads` filter is correct.
Deploying a 2nd gen Cloud Function triggered by Cloud Storage requires using the `gcloud functions deploy` command with the `--gen2` flag and Eventarc event filters. The filter `type=google.cloud.storage.object.v1.finalized` combined with `bucket=raw-image-uploads` ensures that the function is invoked whenever a new file is uploaded to the specified bucket.

Step-by-Step Solution

1
Identify the target deployment model and runtime engine.
The requirement specifies Cloud Functions (2nd gen) for event-driven processing of Cloud Storage events.
Cloud Functions 2nd gen relies on Eventarc event filters for background bucket events.
2
Determine the mandatory gcloud flags for Cloud Storage event triggers in 2nd gen functions.
Use `--gen2` with `--trigger-event-filters="type=google.cloud.storage.object.v1.finalized"` and `--trigger-event-filters="bucket=BUCKET_NAME"`.
This registers the Eventarc trigger to invoke the function automatically upon object creation.

Key Concept

Deploying Cloud Functions (2nd gen) with Cloud Storage Eventarc triggers
Question 1359Question →

An organization is deploying a Compute Engine virtual machine instance named `data-worker` to process batch analytics. The application running inside `data-worker` must read files from a Cloud Storage bucket using a custom service account named `[email protected]`. To follow Google Cloud security best practices, the custom service account has been granted only the Storage Object Viewer IAM role on the bucket. Which `gcloud compute instances create` command correctly attaches the custom service account while allowing IAM roles to govern the instance's access?

Show answer & explanation

Answer: gcloud compute instances create data-worker --service-account=processing-sa@prod-project.iam.gserviceaccount.com --scopes=https://www.googleapis.com/auth/cloud-platform

Answer

Execute gcloud compute instances create data-worker --service-account=processing-sa@prod-project.iam.gserviceaccount.com --scopes=https://www.googleapis.com/auth/cloud-platform
When creating a Compute Engine VM with a custom service account, Google Cloud best practice requires attaching the service account via the --service-account flag and setting the scope to https://www.googleapis.com/auth/cloud-platform. This allows IAM permissions granted to that service account to serve as the effective boundary for Google Cloud API requests.

Step-by-Step Solution

1
Identify the service account flag requirement
Pass the custom service account email address to the --service-account flag.
This binds the specific service account identity to the Compute Engine VM.
2
Determine the correct access scope setting for custom service accounts
Set --scopes=https://www.googleapis.com/auth/cloud-platform.
Using the cloud-platform scope allows IAM roles assigned to the custom service account to grant and restrict API access without scope-level limitations.

Key Concept

Attaching custom service accounts and configuring access scopes during Compute Engine VM deployment
Question 1360Question →

A DevOps team is setting up an automated worker pool on Compute Engine to execute nightly video encoding jobs. The encoding tasks process independent chunks of data, persist progress checkpoints to Cloud Storage, and can automatically resume if an instance terminates unexpectedly. The team wants to minimize compute costs while maintaining processing capacity across the region. Which deployment strategy should the team implement?

Show answer & explanation

Answer: Create a regional Managed Instance Group utilizing Spot VM instances across multiple zones.

Answer

Create a regional Managed Instance Group utilizing Spot VM instances across multiple zones.
Spot VMs provide significant cost savings for batch workloads that checkpoint progress and tolerate preemption. Combining Spot VMs with a regional Managed Instance Group ensures high availability across multiple zones within the region.

Step-by-Step Solution

1
Analyze workload requirements
Identified that the video encoding workload is fault-tolerant, stateless, checkpointed, and cost-sensitive.
Fault-tolerant batch processing workloads are ideal candidates for Spot VMs, which offer heavy discounts compared to standard VMs.
2
Evaluate availability and resilience requirements
Determined that deploying across multiple zones in a regional Managed Instance Group mitigates regional preemptions and capacity constraints.
Distributing Spot VM instances across multiple availability zones improves overall workload completion reliability.

Key Concept

Managing Compute Engine Spot VMs and Regional Managed Instance Groups for Batch Workloads
PreviousPage 68 / 80Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin