All practice questions

1591 questions

All types1,591 Multiple choice816 Multiple select491 Numeric12 Matching10 Ordering262

An enterprise DevOps team is designing the GKE deployment architecture for two upcoming microservices:

1. A stateless HTTP API service that experiences sudden, unpredictable load spikes and requires hands-off node infrastructure management with zero operational overhead for cluster upgrades.
2. A specialized network security monitoring daemon that requires elevated Linux privileges (`CAP_SYS_ADMIN`) and direct access to the host node network namespace (`hostNetwork: true`).

Which GKE deployment and cluster configuration strategy correctly fulfills both application requirements while adhering to Google Cloud recommended best practices?

Deploy the stateless HTTP API service to a GKE Autopilot cluster, and deploy the network security daemon to a GKE Standard cluster with a dedicated node pool.

Deploy both microservices to a single GKE Autopilot cluster using separate Kubernetes namespaces and custom pod security standards.

Deploy both microservices to a single GKE Standard cluster using Spot VM node pools for both workloads to minimize operational costs.

Deploy the HTTP API service to GKE Standard using a Horizontal Pod Autoscaler (HPA) configured to scale the node pool VM instance count, and deploy the daemon to GKE Autopilot.

Show answer & explanation

Answer: Deploy the stateless HTTP API service to a GKE Autopilot cluster, and deploy the network security daemon to a GKE Standard cluster with a dedicated node pool.

Answer

Deploy the stateless HTTP API service to a GKE Autopilot cluster, and deploy the network security daemon to a GKE Standard cluster with a dedicated node pool.

The correct strategy separates the workloads based on GKE operational boundaries. GKE Autopilot provides fully managed node provisioning, scaling, and maintenance for stateless workloads without infrastructure management overhead. However, Autopilot restricts host network binding (`hostNetwork: true`) and elevated Linux capabilities (`CAP_SYS_ADMIN`). Consequently, the privileged monitoring daemon must be deployed to a GKE Standard cluster where node configuration and pod security settings can be customized.

Step-by-Step Solution

Evaluate the operational and security constraints of GKE Autopilot.

GKE Autopilot manages all node infrastructure, provisioning, and OS patching, making it ideal for stateless web workloads. However, to maintain cluster security, Autopilot blocks capabilities such as hostNetwork: true, hostPort, and elevated Linux capabilities like CAP_SYS_ADMIN.

Security boundaries in GKE Autopilot prevent workloads from modifying host node networking or kernel capabilities.

Evaluate requirements for the privileged monitoring daemon.

The network security daemon requires host network namespace access and CAP_SYS_ADMIN privileges, which are supported in GKE Standard node pools where administrators have full control over node configurations and pod security contexts.

GKE Standard allows custom node pool management and unrestricted Pod Security Standards when explicitly configured.

Synthesize the cluster architecture selection.

Combining GKE Autopilot for the hands-off HTTP API service and GKE Standard for the privileged security daemon satisfies all operational and technical requirements.

This workload segregation respects GKE feature boundaries while following Google Cloud architectural guidelines.

Key Concept

GKE Autopilot vs. Standard Operational Boundaries and Workload Isolation Requirements

Question 382Question →

A developer has created a Google Kubernetes Engine (GKE) cluster to host an application. Before running `kubectl` commands to manage workloads on the cluster, the developer must retrieve cluster access credentials and configure the local command-line environment. Which `gcloud` command should the developer run to update the local `kubeconfig` file with these credentials?

gcloud container clusters get-credentials my-cluster --zone us-central1-a

gcloud config set container/cluster my-cluster

gcloud container node-pools describe my-cluster --zone us-central1-a

gcloud compute instances describe my-cluster-node --zone us-central1-a

Show answer & explanation

Answer: gcloud container clusters get-credentials my-cluster --zone us-central1-a

Answer

Execute `gcloud container clusters get-credentials my-cluster --zone us-central1-a` to automatically populate the local kubeconfig file with cluster endpoints and security credentials.

Executing `gcloud container clusters get-credentials` authenticates against the specified GKE cluster and writes the required certificate authority data, cluster endpoint, and user token into the local `kubeconfig` file. This establishes the active context needed for `kubectl` to communicate with the cluster API server.

Step-by-Step Solution

Identify the CLI tool required to authenticate kubectl with a GKE cluster.

The gcloud container component provides cluster credential integration.

kubectl requires an active context entry containing the cluster API server endpoint and authorization certificate.

Select the exact command designed to fetch cluster credentials.

`gcloud container clusters get-credentials` updates `~/.kube/config`.

This command generates authentication entries so kubectl commands seamlessly talk to the GKE control plane.

Key Concept

Configuring local kubectl context using gcloud container clusters get-credentials

Question 383Question →

An enterprise IoT solutions provider is designing a Google Kubernetes Engine (GKE) cluster architecture to host two distinct workloads. The first workload is a specialized edge telemetry receiver that requires custom Linux kernel parameters (sysctl settings) configured directly on the underlying node OS. The second workload is a stateless, fault-tolerant data transformation pipeline that processes incoming message queues and must run at the lowest possible infrastructure cost. The operations team aims to minimize management complexity while meeting all technical requirements. Which cluster architecture recommendation best fulfills these requirements?

Deploy a single GKE Standard cluster. Create one node pool with standard Compute Engine instances for the edge telemetry workload to support custom kernel parameters, and create a separate node pool utilizing Spot VMs for the stateless data transformation pipeline.

Deploy a single GKE Autopilot cluster for both workloads, configuring pod security settings to allow the edge telemetry workload to apply sysctl kernel modifications at runtime.

Deploy a GKE Standard cluster configured with a single node pool of Spot VMs to host both the edge telemetry receiver and the data transformation pipeline.

Deploy a GKE Standard cluster using standard instances, and configure the Horizontal Pod Autoscaler (HPA) to provision new Compute Engine nodes whenever worker node CPU usage exceeds limits.

Show answer & explanation

Answer: Deploy a single GKE Standard cluster. Create one node pool with standard Compute Engine instances for the edge telemetry workload to support custom kernel parameters, and create a separate node pool utilizing Spot VMs for the stateless data transformation pipeline.

Answer

Deploy a single GKE Standard cluster with a standard node pool for the telemetry receiver and a Spot VM node pool for the stateless transformation pipeline.

The solution correctly identifies that custom Linux sysctl kernel configurations necessitate GKE Standard because GKE Autopilot restricts host OS kernel modifications. Additionally, using a dedicated Spot VM node pool for the stateless transformation pipeline optimizes costs without risking the stability of the telemetry receiver.

Step-by-Step Solution

Analyze the operational boundary between GKE Autopilot and GKE Standard.

GKE Autopilot manages the underlying infrastructure and restricts node-level OS modifications, including custom sysctl parameters. Therefore, GKE Standard is required for the telemetry receiver workload.

GKE Autopilot enforces strict security posture and node management boundaries that prevent custom host OS kernel configuration.

Evaluate node pool cost-optimization strategies for the stateless workload.

Spot VMs provide significant cost savings (up to 60-91% off standard pricing) and are ideal for fault-tolerant, stateless batch workloads that can handle instance preemptions.

Segmenting workloads into separate node pools allows tailored instance selection and cost optimization per workload profile.

Synthesize the cluster architecture design.

A GKE Standard cluster with two dedicated node pools (Standard VMs for telemetry; Spot VMs for stateless processing) satisfies technical and budget constraints.

This setup maintains cluster operational efficiency while respecting underlying node OS customization and fault tolerance boundaries.

Key Concept

Planning GKE Cluster Architectures with Node Pool Segmentation and Operating Model Choices

Question 384Question →

Your company is deploying a non-HTTP application service running on custom TCP ports across multiple Compute Engine virtual machine instances in a single Google Cloud region. The service must only be accessible to client applications located inside your Virtual Private Cloud (VPC) network. Which Google Cloud load balancing solution should you select?

Internal Passthrough Network Load Balancer

Global External Application Load Balancer

Cloud CDN with a Storage Bucket backend

Cloud DNS Private Zone

Show answer & explanation

Answer: Internal Passthrough Network Load Balancer

Answer

Internal Passthrough Network Load Balancer

The Internal Passthrough Network Load Balancer is a regional, Layer 4 internal load balancer that distributes non-HTTP (raw TCP or UDP) traffic among backend Compute Engine VM instances within a private VPC network.

Step-by-Step Solution

Analyze the access scope requirement

The service must be accessible only to clients within the internal VPC network, requiring an internal load balancing service.

External load balancers expose services to the public internet, which violates the internal access constraint.

Analyze the protocol requirement

The application uses custom non-HTTP raw TCP traffic.

Layer 7 Application Load Balancers are designed for HTTP/HTTPS traffic, whereas Layer 4 Passthrough Network Load Balancers handle raw TCP/UDP traffic.

Select the matching Google Cloud networking service

An Internal Passthrough Network Load Balancer meets both internal VPC access and raw TCP protocol requirements.

It handles internal non-HTTP (TCP/UDP) traffic targeted at backend Compute Engine instances within a region.

Key Concept

Selecting GCP Load Balancers based on Traffic Scope (Internal vs External) and Protocol (HTTP vs non-HTTP TCP/UDP)

Estimated Time:1m 0s

Question 385Question →

A cloud administrator is configuring a local command-line environment to deploy workloads onto a newly provisioned Google Kubernetes Engine (GKE) Standard cluster. The cluster hosts both critical application endpoints and fault-tolerant stateless background workers. Which TWO actions should the administrator perform to establish cluster management access and properly deploy these stateless workloads?

Select all that apply

Execute gcloud container clusters get-credentials specifying the cluster name and location to populate the local kubeconfig file.

Configure node selectors and tolerations on stateless worker deployments to allow scheduling on a dedicated Spot VM node pool.

Run gcloud config set container/cluster with the cluster name to configure cluster authentication context for kubectl.

Deploy persistent relational database instances onto a Spot VM node pool with default configurations to reduce overall compute costs.

Show answer & explanation

Answer: Execute gcloud container clusters get-credentials specifying the cluster name and location to populate the local kubeconfig file.; Configure node selectors and tolerations on stateless worker deployments to allow scheduling on a dedicated Spot VM node pool.

Answer

To manage and deploy workloads on GKE, administrators must execute gcloud container clusters get-credentials to populate kubeconfig, and configure stateless, fault-tolerant workloads with appropriate tolerations and node selectors to run on Spot VM node pools.

Establishing cluster access requires executing gcloud container clusters get-credentials to generate the kubeconfig context needed for kubectl operations. For workload management, stateless fault-tolerant jobs are ideal candidates for Spot VM node pools when paired with proper node selectors and tolerations.

Step-by-Step Solution

Authenticate and update local Kubernetes credentials

Local environment obtains control plane endpoint info and credentials in kubeconfig

kubectl requires active credentials and endpoint parameters generated by gcloud container clusters get-credentials to interact with the GKE control plane.

Align workload traits with compute infrastructure types

Stateless workloads are assigned to cost-optimized Spot VM node pools

Spot VMs offer significantly lower costs for workloads that are stateless and resilient to sudden termination.

Key Concept

GKE Cluster Credential Acquisition and Workload Placement on Spot Node Pools

Question 386Question →

A cloud engineer needs to enable Object Versioning on an existing Google Cloud Storage bucket named `app-logs-prod` using the Google Cloud CLI (`gcloud`). Which command should the engineer run?

gcloud storage buckets update gs://app-logs-prod --versioning

gcloud storage buckets update gs://app-logs-prod --enable-versioning

gcloud compute buckets update gs://app-logs-prod --versioning

gsutil versioning set on app-logs-prod

Show answer & explanation

Answer: gcloud storage buckets update gs://app-logs-prod --versioning

Answer

The correct command is `gcloud storage buckets update gs://app-logs-prod --versioning`.

To update settings on an existing Cloud Storage bucket such as enabling Object Versioning using the Google Cloud CLI, the correct command is `gcloud storage buckets update gs://[BUCKET_NAME] --versioning`.

Step-by-Step Solution

Identify the target Cloud Storage resource and command group

The target is the existing bucket `app-logs-prod`, managed via the `gcloud storage` CLI component.

Google Cloud CLI manages object storage resources using `gcloud storage buckets` subcommands.

Specify the update action and versioning flag

Execute `gcloud storage buckets update gs://app-logs-prod --versioning`.

The `update` subcommand combined with the `--versioning` flag enables Object Versioning on the bucket.

Key Concept

Deploying and configuring Cloud Storage bucket features using gcloud storage CLI

Estimated Time:45s

Question 387Question →

A cloud engineer needs to configure automated cost-control actions triggered by Cloud Billing budget alerts using a serverless event architecture. Arrange the following deployment steps in the correct chronological order required to set up this workflow.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with granting the appropriate IAM permissions on the Cloud Billing account, followed by creating the destination Cloud Pub/Sub topic, configuring the Cloud Billing budget linked to that Pub/Sub topic, and finally deploying the Cloud Function subscriber to handle automated remediation logic.

The correct order establishes prerequisite security permissions first, provisions the messaging infrastructure second, binds the billing budget alert policy to the Pub/Sub endpoint third, and implements the serverless consumer logic fourth. This sequence ensures all dependency relationships (permissions -> Pub/Sub topic -> budget binding -> event consumer) are satisfied without workflow errors.

Step-by-Step Solution

Ensure IAM administrative access for Cloud Billing.

The engineer has permission to manage billing budget alerts and export configurations.

Without roles such as Billing Account Costs Manager or Billing Account Administrator, budget modifications and pub/sub sink settings cannot be saved.

Provision the Cloud Pub/Sub notification endpoint.

A Pub/Sub topic is established to receive automated JSON alert messages from Google Cloud Billing.

Google Cloud Billing budgets require an existing Pub/Sub topic identifier when attaching a programmatic notification channel.

Create the Cloud Billing budget and link the Pub/Sub topic.

Budget threshold rules are active and configured to publish messages to the Pub/Sub topic when spending targets are met.

Budget alert policies send events to the Pub/Sub topic only after explicit association in the billing console or gcloud command.

Deploy the event-driven subscriber logic via Cloud Functions.

An automated listener receives Pub/Sub event notifications and executes administrative actions to stop workloads or cap costs.

Budget notifications do not automatically stop resources by default; custom code in Cloud Functions/Run is required to parse notifications and invoke GCP APIs to enforce cost limits.

Key Concept

Programmatic Billing Budget Notifications and Automated Remediation Workflow

Question 388Question →

A site reliability engineer is setting up a freshly imaged workstation to manage an active Google Kubernetes Engine (GKE) Standard cluster named `prod-app-cluster` located in region `us-central1`. When attempting to run `kubectl get pods`, the command fails with an error indicating that the connection to `localhost:8080` was refused because the local environment context is unconfigured. Which `gcloud` command must the engineer execute to retrieve cluster credentials and update the local `kubeconfig` file?

gcloud container clusters get-credentials prod-app-cluster --region=us-central1

gcloud config set container/cluster prod-app-cluster

gcloud container node-pools create spot-pool --cluster=prod-app-cluster --enable-spot --region=us-central1

gcloud container clusters update prod-app-cluster --enable-autopilot --region=us-central1

Show answer & explanation

Answer: gcloud container clusters get-credentials prod-app-cluster --region=us-central1

Answer

The command `gcloud container clusters get-credentials prod-app-cluster --region=us-central1` must be executed to update the local kubeconfig file.

Executing the command `gcloud container clusters get-credentials prod-app-cluster --region=us-central1` authenticates to Google Cloud, retrieves the cluster endpoint certificates, and writes an authenticated context entry directly into the local `kubeconfig` file so that `kubectl` can target the cluster.

Step-by-Step Solution

Identify why kubectl fails with a localhost:8080 error.

Recognize that kubectl defaults to localhost:8080 when no valid target API server context exists in the local ~/.kube/config file.

Before kubectl can target a remote GKE cluster, local credentials and context entries must be populated.

Determine the correct gcloud CLI command to populate cluster credentials.

Select `gcloud container clusters get-credentials` along with the cluster name and region flag.

This command generates security tokens, fetches cluster endpoint IPs, and constructs the current-context entry inside kubeconfig.

Key Concept

Fetching GKE cluster credentials to configure local kubectl context

Question 389Question →

An organization operates a custom-mode Virtual Private Cloud (VPC) in Google Cloud. A network engineer is tasked with expanding the primary IP range of `subnet-east` to accommodate additional compute instances.

The current VPC subnet allocation and connected routes are configured as follows:
- `subnet-east` primary IP range: $10.80.12.0/23$ ( $10.80.12.0 - 10.80.13.255$ )
- `subnet-west` primary IP range: $10.80.14.0/23$ ( $10.80.14.0 - 10.80.15.255$ )
- `subnet-central` primary IP range: $10.80.8.0/23$ ( $10.80.8.0 - 10.80.9.255$ )
- On-premises network (via Cloud VPN): $10.80.0.0/21$ ( $10.80.0.0 - 10.80.7.255$ )

The engineer plans to expand `subnet-east` to a $/22$ prefix length to double its IP capacity. Which statement accurately describes the outcome and requirements for this expansion?

The expansion will fail because the only valid

/22

CIDR block containing

10.80.12.0/23

10.80.12.0/22

, which overlaps with `subnet-west` (

10.80.14.0/23

The expansion will succeed if `subnet-east` is expanded to

10.80.10.0/22

, utilizing the unused IP addresses between `subnet-central` and `subnet-east`.

The expansion will succeed if `subnet-east` is expanded to

10.80.8.0/22

, because Google Cloud automatically re-aggregates adjacent subnets within the same VPC.

The expansion will fail because Google Cloud subnets can only be expanded if the original prefix length is

/24

or smaller.

Show answer & explanation

Answer: The expansion will fail because the only valid $/22$ CIDR block containing $10.80.12.0/23$ is $10.80.12.0/22$ , which overlaps with `subnet-west` ( $10.80.14.0/23$ ).

Answer

The expansion will fail because the only valid

/22

CIDR block containing

10.80.12.0/23

10.80.12.0/22

, which overlaps with `subnet-west` (

10.80.14.0/23

Expanding a primary subnet IP range in a GCP Virtual Private Cloud requires two fundamental conditions: the new netmask must be smaller (broader), and the new CIDR block must encompass the existing IP range while remaining aligned on a valid binary CIDR boundary. For

10.80.12.0/23

, the only encompassing

/22

block is

10.80.12.0/22

(

10.80.12.0 - 10.80.15.255

). Because

10.80.14.0/23

is already assigned to `subnet-west`, the expanded block creates an IP overlap, causing Google Cloud to reject the expansion.

Step-by-Step Solution

Determine the binary network alignment required for a

/22

CIDR block.

/22

IPv4 subnet mask covers 4 contiguous values in the third octet (

2^{32-22} = 1024

total addresses) and must start at a third-octet value that is a multiple of 4 (e.g., 0, 4, 8, 12, 16).

CIDR blocks must align on standard binary subnet boundaries.

Identify the

/22

block that encloses the current `subnet-east` range (

10.80.12.0/23

The target range

10.80.12.0/23

spans

10.80.12.0 - 10.80.13.255

. The only valid

/22

block containing this range is

10.80.12.0/22

, spanning

10.80.12.0 - 10.80.15.255

Subnet primary IP expansion requires the existing range to be fully contained within the expanded CIDR block.

Evaluate the expanded

/22

block against existing subnet allocations and routes.

10.80.12.0/22

includes

10.80.14.0 - 10.80.15.255

, which is already assigned to `subnet-west` (

10.80.14.0/23

Google Cloud VPC prevents subnet expansion if the new range overlaps with any existing subnet CIDR block in the same VPC network.

Key Concept

VPC Primary Subnet Expansion CIDR Boundary and Overlap Rules

Estimated Time:2m 0s

Question 390Question →

A cloud engineer needs to update an existing application running on a Google Kubernetes Engine (GKE) cluster with a new container image version. What is the correct sequence of actions to build, publish, and verify the deployment of this updated workload?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with building and tagging the container image locally, pushing the image to Google Cloud Artifact Registry, updating the container image on the GKE deployment using kubectl set image, and finally verifying the deployment progress using kubectl rollout status.

The workflow follows standard container lifecycle and Kubernetes deployment practices: first creating the local container image, pushing it to Google Cloud Artifact Registry so GKE can access it, applying the image update to the deployment manifest via kubectl, and lastly inspecting the rollout status to confirm workload health.

Step-by-Step Solution

Build and tag the application image locally.

A tagged container artifact exists locally ready for deployment repository upload.

Containerized workloads require a built image artifact prior to registry publishing.

Publish the image to Google Cloud Artifact Registry.

The image artifact becomes accessible to the GKE worker nodes.

GKE nodes pull container images from centralized cloud registries during pod scheduling.

Update the GKE workload image using kubectl set image.

GKE initiates a rolling update to replace existing pod replicas with the new container image version.

Modifying the pod template specification in the deployment resource triggers Kubernetes declarative updates.

Monitor the update using kubectl rollout status.

Confirmation that all updated pod replicas are running and healthy.

Verifying the rollout ensures the application update completed successfully without failure loops.

Key Concept

Updating and Monitoring GKE Workloads

Question 391Question →

A financial analytics firm is planning the deployment of two backend components for a new serverless application on Google Cloud:

1. Component 1: A report generator service that executes a custom-compiled Linux C++ executable requiring specific OS system libraries packaged in a container.
2. Component 2: A lightweight event processing snippet that parses JSON data whenever a new message is published to a Cloud Pub/Sub topic.

Which TWO architectural decisions should the cloud engineer select to meet these requirements with minimal operational management? (Select TWO.)

Select all that apply

Deploy Component 1 to Cloud Run using a custom container image.

Deploy Component 2 to Cloud Functions (2nd gen) triggered by Cloud Pub/Sub.

Deploy Component 1 to Cloud Functions (1st gen) by uploading the compiled binary inside an inline zip archive.

Deploy Component 2 to Compute Engine virtual machines configured with Managed Instance Groups.

Show answer & explanation

Answer: Deploy Component 1 to Cloud Run using a custom container image.; Deploy Component 2 to Cloud Functions (2nd gen) triggered by Cloud Pub/Sub.

Answer

Deploy the report generator service (Component 1) to Cloud Run using a custom container image, and deploy the event-driven parser (Component 2) to Cloud Functions (2nd gen) triggered by Cloud Pub/Sub.

Cloud Run executes arbitrary Docker container images, providing full control over system libraries and custom binaries needed by the report generator service. Cloud Functions (2nd gen) integrates natively with Eventarc and Pub/Sub, providing a fully managed serverless environment ideal for lightweight event handler snippets without container maintenance.

Step-by-Step Solution

Analyze requirement for Component 1

Component 1 requires custom C++ binaries and Linux OS system libraries.

Cloud Run is designed to run any containerized application, satisfying requirements for custom runtime dependencies and native binaries.

Analyze requirement for Component 2

Component 2 requires lightweight event-driven execution triggered by Pub/Sub.

Cloud Functions offers a simplified function-as-a-service paradigm for handling asynchronous GCP events with minimal boilerplate.

Key Concept

Selecting serverless compute platforms based on containerization requirements, custom OS library dependencies, and event-driven trigger patterns.

Question 392Question →

An administrator needs to relocate an existing Google Cloud project from a parent folder named `Staging` to another folder named `Production` within the organization resource hierarchy. The administrator already has the `Project Editor` role directly on the project being relocated, but the migration attempt fails with a permission denied error. Which administrative role or permission requirement explains why this move was denied?

The administrator requires permissions to detach the project from the source folder and attach it to the destination folder, requiring write permissions on both folders in addition to project update rights.

The Project Editor role grants sufficient authority on the project, but permissions inherited from the child project level automatically override parent folder policies to block folder-to-folder movement.

Moving projects between folders cannot be accomplished using predefined roles and strictly requires assigning the primitive Organization Owner role at the root organization node.

The project must first be unlinked from its central Cloud Billing Account because active billing account associations prevent moving projects between resource hierarchy folders.

Show answer & explanation

Answer: The administrator requires permissions to detach the project from the source folder and attach it to the destination folder, requiring write permissions on both folders in addition to project update rights.

Answer

The administrator requires write/move permissions on both the source and target parent folders in addition to update permissions on the project itself.

To move a GCP project between folders in the resource hierarchy, an identity must hold rights on all affected nodes: project update permissions on the project being moved, as well as parent modification/move rights (such as `resourcemanager.projects.move` or Project Mover role) on both the source parent folder and the target parent folder.

Step-by-Step Solution

Analyze resource hierarchy movement permission requirements

Identified that moving a GCP project affects three distinct hierarchy nodes: the project itself, the source parent folder, and the destination parent folder.

Google Cloud IAM evaluates access control at every affected level of the resource hierarchy.

Evaluate permissions granted by the Project Editor role

The Project Editor role grants `resourcemanager.projects.update` on the project, which satisfies the project-level requirement.

Editing the project configuration is only one part of relocating a resource.

Determine missing folder-level IAM permissions

The operation fails because the user lacks permissions to modify the project list of the source folder (removing the project) and the destination folder (adding the project).

Granting appropriate predefined roles (e.g., Project Mover or Folder Admin) at the source and destination folder levels fulfills the least-privilege requirement for moving projects.

Key Concept

GCP Project Relocation Permission Requirements in Resource Hierarchy

Estimated Time:1m 30s

Question 393Question →

A Cloud Engineer needs to request an increase for the regional Compute Engine N2 CPUs quota in a Google Cloud project using the Google Cloud Console. What is the correct sequence of steps to submit this quota increase request?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order to request a GCP quota increase is: First, navigate to IAM & Admin > Quotas & System Limits in the Google Cloud Console. Second, filter for the specific service, metric, and target region. Third, select the quota metric checkbox and click Edit Quotas. Fourth, enter the new requested limit value, provide a justification, and submit the request.

To successfully request a GCP resource quota increase in the Cloud Console, an engineer must start at IAM & Admin > Quotas & System Limits, filter down to the specific service and regional metric, select the item to click Edit Quotas, and finally supply the requested limit and justification upon submission.

Step-by-Step Solution

Navigate to the Quotas & System Limits section

Opens the central quota management interface for the project

Quota management tools in GCP are located under the IAM & Admin section of the console.

Filter for the target quota metric

Displays the exact Compute Engine N2 CPUs entry for the specific region

Quotas are scoped by service, resource metric, and geographic region or location.

Initiate quota editing

Opens the request panel for modifying the selected quota

Selecting the quota line item and clicking Edit Quotas enables input fields for request submission.

Provide new limit and justification before submitting

Sends the quota increase request to Google Cloud support for review

Quota increases require specifying the target limit value and a business justification.

Key Concept

Requesting GCP Resource Quota Increases via Cloud Console

Estimated Time:1m 30s

Question 394Question →

A Cloud Engineer is tasked with setting up a new development environment in Google Cloud from scratch. The setup requires creating a dedicated Folder under the Organization, creating a Project inside that Folder, associating the Project with an active Billing Account, enabling the Compute Engine API, and granting least-privilege IAM access to the development team. What is the correct sequence of steps to complete this configuration using gcloud CLI commands?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: 1) Create the target Folder under the Organization, 2) Create the Project inside the Folder, 3) Link the Project to the active Billing Account, 4) Enable the Compute Engine API on the Project, and 5) Bind predefined IAM roles to the development team.

Establishing a new cloud environment follows a strict operational hierarchy: first create the top-level container (Folder), then create the child resource (Project), attach financial backing (Billing Account), activate required service APIs, and finally delegate permissions to team members via IAM bindings.

Step-by-Step Solution

Create the parent Folder node

The target folder container is provisioned in the organization resource hierarchy.

Parent containers must exist prior to placing child resources under them.

Create the child Project

The project is created directly under the specified folder ID.

The project must exist before billing accounts can be attached or service APIs enabled.

Associate Billing Account

The project is linked to a valid billing account.

Google Cloud requires an active billing attachment before billable services like Compute Engine can be enabled.

Enable Compute Engine API

The Compute Engine API is activated for the project.

Service APIs must be explicitly enabled on the project prior to resource provisioning or role access usage.

Apply IAM Policy Bindings

Developers are granted predefined IAM roles on the project.

Assigning least-privilege roles to users completes the initial project governance setup.

Key Concept

Procedural dependency and lifecycle order for GCP resource hierarchy, billing association, API activation, and IAM access configuration.

Question 395Question →

Your enterprise organization needs to author, test, and release a custom IAM role at the organization level using a declarative definition. Place the operational steps in the correct sequential order to create, evaluate, and promote the custom IAM role using the gcloud CLI following Google Cloud best practices.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with drafting the local YAML role definition file with launchStage set to ALPHA, followed by creating the role at the organization level with gcloud iam roles create, testing the role assignment on a project via gcloud projects add-iam-policy-binding, and finally updating the role's launch stage to GA via gcloud iam roles update.

Declarative custom IAM role creation follows a structured lifecycle: defining the specification in YAML with an initial ALPHA stage, instantiating the role in GCP using gcloud iam roles create, testing permission effectiveness by binding the role to a test principal, and finally updating the role's launch stage to GA using gcloud iam roles update.

Step-by-Step Solution

Define the custom role structure locally in YAML.

A valid YAML configuration file containing title, description, permissions list, and ALPHA launch stage.

gcloud CLI declarative role creation requires a pre-configured YAML file containing the permission payload.

Create the organization custom role via gcloud CLI.

The custom IAM role is instantiated at the organization resource level.

Creating the role makes its resource identifier available across child projects in the resource hierarchy.

Bind the role to a service account for integration testing.

The identity receives the defined permissions within the specific test project scope.

Testing the ALPHA role validates that no required permissions were omitted from the custom role definition.

Promote the custom role to GA status via gcloud iam roles update.

The role lifecycle stage updates to GA, signaling readiness for enterprise production workloads.

Updating the YAML launchStage and executing the update command updates the official lifecycle metadata of the role.

Key Concept

Custom IAM Role Lifecycle and Declarative Management via gcloud CLI

Question 396Question →

A cloud engineer is designing a custom-mode Virtual Private Cloud (VPC) network. The current setup includes a primary subnet in `us-central1` configured with a CIDR block of $10.10.1.0/24$ and another primary subnet in the same VPC configured with $10.10.2.0/24$ . Due to anticipated growth, the engineer needs to double the IP address capacity of the $10.10.1.0/24$ subnet without re-creating the subnet or disrupting existing workloads. Which CIDR range configuration update is valid and prevents IP range overlap?

Expand the subnet primary IP range to

10.10.0.0/23

Expand the subnet primary IP range to

10.10.1.0/23

Change the VPC mode from custom-mode to auto-mode to allow Google Cloud to automatically expand subnets.

Add a non-contiguous secondary CIDR range of

10.10.3.0/24

directly to the primary IP range of the subnet.

Show answer & explanation

Answer: Expand the subnet primary IP range to $10.10.0.0/23$ .

Answer

Expand the subnet primary IP range to

10.10.0.0/23

Expanding the primary CIDR block of a custom-mode subnet requires keeping the range contiguous and aligned to proper binary network boundaries. Expanding

10.10.1.0/24

10.10.0.0/23

covers IP addresses from

10.10.0.0

10.10.1.255

, incorporating the original range, doubling capacity to

512

addresses, and avoiding collision with the existing

10.10.2.0/24

subnet.

Step-by-Step Solution

Analyze the starting primary IP address range and target capacity expansion.

The subnet currently uses

10.10.1.0/24

(

256

IP addresses). Doubling capacity requires a

/23

prefix (

512

IP addresses).

Expanding a subnet primary CIDR block requires shifting to a smaller prefix length while remaining contiguous.

Evaluate valid

/23

network boundaries that include

10.10.1.0/24

/23

subnet boundary aligned on binary boundaries covers

10.10.0.0

10.10.1.255

(represented as

10.10.0.0/23

10.10.1.0/23

is not a valid network address base; the network address for this

/23

block is

10.10.0.0/23

Verify there is no IP range overlap with other subnets in the VPC.

10.10.0.0/23

covers

10.10.0.0

–

10.10.1.255

, which does not collide with the neighboring subnet at

10.10.2.0/24

Google Cloud VPC subnet expansion fails if the new expanded CIDR range overlaps with any pre-existing subnets in the network.

Key Concept

Subnet IP Range Expansion in Google Cloud VPC

Question 397Question →

A cloud engineer is using the Google Cloud Pricing Calculator to model monthly operational costs for a mission-critical production workload running continuously 24/7 year-round. The architecture requires 20 Compute Engine instances for base application traffic and a 10 TB data layer that will be queried and updated multiple times per day. Which configuration strategy in the Google Cloud Pricing Calculator provides the most accurate and cost-effective estimate for this workload?

Specify 3-year Committed Use Discounts (CUDs) for the 20 Compute Engine instances and select Standard Cloud Storage for the frequently accessed 10 TB data layer.

Combine automatic Sustained Use Discounts (SUDs) with 3-year Committed Use Discounts (CUDs) for the Compute Engine instances, and select Archive Storage to minimize baseline storage costs.

Configure all 20 Compute Engine instances as Spot VM instances to maximize discount percentages, and select Coldline Storage for the active data layer.

Model the application layer using GKE Autopilot pods with Archive Storage for the active data layer, while assuming node management fees will cover data egress and storage access.

Show answer & explanation

Answer: Specify 3-year Committed Use Discounts (CUDs) for the 20 Compute Engine instances and select Standard Cloud Storage for the frequently accessed 10 TB data layer.

Answer

Specify 3-year Committed Use Discounts (CUDs) for the 20 Compute Engine instances and select Standard Cloud Storage for the frequently accessed 10 TB data layer.

The correct strategy specifies 3-year Committed Use Discounts (CUDs) for the continuous 24/7 Compute Engine workload to lock in the maximum discount rate available in the Google Cloud Pricing Calculator. For the data layer accessed multiple times daily, Standard Cloud Storage is required because nearline, coldline, and archive tiers incur expensive data access and retrieval fees that outweigh their lower baseline at-rest storage costs.

Step-by-Step Solution

Evaluate compute usage pattern and discount options in the Google Cloud Pricing Calculator.

Identify that a continuous 24/7 mission-critical workload operating over long horizons qualifies for Committed Use Discounts (CUDs), which yield higher cost savings than Sustained Use Discounts (SUDs) and cannot be stacked together.

CUDs commit to a specific amount of resource usage for 1 or 3 years, overriding automatic SUDs.

Assess storage class access requirements based on workload access frequency.

Determine that data accessed multiple times per day requires Standard Cloud Storage to avoid operational retrieval fees.

Coldline and Archive storage tiers have low at-rest pricing but high data retrieval fees, making them cost-prohibitive for active data.

Synthesize compute and storage choices to select the optimal calculator configuration.

Combine 3-year CUDs for VMs with Standard Cloud Storage for active data.

This combination achieves maximum valid compute savings while eliminating unexpected storage retrieval penalties.

Key Concept

Pricing Calculator discount modeling and storage tier access trade-offs

Question 398Question →

A cloud security administrator at a biotechnology firm needs to grant a lead bio-informatician the required privileges to link a newly provisioned Google Cloud project, `genomics-pipeline-prod`, to the enterprise Cloud Billing Account. The administrator must strictly adhere to the principle of least privilege, ensuring the bio-informatician cannot manage payment details or alter billing account permissions. Which IAM role combination should be granted to the bio-informatician?

Billing Account User (roles/billing.user) on the Cloud Billing Account and Project Billing Manager (roles/resourcemanager.projectBillingManager) on the target project

Billing Account Administrator (roles/billing.admin) on the Cloud Billing Account and Owner (roles/owner) on the target project

Billing Account User (roles/billing.user) on the Cloud Billing Account only

Project Billing Manager (roles/resourcemanager.projectBillingManager) on the target project only

Show answer & explanation

Answer: Billing Account User (roles/billing.user) on the Cloud Billing Account and Project Billing Manager (roles/resourcemanager.projectBillingManager) on the target project

Answer

Grant Billing Account User (roles/billing.user) on the Cloud Billing Account and Project Billing Manager (roles/resourcemanager.projectBillingManager) on the target project.

Linking a Google Cloud project to a Cloud Billing Account requires permissions on both entities. The predefined role Billing Account User (`roles/billing.user`) gives the permission `billing.resourceAssociations.create` on the billing account. The predefined role Project Billing Manager (`roles/resourcemanager.projectBillingManager`) gives the permission `resourcemanager.projects.createBillingAssignment` on the project. This combination grants the exact rights required without over-privileging the user.

Step-by-Step Solution

Identify the minimum permission required on the Cloud Billing Account

The permission `billing.resourceAssociations.create` is needed, which is provided by the predefined role Billing Account User (`roles/billing.user`).

This allows the user to associate projects with the billing account without granting administrative access over payment settings or billing administration.

Identify the minimum permission required on the target Google Cloud Project

The permission `resourcemanager.projects.createBillingAssignment` is needed, which is provided by the predefined role Project Billing Manager (`roles/resourcemanager.projectBillingManager`).

This allows the user to link or unlink the billing account on that specific project without granting broad primitive roles like Owner or Editor.

Combine both permissions to achieve least privilege compliance

Pairing Billing Account User on the billing account with Project Billing Manager on the project provides exact, dual-side authorization required for project-billing linking.

Google Cloud requires explicit authorization on both resource entities (the billing account and the project).

Key Concept

Dual-sided IAM requirements for linking Google Cloud Projects to Cloud Billing Accounts

Question 399Question →

An enterprise SaaS organization is architecting a Google Kubernetes Engine (GKE) environment to host two distinct workloads with strict operational requirements:

1. A high-throughput custom API gateway service that requires modifying specific OS kernel sysctl parameters (`net.core.somaxconn`) on the underlying cluster nodes.
2. A fault-tolerant, stateless asynchronous batch analytics engine designed to process non-critical queued jobs at minimal cost.

You need to plan a cluster architecture that meets these workload demands while minimizing operational expenditure. Which TWO architectural decisions should you execute?

Select all that apply

Deploy a GKE Standard cluster with a custom node pool where kernel sysctl settings can be customized for the API gateway workload.

Provision a dedicated node pool utilizing Spot VMs configured with taints and tolerations for the asynchronous batch analytics workload.

Deploy a GKE Autopilot cluster for the API gateway workload to eliminate node management while applying custom OS sysctl kernel configurations.

Provision a Spot VM node pool to host the primary stateful database instances supporting the SaaS platform.

Configure the Horizontal Pod Autoscaler (HPA) to scale out the number of Compute Engine worker nodes when batch processing queues grow.

Show answer & explanation

Answer: Deploy a GKE Standard cluster with a custom node pool where kernel sysctl settings can be customized for the API gateway workload.; Provision a dedicated node pool utilizing Spot VMs configured with taints and tolerations for the asynchronous batch analytics workload.

Answer

Select GKE Standard for custom OS kernel sysctl modifications on the node pool, and utilize Spot VMs with taints and tolerations for stateless batch processing workloads.

Choosing GKE Standard enables necessary low-level node kernel modifications (sysctl settings) required by high-throughput network components. Additionally, implementing Spot VMs with proper taints and tolerations enables significant cost reductions for fault-tolerant, stateless batch workloads without exposing critical services to preemption risks.

Step-by-Step Solution

Analyze the operational boundary requirements for custom OS kernel settings.

GKE Autopilot locks down node-level configurations. Custom sysctl parameters require GKE Standard node pools.

Only GKE Standard allows custom node configuration scripts and low-level kernel tuning.

Analyze the compute cost optimization strategy for the asynchronous batch engine.

Spot VMs provide high discount rates for interruptible, stateless workloads.

Taints and tolerations ensure only the batch processing pods schedule onto Spot VM nodes.

Key Concept

GKE Standard vs Autopilot node management boundaries and Spot VM workload suitability

Estimated Time:2m 0s

Question 400Question →

An industrial manufacturing company uploads high-resolution optical inspection images to Google Cloud Storage. Analysis of the data lifecycle reveals the following operational requirements:

- Newly created images are accessed continuously by automated quality assurance systems during the first 30 days.
- Between 31 and 90 days, images are queried infrequently (approximately once per month) for batch defect trend reporting.
- After 90 days, images are rarely accessed but must be kept for 3 years to comply with industrial safety audits.

You need to design a Cloud Storage lifecycle policy that optimizes total operational cost while avoiding premature transition fees and excessive retrieval charges. Which storage class transition strategy should you implement?

Create a bucket with the Standard storage class. Add a lifecycle rule to transition objects to Nearline storage after 30 days, and a second rule to transition objects to Coldline storage after 90 days.

Create a bucket with the Nearline storage class as default. Add a lifecycle rule to transition objects directly to Archive storage after 30 days.

Create a bucket with the Standard storage class. Add a lifecycle rule to transition objects directly to Archive storage after 30 days.

Create a bucket with the Coldline storage class as default. Add a lifecycle rule to transition objects to Archive storage after 90 days.

Show answer & explanation

Answer: Create a bucket with the Standard storage class. Add a lifecycle rule to transition objects to Nearline storage after 30 days, and a second rule to transition objects to Coldline storage after 90 days.

Answer

The correct strategy starts with Standard storage to allow frequent QA reads during the first 30 days without incurring retrieval fees. Transitioning to Nearline after 30 days reduces storage costs while accommodating monthly batch reporting queries. Transitioning to Coldline after 90 days further reduces long-term retention costs for compliance while respecting the 90-day minimum duration policy of Coldline storage.

Step-by-Step Solution

Analyze the access pattern and minimum duration requirements for the initial 30 days.

Images are continuously accessed during the first 30 days, requiring zero retrieval fees.

Standard storage class has no minimum storage duration and zero retrieval costs, making it the most cost-effective tier for frequently accessed active data.

Analyze the access pattern and minimum duration requirements for days 31 to 90.

Images are accessed once per month, fitting the Nearline access pattern.

Nearline storage is optimized for data accessed less than once a month and requires a 30-day minimum storage duration, matching the 30-day transition threshold.

Analyze the access pattern and minimum duration requirements after 90 days.

Images are rarely accessed over a 3-year compliance period, fitting the Coldline access pattern.

Coldline storage is optimized for data accessed at most once every 90 days and carries a 90-day minimum storage duration, matching the 90-day transition threshold.

Key Concept

Google Cloud Storage Storage Classes and Object Lifecycle Management

Estimated Time:2m 0s

PreviousPage 20 / 80Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept