Examkin

All practice questions

1591 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 1201Question →

A cloud operations team manages standalone Compute Engine VM instances hosting an enterprise web application. You need to configure the instances to send guest OS memory utilization metrics to Cloud Monitoring and ensure that the instances remain running without application downtime during scheduled infrastructure maintenance events. Which TWO actions should you perform? (Select 2 answers.)

Select all that apply

Show answer & explanation

Answer: Install and configure the Google Cloud Ops Agent on the Compute Engine VM instances.; Configure the VM instance host maintenance behavior setting to Migrate VM instance.

Answer

To collect guest-level memory metrics and maintain continuous uptime during host maintenance, you must install the Google Cloud Ops Agent and set the host maintenance policy to 'Migrate VM instance'.
Collecting guest OS memory metrics in Compute Engine requires installing the unified Google Cloud Ops Agent, which reports RAM and disk performance metrics directly to Cloud Monitoring. To protect the application from downtime during Google Cloud host maintenance, configuring the 'On host maintenance' option to 'Migrate VM instance' leverages Google Cloud's Live Migration capability to keep the VM running uninterrupted on another physical host.

Step-by-Step Solution

1
Determine the correct agent for guest-level metric collection on Compute Engine.
Identify that the Google Cloud Ops Agent combines logging and metrics collection into a unified, supported agent capable of capturing guest memory utilization.
Cloud Monitoring cannot capture OS-level memory metrics without an agent installed inside the guest OS.
2
Determine the correct maintenance policy setting to prevent downtime during hardware or host maintenance.
Set the 'On host maintenance' property to 'Migrate VM instance'.
Live Migration seamlessly transitions running VM instances to a new host during maintenance without resetting or stopping the instance.
3
Validate security and role requirements for metric export.
Avoid primitive roles like Owner, using standard predefined roles (such as Monitoring Metric Writer) attached to the service account.
Applying primitive roles grants excessive permissions across GCP resources.

Key Concept

Compute Engine Host Maintenance Policies and Guest-level Telemetry Collection via Ops Agent
Question 1202Question →

An organization wants to configure a GitHub Actions CI/CD pipeline to deploy Cloud Run services without exporting long-lived service account JSON keys. What is the correct sequential order of steps to establish Workload Identity Federation and service account impersonation for this setup?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with creating the Workload Identity Pool and Provider, followed by creating the target GCP Service Account, granting the `roles/iam.workloadIdentityUser` role to the GitHub repository identity on that service account, and lastly updating the workflow step to request short-lived credentials.
Establishing Workload Identity Federation requires creating the federated infrastructure (Pool & Provider), defining the target GCP identity (Service Account), binding the `roles/iam.workloadIdentityUser` role to the external identity principal, and lastly referencing these resources in the pipeline execution workflow.

Step-by-Step Solution

1
Set up the Workload Identity Pool and Provider in GCP
Establishes federated trust between Google Cloud IAM and GitHub's OpenID Connect (OIDC) issuer.
Google Cloud needs a registered pool and provider to validate incoming OIDC assertion tokens from external workloads.
2
Provision the target GCP Service Account with Cloud Run deployment roles
Creates the GCP identity holding minimal privileges required for the deployment.
The external workload cannot execute GCP commands without an authorized target service account to impersonate.
3
Bind `roles/iam.workloadIdentityUser` on the Service Account to the GitHub repository principal
Authorizes the specific external repository identity to assume the target service account.
Impersonation via Workload Identity Federation requires explicit authorization using the Workload Identity User role on the target service account.
4
Configure the GitHub Actions workflow to exchange OIDC tokens for GCP credentials
Enables keyless, short-lived authentication for deployment steps.
The pipeline workflow step uses the official auth action to exchange GitHub tokens for temporary Google Cloud access tokens.

Key Concept

Configuring Workload Identity Federation for keyless service account impersonation from external CI/CD pipelines.
Question 1203Question →

An engineer needs to deploy a containerized API microservice to Google Cloud Run using the gcloud CLI. The containerized application is configured to listen internally on custom TCP port 8085, and it must execute using a dedicated user-managed service account named [email protected] to adhere to least privilege permissions. Which TWO gcloud CLI configuration flags must be included in the deployment command to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Include the --port=8085 flag to instruct Cloud Run to send incoming HTTP requests to port 8085 inside the container.; Include the --service-account=sa-api-processor@my-project.iam.gserviceaccount.com flag to attach the dedicated identity to the Cloud Run revision.

Answer

The deployment command must include both the --port=8085 flag to route incoming traffic to the container's custom listening port and the --service-account flag to attach the dedicated user-managed service account.
Deploying a Cloud Run service that listens on a non-standard port requires setting the --port flag in the gcloud run deploy command so that ingress traffic is forwarded correctly. Furthermore, specifying the --service-account flag ensures that the service executes under a dedicated user-managed service account rather than the default compute service account.

Step-by-Step Solution

1
Configure the container ingress port using gcloud run deploy flags.
Adding --port=8085 configures the Cloud Run routing layer to proxy requests to port 8085 inside the container container instance.
By default Cloud Run expects the container to listen on port 8080 unless explicitly overridden via the --port flag.
2
Specify the custom execution identity for the serverless workload.
Adding --service-account=sa-api-processor@my-project.iam.gserviceaccount.com binds the custom IAM service account to the deployed revision.
This ensures the container runs under a non-default identity with minimal required IAM permissions.

Key Concept

Deploying Cloud Run services with custom port configuration and user-managed service account identities using gcloud CLI.
Estimated Time:1m 30s
Question 1204Question →

You are managing identity configuration in a Google Cloud project with the ID `finance-analytics-prod`. You need to create a new user-managed service account named `app-scanner` to run an internal data inspection tool. Which TWO of the following statements regarding the creation and default attributes of this service account are correct?

Select all that apply

Show answer & explanation

Answer: The service account email address will automatically be generated in the format `[email protected]`.; You can create the service account using the CLI command `gcloud iam service-accounts create app-scanner --display-name="App Scanner"`.

Answer

The statement specifying that the service account email is formatted as `[email protected]` and the statement specifying the `gcloud iam service-accounts create` command are both correct.
User-managed service accounts in Google Cloud are assigned an email address structured as `[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com`. Furthermore, the standard gcloud command to provision a service account is `gcloud iam service-accounts create [SA_NAME]`.

Step-by-Step Solution

1
Identify the standard email naming convention for Google Cloud user-managed service accounts.
User-managed service account emails follow `[SA-NAME]@[PROJECT-ID].iam.gserviceaccount.com`.
This provides a globally unique identity identifier within Google Cloud IAM.
2
Verify the correct `gcloud` command for service account creation.
`gcloud iam service-accounts create app-scanner --display-name="App Scanner"` is valid syntax.
The `gcloud iam service-accounts create` command registers a new user-managed service account in the active project.
3
Evaluate default permissions and security behaviors of new service accounts.
Service accounts are created with zero permissions and no default key export files.
Google Cloud enforces default secure configurations, requiring explicit IAM role binding.

Key Concept

Creating User-Managed Service Accounts and Default IAM Properties
Question 1205Question →

An enterprise security team requires an update to the firewall rule configuration of a custom Virtual Private Cloud (VPC) network named `prod-vpc`. Currently, an existing ingress firewall rule named `allow-web-internal` has a priority of `1000` and allows TCP port `8080` traffic from `10.1.0.0/16` to all instances in the network. The security team needs to immediately block all TCP port `8080` traffic originating specifically from the subnetwork `10.1.50.0/24`, while maintaining allowed access for all other IP addresses within `10.1.0.0/16`. Which firewall rule configuration should the Cloud Engineer implement to meet this requirement?

Show answer & explanation

Answer: Create a new ingress firewall rule with action DENY, target port TCP 8080, source filter 10.1.50.0/24, and assign it a priority of 500.

Answer

Create a new ingress firewall rule with action DENY, target port TCP 8080, source filter 10.1.50.0/24, and assign it a priority lower than 1000 (such as 500).
GCP firewall rules evaluate in order of numerical priority from 0 to 65535, where lower numbers take precedence. Creating a DENY rule for 10.1.50.0/24 with priority 500 ensures that matching packets are evaluated and dropped before reaching the broader ALLOW rule configured at priority 1000.

Step-by-Step Solution

1
Analyze existing firewall evaluation precedence.
The existing rule `allow-web-internal` has a priority of 1000 allowing TCP port 8080 from 10.1.0.0/16.
Firewall rules in GCP are processed in order from lowest numerical priority value (highest precedence) to highest numerical priority value.
2
Determine the required action and priority for the new specific restriction.
To override a broader ALLOW rule at priority 1000 for a specific subset range (10.1.50.0/24), a DENY rule must be created with a priority strictly less than 1000 (e.g., 500).
When a packet matches a rule with lower numerical priority value, processing stops and that action (DENY) is immediately enforced.
3
Verify rule parameters.
Action: DENY, Direction: INGRESS, Target port: 8080, Source IPv4 range: 10.1.50.0/24, Priority: 500.
Traffic from 10.1.50.0/24 hits priority 500 first and gets blocked; traffic from other parts of 10.1.0.0/16 misses priority 500 and evaluates against priority 1000 where it is allowed.

Key Concept

GCP VPC Firewall Rule Priority Precedence & Action Evaluation
Estimated Time:2m 0s
Question 1206Question →

A cloud engineer is standardizing security controls across Google Cloud Storage buckets. The team recently enabled Uniform Bucket-Level Access on a bucket named `app-audit-logs` to comply with organization security policies. An automated deployment script now fails when executing `gcloud storage objects add-acl --object=daily_summary.json --rw-grant=...` to grant read access to a downstream processing account. What is the recommended operational fix to grant access while adhering to the security policy?

Show answer & explanation

Answer: Grant the downstream processing account the Storage Object Viewer role on the bucket, using IAM Conditions to restrict permission to the target object path.

Answer

Grant the downstream processing account the Storage Object Viewer role on the bucket, using IAM Conditions to restrict permission to the target object path.
When Uniform Bucket-Level Access (UBLA) is enabled, Cloud Storage disables ACLs and manages permissions strictly through Cloud IAM. To grant access to specific objects without violating UBLA or granting excessive permissions, administrators should assign predefined Cloud Storage IAM roles (such as Storage Object Viewer) at the bucket level and apply IAM Conditions to scope access to the required object path.

Step-by-Step Solution

1
Identify the cause of the command failure.
Uniform Bucket-Level Access (UBLA) disables legacy Access Control Lists (ACLs) entirely for the bucket and its objects.
All object-level ACL operations (such as gcloud storage objects add-acl) fail when UBLA is enforced.
2
Determine the appropriate access management mechanism under UBLA.
Access must be granted exclusively via Cloud IAM policies.
UBLA unifies access control strictly through Google Cloud IAM.
3
Configure scoped IAM access using predefined roles and conditions.
Assign the Storage Object Viewer role at the bucket level scoped with an IAM Condition matching the target object path.
This grants access to the specific object while maintaining UBLA compliance and adhering to the principle of least privilege.

Key Concept

Uniform Bucket-Level Access & IAM Scoping
Question 1207Question →

A cloud engineer is migrating an enterprise Cloud Storage bucket named `archival-reports-prod` to meet security audit compliance standards requiring Uniform Bucket-Level Access (UBLA). Previously, legacy applications relied on individual object Access Control Lists (ACLs) for read permissions. Immediately after the engineer enables UBLA on the bucket, a dedicated service account `[email protected]` receives HTTP 403 Access Denied errors when reading objects. The engineer must restore object read permissions for this service account while strictly maintaining UBLA enforcement. Which administrative action should the engineer take?

Show answer & explanation

Answer: Grant the predefined Storage Object Viewer role (roles/storage.objectViewer) to serviceAccount:[email protected] at the bucket level.

Answer

Grant the predefined Storage Object Viewer role (roles/storage.objectViewer) to serviceAccount:[email protected] at the bucket level.
When Uniform Bucket-Level Access (UBLA) is enabled on a Cloud Storage bucket, ACLs are disabled and ignored. Permission management transitions exclusively to IAM. Assigning the predefined Storage Object Viewer role (`roles/storage.objectViewer`) directly to the service account at the bucket level grants read access to all objects in the bucket while upholding UBLA compliance and maintaining least-privilege security standards.

Step-by-Step Solution

1
Analyze the impact of enabling Uniform Bucket-Level Access (UBLA) on Google Cloud Storage buckets.
Enabling UBLA disables all per-object ACLs, meaning object access relies entirely on Cloud Storage IAM permissions granted at the bucket, folder, or project level.
Legacy applications using object ACLs lose access when UBLA is enabled because ACL checks are bypassed and ignored.
2
Identify the appropriate IAM role and scope to restore access under the principle of least privilege.
The predefined role `roles/storage.objectViewer` granted on the specific bucket provides read access to all objects in that bucket without exposing other resources or project services.
IAM roles at the bucket level satisfy the UBLA requirement while giving the exact permissions needed by the service account.
3
Evaluate alternative option proposals against GCP security best practices.
Modifying object ACLs fails under UBLA, granting primitive project roles violates least privilege, and disabling UBLA fails the mandatory security audit criteria.
Only bucket-level predefined IAM role assignment satisfies both access requirements and security constraints.

Key Concept

Uniform Bucket-Level Access (UBLA) enforcement and Cloud Storage IAM role delegation
Question 1208Question →

A DevOps team is deploying a new production Cloud Spanner instance named 'global-inventory-db' to support a multi-region transactional workload. The design specification mandates using the multi-region instance configuration 'nam-eur-asia1' and allocating a compute capacity of 1,000 processing units. Which TWO parameters are required when creating this instance using the gcloud CLI? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: --config=nam-eur-asia1; --processing-units=1000

Answer

When creating a Cloud Spanner instance using the gcloud CLI, the --config flag specifies the regional or multi-region placement configuration (such as nam-eur-asia1), and the --processing-units flag defines the compute capacity allocated to the instance (1,000 processing units equals 1 node).
Cloud Spanner instance provisioning requires defining the regional or multi-region instance configuration using the --config flag and the instance compute capacity using either --nodes or --processing-units. Specifying --config=nam-eur-asia1 and --processing-units=1000 correctly configures the multi-region topology and compute allocation.

Step-by-Step Solution

1
Identify the managed database engine being provisioned.
The target managed database service is Cloud Spanner.
Cloud Spanner uses instance configs and processing units/nodes rather than machine tiers or IP assignment flags.
2
Determine the gcloud command line parameters for Cloud Spanner instance creation.
Use 'gcloud spanner instances create' with --config for location placement and --processing-units for capacity allocation.
These flags fulfill the requirements for multi-region placement ('nam-eur-asia1') and capacity allocation ('1000').

Key Concept

Provisioning Cloud Spanner instances via the gcloud CLI using instance configuration and compute capacity flags.
Question 1209Question →

An organization mandates that infrastructure deployments executed by developers from their local workstations to the production project `proj-landing-zone` must use short-lived credentials. Long-lived service account JSON keys are explicitly prohibited by organizational policy. A dedicated service account `[email protected]` has already been assigned all necessary resource management permissions in `proj-landing-zone`. To enable developers to execute `gcloud auth application-default login --impersonate-service-account=sa-terraform-deployer@proj-landing-zone.iam.gserviceaccount.com` without granting them direct permissions to modify resources in the project, which IAM configuration is required?

Show answer & explanation

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

Answer

Grant the developer group the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) directly on the target service account resource.
To impersonate a service account using gcloud CLI or Application Default Credentials (ADC) short-lived token generation, the calling principal must be granted the Service Account Token Creator role (`roles/iam.serviceAccountTokenCreator`). Granting this role directly on the specific service account adheres to the principle of least privilege and avoids using long-lived JSON service account keys.

Step-by-Step Solution

1
Identify the authentication requirement and organizational constraints.
Developers must authenticate using short-lived credentials via service account impersonation without downloading JSON keys.
Security mandates keyless short-lived authentication for local workstation executions.
2
Distinguish between IAM roles related to service accounts.
The Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) provides permissions to mint short-lived tokens (iam.serviceAccounts.getAccessToken, signJwt, etc.), whereas Service Account User (roles/iam.serviceAccountUser) only grants permission to attach service accounts to GCP compute resources.
CLI impersonation via application-default login requires generating OAuth 2.0 access tokens on behalf of the service account.
3
Apply least privilege access binding on the specific resource.
Bind roles/iam.serviceAccountTokenCreator directly on the target service account ([email protected]) to the developer principal group.
Binding at the service account level restricts token creation privileges specifically to that service account rather than across all project service accounts or granting unnecessary project-level access.

Key Concept

Service Account Impersonation and Token Creation Roles
Question 1210Question →

An enterprise data team is configuring IAM permissions for an automated data processing service account. The service account needs to execute BigQuery query jobs and modify table contents only within a single project named `analytics-warehouse-prod`. Security policy mandates strict adherence to the principle of least privilege while preventing permission inheritance across adjacent production projects. Which IAM role assignment strategy should you use?

Show answer & explanation

Answer: Grant the BigQuery Job User (`roles/bigquery.jobUser`) and BigQuery Data Editor (`roles/bigquery.dataEditor`) roles to the service account bound specifically at the `analytics-warehouse-prod` project level.

Answer

Grant the predefined BigQuery Job User and BigQuery Data Editor roles specifically at the target project level.
Combining the predefined roles BigQuery Job User and BigQuery Data Editor at the project scope satisfies all operational requirements (running jobs and modifying tables) while adhering to the principle of least privilege and scoping access strictly to the intended project.

Step-by-Step Solution

1
Identify the minimum necessary permissions required for the task.
Running jobs requires BigQuery Job User permissions, and writing table data requires BigQuery Data Editor permissions.
Selecting granular predefined roles avoids granting unnecessary administrative or broad resource permissions.
2
Determine the narrowest resource scope for the binding.
Bind the roles specifically on the target project (`analytics-warehouse-prod`).
Assigning permissions at the project level prevents unwanted access inheritance to other projects within the parent folder or organization.

Key Concept

Applying Least Privilege using Predefined IAM Roles and Appropriate Resource Hierarchy Scope
Question 1211Question →

An event-driven microservice deployed in Google Cloud needs to publish telemetry messages to a specific Cloud Pub/Sub topic named `device-telemetry-topic` in the project `iot-ingestion-prod`. The microservice should only be granted permissions to publish messages to this specific topic and must not be allowed to create topics, modify subscriptions, or access other resources in the project. Which access control configuration adheres to the principle of least privilege?

Show answer & explanation

Answer: Grant the Pub/Sub Publisher role (`roles/pubsub.publisher`) to the microservice's service account directly on the `device-telemetry-topic` resource.

Answer

Grant the predefined Pub/Sub Publisher role (`roles/pubsub.publisher`) to the microservice's service account directly on the target topic resource (`device-telemetry-topic`).
The correct approach applies the principle of least privilege by combining a specific predefined role (`roles/pubsub.publisher`) with the narrowest resource scope (the `device-telemetry-topic` topic itself). This allows message publishing while preventing access to any other resources or administrative actions.

Step-by-Step Solution

1
Identify the specific capability needed by the workload
The microservice only needs to publish messages to a single Pub/Sub topic.
Determining exact operational requirements is the first step in applying least privilege.
2
Select the appropriate IAM role type
Choose the predefined Pub/Sub Publisher role (`roles/pubsub.publisher`) over broad primitive roles (Owner, Editor, Viewer).
Predefined roles provide narrow permission sets tailored to specific task requirements.
3
Select the narrowest applicable resource scope for the binding
Bind the role at the topic resource level rather than project, folder, or organization level.
Cloud Pub/Sub supports resource-level IAM policies, preventing unnecessary access to other topics or Pub/Sub resources in the project.

Key Concept

Principle of Least Privilege with Predefined Roles and Resource-Level IAM Bindings
Question 1212Question →

A Cloud Engineer is managing a stateless web application running on a Google Kubernetes Engine (GKE) Standard cluster. To maintain performance during peak usage, the application must automatically scale its pod replica count whenever average CPU usage exceeds 75%. Additionally, if pods enter a Pending state due to insufficient compute capacity in the cluster, the underlying GKE node pool must automatically provision additional Compute Engine instances. Which TWO actions should the engineer perform to fulfill these operational requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Execute kubectl autoscale deployment web-app --cpu-percent=75 --min=2 --max=10 to create a Horizontal Pod Autoscaler for the application workload.; Execute gcloud container node-pools update pool-1 --enable-autoscaling --min-nodes=2 --max-nodes=10 --cluster=prod-cluster --zone=us-central1-a to enable Cluster Autoscaler on the GKE node pool.

Answer

The correct operational actions are to configure Horizontal Pod Autoscaler (HPA) using `kubectl autoscale deployment` to scale pod replica counts based on CPU usage, and to enable Cluster Autoscaler on the node pool using `gcloud container node-pools update` to provision extra GKE nodes when pending pods cannot be scheduled.
Managing GKE resources efficiently requires configuring scaling at two distinct layers: pod-level workload scaling and node-level infrastructure scaling. Executing `kubectl autoscale deployment` creates a Horizontal Pod Autoscaler (HPA) resource that adjusts pod counts according to workload CPU utilization. Executing `gcloud container node-pools update --enable-autoscaling` configures the GKE Cluster Autoscaler to provision additional worker nodes whenever pending pods cannot be scheduled onto existing nodes.

Step-by-Step Solution

1
Configure pod-level scaling based on CPU utilization
Deployment replicas scale dynamically between min and max bounds
Horizontal Pod Autoscaler monitors pod CPU metrics and adjusts the desired replica count when the 75% threshold is crossed.
2
Configure node-level scaling for infrastructure capacity
GKE node pool automatically adds Compute Engine instances when unschedulable pods are pending
Cluster Autoscaler monitors for pods that fail to schedule due to resource depletion and automatically scales up the node pool capacity.

Key Concept

Dual-Layer GKE Scaling (Horizontal Pod Autoscaler vs. Cluster Autoscaler)
Question 1213Question →

A Cloud Engineer needs to perform a Point-in-Time Recovery (PITR) for a Cloud SQL instance after a developer accidentally dropped a critical database table. What is the correct operational sequence of steps to safely restore the database state and transition application traffic to the restored instance?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts by identifying the exact pre-corruption timestamp, followed by cloning to a new instance at that timestamp, verifying data integrity on the new instance, and finally updating application connection strings to target the restored instance.
Point-in-Time Recovery (PITR) for Cloud SQL requires first determining the exact point in time prior to data loss. Running the recovery/clone command provisions a new Cloud SQL instance containing data up to that specified moment. Best practice requires verifying data and schema integrity on the newly created instance before updating application connection settings to complete the operational cutover.

Step-by-Step Solution

1
Identify the target recovery timestamp
Retrieved the exact UTC timestamp prior to the table drop.
PITR requires a specific timestamp boundary to roll back transactional logs.
2
Restore data to a new Cloud SQL instance using point-in-time cloning
Created a new running Cloud SQL instance with data restored up to the specified moment.
Cloud SQL PITR creates a distinct new target instance, preventing accidental overwrites of existing instance configurations.
3
Perform database integrity checks
Confirmed that the dropped table exists and contains expected records.
Validation ensures the restored instance is complete and healthy prior to cutover.
4
Update application database endpoints
Application traffic is successfully redirected to the restored instance.
Modifying connection settings points application services to the verified database endpoint.

Key Concept

Cloud SQL Point-in-Time Recovery (PITR) Operational Workflow
Estimated Time:1m 30s
Question 1214Question →

A cloud engineer is managing a Google Cloud Storage bucket that contains confidential audit records. To enforce organization-wide security policies, Uniform Bucket-Level Access was recently enabled on the bucket. However, external auditors report that they can no longer view specific objects that were previously accessible via fine-grained object Access Control Lists (ACLs). You need to restore the auditors' read access while maintaining compliance with the uniform access mandate. What should you do?

Show answer & explanation

Answer: Grant the Storage Object Viewer IAM role to the auditors at the bucket level.

Answer

Grant the Storage Object Viewer IAM role to the auditors at the bucket level.
Enabling Uniform Bucket-Level Access (UBLA) turns off ACLs for all objects in the bucket, making Cloud IAM the sole mechanism for access control. To restore read access for the external auditors while respecting the principle of least privilege and UBLA enforcement, you must grant the predefined Storage Object Viewer IAM role to the auditors at the bucket level.

Step-by-Step Solution

1
Analyze the impact of enabling Uniform Bucket-Level Access (UBLA) on Cloud Storage access control.
UBLA disables object-level Access Control Lists (ACLs) entirely, forcing all access permissions to be governed uniformly by Cloud IAM.
Understanding UBLA behavior helps identify why fine-grained ACLs stopped functioning for external users.
2
Select the appropriate Cloud IAM predefined role for object read-only access.
The Storage Object Viewer (roles/storage.objectViewer) role provides read permission to storage objects without granting administrative or write privileges.
Adhering to the principle of least privilege requires choosing predefined roles tailored to specific tasks.
3
Apply the Cloud IAM role at the correct resource level.
Grant the Storage Object Viewer role to the auditors' identity group or service account at the bucket level.
Bucket-level IAM role bindings apply access permissions consistently across all objects stored inside the bucket.

Key Concept

Uniform Bucket-Level Access disables fine-grained per-object ACLs, requiring Cloud Storage access permissions to be managed exclusively via Cloud IAM roles applied at the bucket or project level.
Question 1215Question →

A cloud administrator is planning to enforce security restrictions across Google Cloud resources by applying Organization Policy constraints at the Organization level. Which of the following statements correctly describe the behavior and evaluation of Organization Policies in the resource hierarchy? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Organization Policy constraints are inherited down the resource hierarchy from the Organization to child Folders and Projects unless an explicit policy evaluation change is configured at a lower level.; Organization Policies establish programmatic guardrails that restrict resource configurations regardless of the IAM roles granted to a user.

Answer

Organization Policies are inherited down the resource hierarchy from the Organization to child Folders and Projects unless overridden, and they establish guardrails that restrict resource configurations regardless of IAM permissions.
The correct statements recognize that Organization Policies inherit downward through the resource hierarchy (from Organization to Folders and Projects) and that they enforce resource configuration limits independently of IAM roles assigned to users.

Step-by-Step Solution

1
Analyze how Organization Policies propagate through the resource hierarchy.
Confirm that policies applied at the Organization root node descend down through Folders to Projects by default.
GCP resource hierarchy rules dictate downward inheritance for Organization Policy constraints.
2
Differentiate between Organization Policies and IAM permissions.
Identify that Organization Policies act as configuration constraints on resources, while IAM controls identity access.
Even identities with broad IAM roles (such as Owner) remain subject to Organization Policy constraints enforced on the target resource.

Key Concept

Organization Policy inheritance and distinction from IAM roles
Estimated Time:1m 0s
Question 1216Question →

A security lead mandates that developers executing maintenance scripts from their local workstations must access BigQuery datasets as the target service account [email protected] without downloading service account keys. Which of the following configurations are required to establish valid service account impersonation for the developer account [email protected]? (Select TWO correct answers.)

Select all that apply

Show answer & explanation

Answer: Grant [email protected] the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) on the target service account resource.; Execute gcloud commands with the --impersonate-service-account=data-exporter@analytics-prod.iam.gserviceaccount.com flag or set the corresponding gcloud configuration property.

Answer

To configure service account impersonation using the gcloud CLI without service account keys, grant the user the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) on the target service account and execute commands using the --impersonate-service-account flag.
Establishing secure keyless service account impersonation requires granting the requesting principal the Service Account Token Creator role on the target service account and configuring local CLI tools using the --impersonate-service-account flag to request short-lived access tokens dynamically.

Step-by-Step Solution

1
Identify the required IAM permissions for token generation
The principal performing impersonation requires the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) on the target service account.
Impersonation relies on generating short-lived OAuth 2.0 access tokens or signed JWTs on behalf of the service account.
2
Configure the client tooling to use short-lived credentials
Pass the --impersonate-service-account flag with gcloud commands or configure auth/impersonate_service_account.
This instructs gcloud to authenticate requests via credentials minted from the target service account rather than the user's primary credentials.

Key Concept

Service Account Impersonation via gcloud CLI
Question 1217Question →

An administrator needs to ensure that access to all objects in a Google Cloud Storage bucket is managed strictly through Cloud IAM permissions, completely disabling individual per-object Access Control Lists (ACLs). Which configuration should the administrator apply to the bucket?

Show answer & explanation

Answer: Enable Uniform Bucket-Level Access on the bucket.

Answer

Enable Uniform Bucket-Level Access on the bucket.
Enabling Uniform Bucket-Level Access disables legacy object-level Access Control Lists (ACLs) for the bucket, ensuring that all access to storage objects is evaluated solely through Cloud IAM policies.

Step-by-Step Solution

1
Identify the goal
Unify permissions under Cloud IAM and disable per-object ACLs for consistent bucket security.
The requirement specifies enforcing bucket-wide IAM controls exclusively.
2
Evaluate Google Cloud Storage access control options
Enabling Uniform Bucket-Level Access (UBLA) turns off ACLs and relies solely on Cloud IAM permissions.
UBLA simplifies access management and ensures uniform security across all bucket objects.

Key Concept

Uniform Bucket-Level Access (UBLA)
Estimated Time:45s
Question 1218Question →

An organization runs an asynchronous media rendering service on a Compute Engine Managed Instance Group (MIG) that scales dynamically using CPU utilization metrics. During peak operational hours, brief, intermittent drops in CPU usage cause the autoscaler to prematurely terminate VM instances that are still processing long-running rendering tasks. You need to prevent premature instance termination during transient CPU fluctuations while maintaining automated horizontal scaling capabilities. Which configuration change should you make following Google-recommended best practices?

Show answer & explanation

Answer: Configure scale-down control settings on the MIG autoscaler by establishing a stabilization period window to delay instance deletion during temporary metric drops.

Answer

Configure scale-down control settings on the MIG autoscaler by establishing a stabilization period window to delay instance deletion during temporary metric drops.
The correct answer provides the standard Compute Engine autoscaling solution for premature scale-down events. By configuring scale-down control settings—specifically setting a stabilization period—the autoscaler calculates capacity based on peak load observed within that window. This prevents transient drops in CPU utilization from triggering premature instance deletions while preserving full autoscaling functionality.

Step-by-Step Solution

1
Analyze the operational problem and autoscaling behavior.
Identified that rapid metric fluctuations cause premature scale-down actions while background processing tasks remain incomplete.
Default autoscaler evaluation windows may react too quickly to temporary drops in CPU utilization.
2
Evaluate Compute Engine MIG autoscaler stabilization mechanisms.
Scale-down control stabilization periods allow administrators to specify a time window (e.g., 600 seconds) during which the autoscaler considers the peak required capacity rather than instantaneous minimums.
This ensures VMs are kept active long enough for temporary workload dips to subside or tasks to complete.
3
Apply Google-recommended best practices for autoscaler configuration.
Configuring `--scale-down-control time-window` on the autoscaler achieves metric smoothing without disabling automated scale-down capabilities entirely.
It maintains cost efficiency while guarding against premature VM termination.

Key Concept

Compute Engine MIG Autoscaler Scale-Down Controls and Stabilization Windows
Question 1219Question →

A cloud administration team needs to securely provision a Compute Engine virtual machine instance that automatically executes a startup script stored in a private Google Cloud Storage bucket. Place the operational steps in the correct order to successfully deploy and verify this virtual machine workload.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts by establishing the dedicated IAM service account, storing the startup script in Cloud Storage, binding the Storage Object Viewer role to the service account, provisioning the VM instance configured with the service account and startup-script-url metadata flag, and finally auditing serial port output for execution status.
Securing VM initialization requires setting up identity and access prerequisites before launching compute resources. Creating the service account, staging the script in Cloud Storage, and granting Storage Object Viewer permissions ensures that when `gcloud compute instances create` is run with `--metadata=startup-script-url`, the VM guest environment can successfully authenticate to GCS and download the script during startup. Serial port output inspection completes the workflow by verifying execution logs.

Step-by-Step Solution

1
Create the custom IAM service account.
Establishes a non-primitive identity for instance authentication following the least privilege principle.
Permissions cannot be bound until the service account identity exists.
2
Upload the initialization script to Cloud Storage.
Places the script executable in a secure GCS bucket.
Provides a centralized GCS URI path required by the Compute Engine metadata server.
3
Assign the Storage Object Viewer (roles/storage.objectViewer) role to the service account for the GCS bucket.
Grants read access to the script storage object.
If permissions are granted after VM instantiation, the startup script downloader daemon will fail with a 403 Access Denied error during boot.
4
Provision the VM using gcloud with the --service-account and --metadata=startup-script-url flags.
Launches the Compute Engine VM instance attached to the custom identity and boot metadata configuration.
Tells Compute Engine startup scripts agent to retrieve and run the script from GCS using the attached service account scope.
5
Review startup execution via gcloud compute instances get-serial-port-output.
Validates that the startup script completed successfully.
Serial console output captures stdout/stderr of Linux daemon boot scripts for troubleshooting.

Key Concept

Provisioning Compute Engine VMs with custom service accounts and GCS-hosted startup scripts
Question 1220Question →

An organization maintains two Virtual Private Cloud (VPC) networks in Google Cloud: a central network named `hub-vpc` and a workload network named `spoke-vpc`. The two networks are connected using VPC Network Peering via a peering connection named `peering-hub-to-spoke` created on `hub-vpc`. The workload team recently added custom static routes in `spoke-vpc` and enabled custom route exporting on their peering end. However, virtual machines in `hub-vpc` cannot route traffic to those custom destinations because `hub-vpc` is not receiving the advertised routes. Which `gcloud` command should the cloud engineer execute to configure `hub-vpc` to receive the exported custom routes from `spoke-vpc`?

Show answer & explanation

Answer: gcloud compute networks peerings update peering-hub-to-spoke --network=hub-vpc --import-custom-routes

Answer

The correct action is to execute `gcloud compute networks peerings update peering-hub-to-spoke --network=hub-vpc --import-custom-routes`.
In Google Cloud VPC Network Peering, custom route exchange is bi-directional but independently controlled. For `hub-vpc` to receive custom routes from `spoke-vpc`, the peering connection on `spoke-vpc` must have custom route exporting enabled, and the peering connection on `hub-vpc` (`peering-hub-to-spoke`) must have custom route importing enabled via `gcloud compute networks peerings update peering-hub-to-spoke --network=hub-vpc --import-custom-routes`.

Step-by-Step Solution

1
Identify the VPC Network Peering route exchange requirement
Recognize that for custom static or dynamic routes to cross a VPC peering boundary, the sending VPC peering end must export custom routes and the receiving VPC peering end must import custom routes.
VPC Network Peering does not automatically import custom routes by default even if the peer VPC is exporting them.
2
Determine the required command context and target flags
Identify that the configuration must be applied to the peering connection named `peering-hub-to-spoke` located on `--network=hub-vpc` using the `--import-custom-routes` flag.
The receiving network (`hub-vpc`) must explicitly set its peering configuration to import incoming custom routes.
3
Validate `gcloud` CLI syntax for network peerings
Select `gcloud compute networks peerings update peering-hub-to-spoke --network=hub-vpc --import-custom-routes`.
This is the precise GCP CLI command structure required to update peering configuration properties.

Key Concept

VPC Network Peering Custom Route Exchange
PreviousPage 61 / 80Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin