All practice questions

1591 questions

Question 1321Question

A cloud security administrator needs to grant an automated compliance service permission to read metadata and configuration settings for both Cloud SQL instances and Cloud Pub/Sub topics within a target Google Cloud project named `prod-data-pipeline`. The solution must enforce the Principle of Least Privilege and restrict access strictly to the target project. Which two IAM role bindings should you grant to the service account? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Grant the Cloud SQL Viewer (roles/cloudsql.viewer) role to the service account on the prod-data-pipeline project.; Grant the Pub/Sub Viewer (roles/pubsub.viewer) role to the service account on the prod-data-pipeline project.

Answer

The correct role bindings are granting Cloud SQL Viewer (roles/cloudsql.viewer) and Pub/Sub Viewer (roles/pubsub.viewer) to the service account scoped specifically to the target project.
To satisfy least privilege for a read-only metadata compliance audit on specific services within a single project, you must assign resource-specific predefined viewer roles—specifically Cloud SQL Viewer (roles/cloudsql.viewer) and Pub/Sub Viewer (roles/pubsub.viewer)—bound directly to the target project. These roles provide exact read visibility into the target services without permitting data modification or inheriting permissions across other projects.

Step-by-Step Solution

1
Identify the required permissions for Cloud SQL and Cloud Pub/Sub
The application requires read-only configuration access for Cloud SQL and Cloud Pub/Sub resources.
Least privilege mandates selecting predefined roles that match exact operational capabilities rather than administrative or broad primitive permissions.
2
Select the appropriate predefined roles matching the required permissions
Select roles/cloudsql.viewer for Cloud SQL access and roles/pubsub.viewer for Cloud Pub/Sub topic/subscription metadata inspection.
These predefined roles isolate read capabilities to their respective services without granting write or administrative privileges.
3
Determine the correct resource hierarchy binding scope
Apply both role bindings directly on the target project (prod-data-pipeline).
Granting roles at higher resource levels (such as parent Folders or the Organization) causes permissions to be inherited across all sibling projects, violating scope restrictions.

Key Concept

Principle of Least Privilege with Predefined Roles and Resource Hierarchy Scope
Question 1322Question

A cloud engineer is operating a VPC network named `prod-vpc` where a high-priority ingress firewall rule named `block-external-ingress` with priority `1000` denies all incoming traffic from external networks. The engineer needs to configure firewall access to allow Google Cloud load balancer health check probes (`35.191.0.0/16` and `130.211.0.0/22`) to reach backend instances tagged as `web-backend` over TCP port 80. Which `gcloud` command should the engineer run to ensure the health check probes are successfully evaluated and permitted?

Show answer & explanation

Answer: gcloud compute firewall-rules create allow-health-checks --network=prod-vpc --action=ALLOW --direction=INGRESS --source-ranges=35.191.0.0/16,130.211.0.0/22 --target-tags=web-backend --rules=tcp:80 --priority=500

Answer

Execute the `gcloud compute firewall-rules create` command specifying `--action=ALLOW`, `--direction=INGRESS`, `--source-ranges=35.191.0.0/16,130.211.0.0/22`, `--rules=tcp:80`, and a priority number lower than 1000 (such as 500).
The correct command uses `--priority=500` which evaluates before the existing `--priority=1000` deny rule because lower numbers take precedence in GCP firewall rule ordering. Additionally, it accurately uses `--source-ranges` to specify probe IP origins and `--rules=tcp:80` for the health check protocol.

Step-by-Step Solution

1
Analyze GCP firewall priority ordering rules.
GCP evaluates firewall rules starting from the lowest numerical priority (0) to the highest (65535). The first matching rule applies.
Because an existing rule denies traffic at priority 1000, any new rule intended to permit health checks must have a priority number strictly less than 1000.
2
Identify mandatory parameter flags for ingress health check probes.
Ingress traffic filters require `--direction=INGRESS` and `--source-ranges` containing the Google Cloud health check IP blocks `35.191.0.0/16` and `130.211.0.0/22`.
Health check probes originate from these known IP blocks and target backend instances via TCP.
3
Construct the exact `gcloud compute firewall-rules create` syntax.
Setting `--priority=500`, `--rules=tcp:80`, `--target-tags=web-backend`, and `--source-ranges=35.191.0.0/16,130.211.0.0/22` permits the probes before reaching the priority 1000 deny rule.
This guarantees health check packets pass successfully to the instance instances.

Key Concept

VPC Firewall Rule Priority and Health Check Ingress Configuration
Estimated Time:1m 30s
Question 1323Question

A Cloud Engineer needs to update the resource configuration of an existing Cloud Run service named `order-service` in the `us-central1` region. The service must be configured to handle up to 50 concurrent requests per container instance while maintaining at least 3 warm instances at all times to minimize latency caused by cold starts. Which `gcloud` command should the engineer run to meet these operational requirements?

Show answer & explanation

Answer: gcloud run services update order-service --concurrency=50 --min-instances=3 --region=us-central1

Answer

Execute `gcloud run services update order-service --concurrency=50 --min-instances=3 --region=us-central1` to set concurrency and minimum instances on the Cloud Run service.
The `gcloud run services update` command modifies existing configuration parameters of a Cloud Run service. Specifying `--concurrency=50` ensures that a single container instance processes at most 50 concurrent requests before scaling out, and `--min-instances=3` guarantees three container instances remain initialized to eliminate cold start latency.

Step-by-Step Solution

1
Identify the target resource and operation
The target is an existing Cloud Run service named `order-service` in region `us-central1` needing parameter adjustments.
Modifying operational settings like concurrency and minimum instances requires updating the Cloud Run service via `gcloud run services update`.
2
Specify the required flags for concurrency and warm instances
Use `--concurrency=50` to limit requests per instance and `--min-instances=3` to keep baseline instances running.
Cloud Run provisions baseline instances using `--min-instances` to reduce cold starts and manages maximum concurrent connections per container using `--concurrency`.

Key Concept

Cloud Run Instance Lifecycle and Concurrency Management
Estimated Time:1m 30s
Question 1324Question

A security team enables Uniform Bucket-Level Access (UBLA) on a Google Cloud Storage bucket storing sensitive financial reports. Consequently, legacy automated pipelines attempting to apply per-object Access Control Lists (ACLs) fail. You must grant a financial auditor read access to objects in this bucket while maintaining organizational compliance and least privilege principles. Which TWO actions should you take?

Select all that apply

Show answer & explanation

Answer: Grant the auditor the predefined Storage Object Viewer role (roles/storage.objectViewer) on the Cloud Storage bucket via Cloud IAM.; Refactor data ingestion workflows to rely exclusively on Cloud IAM policies rather than setting per-object ACL flags.

Answer

The correct actions are granting the predefined Storage Object Viewer role (roles/storage.objectViewer) at the bucket level using IAM, and refactoring ingestion workflows to manage access via IAM policies rather than per-object ACLs.
Enabling Uniform Bucket-Level Access (UBLA) centralizes permissions management strictly through Google Cloud IAM, ignoring individual object ACLs. Assigning the predefined Storage Object Viewer role (roles/storage.objectViewer) to the auditor satisfies read requirements under the principle of least privilege. Additionally, updating ingestion pipelines to use IAM policies prevents automated pipeline failure caused by forbidden ACL assignments under UBLA.

Step-by-Step Solution

1
Analyze access control enforcement under Uniform Bucket-Level Access (UBLA).
Identify that UBLA disables legacy ACLs on all objects and enforces Cloud IAM exclusively.
Individual ACL modifications produce permission errors when UBLA is enabled.
2
Apply least-privilege predefined Cloud IAM roles.
Assign Storage Object Viewer (roles/storage.objectViewer) to the financial auditor at the bucket resource level.
This provides read access to bucket objects without over-granting project-wide permissions.
3
Remediate ingestion pipeline logic.
Remove per-object ACL flags (such as canned ACLs) from object uploads and administrative scripts.
All access policies must be declared through bucket and project IAM policy bindings.

Key Concept

Uniform Bucket-Level Access (UBLA) disables per-object ACLs in Google Cloud Storage and enforces Cloud IAM predefined roles for bucket security management.
Question 1325Question

An infrastructure team wants to block all incoming SSH traffic (TCP port 22) to Compute Engine instances across a Virtual Private Cloud (VPC) network, while allowing SSH access strictly to instances assigned the network tag `bastion-host`. The team configures a VPC firewall rule with a priority of 1000 that denies ingress TCP port 22 for all instances in the network. Which configuration for a second firewall rule will successfully permit SSH traffic to only the tagged instances?

Show answer & explanation

Answer: Create an ALLOW ingress rule for TCP port 22 targeting the network tag `bastion-host` with a priority of 500.

Answer

Create an ALLOW ingress rule for TCP port 22 targeting the network tag 'bastion-host' with a priority of 500.
In Google Cloud VPC firewall evaluation, rules are processed according to numerical priority, where lower integer values take precedence. An ALLOW ingress rule set to priority 500 targeting instances with the 'bastion-host' tag will be evaluated before the broad DENY ingress rule set at priority 1000, allowing SSH access to the intended targets while blocking all others.

Step-by-Step Solution

1
Analyze Google Cloud VPC firewall rule priority evaluation order.
GCP evaluates rules in order of priority from 0 to 65535, where lower numerical values indicate higher precedence.
To override a broad DENY rule configured at priority 1000, a specific ALLOW rule must have a priority value strictly less than 1000 (such as 500).
2
Determine the direction and target parameters required for the rule.
The rule must be an INGRESS rule specifying TCP port 22 and target the network tag 'bastion-host'.
SSH access from external clients represents incoming network traffic directed at specific Compute Engine instances.

Key Concept

VPC Firewall Rule Priority and Target Tag Evaluation
Estimated Time:1m 30s
Question 1326Question

An organization is setting up a hybrid architecture where an on-premises application running inside a Linux server needs to upload hourly diagnostic reports directly to a Google Cloud Storage bucket in project `analytics-prod-994`. Security policy strictly forbids storing long-lived, downloadable service account key files (.json or .p12) on local disks outside of Google Cloud. Which of the following setup actions are required to establish secure, keyless access for this external workload using GCP recommended service account practices? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure Workload Identity Federation by creating a Workload Identity Pool and Provider in Google Cloud IAM that trusts the on-premises identity provider.; Grant the `roles/iam.workloadIdentityUser` role on the target service account to the external identity principal set defined in the Workload Identity Pool.

Answer

The required actions are establishing Workload Identity Federation by creating a Workload Identity Pool and Provider in GCP IAM, and granting the Workload Identity User role (`roles/iam.workloadIdentityUser`) on the service account to the federated external identity principal set.
To grant external workloads secure access to Google Cloud resources without exporting static service account keys, Google Cloud recommends Workload Identity Federation. This requires configuring a Workload Identity Pool and Provider to establish identity trust, and then granting `roles/iam.workloadIdentityUser` on the target service account to the external principal set so short-lived IAM credentials can be exchanged securely.

Step-by-Step Solution

1
Set up external identity trust in Google Cloud IAM
Created Workload Identity Pool and Provider mapped to the on-premises identity provider.
Allows Google Cloud to authenticate incoming tokens issued by the external on-premises environment.
2
Bind the federated identity to the target GCP Service Account
Granted `roles/iam.workloadIdentityUser` to `principalSet://iam.googleapis.com/projects/.../attribute.my_attr/...` on the service account.
Authorizes the authenticated external workload identity to impersonate the GCP service account and obtain short-lived access tokens without static key files.

Key Concept

Keyless authentication for external workloads via Workload Identity Federation and Service Account Impersonation
Question 1327Question

An organization operates three separate Google Cloud projects (`proj-services-prod`, `proj-data-prod`, and `proj-auth-prod`) hosting microservice workloads. The Operations team needs a single, centralized Cloud Monitoring dashboard and alerting view to monitor compute infrastructure metrics across all three projects simultaneously without moving the workloads. They create a central administrative project named `proj-monitoring-central`. Which step should the Cloud Engineer perform to achieve this unified observability setup?

Show answer & explanation

Answer: Add `proj-services-prod`, `proj-data-prod`, and `proj-auth-prod` as monitored projects within the Metrics Scope of `proj-monitoring-central`.

Answer

Add `proj-services-prod`, `proj-data-prod`, and `proj-auth-prod` as monitored projects within the Metrics Scope of `proj-monitoring-central`.
Google Cloud Monitoring uses Metrics Scopes to consolidate observability across multiple projects. By designating `proj-monitoring-central` as the scoping project and adding `proj-services-prod`, `proj-data-prod`, and `proj-auth-prod` as monitored projects within its Metrics Scope, operations teams can view unified dashboards, query combined metrics, and set up centralized alerts across the entire fleet without modifying individual workloads.

Step-by-Step Solution

1
Identify the multi-project monitoring requirement.
Recognize that observing metrics from multiple GCP projects in a single interface requires a Cloud Monitoring Metrics Scope.
Cloud Monitoring uses a Scoping Project to host dashboards, alerting policies, and uptime checks for multiple Monitored Projects.
2
Configure the scoping relationship.
Link `proj-services-prod`, `proj-data-prod`, and `proj-auth-prod` as monitored projects inside `proj-monitoring-central`.
This allows `proj-monitoring-central` to query and display metrics originating from all linked workload projects.

Key Concept

Cloud Monitoring Metrics Scope (Multi-Project Monitoring)
Estimated Time:2m 0s
Question 1328Question

A healthcare organization is configuring a Google Cloud Storage bucket named `med-research-imaging-archive` to share anonymized medical data with external research partners. Regulatory compliance requires that all storage security policies be unified and administered strictly through IAM, prohibiting any per-object Access Control Lists (ACLs). Additionally, external partners must be granted read access to the stored objects while strictly following the principle of least privilege.

Which TWO configuration steps should the cloud administrator take? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Enable Uniform Bucket-Level Access on the `med-research-imaging-archive` bucket to disable legacy ACLs and enforce IAM policies across all objects.; Grant the predefined Storage Object Viewer role (`roles/storage.objectViewer`) to the external research partner principal resource directly on the bucket.

Answer

The administrator must enable Uniform Bucket-Level Access on the bucket and grant the predefined Storage Object Viewer role directly on the bucket to the research partner principal.
Enabling Uniform Bucket-Level Access standardizes access control by disabling per-object ACLs and enforcing bucket-level IAM policies across all objects. Granting the predefined Storage Object Viewer role directly on the target bucket ensures external partners can view object content while adhering strictly to the principle of least privilege.

Step-by-Step Solution

1
Enforce unified bucket security governance
Uniform Bucket-Level Access (UBLA) is activated on `gs://med-research-imaging-archive`, disabling object-level ACLs.
UBLA satisfies compliance by forcing all access decisions to evaluate IAM policies instead of object ACLs.
2
Identify the principle of least privilege IAM role for object access
The predefined role `roles/storage.objectViewer` is selected rather than broad primitive roles.
Predefined roles limit permissions strictly to viewing storage objects without exposing administrative operations or unrelated project services.
3
Bind the IAM role at the appropriate resource hierarchy level
The role binding is applied directly to the bucket resource `gs://med-research-imaging-archive`.
Applying the role at the bucket level prevents granting access to other Cloud Storage buckets or resources within the project.

Key Concept

Uniform Bucket-Level Access & IAM Least Privilege
Question 1329Question

A Cloud Operations engineer needs to provision a Compute Engine virtual machine instance named `data-processor-vm` in zone `us-central1-a`. The virtual machine requires an automated initial startup script stored in a Cloud Storage bucket at `gs://company-bootstrap-scripts/init-processor.sh` to execute upon system boot. Which `gcloud compute` command correctly configures the instance to use this remote script?

Show answer & explanation

Answer: gcloud compute instances create data-processor-vm --zone=us-central1-a --metadata=startup-script-url=gs://company-bootstrap-scripts/init-processor.sh

Answer

The command using `--metadata=startup-script-url=gs://company-bootstrap-scripts/init-processor.sh` is the correct approach.
The correct command uses `--metadata=startup-script-url=gs://company-bootstrap-scripts/init-processor.sh`. Compute Engine retrieves and runs startup scripts hosted in Cloud Storage when the `startup-script-url` key is passed within the standard `--metadata` flag.

Step-by-Step Solution

1
Identify the mechanism Compute Engine uses for startup scripts hosted in Google Cloud Storage.
Compute Engine looks for the custom metadata key `startup-script-url`.
When a startup script resides in Cloud Storage, Compute Engine downloads the script using the `startup-script-url` metadata entry.
2
Select the correct `gcloud` flag syntax for inline metadata key-value assignment.
The flag syntax `--metadata=KEY=VALUE` is used.
`--metadata` accepts key-value pairs separated by commas, allowing `startup-script-url` to be pointed directly to the `gs://` URI.

Key Concept

Configuring Compute Engine Startup Scripts via Cloud Storage Metadata
Question 1330Question

You are auditing the security configuration of a Google Cloud resource hierarchy. The root Organization node enforces an Organization Policy list constraint (`constraints/compute.trustedImageProjects`) that restricts Compute Engine instance creation to images from `projects/shared-base-images`. A newly created folder named `DataEngineering` requires access to images from `projects/analytics-images` in addition to the globally allowed images. How should you configure the Organization Policy at the `DataEngineering` folder level to satisfy this requirement for all underlying projects?

Show answer & explanation

Answer: Configure the policy constraint on the DataEngineering folder, set inheritFromParent to true, and add projects/analytics-images to the allowed values list.

Answer

Configure the policy constraint on the DataEngineering folder, set inheritFromParent to true, and add projects/analytics-images to the allowed values list.
For list constraints in Google Cloud Organization Policies, setting `inheritFromParent` to `true` at a child resource level (such as a folder) merges the child's allowed values with the inherited values from higher levels in the resource hierarchy. Adding `projects/analytics-images` alongside `inheritFromParent = true` allows images from both `projects/shared-base-images` (inherited) and `projects/analytics-images` (locally specified).

Step-by-Step Solution

1
Analyze the goal and current hierarchy configuration
The root node permits `projects/shared-base-images`. The `DataEngineering` folder needs to allow both `projects/shared-base-images` and `projects/analytics-images`.
Organization Policy list constraints dictate allowed or denied resource attributes down the hierarchy.
2
Evaluate Organization Policy inheritance rules for list constraints
When `inheritFromParent` is set to `true` on a child node, any additional allowed values specified at the child node are merged with the allowed values inherited from parent nodes.
Setting `inheritFromParent = true` ensures that higher-level organizational baseline constraints remain active while expanding permitted values locally.
3
Select the correct configuration mechanism
Applying the constraint at the `DataEngineering` folder with inheritance enabled and appending `projects/analytics-images` satisfies both global and folder-specific image policies.
This maintains the principle of minimal policy maintenance and compliance enforcement across all nested child projects.

Key Concept

Organization Policy List Constraint Inheritance and Merging
Question 1331Question

A cloud developer is deploying a containerized REST API microservice named orders-api to Google Cloud Run using the gcloud command-line tool. The microservice needs to accept public HTTP traffic from external clients and dynamically receive requests on the port assigned by the platform container contract. Which two configuration actions are required to ensure the microservice successfully receives and handles incoming requests on Cloud Run? Select 2 options.

Select all that apply

Show answer & explanation

Answer: Configure the application container code to listen on the HTTP port defined by the PORT environment variable injected by Cloud Run.; Include the --allow-unauthenticated flag when executing the gcloud run deploy command.

Answer

The microservice requires configuring the container application to listen on the port specified by the injected PORT environment variable and deploying the service with the --allow-unauthenticated flag to accept public HTTP traffic.
Cloud Run requires containers to comply with its runtime contract by listening on the port provided in the PORT environment variable. Additionally, to expose a service to public unauthenticated callers, the deployment command must pass the --allow-unauthenticated flag.

Step-by-Step Solution

1
Verify container runtime contract adherence
The application code must listen on the port assigned via the PORT environment variable.
Cloud Run sends requests to the container on the PORT environment variable value, which defaults to 8080.
2
Set invocation permissions during deployment
Use gcloud run deploy orders-api with the --allow-unauthenticated flag.
Public HTTP access requires explicitly permitting unauthenticated invocations on the service endpoint.

Key Concept

Cloud Run Container Contract and Ingress Authentication
Question 1332Question

A Cloud Engineer is managing a network setup where two Virtual Private Cloud networks, `vpc-analytics` and `vpc-core`, are connected using VPC Network Peering. Custom static routes created in `vpc-analytics` are currently not propagating to virtual machines in `vpc-core`. Which two actions must be taken using `gcloud compute networks peerings` to allow custom static routes to be properly exchanged between these two peered networks? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Update the peering connection configuration in `vpc-analytics` to enable the `--export-custom-routes` flag.; Update the peering connection configuration in `vpc-core` to enable the `--import-custom-routes` flag.

Answer

To successfully exchange custom static routes between peered VPC networks, the sending network must update its peering configuration to export custom routes (`--export-custom-routes`), and the receiving network must update its peering configuration to import custom routes (`--import-custom-routes`).
In Google Cloud VPC Network Peering, custom static routes are not shared automatically. Exchanging custom routes requires a two-sided configuration: the peer network originating the routes (`vpc-analytics`) must set `--export-custom-routes`, and the receiving network (`vpc-core`) must set `--import-custom-routes`.

Step-by-Step Solution

1
Identify the routing requirement across VPC Peering
By default, VPC Network Peering exchanges subnet routes, but custom static routes and dynamic routes are not exported or imported unless explicitly configured.
VPC peering routes require bi-directional consent for custom route exchange.
2
Configure route exporting on the source network
Execute `gcloud compute networks peerings update` on `vpc-analytics` specifying `--export-custom-routes`.
The source network must grant permission to send its custom static routes over the peering connection.
3
Configure route importing on the target network
Execute `gcloud compute networks peerings update` on `vpc-core` specifying `--import-custom-routes`.
The destination network must grant permission to receive and insert peer custom static routes into its routing table.

Key Concept

VPC Network Peering Custom Route Exchange
Question 1333Question

A cloud engineer is setting up a new custom-mode VPC subnet in the `us-central1` region named `backend-subnet` for internal application instances. The workload has two strict operational requirements:
1. Virtual machines in `backend-subnet` must be able to securely reach Google Cloud APIs and services without having external IPv4 addresses assigned.
2. Ingress traffic on TCP port 8080 must be restricted specifically to instances running under the service account `[email protected]`.

Which TWO configuration steps must the engineer perform when deploying the subnet and firewall rules to fulfill these requirements?

Select all that apply

Show answer & explanation

Answer: Enable Private Google Access on the `backend-subnet` configuration.; Create an ingress firewall rule on the VPC network specifying `--target-service-accounts=app-backend@project-id.iam.gserviceaccount.com` and allowing TCP port 8080.

Answer

The cloud engineer must enable Private Google Access on the backend subnet and create an ingress firewall rule specifying the target service account with TCP port 8080 allowed.
Enabling Private Google Access allows instances without external IP addresses to reach Google API endpoints internally. Additionally, using target service accounts in an ingress firewall rule enforces network access controls based on instance service account identity rather than IP addresses or broad network tags.

Step-by-Step Solution

1
Enable Private Google Access on the subnet
VMs with only internal IP addresses can reach Google API endpoints.
Private Google Access provides secure internal routing to Google Cloud service endpoints without assigning external IPv4 addresses.
2
Configure an ingress firewall rule filtered by target service account
Ingress traffic on TCP port 8080 is restricted strictly to VMs associated with the specified service account.
VPC firewall rules allow filtering target instances by service account email addresses for precise identity-based network access control.

Key Concept

Private Google Access configuration and target service account firewall rule filtering in GCP VPC networks.
Question 1334Question

A Cloud Engineer is tasked with performing a canary release for an updated container image on an existing Cloud Run service named `orders-api`. The objective is to deploy the updated revision without exposing it to live production traffic immediately, perform validation on the revision's dedicated URL, gradually shift 10% of production traffic to the new revision, and monitor its operational metrics. Sequence the following deployment and traffic management steps in the correct order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps for a Cloud Run canary deployment is: 1) Deploy the new container image using `gcloud run deploy` with the `--no-traffic` flag, 2) Test the new revision using its direct revision-specific URL, 3) Update the traffic distribution using `gcloud run services update-traffic` to route 10% of traffic to the new revision, and 4) Monitor service logs and metrics in Cloud Operations to verify operational health.
The deployment workflow requires creating the revision safely without live traffic (`--no-traffic`), verifying its health via direct revision URL targeting, applying a 10% canary traffic split with `gcloud run services update-traffic`, and finally inspecting metrics in Cloud Operations to ensure baseline operational stability.

Step-by-Step Solution

1
Deploy the updated container image to Cloud Run ensuring live traffic is not impacted.
A new Cloud Run revision is instantiated, but 100% of production traffic continues to serve from the existing revision due to `--no-traffic`.
Deploying with `--no-traffic` prevents unverified code from immediately receiving live production requests.
2
Perform direct revision testing.
The engineer confirms that the revision responds correctly without risking impact on end users.
Cloud Run automatically assigns a unique URL (or tag-based URL) to each revision for targeted testing.
3
Configure traffic splitting via CLI.
10% of inbound service requests are routed to the new revision and 90% to the previous revision.
The command `gcloud run services update-traffic` adjusts traffic percentages across active revisions.
4
Observe performance and error metrics.
Metrics confirm whether the canary revision operates stably under real traffic conditions.
Monitoring latency and HTTP error rates provides empirical proof of success before rolling out 100% of traffic.

Key Concept

Canary Deployments and Traffic Splitting in Cloud Run
Question 1335Question

A cloud engineering team needs to standardize a base environment for auto-scaling a web application currently running on a standalone Compute Engine instance. The team plans to capture the configuration of the existing instance's boot disk, package it into a custom image, and use that image to generate an instance template for a new Managed Instance Group (MIG). In what sequential order should the engineer perform these gcloud CLI operations to ensure data consistency and proper resource dependency?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct execution sequence is: 1) Stop the source Compute Engine instance to flush disk caches and guarantee data consistency. 2) Create a persistent disk snapshot from the stopped VM's boot disk. 3) Create a custom image with the snapshot specified as its source. 4) Create an instance template referencing the newly created custom image.
The correct order follows dependency and data-integrity requirements: stopping the VM ensures disk consistency, creating a disk snapshot captures that state, building a custom image from the snapshot provides a reusable boot resource, and defining the instance template uses the finished custom image.

Step-by-Step Solution

1
Halt file system writes on the source virtual machine.
The VM enters the TERMINATED state, ensuring disk integrity.
Creating snapshots from a running instance without stopping it or unmounting the file system can lead to crash-inconsistent snapshots.
2
Execute `gcloud compute disks snapshot` against the instance boot disk.
A consistent persistent disk snapshot resource is created.
Snapshots store point-in-time data required to build portable, versioned images.
3
Execute `gcloud compute images create` pointing to the snapshot as the source.
A custom image resource is added to the project's image family/catalog.
Instance templates require a boot image reference, which is constructed from the snapshot asset.
4
Execute `gcloud compute instance-templates create` with the `--image` flag set to the custom image.
An instance template is established for deployment into Managed Instance Groups.
Instance templates are immutable specifications that require all underlying image dependencies to already exist.

Key Concept

Compute Engine Image and Template Lifecycle Management
Question 1336Question

An organization is onboarding a database administrator who is responsible for creating, modifying, and managing Cloud Spanner instances and databases within a specific development Google Cloud project. The administrator must not be granted permissions to manage IAM access policies or administer other unrelated cloud services in the project. Following the principle of least privilege, which IAM role should you grant to the administrator at the project level?

Show answer & explanation

Answer: Cloud Spanner Admin (roles/spanner.admin)

Answer

Grant the Cloud Spanner Admin (roles/spanner.admin) predefined role at the project level.
The Cloud Spanner Admin (roles/spanner.admin) predefined role provides complete access to manage Cloud Spanner instances and databases while strictly adhering to the principle of least privilege. Bound at the project level, it grants only the necessary privileges required for Cloud Spanner operations without opening permissions to other GCP services or allowing IAM policy modifications.

Step-by-Step Solution

1
Identify the required permissions for managing Cloud Spanner instances and databases.
Full administrative control over Cloud Spanner instances, databases, and backups is required.
The database administrator needs administrative access specifically to Cloud Spanner resources.
2
Apply the Principle of Least Privilege by selecting a specific predefined role instead of a primitive role.
Select roles/spanner.admin over primitive roles like Editor or Owner.
Predefined roles limit capabilities strictly to the relevant service features without exposing unrelated Google Cloud resources or IAM policy controls.
3
Determine the minimal resource hierarchy scope required.
Bind the role directly to the user at the specific project level.
Assigning the role at a higher folder or organization level would grant unnecessary administrative access across all projects within that folder due to IAM policy inheritance.

Key Concept

Principle of Least Privilege and Role Scoping in GCP IAM
Question 1337Question

A cloud security administrator must set up audit logging to track and analyze user access to Cloud SQL databases across all projects within an organization. The solution requires enabling Cloud SQL Data Access audit logging, aggregating and routing these logs to a central BigQuery dataset in a security project, and granting a security analyst least-privilege permissions to inspect these logs in both Logs Explorer and BigQuery. What is the correct sequence of steps to configure log generation, export routing, writer authorization, and analyst access?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by enabling Data Access audit logging for Cloud SQL, creating an aggregated organization log sink targeting BigQuery, granting the sink service account write access to the dataset, assigning the Private Logs Viewer role to the analyst for Cloud Logging, and finally granting BigQuery Data Viewer permissions for SQL analysis.
The workflow follows logical and administrative dependencies: log generation must first be enabled for the service; log collection and destination routing must then be established at the organization level; the sink's unique service account must be authorized to write to the destination dataset; and finally, least-privilege IAM permissions must be granted to the analyst for inspecting logs in both Logs Explorer (Private Logs Viewer) and BigQuery (BigQuery Data Viewer).

Step-by-Step Solution

1
Enable Audit Log Generation
Cloud SQL Admin API generates DATA_READ and DATA_WRITE audit events.
Data Access audit logs are disabled by default for most GCP services (except BigQuery). Enabling them in the IAM Audit Logs interface is mandatory to begin producing log entries.
2
Configure Aggregated Log Sink
Organization-wide audit entries are directed to the central BigQuery dataset.
An aggregated sink at the organization node ensures that logs across all child folders and projects are collected into one sink destination.
3
Authorize Writer Identity
The log sink service account receives write authorization on BigQuery.
GCP log sinks use dedicated writer service accounts. Without assigning roles/bigquery.dataEditor on the target dataset, exported logs will be dropped.
4
Grant Cloud Logging IAM Permissions
The security analyst gains permission to inspect private audit logs in Cloud Logging.
Standard roles/logging.viewer permissions do not grant access to Data Access logs. The roles/logging.privateLogViewer role is required.
5
Grant BigQuery Query Permissions
The security analyst can execute SQL queries against the audit log tables in BigQuery.
Permissions in Cloud Logging do not transfer to BigQuery; explicit roles/bigquery.dataViewer access on the sink dataset is required.

Key Concept

Configuring Cloud Audit Log Enablement, Sink Routing, Writer Service Account Authorization, and Private Log Access Control
Question 1338Question

An infrastructure team is standardizing security controls on Google Cloud Storage buckets containing telemetry data. To comply with corporate audit standards, the team enables Uniform Bucket-Level Access (UBLA) on a bucket named telemetry-analytics-prod. Shortly after, an automated data ingestion process fails when executing a script that uploads log files with specific Access Control Lists (ACLs) using the Cloud Storage API. You need to resolve the error while maintaining UBLA compliance on the bucket. What should you do?

Show answer & explanation

Answer: Remove the object ACL parameters from the ingestion script and grant the ingestion service account the Storage Object Creator predefined IAM role on the bucket.

Answer

Remove the object ACL parameters from the ingestion script and grant the ingestion service account the Storage Object Creator predefined IAM role on the bucket.
When Uniform Bucket-Level Access is enabled on a Cloud Storage bucket, ACLs are completely disabled and access is strictly managed via Cloud IAM. The proper resolution is to update the application script to remove ACL parameters and assign the appropriate predefined Cloud IAM role (such as Storage Object Creator) to the principal.

Step-by-Step Solution

1
Identify the cause of the ingestion failure
Uniform Bucket-Level Access (UBLA) disables Access Control Lists (ACLs) for all objects in the bucket, causing API requests that include ACL settings to fail.
UBLA unifies access management under Cloud IAM, ignoring individual object ACL operations.
2
Modify the ingestion script
The script uploads objects without specifying per-object ACL flags or permissions.
Object uploads under UBLA must rely solely on IAM permissions rather than ACL metadata.
3
Configure Cloud IAM access
Grant the Storage Object Creator (roles/storage.objectCreator) role to the ingestion service account on the bucket.
This adheres to the principle of least privilege while providing necessary permissions to upload objects.

Key Concept

Uniform Bucket-Level Access (UBLA) disables legacy ACLs, requiring all access controls to be configured using Cloud IAM roles.
Question 1339Question

An automated log-processing service account running in a GCP environment requires read-only access to source logs stored in a Cloud Storage bucket in Project Alpha (`src-logs-bucket`) and must write processed log output to a destination Cloud Storage bucket in Project Beta (`dst-logs-bucket`). Which of the following IAM role assignments adhere to the principle of least privilege while providing the necessary permissions? (Select TWO answers.)

Select all that apply

Show answer & explanation

Answer: Grant Storage Object Viewer (roles/storage.objectViewer) on the source Cloud Storage bucket in Project Alpha.; Grant Storage Object Creator (roles/storage.objectCreator) on the destination Cloud Storage bucket in Project Beta.

Answer

The correct role assignments are granting Storage Object Viewer (roles/storage.objectViewer) on the source Cloud Storage bucket in Project Alpha, and granting Storage Object Creator (roles/storage.objectCreator) on the destination Cloud Storage bucket in Project Beta.
To adhere to the principle of least privilege, access must be scoped to the specific target resources and restricted to the minimum required permissions. Granting Storage Object Viewer on the source bucket in Project Alpha permits reading log files without access to other project resources. Granting Storage Object Creator on the destination bucket in Project Beta allows writing output logs without permitting reading or modifying existing objects.

Step-by-Step Solution

1
Analyze the read requirement for the source bucket in Project Alpha.
The service account only needs to read objects in `src-logs-bucket`.
The predefined role Storage Object Viewer (`roles/storage.objectViewer`) applied directly at the bucket resource level provides read access without excess permissions.
2
Analyze the write requirement for the destination bucket in Project Beta.
The service account only needs to create new objects in `dst-logs-bucket`.
The predefined role Storage Object Creator (`roles/storage.objectCreator`) applied directly at the destination bucket level allows creating objects without providing permissions to view or delete existing data.
3
Evaluate scope and role breadth to ensure compliance with least privilege.
Resource-level bindings using specialized predefined roles avoid project-wide or organization-wide over-granting.
Granting broad primitive roles or assigning permissions at higher levels in the resource hierarchy violates Google Cloud security best practices.

Key Concept

Applying Least Privilege with Resource-Scoped Predefined IAM Roles
Estimated Time:1m 30s
Question 1340Question

A software team is deploying an existing internal microservice named `analytics-ingest` to Google Cloud Run using the `gcloud` CLI. The application container is hardcoded to listen for incoming web traffic on port 3000 and does not dynamically adapt to the default `PORT` environment variable. When deployed with default parameters, the service fails health checks because Cloud Run routes requests to port 8080. Which `gcloud run deploy` parameter must be included to resolve this issue?

Show answer & explanation

Answer: --port=3000

Answer

Use the `--port=3000` flag in the `gcloud run deploy` command to direct Cloud Run to route requests to port 3000 inside the container.
By default, Cloud Run sends requests to port 8080 inside the container and sets the `PORT` environment variable to 8080. If a container application is hardcoded to listen on a non-standard port such as 3000, passing `--port=3000` to `gcloud run deploy` tells Cloud Run to route traffic to port 3000 and sets `PORT=3000` within the container environment.

Step-by-Step Solution

1
Identify the container's listening port requirement
The microservice container listens strictly on port 3000 instead of the Cloud Run default port 8080.
Cloud Run assumes the container listens on port 8080 unless configured otherwise.
2
Select the correct gcloud run deploy flag for port configuration
The `--port` flag explicitly sets the ingress container listening port for Cloud Run.
Passing `--port=3000` instructs Cloud Run to perform container startup checks and send HTTP traffic to port 3000.

Key Concept

Cloud Run Container Port Binding
PreviousPage 67 / 80Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin