Examkin

All practice questions

1591 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 1301Question →

A financial services company runs a batch data processing pipeline on Compute Engine virtual machines using a workload service account named [email protected]. The pipeline requires short-lived authorization to perform operations against Cloud Storage buckets in a separate data project, acting as the target service account [email protected]. Corporate governance explicitly forbids creating and downloading service account JSON keys. Which IAM role assignment adheres to the principle of least privilege to grant app-worker permission to impersonate storage-mgr?

Show answer & explanation

Answer: Grant [email protected] the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) on [email protected].

Answer

Grant [email protected] the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) on [email protected].
To allow a principal (such as a source service account) to impersonate a target service account and generate short-lived OAuth 2.0 tokens, the principal must be granted the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) on the target service account resource. Binding this role directly on the target identity enforces the principle of least privilege while complying with keyless security mandates.

Step-by-Step Solution

1
Identify authentication constraints and requirements
The source workload service account (app-worker) must perform actions as the target service account (storage-mgr) without using exported service account JSON keys.
Corporate security policy explicitly bans exported service account keys, mandating short-lived credential impersonation.
2
Select the specific IAM role required for token creation and identity delegation
The Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) contains permissions such as iam.serviceAccounts.getAccessToken required to mint short-lived OAuth 2.0 access tokens.
Impersonation requires token creation permissions rather than resource attachment permissions.
3
Apply the IAM role resource binding using least privilege principles
Grant roles/iam.serviceAccountTokenCreator specifically on the target service account resource (storage-mgr) to the caller principal (app-worker).
Binding the role at the target service account resource level restricts impersonation privileges strictly to that identity.

Key Concept

Service Account Impersonation via Service Account Token Creator Role
Question 1302Question →

A DevOps engineer needs to deploy a Cloud Functions (2nd gen) service from local source code to handle background file processing triggered by a Cloud Storage bucket event. The deployment must adhere to the principle of least privilege using a custom service account. What is the correct sequence of steps to perform this deployment?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: 1) Create a dedicated custom IAM service account for the function. 2) Grant the required IAM roles to the custom service account. 3) Run `gcloud functions deploy` specifying the Cloud Storage trigger and the `--service-account` flag. 4) Upload a test file to the Cloud Storage bucket to verify event delivery and function execution.
Deploying an event-driven Cloud Function following GCP security best practices requires creating the custom service account first. Next, IAM roles must be granted to that service account so it possesses the appropriate execution permissions. Third, executing `gcloud functions deploy` attaches the configured service account and sets up the Cloud Storage trigger. Finally, uploading a file to the bucket tests and verifies that the live function executes as expected.

Step-by-Step Solution

1
Create the custom service account
A unique service account identity is created within the Google Cloud project.
An identity must exist before IAM roles can be granted to it or attached to a Cloud Function.
2
Bind required IAM roles to the service account
The service account gains necessary authorization for runtime resources.
Least privilege access control requires configuring resource access permissions prior to runtime usage.
3
Deploy the function using the gcloud CLI
The serverless function is built, deployed, and linked to the Eventarc trigger and custom service account.
Cloud Functions deployment attaches the pre-configured service account identity.
4
Trigger the event by uploading a file
Eventarc delivers the event notification to the function, invoking the code.
Verification can only occur once the service is active and listening for storage events.

Key Concept

Order of operations for deploying event-driven Cloud Functions with custom service account identities
Question 1303Question →

A security engineer needs to configure Cloud Audit Logging to monitor user activity on Google Cloud Storage buckets and then inspect the resulting audit records. What is the correct sequence of steps to enable Data Access audit logging and view these logs?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order is: 1. Navigate to IAM & Admin > Audit Logs in the Google Cloud Console. 2. Select Google Cloud Storage from the service list, enable Data Read and Data Write audit log types, and save. 3. Perform an object read or write operation in a Cloud Storage bucket within the project. 4. Open Logs Explorer and filter logs using the query logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access".
To inspect Data Access audit logs, an administrator must first navigate to IAM & Admin > Audit Logs and explicitly enable Data Read/Data Write logs for Cloud Storage, because Data Access audit logging is turned off by default. Once enabled, performing an operation generates log entries that are subsequently viewable in Logs Explorer under the cloudaudit.googleapis.com/data_access log stream.

Step-by-Step Solution

1
Open the central Audit Logs settings page
Accesses project-level audit log configuration options
Centralized audit log management for all GCP services is located under IAM & Admin > Audit Logs.
2
Enable Cloud Storage Data Access logging
Activates Data Read and Data Write audit record generation for Cloud Storage
Data Access logs are turned off by default to prevent unexpected log storage costs.
3
Generate audit log activity
Creates log events in the Cloud Logging ingestion stream
Audit logs only record events occurring after logging has been enabled.
4
Query the generated logs in Logs Explorer
Displays Data Access audit log entries matching the Cloud Storage operations
Data Access logs are written to the cloudaudit.googleapis.com/data_access log filter path.

Key Concept

Configuring and Analyzing Data Access Cloud Audit Logs
Estimated Time:1m 0s
Question 1304Question →

A software engineer receives an Access Denied error when running `gcloud storage cp file.txt gs://my-company-assets/ --canned-acl=public-read`. Upon inspecting the bucket configuration, you confirm that Uniform Bucket-Level Access (UBLA) is enabled on `my-company-assets`. According to Google Cloud security best practices, how should you grant public read access to the objects in this bucket?

Show answer & explanation

Answer: Grant the predefined Storage Object Viewer role (roles/storage.objectViewer) to allUsers on the bucket IAM policy.

Answer

Grant the predefined Storage Object Viewer role (roles/storage.objectViewer) to allUsers on the bucket IAM policy.
When Uniform Bucket-Level Access (UBLA) is enabled on a Cloud Storage bucket, individual object ACLs (such as canned ACLs) are disabled. All access control must be managed through Google Cloud IAM policies. To make all objects in the bucket publicly readable, security best practices dictate granting the predefined `Storage Object Viewer` (`roles/storage.objectViewer`) role to `allUsers` on the bucket's IAM policy.

Step-by-Step Solution

1
Identify the cause of the command failure.
Uniform Bucket-Level Access (UBLA) disables per-object ACLs, rendering flags like `--canned-acl` invalid.
When UBLA is enabled, Cloud Storage relies exclusively on Cloud IAM for access management.
2
Select the appropriate access grant mechanism.
Assign an IAM role on the bucket for the public identity `allUsers`.
IAM bucket-level policies uniformly manage permissions across all objects stored in the bucket.
3
Apply the principle of least privilege.
Use `roles/storage.objectViewer` instead of primitive or project-wide roles.
The predefined `Storage Object Viewer` role limits access strictly to reading objects without granting excessive permissions.

Key Concept

Uniform Bucket-Level Access and IAM Access Control
Estimated Time:1m 15s
Question 1305Question →

A Cloud Engineer is managing a fleet of Compute Engine virtual machine instances running a custom application. The application writes application-level error records to a local log file at `/var/log/app/error.log`. The SRE team requires automated Cloud Monitoring notifications to trigger whenever the rate of `CRITICAL` status log entries in this file exceeds 10 per minute. Which TWO operational steps must be performed to meet these telemetry and alerting requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the Google Cloud Ops Agent on the Compute Engine instances to collect logs from `/var/log/app/error.log` and ingest them into Cloud Logging.; Create a counter log-based metric in Cloud Logging filtered for `CRITICAL` log entries, and define a Cloud Monitoring alerting policy based on this metric.

Answer

The correct steps are configuring the Google Cloud Ops Agent to ingest local log files into Cloud Logging, and creating a counter log-based metric paired with a Cloud Monitoring alerting policy.
To create alerts based on specific text within a local VM log file, the entries must first be ingested into Cloud Logging using the Google Cloud Ops Agent. Once ingested, a counter log-based metric is configured to count matching log occurrences, enabling Cloud Monitoring alerting policies to trigger when the rate crosses defined thresholds.

Step-by-Step Solution

1
Configure Local Log Ingestion
Local log entries from `/var/log/app/error.log` are parsed and streamed into Cloud Logging.
Cloud Logging must ingest log records before log-based metrics can process log content.
2
Create Log-Based Metric and Alert
A counter log-based metric tracks `CRITICAL` logs, and an alerting policy fires when the rate exceeds 10 entries per minute.
Log-based metrics convert log occurrence frequencies into measurable Cloud Monitoring time-series metrics.

Key Concept

Log-based metrics and Ops Agent log ingestion for threshold alerting
Question 1306Question →

A Cloud Operations engineer needs to configure outbound internet connectivity and secure access to Google APIs for virtual machine instances in a custom VPC subnet named `prod-subnet` (located in `us-central1`). None of the VM instances have external IP addresses assigned. Which TWO actions or `gcloud` commands should the engineer execute to fulfill these requirements?

Select all that apply

Show answer & explanation

Answer: Enable Private Google Access on the subnet using `gcloud compute networks subnets update prod-subnet --region=us-central1 --enable-private-ip-google-access`.; Create a Cloud NAT gateway on a Cloud Router in `us-central1` using `gcloud compute routers nats create` to handle egress traffic for instances without external IPs.

Answer

Enable Private Google Access on the subnet via the gcloud subnets update command, and create a Cloud NAT configuration on a Cloud Router using gcloud compute routers nats create.
To allow private Compute Engine instances without external IP addresses to reach Google APIs and external internet destinations, two complementary GCP networking features must be configured. First, enabling Private Google Access on the subnet allows VMs with only internal IP addresses to send traffic to Google API endpoints. Second, creating a Cloud NAT gateway on a Cloud Router in the same region provides NAT translation for outbound internet connections without exposing the instances to incoming internet requests.

Step-by-Step Solution

1
Configure Private Google Access on the subnet
VMs without external IPs can access Google services privately
Private Google Access must be enabled at the subnet level to allow internal VMs to reach endpoints like Cloud Storage and BigQuery.
2
Deploy Cloud NAT on a Cloud Router in the region
Outbound internet access is enabled for private VMs
Cloud NAT performs source NAT for private VMs reaching the internet without requiring public IP assignments.

Key Concept

Configuring Cloud NAT and Private Google Access for private VPC subnets
Question 1307Question →

A data analytics team needs to grant a newly onboarded junior analyst access to execute queries and read data in BigQuery within a specific Google Cloud project named `analytics-prod`. The analyst must not be able to modify existing tables, delete datasets, or access non-BigQuery resources within the project. Which IAM role assignment follows Google Cloud best practices and the principle of least privilege to fulfill this requirement?

Show answer & explanation

Answer: Grant the user the BigQuery Data Viewer (roles/bigquery.dataViewer) and BigQuery Job User (roles/bigquery.jobUser) predefined roles at the project level.

Answer

Grant the user the BigQuery Data Viewer (roles/bigquery.dataViewer) and BigQuery Job User (roles/bigquery.jobUser) predefined roles at the project level.
To run queries and view dataset contents in BigQuery, a principal requires permission to run query jobs (`roles/bigquery.jobUser`) and read table data (`roles/bigquery.dataViewer`). Granting these predefined roles at the project level enforces the principle of least privilege by restricting access specifically to BigQuery tasks in the target project.

Step-by-Step Solution

1
Identify the required permissions for running queries and reading BigQuery data.
The user needs permission to read dataset contents and permission to run BigQuery jobs (queries).
Running a query requires job creation permissions, while accessing dataset records requires data viewing permissions.
2
Select predefined IAM roles that match the exact permission scope without granting extraneous access.
`roles/bigquery.dataViewer` permits reading data, and `roles/bigquery.jobUser` permits running query jobs.
Predefined roles conform to the principle of least privilege, unlike primitive roles like Viewer or Editor.
3
Determine the proper resource hierarchy level for binding the IAM roles.
Bind the roles at the `analytics-prod` project level.
Applying roles at higher levels such as Folder or Organization would grant access to unrelated projects due to IAM policy inheritance.

Key Concept

Principle of Least Privilege with Predefined IAM Roles
Question 1308Question →

An organization manages an enterprise hybrid cloud setup connected to an on-premises data center via Cloud Interconnect. A Cloud Router named `rt-bgp-uscentral1` operating in region `us-central1` handles dynamic routing for the Virtual Private Cloud (VPC) network `production-vpc`. The Cloud Router is configured with custom route advertisements (`--advertisement-mode=CUSTOM`). A new subnet with CIDR range `10.50.0.0/20` was recently added to `production-vpc`. A network engineer must update `rt-bgp-uscentral1` to advertise this new subnet CIDR range to the on-premises BGP peer without overwriting existing custom IP advertisements or resetting the router mode, and then verify the live operational BGP session status and advertised routes. Which TWO `gcloud` commands should the engineer execute? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Execute `gcloud compute routers add-advertised-ip-ranges rt-bgp-uscentral1 --region=us-central1 --ip-ranges=10.50.0.0/20`.; Execute `gcloud compute routers get-status rt-bgp-uscentral1 --region=us-central1`.

Answer

The engineer must run `gcloud compute routers add-advertised-ip-ranges rt-bgp-uscentral1 --region=us-central1 --ip-ranges=10.50.0.0/20` to append the new CIDR block to the custom route advertisements, and run `gcloud compute routers get-status rt-bgp-uscentral1 --region=us-central1` to inspect the live BGP session state and verified advertised routes.
The correct commands combine updating dynamic BGP route advertisements on a Cloud Router and verifying live operational status. The command `gcloud compute routers add-advertised-ip-ranges` specifically appends a new CIDR block to custom route advertisements without overwriting existing custom settings. The command `gcloud compute routers get-status` provides real-time visibility into the BGP session state and active prefix advertisements.

Step-by-Step Solution

1
Identify the command to update custom advertised IP ranges on a Cloud Router.
Using `gcloud compute routers add-advertised-ip-ranges` with `--region=us-central1` appends `10.50.0.0/20` to the router's custom advertisement configuration.
Running `gcloud compute routers update` with `--set-advertised-ip-ranges` would replace existing custom ranges, whereas `add-advertised-ip-ranges` safely preserves existing custom routes.
2
Identify the command to inspect operational BGP peering status and active routes.
Running `gcloud compute routers get-status` returns details on BGP peer connectivity, state (e.g., ESTABLISHED), and advertised prefixes.
Cloud Router operational metrics and live Advertised Routes are displayed via `get-status` rather than configuration describe commands.

Key Concept

Cloud Router Custom Route Advertisements and Status Monitoring
Estimated Time:2m 0s
Question 1309Question →

A security engineer needs to enable a developer to manage Cloud Storage resources by impersonating a target service account from their local workstation using the Google Cloud CLI, without downloading long-lived service account keys. Arrange the steps required to configure and verify service account impersonation in the correct sequential order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct procedure begins by granting the developer the Service Account Token Creator role on the target service account. Next, the developer authenticates their user identity locally using `gcloud auth login`. Then, the developer sets the `auth/impersonate_service_account` CLI property. Finally, the developer runs resource management commands using automatically generated short-lived tokens.
To establish service account impersonation for local gcloud CLI operations, administrative permissions (`roles/iam.serviceAccountTokenCreator`) must first be granted to the developer on the target service account. The developer then authenticates locally using their user identity via `gcloud auth login`. Following successful login, the developer configures gcloud CLI to impersonate the service account using `gcloud config set auth/impersonate_service_account`. Finally, running GCP commands seamlessly uses short-lived tokens minted on demand.

Step-by-Step Solution

1
Grant `roles/iam.serviceAccountTokenCreator` on the target service account to the developer's user identity.
The developer gains authorization to create short-lived OAuth 2.0 access tokens for the service account.
Service account impersonation requires explicit IAM authorization on the service account resource before short-lived token generation is allowed.
2
Execute `gcloud auth login` on the local workstation.
The developer authenticates and stores local user credentials in gcloud CLI.
The gcloud CLI relies on an authenticated user identity to issue Google Cloud IAM credentials API calls.
3
Execute `gcloud config set auth/impersonate_service_account TARGET_SERVICE_ACCOUNT_EMAIL`.
The gcloud CLI updates its active configuration profile to append impersonation parameters.
Setting this configuration tells gcloud CLI to request short-lived tokens for the target service account rather than invoking APIs under the user's base identity.
4
Execute GCP commands such as `gcloud storage ls`.
The storage resources are listed under the context and permissions of the target service account.
With configuration complete, commands transparently fetch short-lived tokens and perform operations under the delegated service account identity.

Key Concept

Configuring Service Account Impersonation via Google Cloud CLI
Question 1310Question →

A cloud engineer needs to deploy a custom enterprise environment in Google Cloud using the Google Cloud CLI (`gcloud`). The environment requires a custom VPC network, a dedicated subnet in `us-central1`, a restrictive ingress firewall rule for web application traffic, and a Compute Engine VM instance. Arrange the operational steps in the correct chronological sequence required to provision this infrastructure successfully.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of operations is: (1) Create the custom-mode VPC network 'prod-vpc', (2) Create the custom subnet 'prod-app-subnet' within the VPC, (3) Create the ingress firewall rule 'allow-app-ingress' targeting tag 'app-server', and (4) Deploy the Compute Engine VM instance 'app-vm-1' attached to 'prod-app-subnet' with tag 'app-server'.
In Google Cloud, infrastructure provisioning follows a strict dependency hierarchy. First, the custom VPC network container must be created (`gcloud compute networks create --subnet-mode=custom`). Second, regional subnets are created inside that VPC (`gcloud compute networks subnets create`). Third, firewall rules are established on the VPC network specifying target network tags (`gcloud compute firewall-rules create`). Finally, Compute Engine VM instances are deployed into the designated subnet and tagged appropriately (`gcloud compute instances create --subnet ... --tags ...`) so that network routing and firewall policies apply immediately.

Step-by-Step Solution

1
Initialize the parent custom VPC network
Network resource 'prod-vpc' exists with auto-subnet creation disabled.
Custom subnets cannot be created without a parent VPC network existing first.
2
Provision the custom subnet
Subnet 'prod-app-subnet' is established in region 'us-central1'.
VM instances require a specific subnet for IP allocation when operating in a custom mode network.
3
Configure network firewall ingress rule
Firewall rule 'allow-app-ingress' is created under network 'prod-vpc'.
Security controls should be defined on the VPC before launching instances to ensure traffic is governed properly upon boot.
4
Deploy Compute Engine VM instance with network tag
VM instance 'app-vm-1' is instantiated inside 'prod-app-subnet' with target tag 'app-server'.
The instance references both the subnet for connectivity and the network tag to inherit the firewall rule configuration.

Key Concept

Deployment dependency order for GCP VPC networks, subnets, firewall rules, and compute instances.
Question 1311Question →

A cloud engineer needs to update an existing Cloud Run service named `analytics-service` in the `us-central1` region to meet two operational requirements: ensure that unauthenticated invocations are disallowed, and cap the maximum number of container instances at 50 to limit billing exposure. Which of the following commands achieve these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: gcloud run services update analytics-service --no-allow-unauthenticated --region=us-central1; gcloud run services update analytics-service --max-instances=50 --region=us-central1

Answer

To enforce authentication and set autoscaling limits on an existing Cloud Run service, use 'gcloud run services update analytics-service --no-allow-unauthenticated --region=us-central1' and 'gcloud run services update analytics-service --max-instances=50 --region=us-central1'.
To update an existing Cloud Run service, the 'gcloud run services update' command is used. Disallowing unauthenticated access requires the '--no-allow-unauthenticated' flag, while capping active instances requires setting the '--max-instances' flag.

Step-by-Step Solution

1
Identify the CLI tool appropriate for managing Cloud Run services.
Use 'gcloud run services update' rather than 'gcloud functions' or project-level IAM commands.
Cloud Run service operational configurations are managed via the 'gcloud run' command family.
2
Determine the flag required to restrict access to authenticated invokers only.
Select the option specifying '--no-allow-unauthenticated'.
This removes 'allUsers' access on the service's IAM policy, enforcing Cloud IAM authentication for incoming requests.
3
Determine the flag required to set maximum container autoscaling limits.
Select the option specifying '--max-instances=50'.
The '--max-instances' flag directly controls the upper bound of active instances provisioned by Cloud Run.

Key Concept

Cloud Run Resource Management via gcloud CLI
Question 1312Question →

A financial data processing pipeline uploads automated daily extract files into a Cloud Storage bucket named `fin-monthly-extracts`. A legacy batch script executed by a dedicated service account currently sets fine-grained object Access Control Lists (ACLs) using `gsutil acl` after each upload. Security policy now mandates enforcing Uniform Bucket-Level Access across all storage buckets in the project. Which action should you take to enforce compliance while ensuring the batch script can successfully read and write objects?

Show answer & explanation

Answer: Grant the service account the predefined Storage Object Admin role at the bucket level, remove the object ACL commands from the script, and enable Uniform Bucket-Level Access on the bucket.

Answer

Grant the service account the predefined Storage Object Admin role at the bucket level, remove the object ACL commands from the script, and enable Uniform Bucket-Level Access on the bucket.
Enabling Uniform Bucket-Level Access (UBLA) standardizes Cloud Storage security by delegating all access decisions strictly to Cloud IAM and disabling individual object Access Control Lists (ACLs). Granting the predefined Storage Object Admin role at the bucket level allows the service account to perform necessary file management operations without exceeding least privilege requirements.

Step-by-Step Solution

1
Analyze access control requirements under Uniform Bucket-Level Access (UBLA).
Determine that UBLA disables fine-grained object ACLs and relies solely on Cloud IAM policies.
When UBLA is enabled, ACL operations are ignored and rejected by Cloud Storage.
2
Assign principle-of-least-privilege IAM permissions.
Grant the Storage Object Admin role directly to the service account at the target bucket level.
This allows object creation, reading, and deletion within the specific bucket without granting excessive project-level access.
3
Remediate application code and activate UBLA.
Remove `gsutil acl` operations from the pipeline script and set UBLA on the bucket.
Removing ACL modification commands prevents runtime execution errors post-UBLA activation.

Key Concept

Uniform Bucket-Level Access (UBLA) unifies permissions exclusively through Cloud IAM roles and explicitly disables legacy Object ACL operations.
Estimated Time:2m 0s
Question 1313Question →

A security administrator needs to grant a development team the ability to deploy Cloud Run services that execute under an existing user-managed service account named [email protected]. Security policy strictly requires enforcing the principle of least privilege and forbids developers from creating service account keys or modifying IAM policies on the service account. Which IAM configuration fulfills these requirements?

Show answer & explanation

Answer: Grant the developers the Service Account User role (roles/iam.serviceAccountUser) on the specific service account resource.

Answer

Granting the Service Account User role (roles/iam.serviceAccountUser) resource-level access on the specific service account gives developers the exact permission required to bind the service account to compute resources like Cloud Run, while withholding service account management and key creation rights.
To allow a identity to attach a service account to a compute service (such as Cloud Run or Compute Engine), the identity requires the Service Account User role (roles/iam.serviceAccountUser). Binding this role directly on the specific service account resource restricts authorization to that single identity, satisfying the principle of least privilege without providing key generation or IAM administrative permissions.

Step-by-Step Solution

1
Identify the functional requirement
Developers need permission to attach an existing service account to a compute resource (Cloud Run).
Deploying resources that run as a managed identity requires service account usage authorization.
2
Determine the least-privilege IAM role for attaching service accounts
The predefined role roles/iam.serviceAccountUser provides the iam.serviceAccounts.actAs permission.
This permission allows a principal to impersonate or run operations under the service account without exposing credentials.
3
Apply resource-level IAM scoping
Bind roles/iam.serviceAccountUser directly to [email protected] rather than project-wide.
Restricting the IAM binding to the specific service account resource prevents unauthorized usage of other service accounts in the project.

Key Concept

Delegating Service Account Usage with Least Privilege
Question 1314Question →

A developer needs to run a local database migration script that connects to a Google Cloud resource using a dedicated service account, `[email protected]`. To follow security policies that strictly prohibit saving service account JSON keys on local workstations, the cloud administrator wants to grant the developer permission to perform service account impersonation using the gcloud CLI.

Which IAM role must be assigned to the developer's user account on the target service account to allow short-lived identity impersonation?

Show answer & explanation

Answer: Service Account Token Creator (`roles/iam.serviceAccountTokenCreator`)

Answer

Assign the Service Account Token Creator role (`roles/iam.serviceAccountTokenCreator`) to the developer's user identity on the target service account.
To impersonate a service account and mint short-lived tokens via gcloud CLI or APIs, the initiating identity requires the Service Account Token Creator role (`roles/iam.serviceAccountTokenCreator`) on the target service account. This allows keyless authorization without exporting JSON keys.

Step-by-Step Solution

1
Identify the mechanism required for keyless short-lived credential generation
Determine that service account impersonation generates temporary OAuth 2.0 access tokens.
Security guidelines require avoiding stored long-lived JSON service account keys on local devices.
2
Evaluate GCP IAM roles specific to service account impersonation
Identify `roles/iam.serviceAccountTokenCreator` as the role providing `iam.serviceAccounts.getAccessToken` and related token generation permissions.
The `roles/iam.serviceAccountUser` role only permits attaching service accounts to compute resources, whereas `roles/iam.serviceAccountTokenCreator` permits generating impersonation tokens.
3
Apply principle of least privilege at the resource level
Grant `roles/iam.serviceAccountTokenCreator` directly on the target service account resource.
Granting the role on the specific service account limits impersonation scope strictly to `[email protected]`.

Key Concept

Configuring Service Account Impersonation using Service Account Token Creator role
Question 1315Question →

A cloud administrator needs to script the deployment of a Compute Engine virtual machine instance named `backend-api` into an existing Virtual Private Cloud (VPC) subnetwork named `prod-subnet`. Additionally, the deployment script must pass key-value pairs (`env=production,role=api`) to the instance metadata server upon creation. Which of the following flags should be included in the `gcloud compute instances create` command to achieve this configuration? (Select TWO answers.)

Select all that apply

Show answer & explanation

Answer: --subnet=prod-subnet; --metadata=env=production,role=api

Answer

The correct flags to include in the `gcloud compute instances create` command are `--subnet=prod-subnet` and `--metadata=env=production,role=api`.
Specifying `--subnet=prod-subnet` ensures the VM instance connects to the intended VPC subnetwork, while `--metadata=env=production,role=api` registers the specified key-value pairs on the instance's metadata server during creation.

Step-by-Step Solution

1
Identify the required network configuration flag for specifying a subnetwork.
The standard `gcloud compute instances create` flag for attaching to a subnetwork is `--subnet`.
Deploying into a specific VPC subnetwork requires passing `--subnet=<subnet-name>`.
2
Identify the required metadata configuration flag for setting key-value pairs.
The standard `gcloud compute instances create` flag for setting instance metadata is `--metadata`.
Custom key-value pairs are passed to the instance metadata server using comma-separated `KEY=VALUE` entries with `--metadata`.

Key Concept

Deploying Compute Engine instances into specific subnets with custom metadata using gcloud CLI flags
Question 1316Question →

A DevOps engineer must configure keyless authentication for a microservice deployed in a Google Kubernetes Engine (GKE) cluster. The microservice runs in the `analytics` namespace and needs to read objects from a Cloud Storage bucket using a Google Service Account (GSA). What is the correct sequence of steps to establish Workload Identity binding between the Kubernetes Service Account (KSA) and the GCP Service Account (GSA)?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: 1) Create the Google Service Account (GSA) and assign it the Storage Object Viewer role on the target bucket, 2) Create the Kubernetes Service Account (KSA) in the `analytics` namespace, 3) Grant the `roles/iam.workloadIdentityUser` role on the GSA to the principal member `serviceAccount:PROJECT_ID.svc.id.goog[analytics/KSA_NAME]`, and 4) Annotate the KSA with `iam.gke.io/gcp-service-account=GSA_EMAIL`.
Establishing Workload Identity requires provisioning the GCP IAM identity (GSA) and Kubernetes identity (KSA), granting `roles/iam.workloadIdentityUser` on the GSA to the KSA principal in the Workload Identity pool (`PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]`), and finally annotating the KSA with the GSA email so the GKE metadata server handles token exchanges.

Step-by-Step Solution

1
Provision the Google Service Account (GSA) and grant required GCP resource roles.
A GSA exists with permission to read objects from the target Cloud Storage bucket.
The GSA acts as the GCP IAM identity possessing the necessary permissions on GCP resources.
2
Provision the Kubernetes Service Account (KSA) in the application's GKE namespace.
A KSA identity is registered inside Kubernetes in the `analytics` namespace.
Pods running inside GKE require a local Kubernetes identity to map to GCP IAM.
3
Grant the `roles/iam.workloadIdentityUser` role on the GSA to the KSA member URI.
GCP IAM allows the specific `PROJECT_ID.svc.id.goog[analytics/KSA_NAME]` identity to impersonate the GSA.
This establishes authorization on the GCP side for the GKE Workload Identity pool principal.
4
Annotate the KSA with the metadata key `iam.gke.io/gcp-service-account=GSA_EMAIL`.
The GKE metadata server maps requests from pods using this KSA directly to the target GSA.
This completes the binding on the Kubernetes side so applications automatically acquire short-lived tokens for the GSA without managing JSON key files.

Key Concept

Configuring Workload Identity Binding between GKE KSAs and GCP GSAs
Question 1317Question →

An e-commerce platform recently enabled Uniform Bucket-Level Access on a Cloud Storage bucket named `order-receipts-prod` to align with company security governance. Shortly after enforcement, an automated ingestion microservice fails when uploading receipt PDFs, returning an HTTP 400 error indicating that Access Control Lists (ACLs) are disabled. Inspection reveals the microservice uses a legacy SDK configured to attach a `public-read` canned ACL to each uploaded object. You must restore microservice functionality while maintaining Uniform Bucket-Level Access compliance on the bucket. Which action should you take?

Show answer & explanation

Answer: Update the microservice code to upload objects without specifying canned ACLs, and assign the Storage Object Creator role to the microservice service account on the bucket.

Answer

Update the microservice code to upload objects without specifying canned ACLs, and assign the Storage Object Creator role to the microservice service account on the bucket.
When Uniform Bucket-Level Access (UBLA) is enabled on a Google Cloud Storage bucket, fine-grained object Access Control Lists (ACLs) are disabled. All access must be authorized using Cloud IAM permissions. Removing the legacy canned ACL metadata from the application's upload request fixes the API rejection, while granting the predefined 'Storage Object Creator' IAM role to the microservice's service account ensures least-privilege compliance.

Step-by-Step Solution

1
Identify the cause of the HTTP 400 upload failure.
Uniform Bucket-Level Access (UBLA) disables all legacy Access Control Lists (ACLs), causing object creation calls containing canned ACL parameters (such as public-read) to fail.
UBLA unifies access management strictly under Cloud IAM policies at the bucket and project level.
2
Remediate the client application request payload.
The microservice must stop sending canned ACL metadata during upload operations.
Removing ACL parameters ensures compatibility with UBLA-enforced buckets.
3
Grant minimum necessary IAM permissions to the application identity.
Assign the predefined IAM role Storage Object Creator (roles/storage.objectCreator) to the microservice's service account at the bucket level.
This grants the exact permission (storage.objects.create) needed to write objects without granting excessive project-wide permissions.

Key Concept

Uniform Bucket-Level Access and IAM Role Allocation
Question 1318Question →

An enterprise auditor needs to review both Admin Activity and Data Access audit logs for Cloud Storage buckets across all projects within a specific GCP Folder. The auditor must be able to view sensitive Data Access logs containing user access records, but must not be granted permissions to view the actual data stored inside the buckets or modify any Cloud Logging routing configurations. Following Google Cloud security best practices, which IAM role assignment satisfies these requirements with least privilege?

Show answer & explanation

Answer: Grant the Logs Private Logs Viewer role (roles/logging.privateLogViewer) on the target Folder.

Answer

Granting the Logs Private Logs Viewer predefined role (roles/logging.privateLogViewer) at the Folder level provides read access to both standard audit logs (Admin Activity) and restricted Data Access audit logs across all inherited child projects without providing access to actual underlying storage payload data or log administration capabilities.
The correct answer specifies granting the Logs Private Logs Viewer role (roles/logging.privateLogViewer) at the Folder level. Cloud Logging categorizes Data Access logs under private logs. While roles/logging.viewer only allows viewing Admin Activity, System Event, and Access Transparency logs, roles/logging.privateLogViewer grants access to Data Access logs as well. Furthermore, it does not grant permissions to read actual object contents stored in Cloud Storage or modify logging sinks, adhering strictly to least privilege.

Step-by-Step Solution

1
Identify log access scope requirement
The requirement specifies reading both Admin Activity and Data Access audit logs.
Data Access logs are categorized as private logs in Cloud Logging because they contain detailed information about user interactions with resource data.
2
Evaluate standard viewer vs. private viewer role permissions
roles/logging.viewer lacks permissions to read Data Access logs, whereas roles/logging.privateLogViewer encompasses all permissions of roles/logging.viewer plus permissions to view private Data Access logs.
Google Cloud segregates Data Access audit log visibility behind the private log viewing permission to prevent unauthorized inspection of operational access patterns.
3
Apply least privilege and resource hierarchy inheritance
Assigning roles/logging.privateLogViewer at the Folder level allows inheritance across all underlying projects while withholding data payload access and logging management rights.
Primitive roles grant excessive resource read rights, and admin roles grant management rights, making predefined private log viewer the minimal required grant.

Key Concept

Cloud Audit Logs IAM Access Granularity
Question 1319Question →

A microservices developer needs to deploy a containerized application stored in Artifact Registry (`europe-west1-docker.pkg.dev/company-prod/apps/payment-gateway:v1`) to Google Cloud Run. The deployment must fulfill the following operational criteria:
- Deploy the service under the name `payment-gateway` in the `europe-west1` region.
- Run the container using the custom service account `[email protected]`.
- Allow public HTTP requests without authentication for incoming webhooks.

Which `gcloud` command should the developer execute to meet these requirements?

Show answer & explanation

Answer: gcloud run deploy payment-gateway --image=europe-west1-docker.pkg.dev/company-prod/apps/payment-gateway:v1 --region=europe-west1 --service-account=payment-sa@company-prod.iam.gserviceaccount.com --allow-unauthenticated

Answer

The command starting with `gcloud run deploy payment-gateway` with `--image`, `--region=europe-west1`, `--service-account`, and `--allow-unauthenticated` flags correctly deploys the Cloud Run service.
The correct command uses `gcloud run deploy payment-gateway` combined with `--image` pointing to Artifact Registry, specifies `--region=europe-west1` for target location, configures `--service-account` for identity, and includes `--allow-unauthenticated` to permit unauthenticated external webhook invocations.

Step-by-Step Solution

1
Identify the proper Google Cloud compute platform for deploying custom container images.
Cloud Run is the appropriate serverless service for running arbitrary container images, using `gcloud run deploy`.
Cloud Functions deploys function source code, whereas Cloud Run deploys stateless container images.
2
Select the required deployment flags for service name, image path, region, execution identity, and ingress authentication.
The flags `--image`, `--region=europe-west1`, `--service-account=payment-sa@company-prod.iam.gserviceaccount.com`, and `--allow-unauthenticated` satisfy all requirements.
These flags specify where to fetch the container image, where to run it, under which IAM service account identity it runs, and whether unauthenticated web traffic is permitted.
3
Verify port configuration best practices for Cloud Run.
Avoid setting `--port=80` unless the container explicitly requires listening on port 80 instead of the standard `$PORT` (8080).
Cloud Run injects the `PORT` environment variable (default 8080) into the container container environment.

Key Concept

Deploying serverless container workloads to Cloud Run using gcloud CLI flags
Estimated Time:1m 30s
Question 1320Question →

An administrator manages a stateless web service deployed on a Compute Engine Managed Instance Group (MIG). Users report that individual instances occasionally stop responding to HTTP requests on port 80, even though the VM status in the Google Cloud Console remains RUNNING. The administrator needs to ensure that any instance failing to serve web traffic is automatically recreated by the group without manual intervention. Which action should the administrator take?

Show answer & explanation

Answer: Create an HTTP health check targeting port 80 and attach it as an autohealing policy to the Managed Instance Group.

Answer

Create an HTTP health check targeting port 80 and attach it as an autohealing policy to the Managed Instance Group.
Attaching an HTTP health check to a Managed Instance Group via an autohealing policy actively probes the application layer on port 80. If the application stops responding, the health check marks the instance as UNHEALTHY, prompting the Managed Instance Group to automatically recreate the VM instance to restore normal operations.

Step-by-Step Solution

1
Identify the failure domain.
The application service on port 80 is unresponsive, but the underlying VM host hypervisor considers the VM state RUNNING.
Host-level metrics cannot detect application-level crashes or hung web server threads.
2
Select the appropriate Compute Engine feature for application monitoring.
Managed Instance Groups support autohealing policies based on Google Cloud health checks.
An HTTP health check actively probes port 80 to verify that the application endpoint is responding properly.
3
Apply the autohealing policy to the MIG.
If an instance fails consecutive health probes beyond the configured threshold, the MIG signals the instance as UNHEALTHY and automatically recreates it.
This automates self-healing of application instances without manual administrative intervention.

Key Concept

MIG Autohealing Policies and Health Checks
Estimated Time:1m 30s
PreviousPage 66 / 80Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin