Examkin

All practice questions

1591 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 781Question →

A Cloud Engineer is tasked with deploying a microservice workload manifest to a newly created regional GKE Autopilot cluster named `analytics-prod-cluster` located in the `europe-west1` region. Which sequence of steps correctly describes the process of establishing cluster credentials, verifying cluster connectivity, deploying the workload manifest, and confirming the rollout status?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational order is: 1) Fetch cluster credentials using `gcloud container clusters get-credentials analytics-prod-cluster --region europe-west1`, 2) Verify cluster node availability using `kubectl get nodes`, 3) Apply the deployment manifest using `kubectl apply -f analytics-deployment.yaml`, and 4) Monitor rollout completion using `kubectl rollout status deployment/analytics-service`.
Deploying workloads to a GKE cluster follows a logical lifecycle: first, authentication credentials and cluster endpoint details must be written to the local `kubeconfig` file using `gcloud container clusters get-credentials`. Second, cluster readiness is verified using `kubectl get nodes`. Third, the workload manifest is submitted using `kubectl apply -f`. Finally, workload instantiation is verified using `kubectl rollout status`.

Step-by-Step Solution

1
Execute `gcloud container clusters get-credentials analytics-prod-cluster --region europe-west1`.
Local `kubeconfig` file is updated with cluster authentication tokens and API server endpoint entries.
kubectl commands will fail due to lack of authentication or invalid context without fetching cluster credentials first.
2
Run `kubectl get nodes` to inspect node status.
The control plane returns the list of worker nodes and their current readiness status.
Confirming cluster connectivity ensures the API server is reachable before submitting resource specifications.
3
Run `kubectl apply -f analytics-deployment.yaml`.
The Kubernetes API server accepts and creates the specified Deployment object.
Workload resources can only be declared after authentication and connectivity validation.
4
Execute `kubectl rollout status deployment/analytics-service`.
The CLI tracks pod creation and displays rollout success once all replicas pass readiness probes.
Verifying rollout completion guarantees that the deployment succeeded without crashing or stalling.

Key Concept

GKE Cluster Credential Fetching and Workload Deployment Workflow
Question 782Question →

An architectural firm uploads high-resolution 3D CAD rendering files to Google Cloud Storage. The design team actively accesses and modifies these files daily during the initial 30-day project design phase. After 30 days, project files are rarely accessed, but regulatory building safety standards require the files to be retained and protected from modification or deletion for 10 years. When old files are requested for an audit, sub-second access latency is required. Which TWO configurations should you implement to satisfy these business and compliance requirements at the lowest total cost? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Set the default storage class of the bucket to Standard, and configure an Object Lifecycle Management action to transition objects to Coldline Storage after 30 days.; Define a Bucket Lock retention policy set to 3,650 days (10 years) on the Cloud Storage bucket and lock the policy.

Answer

The optimal solution is to set the bucket storage class to Standard during the initial 30-day active project phase, use Object Lifecycle Management to transition objects to Coldline Storage after 30 days, and enforce a 10-year locked retention policy via Bucket Lock.
Starting with Standard Storage avoids retrieval charges during the active 30-day design phase. Transitioning to Coldline Storage after 30 days lowers storage costs while maintaining sub-second access latency. Applying a locked retention policy ensures compliance with the 10-year retention mandate.

Step-by-Step Solution

1
Analyze access patterns during the initial phase
High-frequency access during the first 30 days requires Standard Storage to avoid retrieval fees.
Coldline and Archive classes charge per-gigabyte retrieval fees, making them cost-prohibitive for daily access.
2
Select long-term storage class transition policy
Coldline Storage provides sub-second latency and lower monthly storage costs for data accessed less than once a month.
Transitioning via lifecycle rules 30 days after creation aligns storage cost with access frequency.
3
Configure regulatory compliance retention
Enabling and locking a 3,650-day (10-year) retention policy prevents object modification or premature deletion.
Bucket Lock fulfills Write-Once-Read-Many (WORM) compliance requirements.

Key Concept

Cloud Storage Class Lifecycle Transitions and Retention Policies
Question 783Question →

An infrastructure team is setting up a production Cloud SQL PostgreSQL instance that must communicate exclusively via Private IP inside an existing custom Virtual Private Cloud network named `prod-vpc`. Arrange the following administrative commands and procedures in the correct sequential order to establish Private Service Access and deploy the database instance.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Allocate an internal IP range using gcloud compute addresses create, 2) Create the private service peering connection using gcloud services peered-connections create, 3) Create the Cloud SQL instance with gcloud sql instances create --network=prod-vpc --no-assign-ip, and 4) Provision database users using gcloud sql users create.
To deploy a Cloud SQL instance with Private IP connectivity, Google Cloud requires an established Private Service Access connection. The mandatory sequence begins with reserving an internal IP block (`gcloud compute addresses create`), followed by peering the VPC to Google managed services (`gcloud services peered-connections create`), then creating the instance attached to the VPC without a public IP (`gcloud sql instances create --network=prod-vpc --no-assign-ip`), and finally configuring database user credentials (`gcloud sql users create`).

Step-by-Step Solution

1
Reserve an internal IP address block in the VPC network.
An IP address range with purpose VPC_PEERING is allocated in prod-vpc.
Private Service Access requires a dedicated IP address range to be allocated in the user VPC prior to peering.
2
Create the VPC Network Peering connection to servicenetworking.googleapis.com.
The VPC network is peered with the service producer network managed by Google.
Cloud SQL private instances reside inside a Google-managed tenant VPC, requiring network peering to route traffic.
3
Provision the Cloud SQL instance with --network and --no-assign-ip parameters.
Cloud SQL instance is deployed and assigned a private IP from the peered service range.
Attempting to create a Cloud SQL instance with --network before creating the peered connection results in execution failure.
4
Configure database user credentials.
Application user account is created on the deployed database instance.
User management commands require an active database instance target.

Key Concept

Sequential provisioning of GCP Private Service Access and Private IP Cloud SQL instances
Question 784Question →

An organization is deploying an event-driven Python microservice to Cloud Functions (2nd gen) in the `us-central1` region to process medical image uploads from a Cloud Storage bucket named `medical-records-archive`. Security policy dictates that the function must run using a non-default custom service account (`[email protected]`) enforcing the principle of least privilege, and must be triggered whenever new objects are finalized in the storage bucket. Which TWO configuration steps or deployment flags must be used to achieve this setup successfully?

Select all that apply

Show answer & explanation

Answer: Include the `[email protected]` flag when executing `gcloud functions deploy`.; Grant the `roles/storage.objectViewer` role on the `medical-records-archive` bucket to `[email protected]`.

Answer

The deployment must specify the custom service account using the service account deployment flag and grant that service account the Storage Object Viewer role on the target bucket.
Deploying 2nd gen Cloud Functions with custom execution identities requires explicitly attaching the service account during deployment via the service account flag and granting that service account specific resource access roles, such as reading objects from the Cloud Storage bucket.

Step-by-Step Solution

1
Configure the runtime service account identity during function deployment.
Pass `[email protected]` during `gcloud functions deploy` so the runtime instance assumes the identity of the dedicated service account.
By default, Cloud Functions uses the default compute service account which often holds excessive permissions.
2
Grant minimum necessary storage resource access permissions.
Assign `roles/storage.objectViewer` on the bucket `medical-records-archive` to the custom service account.
The function code needs to read object data from the bucket when triggered by object creation events.

Key Concept

Cloud Functions (2nd gen) identity binding and IAM least privilege configuration for Cloud Storage event processing
Question 785Question →

An organization plans to host a production relational database on Google Compute Engine virtual machines that will run continuously 24 hours a day, 7 days a week for several years. The database is stateful, non-fault-tolerant, and requires predictable performance with persistent block storage. When modeling the monthly infrastructure expenses for this workload using the Google Cloud Pricing Calculator, which configuration option should be selected to achieve the maximum guaranteed discount on compute resources?

Show answer & explanation

Answer: Specify Committed Use Discounts (CUDs) for a 1-year or 3-year term for the Compute Engine instance resources.

Answer

Specify Committed Use Discounts (CUDs) for a 1-year or 3-year term for the Compute Engine instance resources.
Committed Use Discounts (CUDs) are designed for workloads with predictable compute needs. By committing to 1-year or 3-year resource usage in the Google Cloud Pricing Calculator, users unlock the maximum possible discount tier for 24/7 Compute Engine workloads.

Step-by-Step Solution

1
Identify the workload characteristics from the scenario
The database workload runs continuously 24/7 (steady-state) and is stateful/non-fault-tolerant.
Understanding workload continuity and fault tolerance determines which pricing model and discount mechanisms are applicable.
2
Evaluate discount options in the Google Cloud Pricing Calculator
Committed Use Discounts (CUDs) offer maximum savings (up to 70% for 3-year terms) for predictable steady-state compute workloads compared to automatic Sustained Use Discounts (SUDs).
CUDs require a commitment to a specified amount of vCPUs and memory for 1 or 3 years, yielding higher savings than automatic sustained usage.
3
Verify suitability of alternative provisioning and storage options
Spot VMs cannot be used due to preemption risks on stateful databases, and block storage persistent disks cannot use Cloud Storage object tiers.
Ensures the cost estimation reflects realistic and supported architectural choices.

Key Concept

Selecting appropriate discount models (CUD vs. SUD) and instance types in the Google Cloud Pricing Calculator based on workload predictability and availability constraints.
Estimated Time:1m 30s
Question 786Question →

A cloud architect is preparing to analyze detailed Google Cloud usage patterns and daily pricing metrics by establishing a continuous Cloud Billing export to BigQuery. Which configuration actions are required to complete this export setup? (Select TWO answers.)

Select all that apply

Show answer & explanation

Answer: Create a BigQuery dataset in the target project to store the exported billing data.; Ensure the user configuring the export possesses the Billing Account Costs Manager role on the billing account.

Answer

The required actions are creating a BigQuery dataset in the target project and ensuring the user setting up the export holds the Billing Account Costs Manager role on the billing account.
Establishing a BigQuery export for Cloud Billing requires creating a destination BigQuery dataset within a project and holding the Billing Account Costs Manager role on the billing account.

Step-by-Step Solution

1
Prepare destination storage in BigQuery.
A target dataset is created in a Google Cloud project to host the exported billing tables.
The export pipeline requires an existing dataset destination.
2
Verify required Billing Account identity permissions.
The user holds the Billing Account Costs Manager role on the billing account.
Setting up exports modifies configuration properties on the Cloud Billing account.

Key Concept

Setting up Cloud Billing export to BigQuery requires destination dataset creation in a project and Billing Account Costs Manager permissions on the billing account.
Question 787Question →

A systems operations team manages an e-commerce platform running on a Google Kubernetes Engine (GKE) Standard cluster. During promotional events, spikes in user traffic cause existing Pods to reach CPU resource limits while newly created Pods remain in a 'Pending' state due to insufficient cluster node capacity. Which TWO actions must be implemented to automatically scale both the Pod workload and the underlying node infrastructure capacity? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Create a Horizontal Pod Autoscaler (HPA) targeting the application Deployment to scale Pod replica counts based on CPU utilization metrics.; Enable Cluster Autoscaler on the GKE node pool using the gcloud container clusters update command to automatically adjust node counts based on unschedulable Pods.

Answer

To automatically scale workload Pods and underlying cluster node capacity in GKE, the team must deploy a Horizontal Pod Autoscaler (HPA) to dynamically adjust Pod replica counts and enable Cluster Autoscaler on the GKE node pool to provision additional nodes for unschedulable Pods.
Handling both workload demand spikes and node capacity limits requires a two-tiered autoscaling strategy. Creating a Horizontal Pod Autoscaler (HPA) dynamically increases the number of Pod replicas when CPU usage surges. Concurrently, enabling Cluster Autoscaler on the GKE node pool ensures that when newly created Pods cannot be scheduled due to lack of available CPU/RAM on existing nodes, GKE automatically provisions new node instances.

Step-by-Step Solution

1
Identify workload-level scaling requirements
Recognize that high CPU utilization within existing Pods requires scaling the number of Pod replicas using Horizontal Pod Autoscaler (HPA).
HPA monitors resource metrics such as CPU usage and adjusts Deployment replica counts accordingly.
2
Identify infrastructure-level capacity constraints
Recognize that Pods remaining in a 'Pending' state indicate insufficient node capacity, which requires Cluster Autoscaler.
Cluster Autoscaler inspects the cluster for Pods in a Pending state due to resource requests and adds Compute Engine VMs to the node pool.
3
Combine dual-layer scaling mechanisms
HPA scales out Pod replicas when traffic spikes, and Cluster Autoscaler provisions new node VMs to host those additional Pod replicas.
Proper GKE resource management requires aligning workload scaling (HPA) with infrastructure scaling (Cluster Autoscaler).

Key Concept

GKE Dual-Layer Autoscaling (Horizontal Pod Autoscaler and Cluster Autoscaler)
Question 788Question →

Your team is deploying an internal microservices application across two Google Cloud Virtual Private Cloud (VPC) networks, `backend-vpc` and `analytics-vpc`, within the same project. You have created a Cloud DNS private zone named `internal-dev-zone` managing the domain `dev.example.internal`. Virtual machines in both VPC networks must be able to resolve domain names defined inside this private zone. Which TWO of the following actions are required to successfully enable DNS resolution for both networks?

Select all that apply

Show answer & explanation

Answer: Add both `backend-vpc` and `analytics-vpc` to the list of authorized VPC networks in the private zone settings.; Ensure the Cloud DNS API is explicitly enabled in the Google Cloud project where the DNS private zone is created.

Answer

The correct actions are to add both VPC networks (`backend-vpc` and `analytics-vpc`) to the authorized networks list of the Cloud DNS private zone and to ensure the Cloud DNS API is enabled in the host project.
To allow VMs across multiple VPC networks to resolve records in a Cloud DNS private zone, each VPC network must be explicitly added to the private zone's authorized networks list. Additionally, the Cloud DNS API must be enabled in the project containing the DNS resources for the service to function.

Step-by-Step Solution

1
Verify API Status
Confirm the Cloud DNS API (`dns.googleapis.com`) is enabled in the project hosting the infrastructure.
GCP services require explicit API enablement in the target project before resources can be configured.
2
Configure Authorized VPC Networks
In the Cloud DNS private zone creation/update settings, attach `backend-vpc` and `analytics-vpc` as authorized networks.
Private DNS zones are invisible to VPC networks unless explicitly authorized in the zone's network configuration list.

Key Concept

Cloud DNS Private Zone Authorization & VPC Network Scope
Question 789Question →

A telehealth company is planning the networking infrastructure for a global web application hosted on Compute Engine. The application serves static web assets to global clients while routing HTTPS API requests to backend instance groups in multiple regions based on user proximity. Internal microservices running inside the VPC network must also securely resolve private domain names without exposing DNS records to the public internet. Which TWO Google Cloud networking configurations should you implement to satisfy these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure a Global External Application Load Balancer with Cloud CDN enabled on the backend service to serve static content and route global HTTPS traffic.; Set up a Cloud DNS private zone bound to the application's VPC network for internal service name resolution.

Answer

The two correct configurations are enabling a Global External Application Load Balancer with Cloud CDN on the backend service and setting up a Cloud DNS private zone bound to the VPC network.
Global HTTPS proxy routing and Cloud CDN caching require an External Application Load Balancer operating at Layer 7. Meanwhile, internal domain resolution restricted to a specific VPC network requires a Cloud DNS private zone.

Step-by-Step Solution

1
Analyze external HTTP(S) and content caching requirements.
Selected Global External Application Load Balancer with Cloud CDN.
Cloud CDN requires an HTTP(S) Layer 7 load balancer to cache content at Google Cloud edge locations globally and route HTTPS requests based on proximity and backend capacity.
2
Analyze internal DNS resolution requirements.
Selected Cloud DNS private zone authorized for the VPC network.
Private DNS zones resolve domain names only for virtual machine instances authorized on specific VPC networks, preventing internal domain records from being exposed to the public internet.

Key Concept

Selecting Layer 7 Global Load Balancing with Cloud CDN for external web content caching alongside Cloud DNS private zones for VPC internal domain resolution.
Question 790Question →

An operations team runs a batch processing pipeline on a Google Kubernetes Engine (GKE) Standard cluster. During workload spikes, newly created Pods remain stuck in a Pending state because current nodes lack unallocated CPU capacity. Additionally, the team needs to reduce infrastructure spending specifically for fault-tolerant batch jobs without risking critical core services. Which TWO configurations should the team implement to address these operational requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Enable Cluster Autoscaler on the node pool to automatically provision additional Compute Engine instances when Pods cannot be scheduled due to insufficient resource requests.; Create a separate node pool utilizing Spot VMs for the batch workloads, and apply matching taints and tolerations to isolate fault-tolerant jobs onto these lower-cost nodes.

Answer

The correct operational choices are enabling Cluster Autoscaler on the node pool to provision nodes for unschedulable Pods, and deploying a dedicated Spot VM node pool with taints and tolerations to lower costs for fault-tolerant workloads.
Enabling Cluster Autoscaler directly addresses unschedulable Pending Pods by automatically expanding the node pool when CPU requests exceed available capacity. Additionally, creating a Spot VM node pool with appropriate taints and tolerations isolates fault-tolerant batch workloads onto lower-cost preemptible infrastructure, achieving the cost-reduction goal without affecting core workloads.

Step-by-Step Solution

1
Address the Pod scheduling bottleneck caused by node CPU allocation limits.
Enabling Cluster Autoscaler allows GKE to detect Pods in a Pending state due to resource deficits and automatically scale up node pool capacity.
Horizontal Pod Autoscaler (HPA) increases Pod counts, which would worsen node resource starvation rather than solving node capacity constraints.
2
Optimize infrastructure costs for non-critical, fault-tolerant batch workloads.
Provisioning a secondary node pool using Spot VMs reduces compute costs significantly. Applying taints to the Spot node pool and tolerations to the batch Pods prevents critical workloads from landing on preemptible hardware.
Spot VMs are ideal for workloads that can tolerate unexpected interruptions, providing significant discounts compared to standard VM instances.

Key Concept

GKE Cluster Autoscaler vs HPA scaling boundaries and Spot VM node pool isolation
Estimated Time:1m 30s
Question 791Question →

A cloud engineer needs to manually scale a running GKE Deployment named 'web-app' to 5 replicas and verify the deployment status using command-line tools. Arrange the operational 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 operational sequence is: 1) Retrieve cluster credentials via gcloud, 2) Inspect current deployment status using kubectl get deployment, 3) Scale the deployment to 5 replicas using kubectl scale, and 4) Verify new pod creation using kubectl get pods.
To manage Kubernetes resources from a local terminal, an engineer must first authenticate and obtain cluster credentials using gcloud. Next, inspecting the current deployment state establishes a baseline. Executing the scale command updates the Deployment manifest in the GKE control plane. Finally, querying pod status verifies successful scheduling and pod startup.

Step-by-Step Solution

1
Authenticate and set context
Local kubeconfig is populated with cluster endpoint and authentication details.
kubectl commands cannot communicate with the GKE control plane without valid cluster credentials.
2
Inspect workload baseline
Current deployment specifications and active replica counts are displayed.
Verifying current workload state confirms target deployment existence and establishes a baseline.
3
Scale workload replicas
Deployment spec desired replica count is updated to 5.
The scale command modifies the deployment spec to trigger Kubernetes controller reconciliation.
4
Verify pod status
All 5 pod instances are listed with Status: Running.
Operational verification ensures cluster nodes have successfully provisioned and started the requested pods.

Key Concept

Manual scaling and status verification of GKE Deployments using gcloud and kubectl CLI tools
Question 792Question →

An operations team needs to deploy a production backend Virtual Machine named `app-backend-prod` in zone `us-central1-a` using the `e2-standard-4` machine type. According to organization security compliance rules, the instance must connect to a custom subnetwork named `prod-app-subnet` within `prod-vpc`, must be assigned a fixed internal IP address of `10.150.0.45`, must not have a public external IP address attached, and must include the network tag `allow-internal-api` for firewall matching. Which `gcloud` command correctly provisions this Compute Engine VM instance?

Show answer & explanation

Answer: gcloud compute instances create app-backend-prod --zone=us-central1-a --machine-type=e2-standard-4 --network=prod-vpc --subnet=prod-app-subnet --private-network-ip=10.150.0.45 --no-address --tags=allow-internal-api

Answer

The command starting with 'gcloud compute instances create app-backend-prod --zone=us-central1-a --machine-type=e2-standard-4 --network=prod-vpc --subnet=prod-app-subnet --private-network-ip=10.150.0.45 --no-address --tags=allow-internal-api' is correct.
The correct response accurately combines `--private-network-ip=10.150.0.45` to set the fixed internal IP, `--no-address` to disable external IP assignment, and `--tags=allow-internal-api` to apply network tags on the specified subnet within `prod-vpc`.

Step-by-Step Solution

1
Identify the proper gcloud CLI flag for assigning a static internal IP address during instance creation.
The correct flag is `--private-network-ip=10.150.0.45`.
Compute Engine CLI uses `--private-network-ip` to specify custom internal IPv4 addresses for primary network interfaces.
2
Identify the proper gcloud CLI flag to prevent allocating an external IP address.
The correct flag is `--no-address`.
By default, gcloud assigns an ephemeral external IP unless `--no-address` is explicitly declared.
3
Identify the network tag flag for firewall rule association on compute instances.
The correct flag is `--tags=allow-internal-api`.
Firewall rules inspect instance network tags specified via `--tags` (unlike target tags specified in firewall rule resources).
4
Verify provisioning model parameters against application workload requirements.
Production core backends must use standard provisioning, avoiding Spot/Preemptible flags.
Spot instances can be reclaimed by GCP at any time and do not guarantee uptime SLAs.

Key Concept

Deploying Compute Engine instances with custom networking flags in gcloud CLI
Question 793Question →

A Cloud Engineer is using Google Cloud Deployment Manager templates stored in a central administrative project named `admin-ops-project` to provision VPC networks and Compute Engine instances into a newly created target project named `finance-workload-prod`. The engineer executes the following command from the Google Cloud CLI:

`gcloud deployment-manager deployments create workload-deployment --config=vpc_vm.yaml --project=finance-workload-prod`

The command fails with an error stating that `deploymentmanager.googleapis.com` is disabled or has not been used in project `finance-workload-prod`. The engineer confirms that the Cloud Deployment Manager API is already enabled in `admin-ops-project`. What should the engineer do to resolve this issue?

Show answer & explanation

Answer: Enable the Cloud Deployment Manager API in the target project finance-workload-prod.

Answer

Enable the Cloud Deployment Manager API in the target project finance-workload-prod.
In Google Cloud, API enablement is scoped strictly to the specific project where operations occur and resources are created. When deploying infrastructure via Deployment Manager into `finance-workload-prod`, the `deploymentmanager.googleapis.com` API must be enabled directly within `finance-workload-prod`, even if templates or deployment scripts are hosted in `admin-ops-project`.

Step-by-Step Solution

1
Identify the project context where resources are being created.
The target project specified by the `--project` flag is `finance-workload-prod`.
Google Cloud API services execute within the context of the resource destination project.
2
Analyze API enablement rules across Google Cloud projects.
Enabling an API in `admin-ops-project` does not enable it in `finance-workload-prod`.
API enablement is scoped strictly per project and is neither shared across independent projects nor inherited from resource hierarchy folders.
3
Select the correct remediation step.
Enable `deploymentmanager.googleapis.com` in `finance-workload-prod` using `gcloud services enable deploymentmanager.googleapis.com --project=finance-workload-prod`.
This satisfies the requirement for the target project to host active Deployment Manager service endpoints.

Key Concept

Target Project API Enablement Scope for Infrastructure as Code
Question 794Question →

You are troubleshooting an unresponsive Linux Compute Engine virtual machine instance that is failing to accept SSH connections. You need to view the raw system console boot logs to identify why the startup process halted. Which gcloud command should you run to inspect these logs?

Show answer & explanation

Answer: gcloud compute instances get-serial-port-output [INSTANCE_NAME]

Answer

The command 'gcloud compute instances get-serial-port-output [INSTANCE_NAME]' is the correct choice because it retrieves the serial port output (console log) of a Compute Engine instance, enabling administrators to diagnose boot errors when SSH is inaccessible.
The command 'gcloud compute instances get-serial-port-output [INSTANCE_NAME]' directly reads the serial port output of the specified instance. This is the Google-recommended approach for troubleshooting VM startup failures, kernel panics, or SSH connectivity issues.

Step-by-Step Solution

1
Identify the administrative requirement
The requirement is to inspect low-level system console boot logs for a Compute Engine instance that cannot be reached over the network or via SSH.
When a VM instance experiences boot failures or network misconfigurations, standard SSH access is unavailable.
2
Evaluate gcloud compute command options for console log retrieval
The command dedicated to fetching serial console output is 'gcloud compute instances get-serial-port-output'.
Compute Engine automatically buffers serial port 1 output, which contains kernel and bootloader startup messages.

Key Concept

Inspecting VM Serial Console Output for Diagnostics
Question 795Question →

A telemetry analysis firm is planning its Google Kubernetes Engine (GKE) cluster strategy. The deployment includes two main workloads: a stateless front-end API service that requires zero node-level operational overhead, and an advanced packet-inspection engine that requires custom Linux kernel settings (sysctl parameters) at the node OS level. Which two architectural decisions should the infrastructure team implement to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Provision a GKE Autopilot cluster to host the stateless front-end API service.; Provision a GKE Standard cluster with customized node pool configurations for the packet-inspection workload.

Answer

The infrastructure team should provision a GKE Autopilot cluster to host the stateless API service, and provision a GKE Standard cluster with customized node pool configurations for the packet-inspection workload.
GKE Autopilot is designed for hands-off management of standard stateless applications where Google manages node provisioning and security. GKE Standard provides full control over node infrastructure, allowing custom OS system configurations such as custom sysctl parameters.

Step-by-Step Solution

1
Evaluate workload operational requirements against GKE operational modes.
GKE Autopilot eliminates node management overhead for standard workloads, making it ideal for stateless web APIs.
Autopilot manages the underlying nodes completely, taking care of node provisioning, auto-repairs, and upgrades.
2
Evaluate workload requirements for host OS kernel customization.
GKE Standard is required for workloads needing custom sysctl kernel configurations.
Autopilot enforces a secure node security baseline and prohibits custom node configuration or host sysctl modifications.

Key Concept

Selecting between GKE Autopilot and GKE Standard based on node management overhead and node-level kernel customization requirements.
Question 796Question →

A cloud engineer needs to deploy a Google Cloud Bigtable instance named `telemetry-db` to store high-throughput IoT sensor data. The project deployment specification requires a cluster named `telemetry-c1` located in the `us-central1-a` zone, provisioned with 3 nodes using SSD storage. Which `gcloud` command correctly provisions this managed database instance?

Show answer & explanation

Answer: gcloud bigtable instances create telemetry-db --display-name="Telemetry DB" --cluster=telemetry-c1 --cluster-zone=us-central1-a --cluster-num-nodes=3 --cluster-storage-type=SSD

Answer

Execute `gcloud bigtable instances create telemetry-db --display-name="Telemetry DB" --cluster=telemetry-c1 --cluster-zone=us-central1-a --cluster-num-nodes=3 --cluster-storage-type=SSD` to provision the Cloud Bigtable instance and cluster.
The correct option uses `gcloud bigtable instances create` and supplies all required parameters: instance ID (`telemetry-db`), `--display-name`, `--cluster`, `--cluster-zone=us-central1-a`, `--cluster-num-nodes=3`, and `--cluster-storage-type=SSD`. This fulfills all specified operational requirements.

Step-by-Step Solution

1
Identify the target database technology
Cloud Bigtable is required for high-throughput IoT time-series sensor data.
Cloud Bigtable is Google Cloud's managed NoSQL wide-column database service for large-scale analytical and operational workloads.
2
Identify the required gcloud CLI command group
Use `gcloud bigtable instances create` instead of `gcloud sql instances create`.
Cloud Bigtable resources are managed under the `gcloud bigtable` CLI group.
3
Verify required CLI flags for instance and cluster creation
Specify `--cluster`, `--cluster-zone`, `--cluster-num-nodes`, and `--cluster-storage-type`.
Creating a Bigtable instance requires defining its initial cluster properties using the `--cluster-*` flag family.

Key Concept

Provisioning Cloud Bigtable Instances via Google Cloud CLI
Question 797Question →

A cloud engineer is securing a custom-mode Virtual Private Cloud (VPC) named `sec-corp-vpc` hosting PCI-DSS compliant workloads across multiple regions. The compliance baseline requires that all outbound (egress) network traffic from instances to internet destinations (0.0.0.0/00.0.0.0/0) must be blocked by default. However, Compute Engine virtual machines designated with the service account `[email protected]` must be allowed to make outbound HTTPS requests (TCP port 443) to external payment gateways. Assuming only the implicit VPC firewall rules currently exist, which configuration of `gcloud compute firewall-rules create` commands correctly enforces this security policy?

Show answer & explanation

Answer: Create an egress DENY rule for protocol `all` to destination `0.0.0.0/0` with priority 200 targeting all instances, and create an egress ALLOW rule for protocol `tcp:443` to destination `0.0.0.0/0` with priority 100 specifying `--target-service-accounts=payment-processor@prod-project.iam.gserviceaccount.com`.

Answer

Create an egress DENY rule for protocol all to destination 0.0.0.0/0 with priority 200 targeting all instances, and create an egress ALLOW rule for protocol tcp:443 to destination 0.0.0.0/0 with priority 100 specifying --target-service-accounts=payment-processor@prod-project.iam.gserviceaccount.com.
The correct option sets up a priority 100 egress ALLOW rule targeted specifically to the payment processor service account for HTTPS traffic (`tcp:443`), alongside a priority 200 egress DENY rule for all protocols (`all`) to `0.0.0.0/0`. Because GCP evaluates lower priority numbers first (100 before 200), traffic matching the service account and port 443 is explicitly permitted, while all other outbound traffic from any instance hits the priority 200 rule and is denied before falling back to the implicit priority 65535 allow rule.

Step-by-Step Solution

1
Analyze implicit VPC firewall rules for egress traffic.
GCP VPC networks include an implicit 'allow all egress' rule at priority 65535 (lowest precedence). To restrict egress, custom rules with higher precedence (lower priority numbers) must be created.
Explicit firewall rules are needed to override default network behavior.
2
Determine priority evaluation order for firewall rules.
GCP firewall rule priority ranges from 0 (highest precedence) to 65535 (lowest precedence). A rule with priority 100 is evaluated before a rule with priority 200.
The more specific ALLOW rule must have a smaller priority number than the general DENY rule so that permitted traffic matches first.
3
Map target requirements to gcloud parameters.
To restrict outbound traffic to specific VMs securely, use `--direction=EGRESS`, `--action=ALLOW`, `--rules=tcp:443`, `--destination-ranges=0.0.0.0/0`, and `--target-service-accounts=payment-processor@prod-project.iam.gserviceaccount.com` at priority 100, alongside a broad `--direction=EGRESS`, `--action=DENY`, `--rules=all`, `--destination-ranges=0.0.0.0/0` at priority 200.
Service accounts provide secure, identity-based target selection for firewall rules that cannot be spoofed like network tags.

Key Concept

VPC Firewall Rule Priority and Egress Target Service Account Filtering
Estimated Time:2m 0s
Question 798Question →

A DevOps engineer is configuring governance controls on Google Cloud to prevent budget overruns in a development environment. When monthly expenditure reaches 80% of the defined threshold, non-essential Compute Engine instances must be stopped automatically. Which configuration strategy correctly enables this programmatic action?

Show answer & explanation

Answer: Link a Cloud Pub/Sub topic to the Cloud Billing budget notification settings, and write a Cloud Function triggered by Pub/Sub messages to stop the target instances.

Answer

Publish budget threshold alerts to a Cloud Pub/Sub topic, which triggers a Cloud Function programmatically designed to call Compute Engine APIs and stop running instances.
Cloud Billing budgets send notifications via email and Pub/Sub topics when actual or forecasted spend crosses specified threshold percentages. To achieve automated resource shutdown or cost capping, you must publish budget messages to a Pub/Sub topic and consume those messages with an automated service such as a Cloud Function that calls the Compute Engine API to stop instances.

Step-by-Step Solution

1
Configure budget alert settings in Cloud Billing
Budget threshold rules (e.g., 80% of budget) are set to send notifications.
Budgets track current and forecasted costs against specified spending limits.
2
Attach a Cloud Pub/Sub topic to the billing budget
JSON-formatted billing alert messages are published to the topic when thresholds are met.
Native GCP billing budgets only publish event messages and send emails; they cannot directly stop resources.
3
Deploy an event-driven Cloud Function or Cloud Run service
The function executes upon receiving Pub/Sub messages and uses Compute Engine APIs to stop non-essential VMs.
Programmatic cost control requires custom code listening to Pub/Sub events.

Key Concept

Cloud Billing budgets issue email and Pub/Sub notifications but require Pub/Sub subscriber integration (such as Cloud Functions) to automate resource enforcement or shutdown.
Question 799Question →

An organization's security compliance team needs to audit Google Cloud Pub/Sub resource configurations and inspect subscription metrics across all projects inside a designated Folder. However, compliance policies strictly prohibit the team from viewing or pulling actual Pub/Sub message payloads. Following Google Cloud recommended best practices and the principle of least privilege, which TWO predefined IAM roles should be granted to the security compliance team at the Folder level?

Select all that apply

Show answer & explanation

Answer: Pub/Sub Viewer (roles/pubsub.viewer); Monitoring Viewer (roles/monitoring.viewer)

Answer

The correct roles to grant are Pub/Sub Viewer (roles/pubsub.viewer) and Monitoring Viewer (roles/monitoring.viewer).
To satisfy the audit requirements under the principle of least privilege, the compliance team requires two distinct capabilities: metadata visibility for Pub/Sub resources and read access to monitoring metrics. The Pub/Sub Viewer role allows inspecting topics, subscriptions, and configurations without granting message pulling permissions. The Monitoring Viewer role provides access to view metrics such as backlog sizes and message throughput in Cloud Monitoring. Inherited at the Folder level, these two predefined roles provide full folder-wide compliance auditing while protecting payload privacy.

Step-by-Step Solution

1
Analyze access requirements and security constraints
The team needs access to resource configurations (metadata) and performance metrics, but must not be allowed to pull or read message contents.
Security compliance requires auditing setup and operational metrics without exposing sensitive message data.
2
Select the least-privilege IAM role for resource configuration visibility
Pub/Sub Viewer (roles/pubsub.viewer) allows viewing topics and subscriptions without message consumption rights.
Other roles such as Pub/Sub Subscriber permit pulling message payloads.
3
Select the least-privilege IAM role for metrics visibility
Monitoring Viewer (roles/monitoring.viewer) provides access to Cloud Monitoring metrics across the folder.
This allows monitoring subscription message counts and rate metrics safely.

Key Concept

Selecting predefined IAM roles for resource metadata and monitoring under the principle of least privilege.
Question 800Question →

A cloud engineer needs to migrate workloads from an existing GKE Standard node pool to a new node pool configured with larger machine types without causing application downtime. In what sequence should the engineer execute these operational steps to perform the migration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: first, provision the new node pool; second, cordon the old nodes to block new Pod assignments; third, drain the old nodes to migrate running Pods to the new pool; and fourth, delete the old node pool.
To migrate GKE workloads seamlessly to a new node pool without downtime, the target infrastructure must exist first (`gcloud container node-pools create`). Next, cordoning the old nodes (`kubectl cordon`) ensures that no new Pods land on nodes scheduled for removal. Draining the old nodes (`kubectl drain`) then gracefully terminates existing Pods so Kubernetes reschedules them on the newly available nodes. Finally, after all Pods are running healthily on the new node pool, the old node pool can be safely deleted (`gcloud container node-pools delete`).

Step-by-Step Solution

1
Create the destination node pool
Additional compute capacity is added to the cluster to receive workloads.
You cannot migrate running Pods off existing nodes unless replacement node capacity already exists.
2
Mark old nodes as unschedulable (cordon)
Old nodes stop accepting new Pod assignments.
Cordoning prevents new or rescheduled Pods from placing themselves back onto the nodes slated for removal.
3
Evict Pods gracefully (drain)
Pods are safely terminated and recreated on the new node pool by their controller deployments.
Draining respects PodDisruptionBudgets and allows graceful termination of application processes.
4
Decommission the old node pool
Unused compute resources are removed from Google Cloud, stopping billing for the old nodes.
Deleting the node pool is the final step after verifying all workloads are running in the new pool.

Key Concept

Zero-downtime GKE Node Pool Migration using Cordon and Drain
PreviousPage 40 / 80Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin