Examkin

All practice questions

1591 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 1221Question →

A DevOps engineer is managing network security for a custom Virtual Private Cloud (VPC) network named `vpc-prod`. An existing ingress firewall rule named `allow-internal-web` with priority 1000 permits TCP traffic on port 8080 from the `10.0.0.0/8` IP range to VM instances tagged `web-frontend`. To address a security compliance finding, the engineer must explicitly block incoming TCP traffic on port 8080 originating from the `10.2.0.0/24` subnet while preserving access for all other subnets within `10.0.0.0/8`. Which `gcloud` command should the engineer execute?

Show answer & explanation

Answer: gcloud compute firewall-rules create block-subnet-web --network=vpc-prod --action=DENY --direction=INGRESS --priority=500 --source-ranges=10.2.0.0/24 --rules=tcp:8080 --target-tags=web-frontend

Answer

Execute the command creating a DENY ingress rule on port 8080 from source range 10.2.0.0/24 targeted at web-frontend with priority 500.
Google Cloud VPC firewall rules are evaluated based on priority order where lower integer values denote higher evaluation precedence. Since the existing ALLOW rule has a priority of 1000, creating a DENY rule with priority 500 ensures that incoming packets from 10.2.0.0/24 matching port 8080 are matched and dropped first before reaching the priority 1000 allow rule.

Step-by-Step Solution

1
Understand GCP VPC firewall rule priority evaluation order.
GCP firewall rules are processed from lowest numerical priority value (0) to highest numerical priority value (65535). Once a matching rule is hit, evaluation stops.
To override an existing ALLOW rule with priority 1000, the DENY rule must have a priority number strictly less than 1000.
2
Evaluate the parameters required for the new firewall rule.
The rule must have `--action=DENY`, `--direction=INGRESS`, `--priority` < 1000 (e.g., 500), `--source-ranges=10.2.0.0/24`, `--rules=tcp:8080`, and `--target-tags=web-frontend`.
This ensures only packets from 10.2.0.0/24 intended for port 8080 on web-frontend instances are dropped.

Key Concept

VPC Firewall Priority Evaluation
Question 1222Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

A DevOps engineer needs to run a database schema migration script from their local workstation using the identity of a dedicated production service account named `[email protected]`. The organization's security policy strictly forbids generating and downloading long-lived service account JSON keys. Which IAM configuration allows the engineer to execute commands on behalf of the service account using gcloud impersonation?

Show answer & explanation

Answer: Grant the engineer's user account the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) on the target service account resource.

Answer

Grant the engineer's user account the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) on the target service account resource.
To impersonate a service account from a local environment or CLI tool using short-lived credentials, a user identity requires the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) bound directly to the target service account.

Step-by-Step Solution

1
Identify the security requirement.
The engineer must run commands as a service account without generating or downloading long-lived JSON keys.
Security policy forbids key export, necessitating IAM service account impersonation.
2
Determine the specific IAM role required for impersonation.
The Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) grants the permission `iam.serviceAccounts.getAccessToken` required to create short-lived OAuth tokens for impersonation.
The Service Account User role (roles/iam.serviceAccountUser) only allows attaching service accounts to GCP compute resources, not token generation for local CLI impersonation.
3
Apply least privilege scoping.
Grant the role specifically on the `[email protected]` service account resource rather than at the project level.
This restricts impersonation permissions exclusively to the intended service account.

Key Concept

Service Account Impersonation
Estimated Time:1m 30s
Question 1224Question →

A developer needs to deploy an event-driven Node.js microservice to Google Cloud Functions (2nd gen) that executes whenever a new image file is created in a Cloud Storage bucket named `user-uploads-bucket`. The code entry point is `processImage`. Which `gcloud` command should be executed to successfully deploy this serverless application?

Show answer & explanation

Answer: gcloud functions deploy image-processor --gen2 --runtime=nodejs20 --entry-point=processImage --trigger-event-filters="type=google.cloud.storage.object.v1.finalized" --trigger-event-filters="bucket=user-uploads-bucket"

Answer

Execute `gcloud functions deploy image-processor --gen2 --runtime=nodejs20 --entry-point=processImage --trigger-event-filters="type=google.cloud.storage.object.v1.finalized" --trigger-event-filters="bucket=user-uploads-bucket"`.
The command starting with `gcloud functions deploy` specifying `--gen2` and `--trigger-event-filters="type=google.cloud.storage.object.v1.finalized"` with `--trigger-event-filters="bucket=user-uploads-bucket"` is correct because Cloud Functions (2nd gen) relies on Eventarc to route Cloud Storage events. Providing both the event type and bucket name in the event filters configures the trigger properly.

Step-by-Step Solution

1
Identify the target serverless platform and generation
The requirement specifies deploying a Cloud Function (2nd gen) using source code with entry point `processImage`.
Cloud Functions 2nd gen is built on top of Cloud Run and Eventarc.
2
Determine the event trigger requirements
The trigger is a Cloud Storage object creation event (`google.cloud.storage.object.v1.finalized`) on the `user-uploads-bucket` bucket.
2nd gen Cloud Functions require Eventarc flags specified via `--trigger-event-filters`.
3
Construct the exact `gcloud functions deploy` command
Combine `--gen2`, `--runtime=nodejs20`, `--entry-point=processImage`, and the two required `--trigger-event-filters` flags.
This matches Google Cloud's CLI specification for deploying 2nd gen event-driven functions.

Key Concept

Deploying 2nd Gen Cloud Functions with Cloud Storage Eventarc Triggers
Estimated Time:1m 30s
Question 1225Question →

A DevOps engineer manages a high-traffic production web application running on an existing regional Managed Instance Group (MIG) in Google Compute Engine. A new application release has been packaged into a updated instance template named `web-template-v2`. The engineer must update all running instances in the MIG to use this new template while maintaining continuous service availability without causing downtime. Which command or operational workflow should the engineer execute to meet these requirements?

Show answer & explanation

Answer: Execute `gcloud compute instance-groups managed rolling-action start-update` targeting the instance group and specify `--version=template=web-template-v2`.

Answer

The correct action is to execute `gcloud compute instance-groups managed rolling-action start-update` targeting the instance group and specifying `--version=template=web-template-v2`.
The Google-recommended practice for updating instances in a Managed Instance Group without downtime is performing a rolling update. The `gcloud compute instance-groups managed rolling-action start-update` command updates the group target template and gradually replaces existing instances while keeping the service active and available.

Step-by-Step Solution

1
Identify the managed instance group update requirement
Recognize that updating an existing MIG with a new instance template without downtime requires a rolling update strategy.
Directly replacing VMs all at once would cause service interruption, whereas a rolling update replaces instances incrementally.
2
Execute the rolling update command using gcloud CLI
Run `gcloud compute instance-groups managed rolling-action start-update <group-name> --version=template=web-template-v2 --region=<region>`.
This command signals Compute Engine to update the MIG configuration and perform an online, controlled replacement of existing VM instances according to the configured update policy.

Key Concept

Managed Instance Group Rolling Updates
Question 1226Question →

A DevOps team is deploying a multi-region network infrastructure using the Google Cloud CLI (`gcloud`). They need to configure a custom-mode Virtual Private Cloud (VPC) named `corp-vpc` with a new primary subnet in `us-central1` (10.20.0.0/2410.20.0.0/24). Additionally, security policies require allowing incoming HTTPS (TCP port 443) traffic exclusively to instances tagged with `frontend`, while ensuring this rule takes precedence over lower-priority default rules. Which TWO actions must be executed to successfully complete this deployment?

Select all that apply

Show answer & explanation

Answer: Run `gcloud compute networks subnets create corp-subnet-us --network=corp-vpc --region=us-central1 --range=10.20.0.0/24` to provision the regional subnet.; Run `gcloud compute firewall-rules create allow-frontend-https --network=corp-vpc --allow=tcp:443 --target-tags=frontend --direction=INGRESS --priority=1000` to permit HTTPS traffic to target instances.

Answer

Provisioning the custom subnet using `gcloud compute networks subnets create` with the specified network, region, and CIDR parameters, and creating an ingress firewall rule specifying `--target-tags=frontend`, `--allow=tcp:443`, and a high-precedence priority value such as 1000.
Creating a custom VPC subnet requires executing `gcloud compute networks subnets create` with the associated VPC network, region, and IP address range parameters. Controlling ingress traffic to specific VM instances requires a VPC firewall rule specifying `--direction=INGRESS`, `--target-tags`, `--allow=tcp:443`, and a priority value lower than default rules (such as 1000) to ensure high precedence.

Step-by-Step Solution

1
Provision the regional subnet using the Google Cloud CLI
Subnet `corp-subnet-us` is created with CIDR range 10.20.0.0/2410.20.0.0/24 in `us-central1` bound to `corp-vpc`.
Custom-mode VPC networks require explicit subnet creation with defined IP ranges per region.
2
Configure the ingress firewall rule with network target tags and priority ordering
Firewall rule `allow-frontend-https` permits TCP port 443 traffic for virtual machines with tag `frontend` with priority 1000.
In GCP firewall evaluation, lower numerical priority numbers (e.g., 1000) take precedence over higher numerical values (up to 65535).

Key Concept

Deploying custom VPC subnets and configuring target-tagged ingress firewall rules with priority precedence.
Question 1227Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

A Cloud Engineer is configuring IAM permissions for a dedicated service account used by a Cloud Function. The function must pull messages from a specific Cloud Pub/Sub subscription and upload processed results into a specific Cloud Storage bucket. Following the principle of least privilege, which two IAM role assignments should be granted to the service account?

Select all that apply

Show answer & explanation

Answer: Grant the Pub/Sub Subscriber role (roles/pubsub.subscriber) scoped directly to the target Pub/Sub subscription.; Grant the Storage Object Creator role (roles/storage.objectCreator) scoped directly to the target Cloud Storage bucket.

Answer

Grant the Pub/Sub Subscriber role (roles/pubsub.subscriber) scoped to the specific subscription, and grant the Storage Object Creator role (roles/storage.objectCreator) scoped to the specific Cloud Storage bucket.
To adhere to the principle of least privilege, access must be limited to predefined roles that grant only the required permissions, bound directly to the target resources (the specific Pub/Sub subscription and Cloud Storage bucket). The Pub/Sub Subscriber role on the subscription allows pulling messages, while the Storage Object Creator role on the bucket permits writing output objects without granting read, list, or deletion capabilities.

Step-by-Step Solution

1
Identify the specific resource interactions required for the service account.
The workload requires pulling Pub/Sub subscription messages and writing object files into a single Cloud Storage bucket.
Understanding exact functional needs is essential for defining fine-grained roles.
2
Select predefined roles over primitive roles.
Use roles/pubsub.subscriber for Pub/Sub consumption and roles/storage.objectCreator for bucket object writes instead of primitive roles like Editor.
Predefined roles restrict actions to specific resource operations, upholding least privilege.
3
Apply role bindings at the lowest relevant resource hierarchy level.
Bind roles at the specific subscription and bucket resource levels rather than project or organization levels.
Resource hierarchy inheritance applies access down all child resources, so restricting the binding scope prevents unintended access.

Key Concept

Applying Least Privilege via Predefined Roles and Fine-Grained Resource Scope Binding
Question 1229Question →

An operations team manages a Cloud SQL for PostgreSQL database instance used for live transaction processing. Business analysts frequently execute heavy reporting queries directly against this primary instance, causing CPU utilization spikes that slow down transactional write operations. You need to mitigate the performance impact on transaction processing with minimal operational overhead. Which action should you take?

Show answer & explanation

Answer: Create a read replica of the Cloud SQL instance and configure the reporting queries to connect to the read replica.

Answer

Create a read replica of the Cloud SQL instance and configure the reporting queries to connect to the read replica.
Creating a Cloud SQL read replica offloads analytical read operations from the primary database instance. The read replica receives data updates asynchronously, allowing business analysts to run resource-intensive reporting queries on the replica without impacting the transaction throughput and CPU utilization of the primary database.

Step-by-Step Solution

1
Identify the root cause of the performance degradation.
Heavy read operations for reporting compete for CPU and IOPS resources with primary transactional writes.
Running analytics directly on a primary database degrades write performance during peak workloads.
2
Evaluate Google Cloud database management solutions for read scaling.
Cloud SQL read replicas replicate data asynchronously from the primary instance and serve read-only queries.
Read replicas isolate reporting workloads from the primary instance while maintaining data synchronization.
3
Select the option that offloads reads with minimal operational overhead.
Provisioning a read replica provides a dedicated endpoint for reporting without requiring schema migrations or complex data pipelines.
It directly satisfies the requirement to protect primary write performance with standard managed database features.

Key Concept

Cloud SQL Read Replicas for Workload Isolation
Question 1230Question →

An enterprise operations team uses a centralized continuous integration runner authenticated as `[email protected]` in the project `shared-tools`. The runner needs to deploy infrastructure into project `prod-app-env` by assuming the identity of a target service account `[email protected]` without relying on exported credentials. Which TWO configuration steps are required to establish secure service account impersonation for this workflow? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Grant `[email protected]` the Service Account Token Creator role (`roles/iam.serviceAccountTokenCreator`) directly on the target `[email protected]` service account resource.; Enable the IAM Service Account Credentials API (`iamcredentials.googleapis.com`) in the project initiating the impersonation request.

Answer

To enable service account impersonation, grant the initiating identity the Service Account Token Creator role on the target service account resource and enable the IAM Service Account Credentials API in the originating project.
Configuring service account impersonation requires granting the Service Account Token Creator role to the impersonating identity on the target service account resource. Additionally, the caller must make requests against the IAM Service Account Credentials API (`iamcredentials.googleapis.com`), which must be enabled in the originating project to issue short-lived tokens.

Step-by-Step Solution

1
Determine the necessary role for identity delegation.
The initiating principal (`ci-runner`) requires `roles/iam.serviceAccountTokenCreator` bound specifically to the target service account (`deployer`).
This specific predefined role allows the caller to generate short-lived tokens for the target service account without exposing long-lived keys.
2
Identify the required API endpoint for credential generation.
The IAM Service Account Credentials API (`iamcredentials.googleapis.com`) must be enabled.
Short-lived tokens and signed assertions are generated dynamically via calls to this Google API.

Key Concept

Service Account Impersonation requires granting the Service Account Token Creator role on the target service account and enabling the IAM Service Account Credentials API.
Question 1231Question →

A site reliability engineer needs read-only access to inspect the configuration, state, and metadata of Compute Engine Virtual Machine (VM) instances in a specific project named `proj-prod-analytics`. The engineer must not be granted permissions to modify VM configurations, start or stop instances, or access instance serial console logs. Following Google Cloud recommended security practices, which IAM role binding should you apply?

Show answer & explanation

Answer: Assign the Compute Viewer role (roles/compute.viewer) bound directly to the user on the proj-prod-analytics project.

Answer

Assign the Compute Viewer role (`roles/compute.viewer`) on the `proj-prod-analytics` project resource.
Binding the predefined `roles/compute.viewer` role directly at the target project level provides exact read-only permissions for Compute Engine instances without granting unnecessary privileges across other Google Cloud services or other projects.

Step-by-Step Solution

1
Identify the required permissions needed for the task.
The engineer requires read-only access limited specifically to Compute Engine VM configurations and metadata.
The requirement mandates read access while prohibiting modifications, lifecycle management (start/stop), or serial console access.
2
Evaluate role granularity adhering to the Principle of Least Privilege.
Select the predefined `roles/compute.viewer` role rather than broad primitive roles (`roles/viewer` or `roles/editor`).
Predefined roles restrict permissions to a specific GCP service, preventing excessive read permissions across unrelated project services.
3
Determine the appropriate level in the resource hierarchy for the IAM policy binding.
Apply the role binding at the specific project level (`proj-prod-analytics`).
Granting permissions at higher levels (such as Organization or Folder) causes downstream IAM inheritance, granting unintended access to other projects.

Key Concept

Applying least-privilege predefined roles at the appropriate resource hierarchy level.
Question 1232Question →

A security operations team wants to ensure that no virtual machines created within a development Folder can be assigned public IP addresses. This rule must automatically apply to all current and future projects inside that folder. Which configuration should be used to enforce this restriction?

Show answer & explanation

Answer: Apply an Organization Policy constraint at the Folder level to restrict public IP addresses.

Answer

Apply an Organization Policy constraint at the Folder level to restrict public IP addresses.
Organization Policies provide centralized, programmatic control over cloud resources. Applying an Organization Policy constraint at the Folder level automatically applies the restriction to all existing and newly created child projects within that folder.

Step-by-Step Solution

1
Identify the requirement scope and goal.
The requirement asks to restrict a specific resource configuration (external IPs on VMs) centrally at a Folder node so that all child projects inherit the restriction.
Centralized resource restrictions across a hierarchy subtree require resource constraints rather than user access management.
2
Evaluate Google Cloud mechanisms for resource configuration enforcement.
Organization Policies are designed to enforce constraints on GCP resources across the resource hierarchy (Organization, Folder, Project).
Setting the constraint at the Folder level ensures all current and future child projects in that folder inherit the policy automatically.

Key Concept

Organization Policy Constraints and Resource Hierarchy Inheritance
Estimated Time:45s
Question 1233Question →

A cloud administrator is configuring access controls for a Google Cloud Storage bucket and needs to enforce Uniform Bucket-Level Access (UBLA) to meet security compliance standards. Which TWO statements accurately describe the behavior and enforcement when Uniform Bucket-Level Access is enabled on a Cloud Storage bucket?

Select all that apply

Show answer & explanation

Answer: Access to all objects in the bucket is controlled exclusively through IAM permissions, disabling Object ACLs.; Existing individual object ACL settings are ignored and ACL access requests are revoked in favor of IAM policy evaluations.

Answer

Access to all objects in the bucket is controlled exclusively through IAM permissions, disabling Object ACLs, and existing individual object ACL settings are ignored in favor of IAM policy evaluations.
Uniform Bucket-Level Access (UBLA) ensures that Cloud Storage evaluates access permissions using Cloud IAM exclusively. When UBLA is enabled, per-object ACL access lists are disabled and ignored, standardizing security management across all objects in the bucket.

Step-by-Step Solution

1
Understand Uniform Bucket-Level Access (UBLA)
Recognize that UBLA unifies access control across Cloud Storage resources to use IAM exclusively.
UBLA disables object-level Access Control Lists (ACLs) to ensure consistent permission management.
2
Evaluate the impact on object ACLs
Identify that object-level ACLs are ignored and cannot be applied when UBLA is active.
This guarantees that access is evaluated solely by IAM roles assigned at the bucket, folder, or project level.

Key Concept

Uniform Bucket-Level Access (UBLA) enforcement and IAM access control
Question 1234Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

Creating and Managing Service Accounts
Question 1235Question →

A company requires a team of data analysts to execute analytical queries against a BigQuery dataset in the analytics-prod project from their local workstations. To strictly align with GCP security best practices, long-lived service account keys must not be created or downloaded. The analysts must perform operations using the identity of a dedicated service account, [email protected], which already possesses the necessary BigQuery permissions. Which configuration properly enables the analysts to impersonate this service account while following the principle of least privilege?

Show answer & explanation

Answer: Grant the data analysts group the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) on the sa-bq-executor service account resource, and instruct analysts to run CLI commands with the --impersonate-service-account flag.

Answer

Granting the data analysts group the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) on the specific target service account allows them to generate short-lived tokens and use the --impersonate-service-account flag, adhering to keyless security best practices and least privilege.
To impersonate a service account for local CLI operations without exporting long-lived service account keys, principals must be granted the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) directly on the target service account resource. They can then specify the target identity using flags such as --impersonate-service-account in gcloud commands.

Step-by-Step Solution

1
Identify keyless authentication requirement
Avoid generating or exporting long-lived JSON service account keys.
Security policy mandates short-lived credential generation via identity impersonation.
2
Determine the minimum required IAM role for token creation
Select roles/iam.serviceAccountTokenCreator on the target service account resource.
This role grants the iam.serviceAccounts.getAccessToken permission needed for gcloud impersonation.
3
Configure local client invocation
Use gcloud or client libraries with the --impersonate-service-account flag.
The flag directs gcloud to request short-lived tokens from GCP IAM on behalf of the authenticated user.

Key Concept

Service Account Impersonation via IAM Token Creator Role
Question 1236Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

An organization is setting up continuous deployment pipelines for a containerized application that interacts with a Cloud Spanner database in a single target project named `prod-app-services`. The automated service account used by the deployment pipeline needs permission to deploy updated Cloud Run services and execute database schema modifications in Cloud Spanner. The security architecture policy strictly mandates applying the Principle of Least Privilege and restricting role scope to only the necessary project. Which TWO IAM role bindings should be granted to the service account? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Cloud Run Developer (roles/run.developer) on the `prod-app-services` project; Cloud Spanner Database Admin (roles/spanner.databaseAdmin) on the `prod-app-services` project

Answer

Granting Cloud Run Developer and Cloud Spanner Database Admin roles on the specific target project fulfills all operational needs while adhering to least privilege.
To satisfy least privilege for a pipeline managing Cloud Run deployments and Cloud Spanner schemas, specific predefined roles targeting those exact services must be chosen. The Cloud Run Developer role allows deploying and updating Cloud Run services without full administrative control over unrelated compute infrastructure. The Cloud Spanner Database Admin role allows creating, editing, and applying DDL schema updates to databases. Both bindings must be restricted to the specific target project.

Step-by-Step Solution

1
Analyze the operational requirements of the deployment pipeline identity.
The pipeline requires permissions to deploy Cloud Run revisions and modify Cloud Spanner database schemas.
Identifying necessary capabilities determines which resource-specific roles are required.
2
Filter roles according to the Principle of Least Privilege.
Cloud Run Developer (roles/run.developer) grants service management permissions without full admin rights, while Cloud Spanner Database Admin (roles/spanner.databaseAdmin) allows database and DDL maintenance. Primitive roles like Editor grant unnecessary permissions across other GCP services and must be avoided.
Predefined roles tailored to specific service duties prevent over-provisioning permissions.
3
Determine the required Resource Hierarchy scope for the role binding.
The bindings must be placed directly on the `prod-app-services` project. Organization-level bindings would inherit downward to all projects, violating scope restrictions.
IAM permissions inherit down the resource hierarchy (Organization → Folder → Project → Resource), so bindings must be placed at the lowest sufficient level.

Key Concept

Principle of Least Privilege and Resource Hierarchy Scope in GCP IAM
Estimated Time:2m 0s
Question 1238Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

Uniform Bucket-Level Access Migration Workflow
Question 1240Question →

A DevOps team manages a web application hosted on a Google Kubernetes Engine (GKE) Standard cluster. The team has configured a Horizontal Pod Autoscaler (HPA) to dynamically scale pod replicas based on CPU utilization. However, during a high-traffic test event, the HPA fails to scale the workload, and running `kubectl describe hpa web-app-hpa` outputs the warning: `unable to get metrics for resource cpu: no metrics returned from resource metrics API`. What action should the Cloud Engineer take to resolve this issue and allow the Horizontal Pod Autoscaler to collect resource metrics?

Show answer & explanation

Answer: Ensure the Metrics Server addon is enabled on the GKE cluster and that container resource requests are defined in the pod specification.

Answer

Ensure the Metrics Server addon is enabled on the GKE cluster and that container resource requests are defined in the pod specification.
The Horizontal Pod Autoscaler relies on the Kubernetes Resource Metrics API to query pod CPU and memory usage. In GKE, the Metrics Server addon collects these metrics from node kubelets. Additionally, the pod deployment spec must include resource requests for HPA to determine the current utilization percentage against the requested target.

Step-by-Step Solution

1
Diagnose the error message from the HPA description.
The message indicates that the Resource Metrics API (`metrics.k8s.io`) is missing metric data.
HPA queries the Kubernetes Resource Metrics API to calculate target resource utilization against defined pod requests.
2
Identify missing prerequisite cluster components and workload configurations.
Metrics Server must be enabled in GKE to collect metrics from kubelet, and `resources.requests.cpu` must be specified in the deployment manifest.
Without Metrics Server, metric data is not aggregated; without resource requests, HPA cannot calculate percentage utilization.

Key Concept

Horizontal Pod Autoscaling Prerequisites and Metrics Server Management
PreviousPage 62 / 80Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin