Examkin

All practice questions

262 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 81Question →

A system administrator needs to provision a Compute Engine virtual machine instance using the Google Cloud CLI (`gcloud`). The VM must execute a local multi-line initialization script on startup and perform read-only operations against a Cloud Storage bucket using a custom service account following the principle of least privilege. In what chronological sequence must the administrator perform the steps to configure and launch this virtual machine?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Create the dedicated user-managed service account, 2) Grant the Storage Object Viewer role to the service account, 3) Write and save the initialization shell script locally, and 4) Run `gcloud compute instances create` referencing the service account, `cloud-platform` scope, and `--metadata-from-file=startup-script=init.sh`.
Provisioning a secure Compute Engine instance follows a logical dependency chain: identity creation, permission assignment, local asset preparation, and finally resource instantiation. The service account must exist before IAM roles can be granted to it. The IAM permissions must be bound before the VM boots and attempts to perform storage actions. The startup script file must be saved on the administrator's client machine before `gcloud` can read its contents via `--metadata-from-file`. Finally, launching the instance attaches the service account identity and uploads the local script content into instance metadata.

Step-by-Step Solution

1
Create the custom service account identity.
Establishes a user-managed service account resource in IAM.
Compute Engine instances requiring specific access patterns should use custom service accounts rather than the Default Compute Engine Service Account.
2
Assign the least-privilege IAM role to the service account.
Binds `roles/storage.objectViewer` to the service account identity for the target storage bucket.
IAM permissions must be configured on the service account so that requests made from the instance succeed upon startup.
3
Author the startup script locally.
Creates a local file containing bash setup directives.
When passing local file content to instance metadata via `--metadata-from-file`, the file must already exist on the local file system.
4
Issue the `gcloud compute instances create` command with appropriate flags.
Provisions the Compute Engine VM with attached identity, proper API scopes, and startup script metadata.
Best practice for custom service accounts is to assign the `https://www.googleapis.com/auth/cloud-platform` scope and manage actual access control entirely through IAM roles.

Key Concept

Compute Engine VM Provisioning with Custom Service Accounts and Metadata Startup Scripts
Question 82Question →

A cloud engineer needs to deploy a new custom Virtual Private Cloud (VPC) network, provision a regional subnet, and enforce ingress traffic security for a specific web server instance using network tags. Arrange the following deployment steps in the correct order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational order is to first create the custom-mode VPC network, then provision the regional subnet with an IP range, followed by creating the target-tagged ingress firewall rule in the VPC, and finally assigning the network tag to the Compute Engine VM instance.
In Google Cloud networking, resource creation follows a strict parent-to-child structural dependency. The custom VPC network must be created first because subnets and firewall rules are child resources of the VPC. The regional subnet defines the IP space, while the firewall rule defines access controls within that network. Finally, attaching the network tag to the virtual machine enables the matching firewall rule for that instance.

Step-by-Step Solution

1
Create the custom VPC network container
An empty custom VPC network is established without default automatic subnets.
Google Cloud infrastructure resources such as subnets and firewall rules depend on a parent VPC network object.
2
Create a regional subnet with a CIDR range
A explicit IP address block is allocated in a specific region within the custom VPC network.
Compute instances require a subnet within a specific region to allocate internal IP addresses.
3
Define a firewall rule targeting a specific network tag
The VPC network registers an ingress filtering rule configured to allow traffic for instances carrying the target tag.
Firewall rules belong to the VPC network level and must be defined before instance tag matching takes effect.
4
Assign the network tag to the target VM instance
The firewall rule dynamically applies ingress filtering to the virtual machine instance.
Network tags on Compute Engine instances trigger matching VPC firewall rules.

Key Concept

Provisioning Custom VPC Networks, Subnets, and Tag-Based Firewall Rules
Estimated Time:1m 0s
Question 83Question →

An associate cloud engineer needs to deploy a Cloud SQL PostgreSQL instance configured exclusively with a Private IP address in a custom Virtual Private Cloud (VPC) network. Place the necessary configuration steps in the correct chronological order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct deployment sequence is: 1) Allocate an IP address range in the VPC network, 2) Create a private connection to the Service Networking API, 3) Provision the Cloud SQL instance with the private network flags, and 4) Create database users and schemas.
Deploying a Cloud SQL instance with Private IP connectivity requires setting up Private Services Access first. You must first reserve an IP address block in your VPC, then establish a private service connection (VPC peering) to the Service Networking API. After peering is established, you create the Cloud SQL instance attached to that network without a public IP assigned. Finally, once the instance is running, you configure database users and application schemas.

Step-by-Step Solution

1
Allocate an IP range for Private Services Access
Reserved IP range is ready in the VPC network for Google service networking.
Google Cloud SQL private IP instances rely on Private Services Access, which requires a reserved IP address range in your VPC.
2
Establish VPC Network Peering connection
VPC Network Peering is established between the target VPC network and the Google managed services network.
This private connection enables private IP routing between compute resources in the VPC and the Cloud SQL instance.
3
Provision the Cloud SQL instance with private IP settings
The instance is created with a private IP address within the peered network range.
Specifying the VPC network and suppressing public IP assignment ensures the database instance is isolated to private traffic.
4
Configure database users and initial schema
Database instance is populated with access credentials and ready for application connections.
User and schema configuration occurs after the underlying database infrastructure and networking are active.

Key Concept

Provisioning Cloud SQL with Private IP using Private Services Access
Estimated Time:1m 0s
Question 84Question →

A cloud engineer must deploy an updated containerized microservice to an existing private Google Kubernetes Engine (GKE) cluster named `private-app-cluster` in zone `us-east4-a`. The cluster control plane is configured with private endpoint access only, and the engineer is operating from an authorized internal management workstation. In what sequence should the engineer execute the operational steps to establish private cluster connectivity, generate local cluster authentication, deploy the application manifest, and verify workload rollout?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Establish a secure network path to the private GKE control plane, 2) Execute `gcloud container clusters get-credentials private-app-cluster --zone us-east4-a --internal-ip`, 3) Execute `kubectl apply -f microservice-deployment.yaml`, and 4) Execute `kubectl rollout status deployment/microservice-app`.
The deployment of workloads to a private GKE cluster follows a logical dependency chain: network connectivity to the private master endpoint must exist first, followed by authentication setup via `gcloud container clusters get-credentials --internal-ip`. Once `kubectl` context is configured, the manifest is submitted with `kubectl apply`, and finally, the rollout state is verified with `kubectl rollout status` to confirm operational readiness.

Step-by-Step Solution

1
Ensure network connectivity to the private GKE control plane internal IP address.
Network routes allow TCP traffic to reach the GKE master API server on port 443.
Private GKE clusters disable public endpoint access, requiring internal network routing or bastion access prior to API invocation.
2
Run `gcloud container clusters get-credentials` using the `--internal-ip` flag.
The local `~/.kube/config` file is updated with cluster endpoint details and user credentials.
Without fetching credentials and specifying `--internal-ip`, local `kubectl` calls will fail to resolve or reach the private control plane.
3
Run `kubectl apply -f microservice-deployment.yaml`.
The Kubernetes API server accepts the deployment specification and schedules requested pods.
Deploying the manifest requires an active, authenticated `kubectl` context pointing to the control plane.
4
Run `kubectl rollout status deployment/microservice-app`.
Real-time deployment lifecycle progress is displayed until all updated replicas are healthy and operational.
Verification ensures that the deployment was not only submitted but also successfully completed without container crashes or scheduling failures.

Key Concept

Private GKE Cluster Management and Workload Deployment Workflow
Question 85Question →

You are deploying a Regional Internal Application Load Balancer in Google Cloud to route internal traffic among microservices running on Compute Engine instance groups within a Virtual Private Cloud (VPC) network. What is the correct sequence of administrative steps required to successfully provision this load balancer infrastructure?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins by creating a proxy-only subnet in the region, followed by provisioning the regional health check, backend service, and attaching backend instance groups. Next, the regional URL map and target HTTP proxy are created to handle HTTP routing rules. Finally, the regional forwarding rule is configured to assign an internal IP address and link incoming network traffic to the target HTTP proxy.
The proper sequence follows GCP resource dependency hierarchy for Envoy-based internal load balancers: 1) Allocate a proxy-only subnet in the region to support proxy infrastructure, 2) Define the backend tier (health check, backend service, and instance group membership), 3) Configure routing objects (URL map linked to backend service, then target HTTP proxy linked to URL map), and 4) Provision the frontend forwarding rule that links an internal IP address to the target HTTP proxy.

Step-by-Step Solution

1
Provision the prerequisite proxy-only subnet
Reserved IP range allocated specifically for Envoy proxy instances in the VPC region.
Regional Internal Application Load Balancers rely on Envoy proxies which demand a dedicated proxy-only subnet in the active region prior to target proxy deployment.
2
Configure health checking, backend service, and backend MIG resources
Backend service established with health monitoring and attached instance group targets.
Routing abstractions depend on a valid backend service that defines traffic distribution policies and target endpoints.
3
Define HTTP request routing via URL map and target proxy
URL map points to the backend service, and target proxy binds to the URL map.
The target proxy processes incoming HTTP connections according to the path and host rules defined within the URL map.
4
Establish the frontend forwarding rule
Internal IP endpoint bound to port 80/443 directing incoming VPC requests to the target proxy.
The forwarding rule serves as the entry point for client traffic, pointing directly to the target proxy.

Key Concept

Deployment dependency sequence for Envoy-based Regional Internal Application Load Balancers in GCP
Question 86Question →

A Cloud Engineer needs to set up a detailed daily Cloud Billing export to BigQuery for central cost governance. Place the steps required to configure and verify this billing export in the correct chronological order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with creating the BigQuery dataset, verifying requisite IAM permissions (Billing Account Administrator and BigQuery Data Editor), navigating to the Cloud Billing export settings in the GCP Console, specifying the target project and dataset to enable Detailed Cost Usage Export, and finally verifying table population in BigQuery.
Configuring BigQuery Cloud Billing exports follows a strict prerequisite workflow: a BigQuery dataset must exist first, proper administrative IAM permissions on both the billing account and dataset must be held, the export sink must be pointed to the project and dataset via the Cloud Billing Console, and data populates into automatically created partitioned tables for verification.

Step-by-Step Solution

1
Create the destination BigQuery dataset
A target dataset exists to receive billing export data.
Cloud Billing export requires an existing dataset before configuration can be saved.
2
Confirm IAM permissions
The identity holds Billing Account Administrator on the billing account and BigQuery Data Editor on the dataset.
Without proper roles on both the billing account and destination dataset, setting up the export sink will fail.
3
Navigate to Cloud Billing export settings
The Billing export management interface is open in the GCP Console.
Billing exports are managed directly within the Cloud Billing account settings.
4
Configure export details and save
The detailed usage cost export sink is activated pointing to the specified BigQuery dataset.
Explicitly selecting the project ID and dataset binds the billing sink to BigQuery.
5
Validate table population and query data
Exported tables appear in BigQuery containing resource usage records.
Verifying table generation ensures that automated daily data loading is operating correctly.

Key Concept

Cloud Billing BigQuery Export Configuration Sequence
Question 87Question →

You need to deploy a Global External Application Load Balancer in Google Cloud using gcloud commands to serve a web application. What is the correct sequence of steps to configure the load balancer components from the back end to the front end?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct deployment sequence from back end to front end is: 1) Create the instance group containing backend VMs, 2) Create a health check and backend service referencing the instance group, 3) Create a URL map referencing the backend service, and 4) Create the target proxy and global forwarding rule for frontend traffic entry.
Google Cloud HTTP(S) load balancers require a bottom-up deployment dependency order. First, backend instances must be grouped into an instance group. Second, a health check and backend service must be created. Third, a URL map is created to route traffic to the backend service. Finally, a target HTTP proxy and global forwarding rule are created to provide the external IP frontend.

Step-by-Step Solution

1
Provision backend Compute Engine instances and group them into an Instance Group.
Backend compute capacity is established.
Traffic destinations must exist prior to configuring load balancing routing components.
2
Create an HTTP health check and define a backend service linking the health check and instance group.
Backend service is ready to handle health verification and traffic routing.
Backend services manage health probes and balancing algorithms for target instance groups.
3
Create a URL map specifying the default backend service.
Routing configuration mapping requests to backend services is created.
Target proxies require a URL map to determine where incoming HTTP requests should be routed.
4
Create a target HTTP proxy referencing the URL map and attach a global forwarding rule.
Frontend configuration is complete and listening for external requests.
The forwarding rule receives external IP traffic and hands it off to the target proxy, completing the chain.

Key Concept

Global External Application Load Balancer Architecture and Dependency Order
Question 88Question →

You are deploying a Global External HTTP Load Balancer using the gcloud CLI to distribute web application traffic across Compute Engine instance groups in multiple regions. Place the deployment steps in the correct chronological order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of deployment steps is: 1) Create a global HTTP health check, 2) Create a global backend service and attach the health check and instance groups, 3) Create a URL map referencing the backend service, 4) Create a target HTTP proxy pointing to the URL map, and 5) Create a global forwarding rule pointing to the target HTTP proxy.
In GCP, load balancer components rely on direct dependency references. You must first create the health monitoring mechanism (health check) and backend pool configuration (backend service), followed by request routing logic (URL map), HTTP protocol processing (target HTTP proxy), and finally the public network listener (global forwarding rule).

Step-by-Step Solution

1
Create the Health Check
A global health check resource is created.
Backend services require a valid health check reference upon creation to monitor backend pool health.
2
Create the Backend Service and add Backends
The global backend service is provisioned with attached Compute Engine managed instance groups.
Backend services aggregate instances and define traffic distribution policies.
3
Create the URL Map
A URL map object is created specifying the default backend service.
URL maps route HTTP requests to specific backend services based on path rules.
4
Create the Target HTTP Proxy
A target proxy resource is provisioned linking to the URL map.
The target proxy evaluates incoming HTTP headers against the URL map rules.
5
Create the Global Forwarding Rule
An external IP and port listener are configured as the load balancer frontend.
The forwarding rule routes incoming client traffic on the frontend IP address to the target proxy.

Key Concept

Deploying a Global External HTTP Load Balancer in Google Cloud follows a bottom-up dependency hierarchy: Health Check → Backend Service → URL Map → Target Proxy → Global Forwarding Rule.
Question 89Question →

A network administrator needs to expand the primary IPv4 address range of an existing custom-mode VPC subnet in Google Cloud from 10.1.0.0/2410.1.0.0/24 to 10.1.0.0/2310.1.0.0/23 without creating IP conflicts or interrupting active virtual machines. In what chronological order should the administrator execute the following steps to ensure a successful and non-disruptive range expansion?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with auditing adjacent networks for IP overlaps (10.1.0.0/2310.1.0.0/23), confirming that the requested CIDR expansion fully encloses the existing subnet range with a smaller netmask prefix, running the gcloud compute networks subnets expand-ip-range command, and finally verifying the updated subnet CIDR configuration.
Expanding a primary IPv4 range in GCP requires verifying non-overlapping address space across interconnected networks before making changes, confirming that the new prefix encloses the old range (e.g., expanding from /24/24 to /23/23), executing the gcloud compute networks subnets expand-ip-range command, and verifying the change upon completion.

Step-by-Step Solution

1
Audit connected networks for IP conflicts
Ensures 10.1.0.0/2310.1.0.0/23 is completely clear across on-premises and peered networks.
Expanding a subnet into an already used range will cause routing issues and break VPC peering or hybrid interconnects.
2
Validate subnet mask enclosing constraints
Confirms the expansion adheres to GCP VPC subnet expansion constraints.
Google Cloud VPC subnets can only be expanded to a larger range (smaller prefix length) that encloses the original range.
3
Execute the expansion command using gcloud CLI
Modifies the subnet configuration non-disruptively in GCP.
The expand-ip-range command performs an in-place range expansion without requiring VM re-creation.
4
Verify updated subnet properties
Confirms successful expansion to 10.1.0.0/2310.1.0.0/23.
Post-implementation validation guarantees that the network resource state matches expected architecture requirements.

Key Concept

Subnet IP range expansion procedures and constraints in GCP Custom Mode VPCs
Question 90Question →

An engineer wants to deploy a new microservice to Google Cloud Run directly from source code using the gcloud CLI. Arrange the following steps in the correct chronological sequence required to execute this deployment.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for deploying a Cloud Run service from source code is: 1) Enable Cloud Run and Cloud Build APIs, 2) Set the active GCP project context using `gcloud config set project`, 3) Run `gcloud run deploy SERVICE_NAME --source .` from the source root, and 4) Select the region and configure access permissions.
The correct deployment sequence starts with enabling the necessary service APIs (Cloud Run and Cloud Build). Next, the developer sets the target active project using `gcloud config set project`. Then, running `gcloud run deploy --source .` builds the container image and initiates deployment. Finally, configuring the deployment region and ingress permissions completes the service initialization.

Step-by-Step Solution

1
Enable required APIs
Cloud Run and Cloud Build services are active and ready to accept calls.
Deploying from source requires Cloud Build to build the container image and Cloud Run to host it.
2
Configure gcloud project property
The CLI is targeted at the intended GCP project.
Prevents deploying resources into an incorrect default project.
3
Initiate source-based deployment
Source code upload and container build pipeline are triggered.
The `--source .` flag instructs Cloud Run to use Cloud Build automatically.
4
Configure deployment options
Service is deployed to the chosen region with desired authentication settings.
Final runtime parameters are set to establish endpoint accessibility.

Key Concept

Deploying Cloud Run Services from Source Code using gcloud CLI
Question 91Question →

A cloud engineer needs to add a new role binding for a service account in a Google Cloud project by modifying the project's IAM policy via the gcloud CLI using a local policy file. Place the operational steps in the correct sequence to complete this procedure.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: Export the existing policy to a local file, edit the local file with the new binding, apply the updated policy back to the project, and verify the changes.
Updating an IAM policy via local files follows a get-edit-set pattern. Exporting the policy first prevents dropping existing access controls, editing adds the new access, setting the policy updates GCP, and verification confirms success.

Step-by-Step Solution

1
Export the current project IAM policy
A local file named `policy.json` containing current bindings is generated.
You must obtain the existing policy structure first to avoid overwriting or dropping existing bindings.
2
Modify the local policy file
The `policy.json` file now contains the newly required role and principal target.
Editing the file locally allows precise changes to the JSON structure before committing policy updates.
3
Set the updated project IAM policy
The project IAM policy in GCP is replaced with the contents of `policy.json`.
The command `gcloud projects set-iam-policy` updates the remote resource hierarchy access rules.
4
Verify the policy modification
Confirmation that the new role binding is active.
Post-deployment audit verifies that the desired least-privilege binding is present.

Key Concept

IAM policy update workflow via declarative gcloud files
Estimated Time:1m 30s
Question 92Question →

A cloud administrator needs to automate object lifecycle management on an existing Google Cloud Storage bucket to transition objects older than 30 days to Nearline storage. Arrange the operational steps in the correct sequence to define, apply, and verify the lifecycle policy using the modern `gcloud storage` CLI tool.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: First, create the local JSON lifecycle policy file specifying the action and age conditions. Second, deploy the policy file to the target bucket using `gcloud storage buckets update --lifecycle-file`. Third, verify the applied policy using `gcloud storage buckets describe`. Fourth, test write operations on the bucket by uploading a test file with `gcloud storage cp`.
The operational workflow for deploying Cloud Storage bucket lifecycle rules follows standard cloud infrastructure configuration steps: policy definition in a local manifest, execution of the updating CLI command to sync changes to GCP, metadata verification to ensure the deployment succeeded, and functional validation through an object upload test.

Step-by-Step Solution

1
Draft the lifecycle JSON configuration file
A local file named `lifecycle.json` containing the transition rule definition is created.
The `gcloud storage` CLI requires lifecycle policies to be supplied via a structured JSON document.
2
Deploy the policy file to Google Cloud Storage
The command `gcloud storage buckets update gs://[BUCKET_NAME] --lifecycle-file=lifecycle.json` applies the lifecycle rule to the cloud resource.
Bucket configuration updates must be committed to the GCP control plane before they can take effect.
3
Verify active lifecycle rules on the bucket
Executing `gcloud storage buckets describe` displays the active lifecycle object within the bucket metadata.
Verification confirms that the configuration was parsed and accepted by Cloud Storage without formatting errors.
4
Perform post-deployment operation testing
Running `gcloud storage cp` successfully uploads an object to the configured bucket.
Testing ensures bucket access controls and object write pathways remain functional after updating bucket metadata.

Key Concept

Configuring Cloud Storage Object Lifecycle Policies using gcloud storage CLI
Question 93Question →

A cloud engineer is tasked with deploying and configuring an enterprise audit logging Cloud Storage bucket in `us-west1` for compliance tracking. The bucket must enforce Uniform Bucket-Level Access, have Object Versioning enabled, apply a lifecycle management policy defined in `policy.json`, and finally receive an initial baseline audit log file. In what chronological sequence must the engineer execute the following operational steps to correctly establish and populate the solution?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: first create the bucket with Uniform Bucket-Level Access (`item_1`), then enable Object Versioning (`item_2`), followed by applying the lifecycle policy file (`item_3`), and finally uploading the baseline audit log object (`item_4`).
The correct operational sequence follows GCP infrastructure deployment best practices: 1) Instantiate the Cloud Storage bucket with specified security settings (`--uniform-bucket-level-access`), 2) Enable Object Versioning to protect data state, 3) Apply object lifecycle policies (`--lifecycle-file`) to manage long-term object state, and 4) Upload the initial object payload (`gcloud storage cp`).

Step-by-Step Solution

1
Identify the foundational resource creation step.
Determine that creating the bucket resource using `gcloud storage buckets create` must be executed first.
Google Cloud Storage resources must exist prior to updating their metadata configurations or uploading files.
2
Determine the sequence of bucket feature enablement prior to policy enforcement.
Enable Object Versioning using `gcloud storage buckets update --versioning`.
Setting bucket feature flags before applying complex policies ensures all subsequent actions respect object history settings.
3
Apply governance and automated object transition rules.
Attach the lifecycle policy file using `gcloud storage buckets update --lifecycle-file=policy.json`.
Bucket configuration parameters and automated lifecycle rules must be active before ingesting production or baseline objects.
4
Perform the data ingestion step.
Upload the target file into the bucket using `gcloud storage cp`.
Uploading data is the final operational step once all target bucket access controls and configuration policies are active.

Key Concept

Deploying and configuring Cloud Storage buckets and objects requires a strict operational dependency order: resource creation with access parameters, metadata and lifecycle policy configuration, and finally object ingestion.
Question 94Question →

Arrange the following administrative procedures in the correct chronological order required to authenticate to a Google Kubernetes Engine (GKE) cluster, confirm active cluster access, submit a new workload manifest, and verify that the pod deployment finishes successfully.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct administrative sequence is: 1. Obtain cluster credentials (`gcloud container clusters get-credentials`), 2. Verify cluster node connectivity (`kubectl get nodes`), 3. Apply the workload manifest (`kubectl apply -f deployment.yaml`), 4. Confirm successful deployment rollout (`kubectl rollout status deployment/web-app`).
The deployment process follows a standard sequence: First, execute `gcloud container clusters get-credentials` to acquire cluster access credentials and set up `kubeconfig`. Second, run `kubectl get nodes` to confirm functional API server access and cluster health. Third, run `kubectl apply -f deployment.yaml` to instruct GKE to create or update the workload resources. Fourth, run `kubectl rollout status deployment/web-app` to observe and verify that all new pods pass readiness probes.

Step-by-Step Solution

1
Generate cluster credentials and update local kubeconfig
The local CLI environment obtains authentication tokens and configures the GKE cluster context.
Commands issued via kubectl will fail unless valid control plane credentials and server endpoints exist in kubeconfig.
2
Test control plane connectivity and node readiness
Returns the list of cluster nodes and their Current status (Ready).
Verifying API server access prevents submitting deployment manifests into an unreachable or broken cluster context.
3
Deploy the application configuration file to the cluster
The Kubernetes API server accepts the deployment specification and triggers pod creation.
Declarative resource creation requires applying the YAML specification file.
4
Observe the progress of the deployment rollout
Monitors pod status until all replicas complete initialization without crash loops or image pull failures.
Executing rollout status provides deterministic verification that the workload update succeeded.

Key Concept

GKE Cluster Authentication and Workload Deployment Lifecycle
Question 95Question →

You are managing a Google Kubernetes Engine (GKE) cluster and need to migrate running workloads from an existing node pool to a newly required machine type with minimal downtime. What is the correct sequence of steps to complete this node pool migration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for migrating workloads to a new node pool is: 1) Provision the new node pool with gcloud container node-pools create, 2) Mark the old nodes as unschedulable with kubectl cordon, 3) Gracefully evict workloads from old nodes with kubectl drain, and 4) Delete the old node pool with gcloud container node-pools delete.
When performing a manual GKE node pool migration, compute capacity must first be provisioned using 'gcloud container node-pools create'. Once the new nodes are ready, old nodes are marked unschedulable with 'kubectl cordon' to prevent new placements. Executing 'kubectl drain' then evicts Pods, allowing Kubernetes to reschedule them onto the new node pool. Finally, 'gcloud container node-pools delete' removes the empty old node pool safely.

Step-by-Step Solution

1
Provision target compute capacity
New nodes are added to the cluster with the desired specification.
Replacement nodes must exist so evicted Pods have available capacity for rescheduling.
2
Disable scheduling on old nodes
Old nodes are cordoned and marked Unschedulable.
Prevents new Pods from being placed on nodes that are about to be decommissioned.
3
Evict workloads from old nodes
Running Pods are safely evicted and recreated on the newly provisioned node pool.
Draining ensures workloads migrate to active capacity without sudden termination.
4
Decommission old node pool
The old node pool is removed from the GKE cluster.
Cleaning up empty infrastructure prevents unnecessary cloud resource charges.

Key Concept

GKE Node Pool Migration Procedure
Question 96Question →

An operations engineer is tasked with configuring a Global External Application Load Balancer using the gcloud CLI to secure incoming HTTPS web traffic destined for Compute Engine managed instance groups. The deployment requires establishing health monitoring, SSL encryption via Google-managed certificates, and frontend traffic routing. Which sequence correctly orders the deployment commands from the backend infrastructure up to the public frontend entry point?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order follows the bottom-up dependency sequence of Google Cloud HTTP(S) Load Balancing: first create the health check, backend service, and attach instance group backends; second, create the URL map pointing to the backend service; third, reserve a static global external IP address and create the Google-managed SSL certificate; fourth, create the target HTTPS proxy linking the URL map and SSL certificate; fifth, establish the global forwarding rule binding the external IP address on port 443 to the target HTTPS proxy.
In Google Cloud Platform, building a Global External Application Load Balancer via gcloud follows a strict dependency chain from backend to frontend. The backend service and health check must exist before a URL map can reference them. Similarly, the URL map and SSL certificate resources must exist before creating the target HTTPS proxy. Finally, the global forwarding rule binds the reserved external IP address and target port to the target HTTPS proxy.

Step-by-Step Solution

1
Define backend resources (Health Check and Backend Service)
Backend service is created with an attached health check and instance group backends registered.
Top-level proxy resources cannot be created without a defined backend service target.
2
Create the URL Map
URL map object routing HTTP(S) traffic to the default backend service is instantiated.
URL maps evaluate incoming request paths and route traffic to configured backend services.
3
Provision IP Address and SSL Certificate frontend dependencies
A global static external IP address and a Google-managed SSL certificate resource are created.
Target HTTPS proxies require an existing SSL certificate object, and forwarding rules require an allocated static IP.
4
Create Target HTTPS Proxy
Target HTTPS proxy binds the URL map and SSL certificate.
The target proxy performs TLS termination using the SSL certificate before consulting the URL map for path routing.
5
Create Global Forwarding Rule
Forwarding rule routes incoming port 443 traffic from the external static IP to the target HTTPS proxy.
The forwarding rule completes the pathway by connecting external network traffic to the GCP load balancing entry point.

Key Concept

Google Cloud Global External Application Load Balancer Architecture & gcloud Dependency Sequence
Estimated Time:3m 0s
Question 97Question →

A cloud engineer needs to deploy a highly available Cloud SQL PostgreSQL instance using Private IP connectivity within a custom Virtual Private Cloud (VPC) network, followed by creating a cross-region read replica using the Google Cloud CLI. Arrange the required infrastructure provisioning and database creation steps in the correct chronological execution order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with reserving an internal IP allocation for VPC peering, establishing the private services access connection to servicenetworking.googleapis.com, creating the regional primary Cloud SQL instance attached to the VPC with public IP disabled, and finally creating the cross-region read replica targeting the primary instance.
Private IP connectivity for Cloud SQL relies on Private Services Access, which is built on VPC Peering between the customer VPC network and Google's internal service network. The workflow requires allocating an internal IP range (`gcloud compute addresses create ... --purpose=VPC_PEERING`), connecting the network to Service Networking (`gcloud services vpc-peerings connect`), provisioning the primary Cloud SQL instance (`gcloud sql instances create ... --no-assign-ip --network=...`), and finally creating any read replicas specifying the primary as the master instance.

Step-by-Step Solution

1
Allocate a private IP range for Private Service Access.
An IP range with purpose VPC_PEERING is reserved in the target VPC network.
Google Cloud service networking requires a pre-allocated IP range to avoid subnet overlap prior to establishing peering.
2
Create the VPC peering connection for Google Managed Services.
The target VPC network is peered with the Service Networking tenant project network.
Cloud SQL Private IP uses Private Services Access, which relies on a underlying Service Networking VPC peering connection.
3
Provision the regional primary Cloud SQL database instance.
A high-availability primary database instance is deployed without a public IP.
The primary database instance must exist and be accessible via the peered network before replicas can be configured.
4
Provision the cross-region read replica.
A read replica is provisioned in the secondary region linked to the primary instance.
Read replicas depend on the primary instance ID specified by the master instance flag during creation.

Key Concept

Provisioning Cloud SQL instances with Private IP requires establishing a Private Services Access (Service Networking VPC Peering) connection before instantiating primary instances or read replicas.
Question 98Question →

A Cloud Engineer needs to securely configure a workload running on Google Kubernetes Engine (GKE) to access Cloud Storage using Workload Identity instead of downloading service account keys. Arrange the following configuration and deployment steps in the correct chronological order required to grant the GKE workload secure access to Cloud Storage.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological order to configure Workload Identity on GKE is: 1) Create the Google Cloud Service Account (GSA) and assign IAM roles, 2) Create the Kubernetes Service Account (KSA) in the cluster, 3) Bind the KSA to the GSA using the Workload Identity User role, 4) Annotate the KSA with the GSA email address, and 5) Reference the KSA under `spec.serviceAccountName` in the workload deployment manifest before applying it.
The correct sequence starts with provisioning the GCP identity (GSA) and cluster identity (KSA). Next, IAM impersonation trust is established by granting `roles/iam.workloadIdentityUser` to the KSA principal. The KSA is then annotated with the GSA email so the GKE metadata server can handle token exchange. Finally, the workload deployment manifest is configured to use the KSA and applied to the cluster.

Step-by-Step Solution

1
Create the Google Cloud IAM Service Account (GSA) and assign permissions.
GCP identity is provisioned with appropriate Cloud Storage access roles.
Cloud permissions must exist on the GCP side before linking Kubernetes resources.
2
Create the Kubernetes Service Account (KSA) in GKE.
In-cluster identity is created within the specified namespace.
GKE workloads require a KSA identity to participate in Workload Identity mapping.
3
Grant `roles/iam.workloadIdentityUser` on the GSA to the KSA member identity (`serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]`).
IAM policy allows the KSA to impersonate the GSA.
Without this role binding, GCP IAM will reject impersonation requests from GKE.
4
Annotate the KSA using `iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com`.
The GKE metadata server links KSA credential requests to the specified GSA.
The annotation informs the GKE metadata server which GSA identity to issue tokens for.
5
Configure `spec.serviceAccountName` in the Deployment spec and apply it to the cluster.
Pods run under the authenticated KSA identity and gain access to GCP resources.
Pods must explicitly select the configured KSA to inherit Workload Identity authentication.

Key Concept

GKE Workload Identity Configuration Sequence
Question 99Question →

A Cloud Engineer needs to establish a daily Cloud Billing detailed usage cost export to BigQuery for organization-wide financial analytics. What is the correct sequence of steps to configure this export?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with verifying required IAM roles (Billing Account Costs Manager on the billing account and BigQuery Data Editor on the target project), followed by enabling the BigQuery API in the destination project, creating the target BigQuery dataset, navigating to the Billing export section in the Cloud Billing console, and finally configuring the Detailed usage cost export with the project ID and dataset name.
Configuring a BigQuery billing export requires completing prerequisite security and infrastructure tasks first. First, verify IAM roles on both the billing account (Billing Account Costs Manager) and project (BigQuery Data Editor). Second, enable the BigQuery API in the destination project. Third, create the target BigQuery dataset. Fourth, navigate to the Billing export section of the Cloud Billing console. Fifth, configure the Detailed usage cost export by entering the target project ID and dataset, then save.

Step-by-Step Solution

1
Grant and verify IAM roles
The engineer holds Billing Account Costs Manager and BigQuery Data Editor roles.
Without billing administrative access and project data editor access, dataset creation and billing sink creation will be denied.
2
Enable BigQuery API
BigQuery API is enabled in the destination project.
Services in GCP cannot be provisioned or configured until their corresponding API is activated in the project.
3
Create destination dataset
Target BigQuery dataset is created.
The export workflow requires selecting an existing dataset as the destination sink.
4
Access Cloud Billing export menu
Billing export settings interface is loaded.
Cloud Billing export sinks are managed within the Cloud Billing account settings.
5
Configure and save export sink
Detailed usage cost data starts exporting daily to BigQuery.
Specifying the project and dataset binds the billing stream to BigQuery.

Key Concept

Configuring BigQuery Billing Exports
Question 100Question →

Your organization is integrating an on-premises data center with a Google Cloud Virtual Private Cloud (VPC) network over Cloud Interconnect. You need to enable on-premises clients to resolve internal Cloud DNS zone records ending in `internal.example.com`. Place the deployment steps in the correct chronological order from first to last to complete this configuration.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts by enabling inbound DNS forwarding via a Cloud DNS server policy on the VPC network, retrieving the allocated inbound forwarder IP addresses, configuring on-premises DNS conditional forwarding to those IP addresses, and finally testing resolution from an on-premises host.
Configuring hybrid DNS resolution requires provisioning the cloud infrastructure first (Cloud DNS server policy with inbound forwarding), identifying the generated inbound forwarder IP addresses, configuring the on-premises DNS server to use those IPs as conditional forwarders, and finally verifying connectivity from an on-premises client.

Step-by-Step Solution

1
Enable inbound DNS forwarding on the VPC network.
A Cloud DNS server policy is created on the VPC network, provisioning inbound DNS forwarder entry points.
Cloud DNS cannot accept external/on-premises DNS queries until inbound forwarding is explicitly enabled via a server policy.
2
Look up the allocated Cloud DNS inbound forwarder IP addresses.
The administrator obtains the specific internal IP addresses created in the VPC subnets for inbound DNS traffic.
These IP addresses serve as the target destinations for DNS queries originating from the on-premises network.
3
Update on-premises DNS conditional forwarding rules.
The on-premises DNS servers forward all requests for `internal.example.com` across the hybrid connection to Google Cloud.
On-premises clients send queries to their local DNS server, which requires conditional forwarding rules pointing to the Cloud DNS forwarders.
4
Test end-to-end resolution from an on-premises client.
Successful DNS response containing the private IP address of the queried Google Cloud resource.
Testing from the end client verifies that routing, firewall rules, and DNS forwarding configurations are operating correctly.

Key Concept

Cloud DNS Inbound Forwarding Configuration for Hybrid Cloud Environments
PreviousPage 5 / 14Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin