Examkin

All practice questions

262 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 41Question →

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 42Question →

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 43Question →

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 44Question →

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 45Question →

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

1
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.
2
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.
3
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.
4
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 46Question →

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

1
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.
2
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.
3
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.
4
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 47Question →

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

1
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.
2
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.
3
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.
4
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 48Question →

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

1
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.
2
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.
3
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.
4
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.
5
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 49Question →

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

1
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.
2
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.
3
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.
4
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 50Question →

A cloud engineer needs to configure a local command-line environment and deploy a containerized application to an existing Google Kubernetes Engine (GKE) cluster. In what sequential order should the engineer execute these tasks from start to finish?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with setting the gcloud project context, fetching the GKE cluster credentials into kubeconfig, validating cluster access with kubectl cluster-info, and finally deploying the application manifest with kubectl apply.
The deployment process requires setting the project context first so gcloud references the correct project. Next, generating local credentials populates kubeconfig, establishing a valid context for kubectl. Validating connection via cluster-info verifies the setup. Finally, applying the manifest submits the workload definition to the GKE control plane.

Step-by-Step Solution

1
Set the active GCP project
The CLI is configured to target the correct project.
Before executing cluster operations, gcloud must point to the project hosting the GKE cluster.
2
Run gcloud container clusters get-credentials
Local kubeconfig is populated with API endpoint and auth token/certificates.
kubectl requires local credentials and control plane address to interact with GKE.
3
Execute kubectl cluster-info
Control plane health and endpoint details are displayed.
Validating connection prevents deployment errors caused by targeting an incorrect or unreachable cluster.
4
Run kubectl apply -f deployment.yaml
Workload resources (Pods, Deployments, Services) are created on the cluster.
Deployment manifests can only be successfully submitted once authentication and cluster context are established.

Key Concept

Configuring local CLI tools (gcloud and kubectl) to access and manage GKE clusters
Estimated Time:1m 30s
Question 51Question →

A Cloud Engineer must deploy a secure Google Cloud Storage bucket named `fin-secure-records-2026` in the `us-central1` region to store sensitive financial documents. The deployment requires configuring Customer-Managed Encryption Keys (CMEK) using a pre-existing Cloud KMS key, enabling Object Versioning to retain historical file modifications, and populating the bucket with initial record files. What is the correct sequence of steps to configure and populate this Cloud Storage solution using the Google Cloud CLI?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins by granting the Cloud Storage Service Agent the Cloud KMS CryptoKey Encrypter/Decrypter role on the KMS key, followed by creating the bucket with the default CMEK key specified, updating the bucket to enable Object Versioning, and finally uploading the files using `gcloud storage cp`.
Configuring CMEK on a Google Cloud Storage bucket requires granting the Cloud Storage service account the `roles/cloudkms.cryptoKeyEncrypterDecrypter` role on the KMS key first. Next, the bucket is provisioned using `gcloud storage buckets create` with the `--default-encryption-key` parameter. Object Versioning is then enabled via `gcloud storage buckets update --versioning`. Finally, files are copied into the fully configured bucket using `gcloud storage cp`.

Step-by-Step Solution

1
Authorize the service account on the encryption key
Cloud Storage Service Agent gains permission to perform encryption/decryption operations with the Cloud KMS key.
If the service agent lacks the CryptoKey Encrypter/Decrypter role prior to bucket setup or object upload, default CMEK bucket operations will fail authorization checks.
2
Provision the Cloud Storage bucket with CMEK
The target bucket `gs://fin-secure-records-2026` is created in `us-central1` with default CMEK settings.
The bucket infrastructure must be created before applying post-creation feature updates or uploading data objects.
3
Enable Object Versioning on the bucket
Object Versioning is active for all future object writes and overwrites.
Enabling versioning after bucket creation ensures that all subsequent upload and modification operations retain version history.
4
Upload objects using `gcloud storage cp`
Files from `./records/*` are copied to `gs://fin-secure-records-2026/` and automatically encrypted with CMEK.
Object ingestion is performed last so that uploaded files inherit both default CMEK encryption and version protection.

Key Concept

Deploying Cloud Storage Buckets with CMEK, Object Versioning, and gcloud storage CLI
Estimated Time:1m 30s
Question 52Question →

A cloud network engineering team is planning to expand an existing primary subnet CIDR block within a custom-mode Virtual Private Cloud (VPC) network to accommodate business growth. The VPC network connects to on-premises data centers via Cloud VPN and is scheduled to establish a VPC Network Peering connection with a partner organization. What is the correct sequence of steps to properly plan, validate, and execute this primary subnet range expansion without causing network outages or IP address range conflicts?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct procedural order is: 1) Audit existing IP address allocations across local, hybrid, and peered environments; 2) Calculate the expanded CIDR prefix complying with bit boundary alignment; 3) Execute the non-disruptive subnet expansion operation in Google Cloud; 4) Update routing advertisements and firewall rules to accommodate the new host address space.
Subnet expansion in an enterprise GCP environment requires a structured progression: first, auditing all existing and planned connected networks (hybrid VPN and VPC Peering) prevents catastrophic IP address collisions. Second, determining a bit-boundary aligned expanded mask ensures compliance with GCP subnet rules. Third, expanding the subnet in GCP is performed as a non-disruptive live configuration update. Fourth, downstream security rules and Cloud Router BGP advertisements must be updated to ensure end-to-end connectivity across the new host range.

Step-by-Step Solution

1
Perform IP allocation audit across connected environments
Identified contiguous, unallocated IP blocks and confirmed zero overlap with hybrid VPN routes or planned VPC Network Peering CIDRs.
VPC Network Peering and Cloud VPN require completely disjoint IP ranges; attempting to expand a subnet into an already allocated or advertised range breaks routing and causes peering establishment failures.
2
Define valid expanded subnet CIDR notation
Calculated a valid expanded range (e.g., 10.10.0.0/2410.10.0.0/24 expanding to 10.10.0.0/2310.10.0.0/23) that encompasses the existing base address.
Google Cloud VPC primary subnets can only be expanded to a larger prefix length (smaller mask number) without changing the network starting address, ensuring bit-boundary alignment.
3
Apply subnet expansion in Google Cloud
The primary IP range of the active subnet is updated seamlessly while running Compute Engine virtual machines maintain active connections.
GCP supports online, zero-downtime subnet CIDR expansion without deleting resources or interrupting current workload IP bindings.
4
Synchronize network security and routing policies
Cloud Routers advertise the new netmask over BGP, and VPC firewall rules permit traffic across the expanded IP space.
Expanding the subnet definition in the VPC control plane does not automatically grant external or cross-premises access unless BGP routes and firewall filters encompass the extended block.

Key Concept

VPC Subnet Expansion & Non-Overlapping IP Planning
Estimated Time:2m 0s
Question 53Question →

A cloud engineer needs to establish a new Google Kubernetes Engine (GKE) environment and deploy a containerized microservice application from scratch using the Google Cloud CLI and `kubectl`. Arrange the following operational steps in the correct chronological sequence required to provision the infrastructure, configure local authentication context, deploy the workload, and verify successful deployment.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with provisioning the GKE cluster using `gcloud container clusters create`, followed by fetching credentials into `kubeconfig` via `gcloud container clusters get-credentials`, verifying cluster control plane access using `kubectl get nodes`, applying the application manifest with `kubectl apply -f deployment.yaml`, and finally confirming workload health using `kubectl rollout status deployment/web-app`.
Deploying workloads to Google Kubernetes Engine follows a logical multi-step workflow. First, cluster infrastructure must be provisioned (`gcloud container clusters create`). Second, administrative authentication credentials must be written to the local workstation context (`gcloud container clusters get-credentials`). Third, connectivity to the Kubernetes API server must be validated (`kubectl get nodes`). Fourth, the application workload definition must be submitted (`kubectl apply -f`). Finally, workload availability must be confirmed by checking rollout progress (`kubectl rollout status`).

Step-by-Step Solution

1
Execute `gcloud container clusters create` with appropriate networking and node pool specifications.
GKE control plane and worker node pools are created in Google Cloud.
Infrastructure creation is the mandatory prerequisite before cluster operations can occur.
2
Run `gcloud container clusters get-credentials [CLUSTER_NAME] --zone [ZONE]`.
Local `~/.kube/config` file is populated with cluster API endpoints and authentication tokens.
`kubectl` relies on `kubeconfig` entries to direct commands to the correct Kubernetes control plane.
3
Execute `kubectl get nodes` to test cluster access.
A list of healthy GKE worker nodes and their statuses is returned in stdout.
Verifying connectivity prevents silent deployment failures caused by invalid authentication context.
4
Run `kubectl apply -f deployment.yaml` targeting the application manifest.
Kubernetes API server processes the specification and creates the Deployment resource.
Submitting the manifest initiates Pod scheduling and container creation across available cluster nodes.
5
Execute `kubectl rollout status deployment/web-app` to monitor deployment progress.
Command completes successfully when all replicas are running and ready.
Validating rollout completion confirms that image retrieval, volume mounts, and readiness probes succeeded.

Key Concept

GKE Workload Lifecycle and Command Sequence
Question 54Question →

A cloud engineer needs to set up a new Google Cloud Storage bucket for an analytics project, grant read permissions to a designated service account, and upload an initial data file. In what sequence should the engineer execute these operational steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: first create the Cloud Storage bucket, next grant the IAM role to the service account, and finally upload the dataset file to the bucket.
Infrastructure provisioning follows a strict order of dependencies: create the bucket container first, configure access governance by applying IAM policy bindings second, and copy objects into the secured bucket last.

Step-by-Step Solution

1
Provision the destination bucket resource.
The Cloud Storage bucket gs://analytics-data-2026 is created in region us-central1.
A storage bucket must exist before any IAM policies can be attached to it or objects stored within it.
2
Attach the IAM policy binding to the bucket.
The service account is assigned the roles/storage.objectViewer role on the bucket.
Configuring access controls prior to populating objects ensures that authorized applications can read data immediately upon upload.
3
Copy the data file to the bucket.
The object sales_report.csv is uploaded into gs://analytics-data-2026/.
Object ingestion is executed once the destination container and permissions are fully established.

Key Concept

Deployment lifecycle sequence for provisioning Cloud Storage buckets, securing them with IAM roles, and uploading objects.
Estimated Time:1m 0s
Question 55Question →

A cloud engineer is preparing to integrate a Google Cloud environment with an on-premises network via Cloud VPN. The current GCP deployment uses an auto-mode Virtual Private Cloud (VPC) network. To prevent future IP CIDR collisions with on-premises subnets and gain control over subnet creation, the engineer must convert the auto-mode VPC to a custom-mode VPC and provision a new subnet in a new region. What is the correct sequence of steps to execute this migration safely?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with auditing existing network IP space for conflicts, followed by converting the VPC network from auto to custom mode, then planning a unique non-overlapping CIDR block for the target region, and finally creating the new custom subnet.
To safely transition a GCP VPC for hybrid connectivity, an engineer must first audit existing IP allocations against on-premises routes to identify potential conflicts. Next, the VPC network mode must be converted from auto to custom mode, which retains existing subnets while granting administrative control over future subnet creation. After conversion, the engineer plans a distinct, non-overlapping CIDR block for the new region, and finally provisions the new custom subnet using that range.

Step-by-Step Solution

1
Audit current IP address space against on-premises routes.
Identified any potential IP collisions before modifying VPC architecture.
Existing subnets must be validated first so active traffic is not disrupted when establishing hybrid connectivity.
2
Convert the VPC network from auto mode to custom mode.
The VPC network is switched to custom mode, preserving existing subnets while disabling automatic subnet creation in new regions.
Auto-mode VPCs automatically create subnets with fixed /20 CIDR blocks in every region, which often overlap with enterprise networks.
3
Plan a non-overlapping IP range for the new region.
A specific, non-colliding CIDR block is allocated for the target expansion region.
Custom-mode VPCs require explicit IP range planning to support scalable hybrid networking.
4
Provision the custom subnet using the planned CIDR block.
The new custom subnet is created and ready to host workloads in the specified region.
Subnets can only be custom created after the VPC network mode has been updated to custom.

Key Concept

Converting Auto-Mode VPC to Custom-Mode VPC for Hybrid Network Planning
Question 56Question →

A cloud security administrator at a healthcare software firm needs to enable a lead developer to provision a new isolated Google Cloud project named `hc-analytics-prod` and associate it with the company's central Cloud Billing account under the principle of least privilege. What is the correct sequence of administrative and operational steps required to grant permissions and complete the project billing configuration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order begins with granting the Project Creator role at the folder/organization level, followed by granting the Billing Account User role on the billing account, then creating the GCP project via CLI, and finally linking the project to the billing account.
Establishing a new project and linking it to billing under least privilege requires granting `roles/resourcemanager.projectCreator` on the parent folder/org and `roles/billing.user` on the Cloud Billing account prior to creating the project (`gcloud projects create`) and linking it (`gcloud billing projects link`).

Step-by-Step Solution

1
Assign the Project Creator (`roles/resourcemanager.projectCreator`) role on the parent Folder or Organization resource.
The target identity gains permission to invoke `resourcemanager.projects.create`.
Permissions must be configured prior to executing CLI provisioning commands.
2
Assign the Billing Account User (`roles/billing.user`) role on the target Cloud Billing account.
The target identity receives `billing.resourceAssociations.create` authority on the billing resource.
Linking a project to a billing account requires authorization on the billing account itself, enforcing least privilege over broader administrative roles like Billing Account Administrator.
3
Run `gcloud projects create hc-analytics-prod`.
The GCP project `hc-analytics-prod` is created, automatically assigning project management rights to the creator.
The project resource must exist before a billing association can be established.
4
Run `gcloud billing projects link hc-analytics-prod --billing-account=ACCOUNT_ID`.
The project is successfully linked to the Cloud Billing account.
This final command links the created project resource with the authorized billing account.

Key Concept

Least-Privilege Billing Account and Project Creation Workflow
Question 57Question →

An administrator needs to configure Workload Identity on a Google Kubernetes Engine (GKE) cluster to allow a pod to access Cloud Storage without downloading service account keys. Arrange the steps in the correct operational sequence from first to last to complete this configuration.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Create the Google Service Account (GSA) in IAM and grant required IAM roles. 2) Create the Kubernetes Service Account (KSA) in the GKE namespace. 3) Add the roles/iam.workloadIdentityUser IAM binding on the GSA for the KSA principal. 4) Annotate the KSA with the GSA email address. 5) Deploy the application workload specifying the KSA in the pod specification.
To securely grant GKE workloads access to GCP services via Workload Identity without exportable keys, you must first establish the GCP IAM identity (GSA), create the cluster identity (KSA), bind the KSA to the GSA using the `roles/iam.workloadIdentityUser` IAM role, annotate the KSA with the GSA email, and finally deploy the workload referencing the KSA in its pod specification.

Step-by-Step Solution

1
Provision the IAM Google Service Account
A GSA identity with specific GCP resource access permissions is created.
GCP resource permissions (such as Storage Object Viewer) must be attached to a Google Cloud IAM identity.
2
Provision the Kubernetes Service Account in GKE
A KSA identity is registered inside the cluster's target namespace.
Pods running inside GKE authenticate internally using Kubernetes Service Accounts.
3
Configure the IAM Workload Identity User policy binding
The GSA authorizes the GKE Workload Identity member principal `serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]` to impersonate it.
IAM must explicitly permit the specific cluster KSA principal to assume the identity of the GSA.
4
Annotate the KSA with the GSA email address
The metadata annotation `iam.gke.io/gcp-service-account` is added to the KSA.
The GKE metadata server reads this annotation to map token requests from pods using this KSA to the correct GSA.
5
Deploy the workload referencing the KSA
Pods run with the KSA specified under `spec.template.spec.serviceAccountName` and obtain short-lived OAuth 2.0 access tokens.
The workload specification links pod execution to the configured identity mapping.

Key Concept

Configuring Workload Identity in Google Kubernetes Engine
Question 58Question →

An enterprise security engineer must configure conditional IAM access for a cloud operational team at the project level. The access must grant the Cloud Functions Developer predefined role (`roles/cloudfunctions.developer`) only for resources whose names start with `prod-`. What is the correct sequential order of steps to programmatically apply and verify this conditional IAM policy update using the `gcloud` CLI?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Export the current project policy to a JSON file, 2) Edit the JSON file to append the predefined role binding with the resource name condition, 3) Write the updated policy back to the project using `set-iam-policy`, and 4) Verify the updated policy bindings using `get-iam-policy` with a filter.
The complete workflow requires retrieving the current live policy via `gcloud projects get-iam-policy` into a local JSON file to safeguard existing permissions, modifying the JSON structure to include the predefined role and condition block, writing the policy back using `gcloud projects set-iam-policy`, and verifying the binding with a filtered `get-iam-policy` command.

Step-by-Step Solution

1
Export existing IAM policy to JSON
A local file named `policy.json` populated with existing policy bindings
Because `gcloud projects set-iam-policy` overwrites the entire policy object, existing bindings must be retrieved first to avoid inadvertently removing access.
2
Add conditional IAM role binding to JSON file
An updated `policy.json` containing the predefined role, group principal, and `resource.name.startsWith()` condition
Declarative policy updates allow precise definition of least-privilege attribute-based access control rules.
3
Apply policy back to the GCP project
The project IAM policy is updated live in Google Cloud
Running `gcloud projects set-iam-policy` commits the edited JSON file back to the resource hierarchy.
4
Verify applied policy binding
CLI output verifying active presence of `roles/cloudfunctions.developer` and condition expression
Inspecting live policy state ensures that syntax or condition validation errors did not silently fail policy enforcement.

Key Concept

Managing IAM Roles and Resource Access Permissions via gcloud CLI Policy Files
Question 59Question →

A DevOps engineer needs to request a regional Compute Engine GPU quota increase for a production project using the Google Cloud Console. What is the correct sequence of steps to perform this request?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct procedural order is: first, navigate to IAM & Admin > Quotas & System Limits in the Cloud Console; second, filter for the specific regional GPU quota metric; third, select the quota item and click Edit Quotas; fourth, enter the new limit value with business justification and submit.
Requesting a quota increase requires navigating to IAM & Admin > Quotas & System Limits, locating the specific regional metric using search filters, opening the modification form via Edit Quotas, and entering the desired limit alongside a valid business justification.

Step-by-Step Solution

1
Open IAM & Admin > Quotas & System Limits
Displays all GCP service limits and current usage for the active project.
Quota management is centralized under IAM & Admin settings.
2
Filter for the target GPU metric and region
Isolates the exact regional GPU quota line item.
Quotas are segmented by service, metric name, and region.
3
Select the line item and click Edit Quotas
Opens the request side panel for adjusting quota limits.
The Edit Quotas action triggers the formal request workflow.
4
Specify new quota limit, add justification, and submit
Submits the quota increase request to GCP support/automation.
Justification is required for GCP review teams to evaluate capacity requests.

Key Concept

Requesting GCP Resource Quota Increases via Google Cloud Console
Question 60Question →

A cloud operations team needs to enforce automated governance by deploying a serverless remediation pipeline that triggers whenever a GCP billing account exceeds defined financial thresholds. In what order should the engineer execute the configuration steps to establish this automated budget notification and remediation workflow?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with creating the Cloud Pub/Sub topic, granting the Cloud Billing Service Agent the Pub/Sub Publisher role on that topic, deploying the serverless remediation workload subscribed to the topic, and finally creating the Cloud Billing budget with the Pub/Sub programmatic notification channel attached.
To build a functional automated remediation pipeline, infrastructure dependencies must be established in order: first create the message queue (Cloud Pub/Sub topic), second grant the Cloud Billing service identity permission to publish to that queue, third deploy the consumer service that executes remediation actions upon receiving messages, and finally define the budget with the Pub/Sub notification channel connected.

Step-by-Step Solution

1
Establish the event bus infrastructure
A Cloud Pub/Sub topic is available to ingest programmatic alert payloads.
Downstream IAM policies and budget channel bindings require a valid target Pub/Sub topic resource.
2
Configure publisher IAM permissions for Cloud Billing
The Cloud Billing system identity receives permissions to publish messages to the Pub/Sub topic.
Without `roles/pubsub.publisher` assigned to the Cloud Billing Service Agent on the topic, message publishing will fail silently upon threshold breaches.
3
Deploy and connect the automated remediation subscriber
A Cloud Function or Cloud Run service is active and listening for pub/sub messages.
The automated handler must be listening to handle incoming JSON budget payloads to alter project states or quotas.
4
Configure the Cloud Billing budget and attach the programmatic notification channel
The budget rule is actively monitoring spending and linked to the Pub/Sub message stream.
Attaching the Pub/Sub topic to the budget completes the integration.

Key Concept

Automated Budget Remediation Architecture and Cloud Billing Pub/Sub Integration Sequence
Estimated Time:2m 0s
PreviousPage 3 / 14Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin