Examkin

All practice questions

1591 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 361Question →

An administrator needs to configure a local management workstation to interact with a newly created Google Kubernetes Engine (GKE) cluster named `finance-app-cluster` in the `us-central1-a` zone. Which of the following commands are required to fetch the cluster credentials for `kubectl` and verify the running workloads? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Execute `gcloud container clusters get-credentials finance-app-cluster --zone us-central1-a` to update the local kubeconfig file.; Execute `kubectl get pods` to list the currently running Kubernetes workload pods in the cluster.

Answer

The correct commands are executing `gcloud container clusters get-credentials finance-app-cluster --zone us-central1-a` to populate the local kubeconfig file and executing `kubectl get pods` to inspect the workload pods.
To manage a GKE cluster via kubectl, credentials must first be fetched using `gcloud container clusters get-credentials`, specifying the cluster name and location (zone or region). Once configured, standard Kubernetes tools like `kubectl get pods` interact directly with the cluster API server.

Step-by-Step Solution

1
Fetch the GKE cluster credentials using the Google Cloud CLI.
The local `~/.kube/config` file is created or updated with the cluster endpoint and API authentication tokens.
kubectl requires active cluster context and authentication credentials before sending requests to the API server.
2
Run kubectl commands to query cluster resources.
Kubectl retrieves and displays the workload pods running in the specified cluster namespace.
`kubectl get pods` uses the context stored in kubeconfig to communicate with the GKE control plane.

Key Concept

Deploying and Managing GKE Clusters and Workloads - Authenticating kubectl and querying GKE resources
Question 362Question →

You are tasked with deploying a new Google Cloud Storage bucket named `analytics-data-dump` in the `us-central1` region using the modern Google Cloud CLI (`gcloud`). Which command should you run to create this bucket following Google Cloud best practices?

Show answer & explanation

Answer: gcloud storage buckets create gs://analytics-data-dump --location=us-central1

Answer

The command `gcloud storage buckets create gs://analytics-data-dump --location=us-central1` correctly deploys a Cloud Storage bucket using the unified Google Cloud CLI.
The correct command uses `gcloud storage buckets create` along with the standard `gs://` prefix and the `--location` flag to specify the target GCP region (`us-central1`). This aligns with current Google Cloud CLI best practices.

Step-by-Step Solution

1
Identify the recommended CLI interface for Cloud Storage management.
`gcloud storage` is the modern standard CLI tool replacing legacy `gsutil` commands.
Google Cloud recommends `gcloud storage` for improved performance and unified command structure.
2
Select the correct subcommand for bucket creation.
Use `gcloud storage buckets create`.
The `buckets create` surface is the standard verb pattern in `gcloud`.
3
Specify the bucket URI prefix and location flag.
Pass `gs://<bucket-name>` and `--location=<region>`.
Cloud Storage buckets require the `gs://` protocol scheme and regional/multi-regional locations specified via `--location`.

Key Concept

Deploying Cloud Storage buckets using modern gcloud storage commands
Question 363Question →

An enterprise is designing the network architecture for a public web application deployed on Compute Engine instances across multiple Google Cloud regions. The application serves HTTP/HTTPS traffic to a worldwide user base. The design requires routing incoming requests to the closest regional backend and caching static content at Google edge locations to reduce latency. Which TWO Google Cloud components should be planned for this implementation? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Global External Application Load Balancer for multi-region HTTP/HTTPS request distribution; Cloud CDN enabled on backend services to cache static content near end users

Answer

The architectural plan must include the Global External Application Load Balancer and Cloud CDN.
To distribute global HTTP/HTTPS traffic efficiently, a Global External Application Load Balancer acts as a single global IP endpoint that forwards requests to the closest regional backend. Enabling Cloud CDN on its backend services leverages Google's global points of presence (PoPs) to cache static responses and lower overall latency.

Step-by-Step Solution

1
Analyze client locality and application layer protocols.
Traffic originates from public internet clients globally using HTTP/HTTPS (Layer 7).
Selecting the correct load balancer requires matching traffic source (external), reach (global), and layer (Layer 7 HTTP/HTTPS).
2
Select the appropriate Google Cloud load balancing product.
Choose the Global External Application Load Balancer.
This component supports global HTTP/HTTPS ingress and routes users to the nearest available compute backend.
3
Select the caching mechanism to minimize latency for static assets.
Enable Cloud CDN on the load balancer's backend service.
Cloud CDN leverages Google's global edge network to cache HTTP responses close to end users.

Key Concept

Selecting load balancer types and caching mechanisms based on protocol, scope, and caching requirements.
Question 364Question →

A software enterprise is planning the infrastructure for a continuous, mission-critical API gateway on Google Cloud that requires non-standard resource allocation of 10 vCPUs and 40 GB of RAM, running 24 hours a day, 7 days a week. The workload cannot tolerate unexpected interruptions or instance terminations. The finance team mandates the most cost-effective architecture for a guaranteed 3-year commitment. Which deployment strategy should you recommend?

Show answer & explanation

Answer: Provision Compute Engine Virtual Machines using a custom machine type with 10 vCPUs and 40 GB of RAM, and purchase a 3-year Committed Use Discount for the required compute capacity.

Answer

Provision Compute Engine Virtual Machines using a custom machine type with 10 vCPUs and 40 GB of RAM, combined with a 3-year Committed Use Discount.
Configuring a custom machine type with exactly 10 vCPUs and 40 GB of RAM ensures the instance is tailored to the exact workload demand without over-provisioning unused resources. Purchasing a 3-year Committed Use Discount (CUD) maximizes savings for steady-state, 24/7 uninterruptible workloads.

Step-by-Step Solution

1
Analyze workload resource ratio and uninterrupted availability requirements.
The requirement calls for 10 vCPUs and 40 GB of RAM (1:4 ratio), running 24/7 without tolerable downtime.
Matching non-standard ratios avoids paying for wasted vCPUs or RAM present in rigid standard machine types, while uninterrupted requirements eliminate Spot/Preemptible VMs.
2
Evaluate pricing structure options for long-term continuous Compute Engine workloads.
A 3-year Committed Use Discount (CUD) offers the deepest discount for baseline Compute Engine vCPU and memory capacity.
Committed Use Discounts require a commitment of 1 or 3 years and are ideal for steady-state workloads with predictable resource needs.

Key Concept

Custom Machine Types and Committed Use Discounts (CUDs)
Estimated Time:1m 30s
Question 365Question →

Your organization needs to configure an automated lifecycle policy for a Google Cloud Storage bucket used to store audit logs. The policy must automatically transition objects from Standard to Nearline storage after 30 days and permanently delete them after 365 days. You want to accomplish this using the modern Google Cloud CLI. Which approach should you take to deploy this configuration?

Show answer & explanation

Answer: Create a JSON configuration file defining the lifecycle rules with Age conditions and corresponding SetStorageClass and Delete actions, then run gcloud storage buckets update gs://[BUCKET_NAME] --lifecycle-file=[FILE_PATH].

Answer

Create a JSON configuration file defining the lifecycle rules with Age conditions and corresponding SetStorageClass and Delete actions, then run gcloud storage buckets update gs://[BUCKET_NAME] --lifecycle-file=[FILE_PATH].
The correct approach is to create a JSON file defining condition rules (age in days) and actions (SetStorageClass to NEARLINE at 30 days, Delete at 365 days), and update the bucket configuration using gcloud storage buckets update gs://[BUCKET_NAME] --lifecycle-file=[FILE_PATH]. This follows Google-recommended practices using modern gcloud CLI tools.

Step-by-Step Solution

1
Define the Object Lifecycle Management rule in JSON format.
A JSON file containing two rules: one with condition 'age: 30' and action 'SetStorageClass' to 'NEARLINE', and another with condition 'age: 365' and action 'Delete'.
Lifecycle rules require condition matching (such as object age) to trigger automated storage actions.
2
Apply the lifecycle configuration file to the Cloud Storage bucket using the modern CLI tool.
The bucket is updated with the lifecycle management rules using gcloud storage buckets update with the --lifecycle-file flag.
Google Cloud recommends using the gcloud storage CLI command set for deploying bucket lifecycle policies.

Key Concept

Cloud Storage Object Lifecycle Management configuration using gcloud storage
Question 366Question →

An enterprise cloud network engineer is planning network expansion for a custom-mode Virtual Private Cloud (VPC) network on Google Cloud. An application subnet in region `us-east4` currently uses the primary IP range 10.240.16.0/2410.240.16.0/24 and must be expanded to support at least 500 virtual machine instances.

The VPC network and connected environments currently have the following IP address allocations:
- Subnet A (Application subnet to expand): 10.240.16.0/2410.240.16.0/24
- Subnet B (Database subnet in `us-east4`): 10.240.17.0/2410.240.17.0/24
- Subnet C (Analytics subnet in `us-central1`): 10.240.18.0/2310.240.18.0/23
- On-premises data center network (connected via Cloud VPN): 10.240.20.0/2210.240.20.0/22

Which strategy should the network engineer implement to meet the capacity requirement without violating Google Cloud VPC networking constraints?

Show answer & explanation

Answer: Provision a new subnet using the non-overlapping range 10.240.24.0/2310.240.24.0/23 in `us-east4` and migrate the application workloads to the new subnet.

Answer

The network engineer must provision a new subnet using a non-overlapping range such as 10.240.24.0/2310.240.24.0/23 in `us-east4` and migrate the application workloads.
Expanding a primary subnet range in GCP requires contiguous IP space. The current subnet 10.240.16.0/2410.240.16.0/24 expanded to /23/23 covers 10.240.16.010.240.16.0 to 10.240.17.25510.240.17.255. Because 10.240.17.0/2410.240.17.0/24 is already allocated to Subnet B, in-place expansion is rejected by Google Cloud. Therefore, creating a new non-overlapping subnet (such as 10.240.24.0/2310.240.24.0/23) and migrating workloads is the only valid solution.

Step-by-Step Solution

1
Calculate required CIDR prefix length for 500 hosts
A /23/23 subnet provides 2(32−23)=5122^{(32-23)} = 512 total IP addresses (507 usable in GCP), meeting the requirement for 500 instances.
Google Cloud reserves 4 IP addresses per subnet plus 1 broadcast address, so a /24/24 (256 addresses) is insufficient, while a /23/23 (512 addresses) provides enough usable IPs.
2
Evaluate in-place expansion of primary IP range 10.240.16.0/2410.240.16.0/24
Expanding 10.240.16.0/2410.240.16.0/24 to /23/23 produces the range 10.240.16.010.240.16.0–10.240.17.25510.240.17.255.
Subnet expansion in GCP can only decrease the netmask prefix length (making the range larger) while keeping the start IP aligned. The new /23/23 block incorporates 10.240.17.0/2410.240.17.0/24.
3
Check for CIDR collisions within the VPC and hybrid network
10.240.17.0/2410.240.17.0/24 is already assigned to Subnet B in the same VPC. Thus, expanding Subnet A in-place causes an illegal CIDR overlap.
GCP VPC architecture strictly prohibits overlapping primary IP ranges between subnets within the same VPC or connected via VPC Peering / Cloud VPN.
4
Determine the valid alternative architecture
Select an unallocated block such as 10.240.24.0/2310.240.24.0/23 that does not conflict with existing subnets (10.240.16.0/2410.240.16.0/24, 10.240.17.0/2410.240.17.0/24, 10.240.18.0/2310.240.18.0/23) or on-premises ranges (10.240.20.0/2210.240.20.0/22).
When contiguous IP expansion is blocked by adjacent subnets, creating a new disjoint subnet with non-overlapping IP space is the required GCP architectural solution.

Key Concept

VPC Subnet IP Range Expansion Constraints and Overlap Prevention
Question 367Question →

An enterprise architecture team is designing a Virtual Private Cloud (VPC) network in Google Cloud to establish a hybrid connection with an on-premises data center via Cloud VPN. The on-premises network uses the private IP block 172.16.0.0/16. The cloud workload requires deploying standard Compute Engine virtual machines in us-central1 and a Google Kubernetes Engine (GKE) private cluster in us-east1. Which TWO subnet design and IP address planning requirements must be met to ensure valid network routing and prevent IP address collisions?

Select all that apply

Show answer & explanation

Answer: Create the VPC network in custom mode to explicitly define regional subnets and avoid IP address overlap with the on-premises 172.16.0.0/16 range.; Allocate disjoint CIDR blocks for the primary subnet range and the GKE secondary ranges (Pods and Services) in us-east1 that do not overlap each other or the on-premises network.

Answer

The correct requirements are creating the VPC in custom mode to prevent IP overlap with on-premises address spaces, and allocating disjoint CIDR blocks for the primary subnet range and GKE secondary ranges in us-east1.
Custom mode VPCs are necessary when integrating with hybrid networks because they allow administrators to explicitly define subnet CIDRs, avoiding collisions with on-premises ranges such as 172.16.0.0/16. Additionally, GKE private clusters mandate that secondary IP ranges assigned to Pods and Services must be non-overlapping, distinct CIDR blocks separate from the primary subnet CIDR and any hybrid connected networks.

Step-by-Step Solution

1
Evaluate VPC creation mode for hybrid network integration.
Custom mode VPC network must be selected.
Auto-mode VPCs automatically generate subnets in every region using fixed IP ranges (10.128.0.0/9), which can conflict with on-premises RFC 1918 ranges such as 172.16.0.0/16.
2
Plan IP address allocation for GKE workloads and Compute Engine instances.
Distinct IP ranges are assigned for primary subnets and GKE alias IP secondary ranges.
GKE private clusters require separate secondary IP ranges for Pods and Services. These secondary ranges must be non-overlapping with each other, the primary subnet CIDR, and connected on-premises IP space.

Key Concept

Custom Mode VPC Design and GKE Secondary IP Range Allocation
Question 368Question →

A data engineering team is deploying a high-throughput, fault-tolerant batch processing pipeline to Google Kubernetes Engine (GKE). The batch worker pods are stateless and can tolerate immediate termination when compute capacity is reclaimed. However, the cluster must also host a stateful database service that requires uninterrupted availability and persistent disk storage to prevent data corruption. To optimize operational costs while guaranteeing stability for the critical component, which cluster deployment strategy should be implemented?

Show answer & explanation

Answer: Provision a GKE Standard cluster with separate node pools: a Spot VM node pool with node selectors and tolerations for batch workers, and a standard node pool for the stateful database.

Answer

Provision a GKE Standard cluster with separate node pools: a Spot VM node pool with node selectors and tolerations for batch workers, and a standard node pool for the stateful database.
GKE Standard clusters support multiple heterogeneous node pools. Placing fault-tolerant batch workloads on a Spot VM node pool drastically reduces compute costs, while placing the stateful database on a standard node pool protects it from sudden preemption.

Step-by-Step Solution

1
Analyze the availability and resilience requirements of each workload component.
Identified batch workers as fault-tolerant (stateless) and the database service as critical and non-fault-tolerant (stateful).
Spot VMs offer significant cost savings but are subject to sudden preemption, making them ideal for stateless batch jobs but dangerous for stateful systems.
2
Evaluate GKE node pool configuration options to isolate compute properties.
GKE Standard allows creating multiple node pools with distinct machine types and provisioning models (Spot vs. Standard).
Dedicated node pools ensure that specific workloads only run on hardware meeting their operational criteria.
3
Apply Kubernetes scheduling constraints (nodeSelectors, taints, and tolerations).
Batch worker pods target the Spot VM node pool via nodeSelectors and tolerations, while database pods schedule onto standard nodes.
Prevents critical database pods from landing on Spot nodes while allowing batch workloads to leverage cheaper capacity.

Key Concept

Workload Isolation with GKE Node Pools and Spot VMs
Question 369Question →

A cloud engineer needs to configure an automated deployment script running on a fresh administrative workstation to deploy a microservice workload to a newly provisioned Google Kubernetes Engine (GKE) Standard cluster. Arrange the required administrative and operational steps in the correct chronological sequence from initial environment configuration to verifying successful pod rollout.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with configuring default CLI project and region properties via `gcloud config set`, followed by generating cluster credentials with `gcloud container clusters get-credentials`. Next, cluster reachability is confirmed using `kubectl get nodes`, after which the application manifest is deployed via `kubectl apply -f deployment.yaml`. Finally, deployment success is confirmed using `kubectl rollout status deployment/<deployment-name>`.
Deploying workloads to a GKE cluster follows a strict prerequisite hierarchy: first set CLI defaults (`gcloud config set`), generate the cluster API kubeconfig authentication entry (`gcloud container clusters get-credentials`), validate cluster node connectivity (`kubectl get nodes`), submit workload manifests (`kubectl apply`), and finally verify pod execution (`kubectl rollout status`).

Step-by-Step Solution

1
Set CLI target environment variables and context.
The local `gcloud` tool points to the correct GCP Project ID and Compute Region.
Prevents credential retrieval commands from failing or targeting clusters in wrong projects/zones.
2
Execute `gcloud container clusters get-credentials CLUSTER_NAME --region REGION`.
The local `kubeconfig` context is updated with cluster API server endpoint addresses and short-lived IAM credentials.
`kubectl` cannot issue requests to a GKE cluster without a valid context entry in `kubeconfig`.
3
Run `kubectl get nodes` to test control plane access.
The cluster returns a list of worker nodes and their current status (e.g., `Ready`).
Verifies that IAM permissions, network routing, and API server authentication are fully functional prior to workload submission.
4
Execute `kubectl apply -f deployment.yaml`.
Kubernetes manifest specifications are parsed and applied to create Deployment and ReplicaSet objects.
Declaratively initiates pod scheduling and container provisioning within the cluster.
5
Run `kubectl rollout status deployment/<deployment-name>`.
The command tracks pod creation until all desired replicas pass readiness probes and reach the `Running` state.
Confirms deployment completion and flags any image pull or initialization errors.

Key Concept

Google Kubernetes Engine Workload Deployment and Lifecycle Management Workflow
Question 370Question →

A global enterprise is designing a multi-region Google Cloud Virtual Private Cloud (VPC) network to connect workloads in us−central1us-central1 and europe−west1europe-west1 to two existing on-premises datacenters (10.100.0.0/1610.100.0.0/16 and 10.200.0.0/1610.200.0.0/16) via Cloud VPN. To prevent IP address exhaustion and ensure future subnet expansion can occur seamlessly without routing conflicts, which TWO architecture and design decisions must the cloud network engineer enforce during initial VPC creation?

Select all that apply

Show answer & explanation

Answer: Provision the VPC network in custom mode and manually assign explicit, non-overlapping regional primary IP ranges.; Reserve contiguous unused IP address blocks adjacent to primary subnet ranges to allow expand-in-place operations.

Answer

The correct architecture decisions are to provision the VPC network in custom mode with explicit non-overlapping regional primary IP ranges, and to reserve contiguous unused IP space adjacent to primary subnets for future expansion.
Custom-mode VPC networks give network architects full control over IP CIDR range allocation, ensuring that Google Cloud subnets do not conflict with on-premises CIDRs. Furthermore, leaving contiguous unused IP space adjacent to primary subnets ensures that subnets can be expanded in place without causing address overlap.

Step-by-Step Solution

1
Analyze network mode requirements for enterprise hybrid connectivity.
Auto-mode VPC networks allocate predefined /20/20 subnets in every region from 10.128.0.0/910.128.0.0/9, creating high risk of IP overlap with internal networks. Custom mode must be used for enterprise hybrid deployments.
Custom mode allows precise specification of subnet CIDR blocks to avoid conflicts with on-premises ranges such as 10.100.0.0/1610.100.0.0/16 and 10.200.0.0/1610.200.0.0/16.
2
Evaluate expansion constraints for VPC subnets.
Subnet expansion in GCP requires expanding the netmask of the existing primary CIDR block (e.g., from /24/24 to /23/23).
If adjacent IP address space is already assigned to another subnet or network resource, expanding the netmask will fail due to CIDR overlap.

Key Concept

Planning Custom Mode VPC Networks and Subnet CIDR Allocation for Hybrid Architecture
Estimated Time:2m 0s
Question 371Question →

Match each Google Cloud storage or database requirement to its appropriate Google Cloud service or disk type.

Click a left item, then click its matching right item

Items

High-performance, ephemeral block storage physically attached to the VM host server for microsecond latency requirements
Fully managed relational database providing global scale, multi-region consistency, and ACID transactions
High-throughput NoSQL wide-column database optimized for large-scale analytical and real-time key-value data
Standard durable network-attached block storage suitable for low-cost sequential workload data volumes

Matches

Show answer & explanation

Answer

Local SSD matches high-performance ephemeral block storage; Cloud Spanner matches global multi-region relational ACID requirements; Cloud Bigtable matches high-throughput NoSQL key-value data; Standard Persistent Disk (pd-standard) matches low-cost sequential block storage.
Each GCP database service and block storage option caters to distinct latency, persistence, scalability, and consistency models: Local SSD provides maximum IOPS with ephemeral host-attached disk; Cloud Spanner delivers globally scalable relational transactions; Cloud Bigtable supports ultra-high-throughput NoSQL operations; and Standard Persistent Disk provides low-cost network-attached HDD block storage.

Step-by-Step Solution

1
Analyze storage performance and lifespan requirements
Identify that physically attached disk storage with microsecond latency corresponds to Local SSD.
Local SSD provides the highest IOPS and lowest latency by residing on the physical host, though data does not persist past instance termination.
2
Evaluate relational vs NoSQL database architecture limits
Map global multi-region relational ACID needs to Cloud Spanner, and high-throughput key-value/wide-column data to Cloud Bigtable.
Cloud Spanner is designed for enterprise global relational workloads, while Cloud Bigtable handles non-relational heavy write/read throughput.
3
Identify block storage persistent disk performance tier
Map cost-effective HDD sequential access requirements to Standard Persistent Disk (pd-standard).
Standard Persistent Disk relies on HDDs providing cost-effective network storage for sequential access scenarios.

Key Concept

Selecting GCP Database and Storage Products Based on Workload Requirements
Question 372Question →

An administrator needs to deploy a Cloud Storage bucket for log archiving and configure a lifecycle management policy using the Google Cloud CLI (`gcloud storage`). Place the following steps in the correct execution order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Create the local lifecycle JSON file, 2) Provision the Cloud Storage bucket with `gcloud storage buckets create`, 3) Apply the lifecycle configuration to the bucket using `gcloud storage buckets update`, and 4) Upload objects to the configured bucket using `gcloud storage cp`.
Deploying a configured storage bucket requires creating the prerequisite configuration files, provisioning the bucket resource via CLI, binding the lifecycle rules file to the bucket resource, and finally populating the bucket with objects.

Step-by-Step Solution

1
Define lifecycle policy rules locally in a JSON file.
A valid `lifecycle.json` file is prepared with specified actions and conditions.
Lifecycle updates using the CLI require a reference file containing the policy definition.
2
Create the bucket resource.
The bucket `gs://my-log-archive-bucket` is instantiated in `us-central1`.
Configurations cannot be applied to a non-existent bucket.
3
Apply the lifecycle JSON policy to the newly deployed bucket.
The bucket lifecycle configuration is set.
Attaching the policy before object ingestion ensures incoming files immediately fall under lifecycle management.
4
Copy target objects into the Cloud Storage bucket.
Objects are stored in the bucket and subject to the configured lifecycle rules.
Data upload occurs after infrastructure provisioning and rule binding.

Key Concept

Cloud Storage Bucket Provisioning and Lifecycle Rule Configuration
Question 373Question →

A cloud administrator needs to configure a new management workstation to connect to an existing Google Kubernetes Engine (GKE) cluster named `app-cluster` in region `us-central1` and deploy a stateless web microservice onto a dedicated Spot node pool. Which TWO actions must the administrator perform? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Execute `gcloud container clusters get-credentials app-cluster --region us-central1` to generate cluster authentication credentials in the local kubeconfig file.; Add a `nodeSelector` or node affinity configuration to the Deployment manifest targeting the Spot node pool labels.

Answer

The administrator must fetch cluster credentials using the `gcloud container clusters get-credentials` command and configure a `nodeSelector` or node affinity in the Deployment manifest targeting the Spot node pool.
To manage a GKE cluster with kubectl, authentication credentials must be fetched into the local environment using `gcloud container clusters get-credentials`. For deploying stateless workloads to specific node pools such as Spot pools, specifying a `nodeSelector` or node affinity rules in the Deployment manifest ensures pods are scheduled onto the designated nodes.

Step-by-Step Solution

1
Authenticate kubectl with the GKE cluster
Local kubeconfig file updated with cluster API credentials and endpoint details.
kubectl requires active cluster context credentials to submit deployment requests.
2
Target the workload to the Spot node pool
Deployment spec includes matching nodeSelector key-value labels for the Spot node pool.
Kubernetes scheduler uses node selectors to assign stateless pod replicas to specific node pools.

Key Concept

GKE Cluster Credential Retrieval and Workload Scheduling on Spot Node Pools
Estimated Time:1m 30s
Question 374Question →

A cloud architect is planning to expand an existing primary subnet CIDR range in a custom-mode Virtual Private Cloud (VPC) that is connected to an on-premises data center via Cloud VPN. To ensure uninterrupted connectivity and prevent IP routing conflicts across the hybrid environment, in what sequence should these steps be executed?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps is: 1) Audit existing on-premises IP subnets and active GCP network ranges to identify available contiguous CIDR blocks. 2) Select an expanded primary subnet CIDR block (e.g., expanding from /24 to /22) that completely contains the original range and avoids on-premises routes. 3) Execute the subnet IP range expansion operation to update the primary IP address range of the subnet. 4) Update Cloud Router BGP advertisements or on-premises static routes to propagate the expanded subnet prefix across the VPN.
The correct sequence follows a logical lifecycle for hybrid cloud networking: first audit existing address space to prevent overlaps, next select a valid expanded CIDR block that encompasses the original range, then perform the actual subnet expansion in GCP, and finally update hybrid BGP or static routes so the on-premises network can reach the newly expanded address range.

Step-by-Step Solution

1
Audit current hybrid network address space
Identified available non-overlapping CIDR space in both GCP and on-premises environments.
Prevents IP collisions between on-premises subnets and newly allocated GCP addresses.
2
Plan the target CIDR block for expansion
Selected a broader netmask (e.g., /22) that encompasses the current primary range (e.g., /24).
GCP subnet expansion rules require that the existing subnet range must be a subset of the new expanded range.
3
Apply the IP range expansion to the primary subnet
GCP updates the primary IP range for the subnet without destroying existing resources.
Modifies the subnet definition in GCP live environment without causing VM downtime.
4
Update hybrid routing configurations
On-premises networks are notified of the expanded IP range via BGP or updated static routes.
Ensures return traffic from on-premises to newly provisioned IPs in the expanded subnet range is routed correctly.

Key Concept

Planning and expanding GCP VPC subnets in a hybrid environment requires verifying CIDR non-overlap, adhering to GCP expansion rules (must encompass original range), applying the expansion, and updating hybrid BGP/static routing.
Estimated Time:1m 30s
Question 375Question →

An organization is decommissioning a legacy application hosted in Google Cloud. An Associate Cloud Engineer attempts to shut down the project using the gcloud command-line tool, but the command fails with an error indicating that the project cannot be deleted because a lien exists on the resource. Which action should the engineer take to resolve this issue and successfully shut down the project?

Show answer & explanation

Answer: Identify and delete the active lien placed on the project before re-executing the project deletion command.

Answer

Identify and delete the active lien placed on the project before re-executing the project deletion command.
In Google Cloud, project liens prevent accidental project deletion. When a lien is active on a project, any attempt to shut down or delete the project fails until an authorized user removes the lien object.

Step-by-Step Solution

1
Inspect active liens on the project.
List the project liens using `gcloud alpha liens list` or the Resource Manager API.
Liens block project deletion requests to prevent accidental destruction of critical resources.
2
Delete the specific lien object.
Execute `gcloud alpha liens delete [LIEN_ID]` to remove the lifecycle lock.
A project cannot enter the 30-day shutdown phase while an active lien is attached.
3
Re-run the project shutdown command.
Execute `gcloud projects delete [PROJECT_ID]` successfully.
Once all liens are removed, standard project deletion permissions apply.

Key Concept

Project Lifecycle Management and Project Liens
Estimated Time:1m 30s
Question 376Question →

A DevOps engineering lead is deploying an automated machine learning batch inference pipeline in a Google Cloud project named `ml-inference-prod`. The workload requires scaling Compute Engine instances across multiple zones in the `europe-west1` region, requiring a total of 256 N2 CPUs. When executing the infrastructure deployment, the process fails with a quota exceeded error indicating that the current regional N2 CPU limit is capped at 64. What is the correct procedure to resolve this limitation and allow the deployment to proceed?

Show answer & explanation

Answer: Submit a quota increase request for N2 CPUs in `europe-west1` via the Quotas section in the Google Cloud Console, specifying 256 as the requested limit along with a business justification.

Answer

Submit a quota increase request for N2 CPUs in europe-west1 via the Quotas section in the Google Cloud Console, specifying 256 as the requested limit along with a business justification.
Resource quotas enforce hard limits on GCP resource usage per project and region. To exceed standard quota boundaries, an explicit quota increase request must be submitted via the Quotas page in the Google Cloud Console or using the Cloud Quotas API, providing appropriate justification.

Step-by-Step Solution

1
Identify the cause of the deployment failure.
The failure is due to a regional resource quota constraint (64 N2 CPUs available vs. 256 required) in the `europe-west1` region for project `ml-inference-prod`.
Google Cloud enforces regional quotas per project to prevent accidental resource over-provisioning.
2
Select the appropriate administrative tool and workflow for quota management.
Access the IAM & Admin > Quotas page in the Google Cloud Console and locate the N2 CPUs metric for `europe-west1`.
Quota limits must be adjusted explicitly through Google Cloud quota administration workflows.
3
Submit an official quota increase request.
Specify the required new limit of 256 CPUs and provide a clear business rationale for evaluation by Google Cloud approval systems.
Submitting a formal request with proper justification is the standard mechanism to permanently increase GCP resource limits.

Key Concept

Managing and Requesting GCP Resource Quotas
Estimated Time:1m 30s
Question 377Question →

A cloud governance specialist at an e-commerce organization needs to set up a new isolated Google Cloud project `vendor-audit-2026` for an external compliance audit team and link it to the organization's central billing account (`012345-6789AB-CDEF01`). Place the operational steps in the correct chronological order to create the project, link the billing account using least-privilege permissions, and verify the billing association.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with granting the necessary least-privilege IAM permissions (`roles/resourcemanager.projectCreator` on the parent folder and `roles/billing.user` on the Billing Account), followed by creating the project (`gcloud projects create`), linking the billing account (`gcloud beta billing projects link`), and finally verifying the configuration (`gcloud beta billing projects describe`).
The workflow follows a standard admin lifecycle: prerequisite access check/grant (IAM verification), resource provision (project creation), binding resource to billing account (linking), and state verification (describing billing status). Linking a project to a billing account specifically requires `roles/billing.user` on the billing account and `resourcemanager.projects.createBillingAssignment` (contained in `roles/billing.user` or Project Owner/Editor).

Step-by-Step Solution

1
Ensure necessary IAM permissions are assigned.
The identity has `roles/resourcemanager.projectCreator` on the folder and `roles/billing.user` on the Billing Account.
Without these permissions, subsequent `gcloud` commands for project creation or billing linking will fail due to access denied errors.
2
Execute project creation command.
The unlinked project `vendor-audit-2026` is created in the specified resource hierarchy folder.
A project entity must be provisioned before a billing account can be attached to it.
3
Link the project to the central Billing Account.
The project `vendor-audit-2026` is attached to billing account `012345-6789AB-CDEF01`.
Linking billing allows resources created inside the project to consume paid GCP services.
4
Verify billing status via CLI.
Output shows `billingAccountName: billingAccounts/012345-6789AB-CDEF01` and `billingEnabled: true`.
Verification confirms that project setup was successful and billing is actively enabled.

Key Concept

Least-privilege billing account linking requires Billing Account User (`roles/billing.user`) on the billing account and Project Creator (`roles/resourcemanager.projectCreator`) on the parent folder/organization prior to project creation and linking commands.
Question 378Question →

A global gaming enterprise stores player match replay files in Google Cloud Storage. Telemetry and replay files are accessed heavily by players and analytics pipelines during the first 30 days after creation. Between 31 and 90 days, files are occasionally accessed by support teams investigating reports. After 90 days, the files are rarely accessed but must be retained for 3 years for compliance before being deleted.

Which TWO design decisions should the cloud architecture team implement to minimize total storage and retrieval costs while meeting access requirements?

Select all that apply

Show answer & explanation

Answer: Set the default storage class of the Cloud Storage bucket to Standard Storage.; Configure Object Lifecycle Management rules to transition objects to Nearline Storage after 30 days and to Archive Storage after 90 days.

Answer

To optimize costs and satisfy access requirements, the bucket should use Standard Storage as its default class and apply Object Lifecycle Management rules that transition objects to Nearline Storage after 30 days and to Archive Storage after 90 days.
Selecting Standard Storage as the initial bucket default ensures zero retrieval fees during the high-access first 30 days. Setting lifecycle rules to transition objects to Nearline Storage at day 30 and Archive Storage at day 90 aligns each storage tier with actual access frequency, minimizing total cost of ownership while avoiding early deletion and retrieval penalties.

Step-by-Step Solution

1
Analyze access patterns for the first 30 days.
Heavy access during initial 30 days requires zero retrieval fees and no minimum storage duration.
Standard Storage delivers high performance for active workloads without incurring retrieval penalties.
2
Analyze access patterns for days 31 to 90.
Occasional access (once a month or less) aligns with Nearline Storage.
Nearline Storage reduces storage costs per gigabyte while offering fast access for data read less than once per month.
3
Analyze long-term compliance retention requirements beyond 90 days.
Data accessed less than once a year and retained for 3 years aligns with Archive Storage.
Archive Storage offers the lowest per-gigabyte cost for long-term cold data retention.

Key Concept

Selecting initial storage classes and designing multi-tier lifecycle transitions based on access frequency and retrieval cost trade-offs.
Question 379Question →

Your organization has a Google Cloud folder named 'Analytics' containing multiple projects with Cloud Storage buckets storing raw telemetry data. A new data analyst needs to read all objects within these Cloud Storage buckets across all projects under the 'Analytics' folder. Additionally, the analyst must be able to execute BigQuery queries using a specific project named 'query-runner' located within the same folder, without having permissions to modify data, alter bucket configurations, or view IAM policy bindings. Which combination of IAM roles assigned to the data analyst follows Google-recommended best practices of least privilege?

Show answer & explanation

Answer: Grant Storage Object Viewer (roles/storage.objectViewer) on the 'Analytics' folder, and grant BigQuery Job User (roles/bigquery.jobUser) on the 'query-runner' project.

Answer

Grant Storage Object Viewer (roles/storage.objectViewer) on the 'Analytics' folder, and grant BigQuery Job User (roles/bigquery.jobUser) on the 'query-runner' project.
Granting Storage Object Viewer on the parent folder allows read access to all storage objects across child projects via resource hierarchy inheritance, while avoiding administrative access. Granting BigQuery Job User specifically on the query-running project enables running queries without granting dataset modification rights. This combination strictly enforces the principle of least privilege using predefined roles.

Step-by-Step Solution

1
Analyze the access requirement for reading Cloud Storage objects across all projects under the folder.
Determine that granting a role at the folder level allows IAM policy inheritance down to all projects and buckets within that folder.
Resource hierarchy inheritance ensures consistent access across all present and future projects in the folder.
2
Select the appropriate role for reading storage objects without admin or edit permissions.
Choose the predefined role Storage Object Viewer (roles/storage.objectViewer).
Predefined roles are preferred over primitive roles (like Viewer) to enforce least privilege.
3
Determine the necessary permission for executing BigQuery jobs in the target project.
Choose BigQuery Job User (roles/bigquery.jobUser) on the 'query-runner' project.
This role allows running query jobs in the project without granting unnecessary data editing or administrative permissions.

Key Concept

Resource hierarchy inheritance and predefined roles for least privilege
Estimated Time:2m 0s
Question 380Question →

An organization is planning to deploy a stateless HTTP microservice to Google Cloud. The application requires a custom system library compiled into a custom Linux container image and must handle up to 80 concurrent HTTP requests per container instance to optimize resource utilization and reduce cost during peak load. Which Google Cloud serverless compute option should you select to fulfill these architectural requirements?

Show answer & explanation

Answer: Deploy the custom container image to Cloud Run and configure the concurrency setting to 80.

Answer

Deploying the custom container image to Cloud Run while configuring maximum concurrency to 80 meets all requirements for custom binary container support and concurrent request handling.
Cloud Run is designed to execute stateless container images invoked via HTTP requests. It allows developers to deploy arbitrary container images containing custom system dependencies and supports serving multiple concurrent requests (up to 1000 per instance, default 80) on a single container instance.

Step-by-Step Solution

1
Analyze containerization and runtime requirements
The application requires a custom system library packaged into a custom Linux container image.
Cloud Run supports any custom container image listening on the HTTP PORT environment variable.
2
Evaluate concurrency requirements
The workload requires processing up to 80 concurrent HTTP requests per container instance.
Cloud Run allows configuring concurrency (up to 1000 requests per instance), enabling cost optimization and high throughput per instance.
3
Select the optimal serverless option
Cloud Run provides serverless container execution with multi-concurrency support out of the box.
Cloud Functions (1st gen) is limited to single-request concurrency per instance and standard language runtimes.

Key Concept

Cloud Run Concurrency and Custom Container Support
Estimated Time:1m 30s
PreviousPage 19 / 80Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin