All practice questions

1591 questions

Question 1181Question

A database administrator needs to execute local gcloud CLI commands to update Cloud Spanner schema configurations using the dedicated service account [email protected]. Security policy strictly forbids creating or downloading static service account JSON keys. Which IAM role assignment and gcloud configuration allows the administrator to temporarily assume the identity of the service account?

Show answer & explanation

Answer: Grant the administrator the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) on the target service account, and pass the --impersonate-service-account flag in gcloud commands.

Answer

Grant the administrator the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) on the target service account, and pass the --impersonate-service-account flag in gcloud commands.
To impersonate a service account using Google Cloud CLI without static service account keys, the user principal performing the action must be granted the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) on the target service account. When the user executes gcloud commands with the --impersonate-service-account flag, gcloud requests short-lived credentials for that service account.

Step-by-Step Solution

1
Identify the security constraint and goal.
The requirement is keyless delegation where a user principal impersonates a target service account via gcloud CLI.
Security directives prohibit static JSON service account key creation.
2
Determine the mandatory IAM role for generating impersonation tokens.
The target identity requires roles/iam.serviceAccountTokenCreator to be granted to the calling user principal.
This permission allows minting short-lived OAuth access tokens on behalf of the target service account.
3
Select the correct gcloud CLI execution mechanism.
Append --impersonate-service-account=spanner-admin@prod-project.iam.gserviceaccount.com to gcloud commands or set gcloud config set auth/impersonate_service_account.
This directs gcloud to fetch short-lived credentials for the target service account using the user's authenticated identity.

Key Concept

Service Account Impersonation via gcloud and IAM Token Creator Role
Question 1182Question

A site reliability engineer is executing a Terraform configuration to provision Google Kubernetes Engine (GKE) clusters in a newly created Google Cloud project named `proj-dev-app-101`. During the `terraform apply` step, the deployment fails with an error indicating that `container.googleapis.com` is disabled. The engineer notes that the Kubernetes Engine API was previously enabled in the central administration project where their local credentials originate. Why did this deployment fail, and what action should be taken to resolve the issue?

Show answer & explanation

Answer: The Kubernetes Engine API must be enabled directly within the target project `proj-dev-app-101` where the resources are being provisioned.

Answer

The Kubernetes Engine API must be enabled directly within the target project `proj-dev-app-101` where the resources are being provisioned.
In Google Cloud, API enablement is scoped individually to each project. Even if deployment tools or identity credentials originate from an administration project, the specific service API (such as `container.googleapis.com`) must be enabled within the destination target project where the infrastructure resources are being provisioned.

Step-by-Step Solution

1
Identify the project context where resources are being created
Resources are targeted for creation inside `proj-dev-app-101`.
Google Cloud API enablement is scoped to individual projects where service resources reside.
2
Analyze API enablement requirements across GCP projects
Enabling an API in one project (e.g., an admin project) has no effect on target workloads in another project.
Each Google Cloud project maintains its own isolated list of enabled service APIs.
3
Select the correct remediation step
Enable `container.googleapis.com` in project `proj-dev-app-101` using `gcloud services enable container.googleapis.com --project=proj-dev-app-101` or a `google_project_service` Terraform resource.
This enables the API API control plane for the specific target project, allowing resource creation to proceed.

Key Concept

GCP Service API Enablement Project Scope
Question 1183Question

An organization is configuring access control for an external site reliability consulting team. The team requires read-only access to view metrics in Cloud Monitoring and read standard application log entries in Cloud Logging within a single Google Cloud project named `telemetry-prod-app`. According to corporate policy, the team must not have access to any other projects in the resource hierarchy, nor should they receive broad read access to unrelated GCP service resources. Which TWO IAM roles should be bound to the consulting team's group identity at the project level to satisfy these requirements while adhering to the principle of least privilege? Select TWO options.

Select all that apply

Show answer & explanation

Answer: Monitoring Viewer (`roles/monitoring.viewer`) granted on the `telemetry-prod-app` project; Logs Viewer (`roles/logging.viewer`) granted on the `telemetry-prod-app` project

Answer

The correct role assignments are Monitoring Viewer (`roles/monitoring.viewer`) and Logs Viewer (`roles/logging.viewer`) granted at the `telemetry-prod-app` project scope.
To satisfy least privilege for viewing metrics and standard logs in a specific project, specific predefined roles must be granted at the project scope. The Monitoring Viewer role (`roles/monitoring.viewer`) grants read-only access to Cloud Monitoring metrics and dashboards. The Logs Viewer role (`roles/logging.viewer`) grants read access to standard Cloud Logging log entries. Granting both roles directly on the target project satisfies all requirements without over-granting access.

Step-by-Step Solution

1
Analyze the access requirements for metrics and logging
Identified that the team needs read-only access specifically to Cloud Monitoring and Cloud Logging data within `telemetry-prod-app`.
Determining exact scope avoids over-granting administrative or primitive permissions.
2
Evaluate role types for least privilege compliance
Selected predefined roles (`roles/monitoring.viewer` and `roles/logging.viewer`) over primitive roles (`roles/viewer`).
Primitive roles grant read access across all project services, violating least privilege.
3
Evaluate the resource hierarchy scope
Applied role bindings strictly at the project level (`telemetry-prod-app`) rather than the folder level.
Folder-level bindings inherit downward to all projects under that folder, granting excessive access.

Key Concept

Applying predefined IAM roles at the project level to fulfill specific operational access requirements while enforcing least privilege and avoiding broad primitive roles or folder-level inheritance.
Question 1184Question

A Cloud Operations engineer is managing Virtual Private Cloud (VPC) networking resources in Google Cloud. The engineer needs to route all outbound traffic destined for a third-party vendor's network range 198.51.100.0/24198.51.100.0/24 through an existing custom gateway Virtual Machine instance named `gateway-instance-1` located in zone `us-east1-b`. The target VPC network is named `enterprise-vpc`. Which `gcloud` command should the engineer execute to correctly configure this routing resource?

Show answer & explanation

Answer: gcloud compute routes create vendor-route --network=enterprise-vpc --destination-range=198.51.100.0/24 --next-hop-instance=gateway-instance-1 --next-hop-instance-zone=us-east1-b

Answer

Execute the command `gcloud compute routes create vendor-route --network=enterprise-vpc --destination-range=198.51.100.0/24 --next-hop-instance=gateway-instance-1 --next-hop-instance-zone=us-east1-b` to create a custom static route in the VPC network targeting the gateway instance.
Creating a static route via `gcloud compute routes create` with `--destination-range`, `--network`, `--next-hop-instance`, and `--next-hop-instance-zone` correctly directs packets targeting 198.51.100.0/24198.51.100.0/24 to the specified VM instance in the target VPC network.

Step-by-Step Solution

1
Identify the resource type to manage
Custom traffic steering requires creating a VPC route resource using `gcloud compute routes create`.
Firewall rules or subnet configurations cannot forward traffic to a next-hop Compute Engine instance.
2
Determine the required command flags
Specify `--network=enterprise-vpc`, `--destination-range=198.51.100.0/24`, `--next-hop-instance=gateway-instance-1`, and `--next-hop-instance-zone=us-east1-b`.
The gcloud CLI requires exact parameter names for custom route definition and instance scope specification.
3
Validate the command structure against gcloud CLI standards
The correct command syntax uses valid flags `--destination-range` and `--next-hop-instance` with its corresponding `--next-hop-instance-zone`.
Using improper flag aliases like `--vpc` or `--destination-cidr` causes command invocation failures.

Key Concept

Managing Custom VPC Routes with gcloud CLI
Estimated Time:2m 0s
Question 1185Question

Your organization requires that access to objects inside a Google Cloud Storage bucket named `finance-reports-prod` be managed strictly using unified Cloud IAM permissions, completely disabling fine-grained Object Access Control Lists (ACLs). Which command should you run to enable Uniform Bucket-Level Access on this bucket?

Show answer & explanation

Answer: gcloud storage buckets update gs://finance-reports-prod --uniform-bucket-level-access

Answer

The command `gcloud storage buckets update gs://finance-reports-prod --uniform-bucket-level-access` correctly enables Uniform Bucket-Level Access on the bucket.
Executing `gcloud storage buckets update gs://finance-reports-prod --uniform-bucket-level-access` directly updates the target bucket configuration to enforce Uniform Bucket-Level Access, ensuring all access is governed by Cloud IAM roles and object ACLs are ignored.

Step-by-Step Solution

1
Identify the requirement for Uniform Bucket-Level Access (UBLA)
Recognize that legacy Object Access Control Lists (ACLs) must be disabled in favor of centralized Cloud IAM policies.
Uniform Bucket-Level Access unifies access control across Cloud Storage resources at the bucket level.
2
Select the appropriate gcloud CLI command and flag
Use `gcloud storage buckets update` with the `--uniform-bucket-level-access` flag targeted at the specific bucket URI.
This flag toggles the bucket setting to enforce uniform IAM permissions across all contained objects.

Key Concept

Configuring Uniform Bucket-Level Access in Google Cloud Storage
Question 1186Question

A systems administrator needs to deploy a secure workload in Google Cloud Platform using the `gcloud` CLI. The design requires a custom-mode Virtual Private Cloud network named `prod-vpc`, a dedicated regional subnet named `prod-subnet-uscentral1` (10.2.0.0/2410.2.0.0/24), an ingress firewall rule permitting SSH traffic to instances with a specific network tag, and a Compute Engine VM instance associated with this configuration. In what chronological order must these administrative commands be executed?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with creating the custom VPC network (`prod-vpc`), followed by provisioning the custom subnet (`prod-subnet-uscentral1`) within that network. Next, the ingress firewall rule (`allow-prod-ssh`) is created on the VPC network targeting the `ssh-enabled` tag. Finally, the VM instance (`prod-app-vm`) is created referencing the subnet and applying the target tag.
Google Cloud infrastructure management follows strict parent-child resource dependencies. A custom VPC network must be created first to act as the parent container. Next, regional subnets must be allocated within that network to provide IP addresses. Ingress firewall rules are defined at the VPC network level using target tags. Finally, Compute Engine instances are launched into the existing subnet and tagged to inherit the firewall rules.

Step-by-Step Solution

1
Create the custom-mode VPC network.
Instantiates `prod-vpc` without automatically generating default subnets across regions.
In custom-mode VPCs, subnets cannot be created until the parent VPC network exists.
2
Create the regional custom subnet.
Allocates IP range 10.2.0.0/2410.2.0.0/24 in `us-central1` associated with `prod-vpc`.
Compute Engine instances in a custom VPC require an active subnet in their deployment zone/region to receive IP configuration.
3
Configure the VPC ingress firewall rule with target tags.
Applies a network rule to `prod-vpc` allowing TCP port 22 ingress for instances carrying the `ssh-enabled` tag.
Firewall rules are associated with the VPC network and should be established prior to or alongside VM deployment so security parameters are defined.
4
Deploy the Compute Engine virtual machine instance.
Launches `prod-app-vm` in `us-central1-a`, attached to `prod-subnet-uscentral1` and tagged with `ssh-enabled`.
The instance command explicitly references both the pre-existing subnet name and the network tag evaluated by the firewall rule.

Key Concept

Resource dependencies and execution ordering when provisioning custom VPC networks, subnets, firewall rules, and instances via gcloud CLI.
Question 1187Question

You are configuring access controls for a new microservice in your Google Cloud project. You need to create a new user-managed service account named 'app-monitoring-sa' using the Google Cloud Command-Line Interface (CLI). Which gcloud command should you run to create this service account?

Show answer & explanation

Answer: gcloud iam service-accounts create app-monitoring-sa --display-name="App Monitoring SA"

Answer

The command 'gcloud iam service-accounts create app-monitoring-sa --display-name="App Monitoring SA"' correctly provisions the user-managed service account.
To create a user-managed service account using the Google Cloud CLI, the correct command syntax is 'gcloud iam service-accounts create [SA_NAME]'. Including a display name provides descriptive metadata visible in the Cloud Console.

Step-by-Step Solution

1
Identify the gcloud CLI command group for managing service account resources
Service account operations belong to 'gcloud iam service-accounts'.
IAM is responsible for identity management in Google Cloud, including user-managed service accounts.
2
Specify the creation subcommand and account identifier
Use 'create app-monitoring-sa' followed by descriptive flags such as '--display-name'.
This creates the service account resource with a generated email identifier formatted as [SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com.

Key Concept

Creating User-Managed Service Accounts via gcloud CLI
Question 1188Question

A DevOps engineer manages a Cloud Storage bucket named `analytics-central-logs-prod` that has Uniform Bucket-Level Access (UBLA) enforced across the enterprise. A third-party security auditing application running on a Compute Engine instance uses a dedicated service account. The application requires read access strictly to log files located under the `application-a/` object prefix path (`gs://analytics-central-logs-prod/application-a/*`), but must be denied access to all other object prefixes inside the bucket. A team member proposes running a command to set fine-grained Access Control Lists (ACLs) on the object prefix, but the command fails with a 400 Bad Request error due to UBLA. Which configuration approach correctly grants the required scoped access while maintaining compliance with UBLA?

Show answer & explanation

Answer: Grant the Storage Object Viewer (`roles/storage.objectViewer`) role to the service account at the bucket level, conditioned with an IAM Condition that checks `resource.name.startsWith("projects/_/buckets/analytics-central-logs-prod/objects/application-a/")`.

Answer

Grant the predefined Storage Object Viewer (`roles/storage.objectViewer`) role to the service account at the bucket level, combined with an IAM Condition that filters `resource.name` using `startsWith("projects/_/buckets/analytics-central-logs-prod/objects/application-a/")`.
When Uniform Bucket-Level Access (UBLA) is enabled on a Cloud Storage bucket, individual object ACLs cannot be used. To grant granular access to a specific object prefix without disabling UBLA, Cloud IAM Conditions should be attached to a bucket-level role binding (such as Storage Object Viewer). The condition checks the `resource.name` attribute using `startsWith()` matching on the target bucket and prefix path.

Step-by-Step Solution

1
Identify access control constraints under Uniform Bucket-Level Access (UBLA).
Recognize that fine-grained per-object ACLs (`gsutil acl` or `gcloud storage objects add-acl`) are disabled when UBLA is enforced on a bucket.
UBLA disables ACLs completely to standardize IAM permissions across all objects in the bucket.
2
Determine how to achieve object-prefix scoping within UBLA.
Use Cloud IAM Conditions on bucket-level role bindings.
IAM Conditions support evaluating object resource attributes such as `resource.name` using prefix matching functions like `startsWith()`.
3
Select the appropriate IAM role adhering to the principle of least privilege.
Use `roles/storage.objectViewer` conditioned on `resource.name.startsWith("projects/_/buckets/analytics-central-logs-prod/objects/application-a/")`.
This grants read-only object access exclusively to objects residing within the specified prefix while satisfying UBLA policy compliance.

Key Concept

Uniform Bucket-Level Access and IAM Conditions for Object Prefix Scoping
Estimated Time:2m 0s
Question 1189Question

A Cloud Engineer is tasked with establishing passwordless, keyless authentication for a pod running in a Google Kubernetes Engine (GKE) cluster to query BigQuery tables. The team has mandated using GKE Workload Identity following Google Cloud best practices. In what precise sequence should the engineer execute the configuration steps to enable this access?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with enabling Workload Identity on the GKE cluster, creating and granting permissions to the Google Service Account (GSA), creating the Kubernetes Service Account (KSA) in the namespace, granting the Workload Identity User role on the GSA to the KSA member URI, and finally annotating the KSA with the GSA email.
The proper deployment flow for GKE Workload Identity requires infrastructure enablement first (enabling Workload Identity on the cluster), establishing both identity endpoints (GSA with BigQuery permissions and KSA in the namespace), authorizing the relationship in IAM (granting roles/iam.workloadIdentityUser on the GSA to the KSA principal URI), and completing the in-cluster mapping (annotating the KSA with the GSA email).

Step-by-Step Solution

1
Enable cluster Workload Identity pool
GKE configures the Workload Identity pool URI (PROJECT_ID.svc.id.goog) for pod identity translation.
Without enabling the feature on the cluster, GKE Metadata Server cannot intercept token requests.
2
Provision GSA with target IAM roles
The GSA possesses GCP resource access rights (BigQuery Data Viewer).
Identity delegation requires an existing target GCP identity that holds the necessary workload permissions.
3
Provision KSA within the Kubernetes namespace
A namespace-scoped KSA object is available in Kubernetes.
The KSA forms the subject reference in the Workload Identity pool URI.
4
Bind roles/iam.workloadIdentityUser on GSA to KSA identity URI
GCP IAM authorizes the KSA principal (serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA]) to impersonate the GSA.
IAM policy must explicitly allow the external Kubernetes service account identity to assume the GSA identity.
5
Annotate KSA with iam.gke.io/gcp-service-account key
Pods using this KSA automatically receive GSA tokens from the GKE Metadata Server.
The annotation triggers the cluster metadata service to map pod calls to the designated GSA.

Key Concept

GKE Workload Identity binding procedure
Question 1190Question

An enterprise application requires a managed relational database service that provides horizontal scaling across multiple Google Cloud regions while maintaining transactional consistency for both read and write operations. A cloud engineer must provision this database using the Google Cloud CLI. Which command correctly provisions the appropriate managed database instance to meet these requirements?

Show answer & explanation

Answer: gcloud spanner instances create prod-db --config=nam-eur-asia1 --description="Production Database" --nodes=3

Answer

Execute gcloud spanner instances create with a multi-region configuration (--config) to provision a horizontally scalable, multi-region relational database.
The requirement specifies a managed relational database that provides multi-region horizontal scaling and strong transactional consistency for both reads and writes. Cloud Spanner is the only Google Cloud database designed for this exact combination of requirements. The gcloud spanner instances create command using a multi-region instance configuration (such as nam-eur-asia1) is the standard CLI method to deploy a Cloud Spanner instance.

Step-by-Step Solution

1
Analyze the workload requirements
Identified requirements for a relational database with multi-region horizontal scaling and transactional consistency (ACID).
Cloud SQL provides relational capabilities within a single region (or with read-only replicas), but only Cloud Spanner satisfies multi-region transactional consistency with horizontal write scaling.
2
Select the appropriate GCP managed database service
Selected Cloud Spanner as the target database engine.
Cloud Spanner is built specifically for global relational transactions and high availability.
3
Formulate the correct gcloud CLI provisioning command
Used gcloud spanner instances create with required flags (--config, --description, --nodes).
This command directly creates the managed Cloud Spanner instance according to Google Cloud CLI standards.

Key Concept

Selecting and Provisioning Managed Databases (Cloud Spanner vs. Cloud SQL vs. Bigtable)
Estimated Time:1m 15s
Question 1191Question

A DevOps team is setting up access controls for a company's cloud infrastructure. An internal compliance auditing group needs to inspect security configurations and IAM policies across all projects contained within a dedicated folder named `financial-services`. Additionally, an automated deployment pipeline service account requires permissions to create and manage Compute Engine instances exclusively inside a single project named `staging-workloads`. Which of the following IAM role assignments adhere to the principle of least privilege and proper resource hierarchy scoping? (Select TWO correct answers.)

Select all that apply

Show answer & explanation

Answer: Grant the Security Reviewer role (roles/iam.securityReviewer) to the compliance auditing group at the folder level for `financial-services`.; Grant the Compute Admin role (roles/compute.admin) to the deployment pipeline service account at the project level for `staging-workloads`.

Answer

The correct role assignments are granting the Security Reviewer role to the compliance auditing group at the folder level, and granting the Compute Admin role to the deployment pipeline service account at the specific project level.
Google Cloud IAM security best practices mandate using predefined roles over primitive roles to adhere to the principle of least privilege. Assigning the Security Reviewer role at the folder level grants the compliance team precise read-only security visibility for all projects in that folder. Assigning the Compute Admin role at the project level ensures the deployment pipeline can manage Compute Engine resources exclusively within the designated staging project.

Step-by-Step Solution

1
Analyze compliance group access requirements.
Read-only access to security and IAM policies across all projects in the `financial-services` folder.
Assigning the predefined Security Reviewer role at the folder level provides exact read visibility for all child projects within that folder without granting unnecessary administrative permissions.
2
Analyze deployment pipeline service account requirements.
Full management permissions for Compute Engine instances strictly limited to `staging-workloads`.
Assigning the predefined Compute Admin role at the project level grants full compute capabilities within the single project while preventing permission inheritance to neighboring projects.

Key Concept

Applying least-privilege access using predefined IAM roles at appropriate levels of the Google Cloud resource hierarchy.
Question 1192Question

An operations team is evaluating database solutions for an application that requires ACID compliance, multi-table SQL joins, and relational transaction capabilities. A developer recommends replacing the current database instance with Cloud Bigtable to increase write throughput. Which statement accurately explains why Cloud Bigtable does not meet the operational requirements for this workload?

Show answer & explanation

Answer: Cloud Bigtable is a NoSQL key-value and wide-column store designed for heavy throughput workloads and does not support relational SQL queries or multi-row transactions.

Answer

Cloud Bigtable is a NoSQL wide-column database optimized for high-throughput time-series and analytical workloads, lacking support for relational SQL queries and multi-row ACID transactions.
The correct answer highlights that Cloud Bigtable is a NoSQL key-value and wide-column data store intended for large-scale analytical and time-series data. Because it does not support relational SQL queries, joins, or multi-row transactions, it cannot replace a relational database requiring full ACID SQL capabilities.

Step-by-Step Solution

1
Analyze workload requirements
Identified requirements for relational data structure, complex SQL joins, and multi-table ACID transactions.
Relational capabilities dictate whether a SQL (Cloud SQL, Cloud Spanner) or NoSQL engine is required.
2
Evaluate Cloud Bigtable engine capabilities
Recognized Cloud Bigtable as a NoSQL wide-column database engine optimized for single-key access patterns and high write rates.
Cloud Bigtable does not provide relational SQL features or multi-row transactional guarantees.
3
Select the appropriate storage and database operational solution
Concluded that Cloud SQL or Cloud Spanner must be retained for relational SQL workloads instead of Cloud Bigtable.
Choosing a NoSQL engine for relational transactional needs leads to architectural failure.

Key Concept

Cloud SQL vs Cloud Bigtable Engine Selection
Estimated Time:1m 30s
Question 1193Question

Your organization operates an on-premises automated data processing platform that needs to read and write data objects in Google Cloud Storage buckets located in a target project named `proj-analytics-prod`. Security mandates require that no long-lived service account JSON keys are generated or stored on external systems, access must strictly adhere to the principle of least privilege, and identity management must be centralized in a dedicated project named `proj-iam-central`.

Which TWO configuration steps must you execute to grant the external workload access to Cloud Storage? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure Workload Identity Federation in `proj-iam-central` to map the external workload's identity to a service account created in `proj-iam-central`, allowing short-lived token exchange without key downloads.; Grant the `roles/storage.objectAdmin` predefined role to the centralized service account on the specific Cloud Storage buckets in `proj-analytics-prod`.

Answer

The correct implementation requires configuring Workload Identity Federation in the central project to enable short-lived keyless authentication, and granting the Storage Object Admin predefined role to the central service account on the target Cloud Storage buckets in the destination project.
To fulfill the requirements, Workload Identity Federation must be configured in the central identity project to provide keyless authentication for the external workload via short-lived tokens. Furthermore, to satisfy least privilege and enable cross-project access, the central service account must be granted the predefined Storage Object Admin role specifically on the Cloud Storage buckets within the target project.

Step-by-Step Solution

1
Establish keyless authentication mechanism for external workloads.
Workload Identity Federation is configured in `proj-iam-central`, enabling the external system to exchange identity tokens for short-lived GCP service account access tokens.
This eliminates the compliance risk associated with exportable, long-lived JSON keys.
2
Configure cross-project permissions adhering to least privilege.
The central service account is granted `roles/storage.objectAdmin` on the target storage buckets inside `proj-analytics-prod`.
Granting predefined object-level roles at the resource scope ensures the service account can only perform necessary storage operations without broad project-wide administrative rights.

Key Concept

Keyless cross-project authentication using Workload Identity Federation and least-privilege predefined IAM roles.
Question 1194Question

You are configuring access control for a background application running in Google Cloud. You need to create a new user-managed service account named `analytics-worker` using the `gcloud` CLI. Which command should you execute to create this service account?

Show answer & explanation

Answer: gcloud iam service-accounts create analytics-worker --display-name="Analytics Worker"

Answer

The command `gcloud iam service-accounts create analytics-worker --display-name="Analytics Worker"` correctly provisions a user-managed service account.
The correct answer uses `gcloud iam service-accounts create analytics-worker --display-name="Analytics Worker"`, which is the standard Google Cloud SDK command for provisioning a new user-managed service account.

Step-by-Step Solution

1
Identify the required administrative operation
Creating a new identity (service account) within Google Cloud IAM.
The requirement asks specifically to create a user-managed service account named analytics-worker.
2
Select the proper gcloud CLI group and command
Use `gcloud iam service-accounts create`.
Service account management commands reside under the `gcloud iam service-accounts` command group.

Key Concept

Creating User-Managed Service Accounts via gcloud CLI
Question 1195Question

An enterprise administrator needs to ensure that no virtual machines created within a specific folder can be assigned external IP addresses. Which Google Cloud service or feature should be configured on the folder to enforce this restriction across all descendant projects?

Show answer & explanation

Answer: An Organization Policy constraint restricting external IP access

Answer

An Organization Policy constraint applied at the folder level enforces restrictions on resource configurations across all child projects.
Organization Policies enable administrators to set centralized configuration guardrails across the Google Cloud resource hierarchy. Applying an Organization Policy constraint at the folder level automatically enforces the restriction across all projects inherited by that folder.

Step-by-Step Solution

1
Identify the requirement to restrict specific resource configurations across multiple projects within a folder.
Recognize that enforcing resource configuration guardrails across a hierarchy node requires Organization Policies rather than IAM roles.
Organization Policies restrict what resources can do or how they are configured, whereas IAM controls who can take actions.
2
Select the appropriate Organization Policy scope.
Apply the policy constraint (such as compute.vmExternalIpAccess) at the target folder level.
Constraints applied at a folder inherit down to all child folders and projects contained within it.

Key Concept

Organization Policies enforce governance constraints on resources across the GCP resource hierarchy.
Question 1196Question

A cloud engineer needs to safely transition an existing Google Cloud Storage bucket from fine-grained access control to Uniform Bucket-Level Access. What is the correct sequence of steps to complete this transition without disrupting user access?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: first audit existing object ACLs, next grant equivalent IAM roles to those principals, and finally enable Uniform Bucket-Level Access on the bucket.
Migrating to Uniform Bucket-Level Access requires discovering existing ACL dependencies first, provisioning equivalent IAM permissions to affected users next, and lastly enabling Uniform Bucket-Level Access on the bucket to enforce IAM-only access control.

Step-by-Step Solution

1
Audit current permissions
Identify all principals dependent on object ACLs.
Prevents accidental access loss when ACL support is removed.
2
Assign IAM roles
Ensure principals have required access via Cloud IAM.
Uniform Bucket-Level Access relies entirely on IAM permissions for authorization.
3
Enforce Uniform Bucket-Level Access
Disables legacy ACL evaluation for all objects in the bucket.
Enforces unified security management across all bucket objects.

Key Concept

Migration workflow from legacy ACLs to Uniform Bucket-Level Access (UBLA)
Question 1197Question

An infrastructure engineer is managing an existing Google Kubernetes Engine (GKE) Standard cluster hosting a multi-tier web application. During high-traffic events, the Horizontal Pod Autoscaler (HPA) successfully increases the target replica count for the deployment. However, several newly created pods remain stuck in a `Pending` state because the current nodes lack sufficient CPU and memory capacity to accommodate the pod resource requests. The engineer needs to ensure that the infrastructure automatically provisions additional node capacity when pods cannot be scheduled due to resource constraints, and scales down nodes when they are underutilized. Which action should the engineer take?

Show answer & explanation

Answer: Enable Cluster Autoscaler on the GKE node pool to automatically adjust the number of worker nodes based on pending pod resource demands.

Answer

Enable Cluster Autoscaler on the GKE node pool so that GKE automatically adds nodes when pods are in a Pending state due to insufficient resource limits.
Enabling Cluster Autoscaler on the node pool allows GKE to inspect the Kubernetes scheduler for unschedulable pods caused by insufficient CPU or memory resources. When pending pods are detected, Cluster Autoscaler provisions additional Compute Engine worker nodes, allowing the pending pods to be scheduled successfully.

Step-by-Step Solution

1
Identify the operational bottleneck in the GKE cluster.
Pods are scaling out via HPA but remain in a Pending status because node compute capacity is exhausted.
HPA operates at the Kubernetes workload layer (increasing pod count), while node provisioning operates at the infrastructure layer.
2
Determine the appropriate GKE scaling component required for infrastructure node adjustment.
Cluster Autoscaler must be enabled for the node pool.
Cluster Autoscaler explicitly monitors unschedulable (Pending) pods and provisions additional GKE worker nodes up to the configured maximum size.

Key Concept

GKE Cluster Autoscaler vs Horizontal Pod Autoscaler (HPA)
Question 1198Question

A Cloud Operations team manages a production Compute Engine instance cluster in a custom Virtual Private Cloud (VPC) network named `prod-vpc` and subnet `prod-subnet-01` located in region `us-central1`. The instances operate without external IP addresses for security compliance. Administrators need to enable Cloud Ops Telemetry logging from these private instances while also permitting secure administrative SSH access through Identity-Aware Proxy (IAP) TCP forwarding. Existing custom ingress rules currently deny all incoming TCP traffic on port 22 with priority 1000. Which TWO `gcloud` configuration steps must the administrator execute to achieve these operational requirements?

Select all that apply

Show answer & explanation

Answer: Run `gcloud compute networks subnets update prod-subnet-01 --region=us-central1 --enable-private-ip-google-access` to allow instances without public IP addresses to reach Google Cloud APIs and services.; Run `gcloud compute firewall-rules create allow-iap-ssh --network=prod-vpc --direction=INGRESS --priority=950 --action=ALLOW --rules=tcp:22 --source-ranges=35.235.240.0/20` to permit IAP SSH traffic.

Answer

The administrator must enable Private Google Access on the regional subnet specifying the us-central1 region and create an ingress firewall rule permitting TCP port 22 from source range 35.235.240.0/20 with a priority value lower than 1000 (such as 950).
Enabling Private Google Access on `prod-subnet-01` with `--region=us-central1` allows compute instances without public IPs to reach Cloud Logging APIs natively. Adding an ingress firewall rule for `35.235.240.0/20` on TCP port 22 with priority 950 correctly allows IAP SSH traffic because priority 950 takes precedence over the existing deny rule evaluated at priority 1000.

Step-by-Step Solution

1
Enable Private Google Access for instances lacking public IP addresses.
Instances in `prod-subnet-01` gain private routing to Google Cloud APIs, enabling telemetry logging.
Subnets require the explicit `--region` flag when modified via `gcloud compute networks subnets update`.
2
Configure the VPC Firewall rule for Identity-Aware Proxy SSH forwarding.
Inbound TCP traffic on port 22 from IP range `35.235.240.0/20` is explicitly allowed.
GCP Firewall rules evaluate lower numerical priority values first. Priority 950 overrides the existing deny rule evaluated at priority 1000.

Key Concept

Managing VPC Subnet Private Access and Firewall Priority Rules
Question 1199Question

An administrator needs to perform scheduled offline maintenance on a standalone Compute Engine instance named `app-server-1`. The administrator must upgrade its machine type to `e2-standard-4` and attach a newly provisioned persistent disk named `log-disk-1` for additional log storage using the `gcloud` CLI. What is the correct sequence of steps to perform this maintenance operation?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: 1) Stop the VM instance (`gcloud compute instances stop`), 2) Update the machine type (`gcloud compute instances set-machine-type`), 3) Create the persistent disk (`gcloud compute disks create`), 4) Attach the persistent disk (`gcloud compute instances attach-disk`), and 5) Start the VM instance (`gcloud compute instances start`).
Changing a Compute Engine VM instance's machine type requires the instance to be in the STOPPED/TERMINATED state. Therefore, stopping the VM is the mandatory first step. Once stopped, the machine type is reconfigured. Next, creating the persistent disk resource must occur before attaching it to the instance. Finally, attaching the disk and starting the VM instance completes the maintenance workflow cleanly.

Step-by-Step Solution

1
Stop the VM instance.
The VM enters the TERMINATED state, releasing hardware resources and allowing hardware property changes like machine type.
Machine types cannot be modified on running Compute Engine instances.
2
Execute gcloud compute instances set-machine-type.
The VM configuration is updated to e2-standard-4.
Reconfiguring instance specs must occur while the VM is stopped.
3
Create the persistent disk resource.
The persistent disk log-disk-1 is created in the target zone.
The disk must exist in GCP before it can be attached to an instance.
4
Attach the disk using gcloud compute instances attach-disk.
The disk log-disk-1 is mapped to app-server-1.
The disk attachment must be configured before launching the application workload.
5
Start the VM instance.
The instance boots up with 4 vCPUs and the secondary persistent disk attached.
Brings the application back online following maintenance.

Key Concept

Managing Compute Engine VM Instance Lifecycle and Disk Operations via gcloud CLI
Estimated Time:1m 30s
Question 1200Question

A platform engineering team is configuring Workload Identity on a Google Kubernetes Engine (GKE) cluster to enable passwordless authentication to Google Cloud resources. A pod running in the namespace `data-pipeline` uses the Kubernetes service account `exporter-ksa` and needs to write files to Cloud Storage. The target Google service account `[email protected]` has already been assigned the Cloud Storage Object Creator role on the destination bucket. Which IAM role binding configuration is required on `storage-writer-sa` to allow the Kubernetes workload to impersonate it?

Show answer & explanation

Answer: Grant the Workload Identity User role (roles/iam.workloadIdentityUser) to serviceAccount:prod-analytics.svc.id.goog[data-pipeline/exporter-ksa] on storage-writer-sa.

Answer

Grant the Workload Identity User role (roles/iam.workloadIdentityUser) to serviceAccount:prod-analytics.svc.id.goog[data-pipeline/exporter-ksa] on storage-writer-sa.
To enable a GKE workload to act as a Google Service Account, GKE Workload Identity maps the Kubernetes service account to the Google service account. This is achieved by granting the `roles/iam.workloadIdentityUser` role on the target Google service account to the member formatted as `serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]`.

Step-by-Step Solution

1
Identify the principal and target resource in the GKE Workload Identity relationship
The target resource is the Google Service Account (GSA) `[email protected]`. The principal is the Kubernetes Service Account (KSA) `exporter-ksa` in namespace `data-pipeline`.
Workload Identity requires mapping a specific Kubernetes service account identity to a specific Google Cloud service account.
2
Construct the fully qualified workload identity member identifier
The member syntax is `serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]`, which evaluates to `serviceAccount:prod-analytics.svc.id.goog[data-pipeline/exporter-ksa]`.
Google Cloud IAM recognizes Kubernetes service accounts via the Workload Identity pool principal format.
3
Apply the appropriate IAM role on the target Google service account
Assign `roles/iam.workloadIdentityUser` to the KSA member on the GSA.
The Workload Identity User role grants permission to exchange KSA tokens for short-lived GSA credentials, satisfying the keyless access requirement.

Key Concept

Configuring Workload Identity bindings between Kubernetes Service Accounts (KSA) and Google Service Accounts (GSA)
PreviousPage 60 / 80Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin