All practice questions

1591 questions

Question 901Question

An organization runs a web application deployed on a Google Kubernetes Engine (GKE) Standard cluster. During unexpected traffic surges, CPU utilization across application pods increases significantly, causing latency. The underlying node pool currently has sufficient unallocated CPU and memory capacity to host additional pods, but the application does not automatically scale up the number of pod replicas. Which solution should the DevOps team implement to dynamically scale the application pod count based on resource demand?

Show answer & explanation

Answer: Configure a Horizontal Pod Autoscaler (HPA) resource targeting the application Deployment.

Answer

Configure a Horizontal Pod Autoscaler (HPA) resource targeting the application Deployment.
Configuring a Horizontal Pod Autoscaler (HPA) allows GKE to automatically scale the number of pod replicas in the Deployment up or down according to measured CPU utilization. Because the node pool already has available capacity, increasing pod replicas directly addresses the workload bottleneck without requiring node scaling.

Step-by-Step Solution

1
Identify the scaling requirement based on workload demand.
Recognize that the bottleneck is insufficient pod replicas despite existing node capacity.
The cluster nodes have free compute capacity, so adding worker nodes will not resolve unscaled workload replicas.
2
Select the appropriate GKE autoscaling mechanism for pod workload scaling.
Determine that Horizontal Pod Autoscaler (HPA) targets Kubernetes Deployments to scale pod instances dynamically based on metrics like CPU utilization.
HPA scales the number of running pod replicas horizontally when targeted utilization thresholds are met.

Key Concept

GKE Workload Autoscaling with Horizontal Pod Autoscaler (HPA)
Question 902Question

A cloud engineer needs to update a containerized workload deployed on a Google Kubernetes Engine (GKE) cluster. During the deployment image update, the new container version fails readiness checks, causing the rollout to stall. Arrange the operational steps in the correct chronological sequence to update the deployment, monitor the rollout, diagnose the failure, and revert the deployment to its previous healthy state.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Update the deployment image using `kubectl set image`, 2) Monitor the deployment update using `kubectl rollout status`, 3) Inspect pod details and logs using `kubectl describe pod` and `kubectl logs`, and 4) Revert the deployment to its previous revision using `kubectl rollout undo`.
The proper GKE workload management lifecycle requires first applying the image change (`kubectl set image`), tracking the deployment status (`kubectl rollout status`), inspecting errors when the rollout stalls (`kubectl describe pod` / `kubectl logs`), and finally executing a rollback (`kubectl rollout undo`) to restore service availability.

Step-by-Step Solution

1
Trigger the workload update.
The GKE cluster updates the deployment spec and begins creating new ReplicaSet pods with the updated container image.
Applying the updated image tag with `kubectl set image` is the initial action required to start a GKE deployment update.
2
Track rollout progress.
The engineer observes that the deployment rollout is stuck awaiting pod readiness.
Executing `kubectl rollout status` provides real-time feedback on whether new pods successfully pass readiness probes.
3
Diagnose pod failure details.
The error root cause (such as a missing configuration parameter or failing readiness probe) is revealed.
Running `kubectl describe pod` inspects lifecycle events while `kubectl logs` retrieves standard output streams from crashing or unready containers.
4
Execute deployment rollback.
GKE terminates unready pods and restores the prior stable ReplicaSet.
Issuing `kubectl rollout undo` safely restores workload availability without needing manual manifest modifications.

Key Concept

Managing GKE Workload Rollouts and Troubleshooting
Question 903Question

To support a microservices backend, a devops team is deploying a new Cloud SQL for PostgreSQL database instance. Company governance rules require that the database use Private IP connectivity over an established Private Services Access connection within the VPC, while also maintaining high availability with regional redundancy. Which TWO options correctly specify the required `gcloud sql instances create` flags to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Specify `--network=VPC_NAME` together with `--no-assign-ip` to enforce Private IP connectivity without exposing a public IP address.; Specify `--availability-type=REGIONAL` to configure primary and standby instances in different zones within the selected region.

Answer

The correct requirements are to specify `--network=VPC_NAME` with `--no-assign-ip` for private connectivity and `--availability-type=REGIONAL` for high availability.
Provisioning a secure, highly available Cloud SQL instance requires disabling public IP assignment (`--no-assign-ip`) while attaching to a VPC network (`--network`), and setting regional availability (`--availability-type=REGIONAL`) to maintain synchronous replication across zones.

Step-by-Step Solution

1
Analyze private connectivity requirements for Cloud SQL
To restrict access exclusively to private IP inside a VPC via Private Services Access, `--network` must be set to the target VPC and public IP allocation must be disabled using `--no-assign-ip`.
Omitting `--no-assign-ip` assigns a public IP address by default.
2
Analyze high availability requirements
To enable automatic regional failover with a primary and standby replica, `--availability-type=REGIONAL` must be specified.
The default availability type is `ZONAL`, which provides no automatic cross-zone failover.

Key Concept

Provisioning Cloud SQL instances with Private IP connectivity and High Availability using the gcloud CLI
Question 904Question

Your organization runs batch processing workloads on Google Compute Engine that are fault-tolerant and can be paused or restarted without losing progress. You want to significantly reduce compute expenses by utilizing Google Cloud's unused capacity. Which VM provisioning option should you select?

Show answer & explanation

Answer: Provision the virtual machines as Spot VMs.

Answer

Provision the virtual machines as Spot VMs.
Provisioning virtual machines as Spot VMs allows workloads to run on unused Google Cloud capacity at deeply discounted rates. Because the batch job is described as fault-tolerant and interruptible, it aligns perfectly with Spot VM behavior.

Step-by-Step Solution

1
Analyze workload characteristics
Identified that the batch workload is fault-tolerant and can tolerate interruptions.
Fault tolerance is the essential prerequisite for safely running workloads on preemptible compute resources.
2
Evaluate Google Cloud cost optimization options for Compute Engine
Spot VMs offer discounts up to 60-90% compared to standard on-demand pricing in exchange for potential preemption when capacity is needed elsewhere.
Using spare capacity via Spot VMs is Google Cloud's recommended strategy for batch and interruptible workloads.

Key Concept

Cost Optimization with Spot VMs
Question 905Question

A Cloud Engineer is tasked with deploying a secure Python microservice to Google Cloud Run using the gcloud CLI. The deployment must adhere to least-privilege security practices by using a custom execution service account, building and storing the container image in Artifact Registry, blocking public unauthenticated HTTP access, and granting invocation permissions to a specific caller service account. Arrange the following deployment and configuration steps in the correct chronological sequence from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: 1) Create the dedicated custom IAM service account, 2) Build and push the container image to Artifact Registry using gcloud builds submit, 3) Deploy the container image to Cloud Run specifying the custom service account and disabling unauthenticated access, and 4) Grant the Cloud Run Invoker role (roles/run.invoker) on the deployed service to the authorized caller principal.
The correct order follows the lifecycle dependencies of GCP resource creation and deployment. First, the runtime execution identity (service account) must be created so it is available for reference. Second, the container image must be built and pushed to Artifact Registry using Cloud Build. Third, Cloud Run deploys the image while attaching the runtime service account and blocking unauthenticated access. Finally, after the service resource is deployed, resource-level IAM policy bindings (Cloud Run Invoker) can be added to allow access to the designated caller.

Step-by-Step Solution

1
Create the custom execution service account
An IAM service account principal is created in Google Cloud Identity/IAM.
Cloud Run deployment flags require an existing service account email address when binding execution identity during service creation.
2
Build and push the container image to Artifact Registry
The container artifact URI is generated and ready for deployment.
Cloud Run requires a valid container image location in Container Registry or Artifact Registry to instantiate revisions.
3
Execute gcloud run deploy with security flags
The Cloud Run service resource is instantiated with unauthenticated access blocked.
Deploying the service instantiates the resource and configures runtime settings like the execution service account and ingress authentication requirement.
4
Bind roles/run.invoker to the caller principal on the Cloud Run service
The caller principal is granted permission to invoke the private HTTP endpoint.
IAM policy bindings targeting specific Cloud Run service resources require the service to already exist in the project.

Key Concept

Deploying Cloud Run services with custom execution identities, Artifact Registry builds, and resource-level IAM invoker permissions
Question 906Question

A cloud engineer is responsible for managing a Google Cloud Storage bucket used for user-submitted document processing. To maintain efficient operations and avoid unexpected charges, the engineer must configure Object Lifecycle Management to meet two criteria: automatically remove incomplete upload attempts older than 7 days, and move previous object versions to a lower-cost tier after 30 days of becoming noncurrent. Which two lifecycle rules should be configured on the Cloud Storage bucket? (Select TWO options.)

Select all that apply

Show answer & explanation

Answer: Configure a lifecycle rule with the action set to Delete for incomplete multipart uploads with an age exceeding 7 days.; Configure a lifecycle rule with the action set to change the storage class to Nearline when DaysSinceNoncurrentTime reaches 30 days.

Answer

The two correct operational configurations are: adding a lifecycle rule with the action set to Delete for incomplete multipart uploads older than 7 days, and adding a rule that sets the storage class to Nearline when the condition DaysSinceNoncurrentTime reaches 30 days.
To manage Cloud Storage buckets effectively, Object Lifecycle Management rules allow administrators to automate object transitions and cleanups. Using the action to delete incomplete multipart uploads after 7 days prevents wasted storage from failed upload sessions. Using the condition based on days since an object became noncurrent allows seamless tiering of previous versions to cheaper storage classes like Nearline without impacting active live objects.

Step-by-Step Solution

1
Identify the requirement for cleaning up failed or partial object uploads.
Recognize that Cloud Storage Object Lifecycle Management provides a specific rule action to abort/delete incomplete multipart uploads based on their age.
Incomplete multipart uploads consume storage space and continue billing until aborted or deleted.
2
Identify the requirement for managing older versioned objects.
Select the condition DaysSinceNoncurrentTime set to 30 combined with the action SetStorageClass to Nearline (or Coldline).
This condition specifically evaluates objects that have become noncurrent due to replacement or deletion in a version-enabled bucket.

Key Concept

Cloud Storage Object Lifecycle Management configuration for versioning and multipart upload cleanup.
Question 907Question

To accommodate an upcoming peak workload, a cloud infrastructure engineer must release a performance-tuned container image `gcr.io/prod-project/event-handler:v2` as a new revision for an existing Cloud Run service named `event-handler`. The operational specification demands that the new container revision must maintain a minimum of 5 warm instances, process up to 250 concurrent requests per container instance, and initially receive exactly 15% of live production traffic, with the remaining 85% remaining assigned to the baseline revision `event-handler-v1`. Which command execution workflow correctly implements this deployment without inadvertently routing 100% of live traffic to the new revision upon deployment?

Show answer & explanation

Answer: Execute `gcloud run deploy event-handler --image gcr.io/prod-project/event-handler:v2 --concurrency 250 --min-instances 5 --no-traffic` followed by `gcloud run services update-traffic event-handler --to-revisions event-handler-v1=85,event-handler-v2=15`

Answer

Deploy the new revision using `gcloud run deploy event-handler --image gcr.io/prod-project/event-handler:v2 --concurrency 250 --min-instances 5 --no-traffic`, then update the traffic allocation using `gcloud run services update-traffic event-handler --to-revisions event-handler-v1=85,event-handler-v2=15`.
The correct option deploys the revision while suppressing immediate traffic assignment via `--no-traffic`, configures container concurrency (`--concurrency 250`) and minimum warm instances (`--min-instances 5`), and subsequently executes `gcloud run services update-traffic` to split live traffic between `event-handler-v1` (85%) and `event-handler-v2` (15%).

Step-by-Step Solution

1
Deploy the new container image revision with configuration flags and traffic prevention.
Revision `event-handler-v2` is created with 250 max concurrency and 5 minimum warm instances, receiving 0% traffic.
The `--no-traffic` flag prevents Cloud Run's default behavior of automatically directing 100% of live traffic to newly deployed revisions.
2
Execute the traffic update command referencing the explicit revision identifiers and percentage split.
Production traffic is updated so that `event-handler-v1` serves 85% and `event-handler-v2` serves 15%.
The `gcloud run services update-traffic` command allows precise canary traffic splitting across revision names.

Key Concept

Cloud Run Revision Management, Concurrency Settings, and Traffic Splitting
Question 908Question

A logistics platform models monthly infrastructure costs in the Google Cloud Pricing Calculator for a fleet tracking service. The workload requires 5 N1 compute instances running continuously for 730 hours per month at a baseline rate of 0.20perhourperinstance.GoogleCloudautomaticallyappliesa300.20 per hour per instance. Google Cloud automatically applies a 30% Sustained Use Discount (SUD) to N1 instance compute charges for 100% monthly utilization. In addition, each instance is attached to 200 GB of Standard Persistent Disk storage priced at 0.05 per GB per month. Note that Persistent Disk pricing is not eligible for Sustained Use Discounts. What is the total estimated monthly cost, in dollars, for this workload?

Show answer & explanation

Answer: 561

Answer

The total estimated monthly cost for the workload is $561.00.
The correct calculation computes the baseline compute cost (730.00),appliesthe30730.00), applies the 30% Sustained Use Discount to arrive at 511.00, and adds the un-discounted Persistent Disk cost of 50.00toyieldatotalmonthlycostof50.00 to yield a total monthly cost of 561.00.

Step-by-Step Solution

1
Calculate the gross compute cost for all instances.
$730.00
5 instances running for 730 hours each at 0.20/hourequals57300.20/hour equals 5 * 730 * 0.20 = $730.00.
2
Apply the Sustained Use Discount (SUD) to compute charges.
$511.00
Continuous monthly usage on N1 instances qualifies for a 30% discount on compute charges (730.000.70=730.00 * 0.70 = 511.00).
3
Calculate the total Persistent Disk storage cost.
$50.00
5 instances with 200 GB each equals 1,000 GB total at $0.05/GB/month. Persistent Disk is not eligible for SUD.
4
Sum the net compute cost and persistent storage cost.
$561.00
511.00(netcompute)+511.00 (net compute) + 50.00 (storage) = $561.00.

Key Concept

Sustained Use Discounts apply automatically to eligible Compute Engine VM instance hours but do not apply to attached Persistent Disk storage.
Estimated Time:2m 0s
Question 909Question

An application engineer accidentally deleted critical database tables in a production Cloud SQL for MySQL instance named `prod-db`. You need to perform a Point-in-Time Recovery (PITR) to restore the database to its state exactly 30 minutes prior to the deletion into a new instance named `prod-db-restored`, verify the data, and switch application traffic. In what order should you execute these operational recovery steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: first, identify the target timestamp from Cloud Audit Logs; second, execute `gcloud sql instances clone` with the `--point-in-time` parameter; third, connect to the new instance to validate recovered data; and fourth, update application database connection configurations to point to the restored instance.
The correct recovery procedure starts by identifying the exact timestamp of the event using Cloud Audit Logs. Next, `gcloud sql instances clone` is executed with the `--point-in-time` flag to create a new instance initialized to that timestamp. Once the instance is provisions, data integrity is verified. Finally, application configurations are updated to point to the newly restored instance.

Step-by-Step Solution

1
Determine the exact historical timestamp from Cloud Audit Logs or database event logs.
Obtained a precise ISO 8601 timestamp prior to the accidental table drop.
Point-in-time recovery requires a specific timestamp to replay binary logs up to that exact moment.
2
Execute the point-in-time clone command via the Google Cloud CLI.
Cloud SQL creates `prod-db-restored` using the latest base backup and replays transaction logs up to the specified point in time.
In GCP Cloud SQL, point-in-time recovery to a new instance is performed using the `gcloud sql instances clone` command with the `--point-in-time` flag.
3
Query the restored database instance `prod-db-restored`.
Verified that all deleted tables exist and data consistency is confirmed.
Verification ensures that the chosen recovery timestamp was correct and that data is intact before sending live traffic.
4
Reconfigure application connection parameters.
Applications seamlessly connect to `prod-db-restored` and resume normal operation.
Traffic must be redirected to the restored instance to restore service functionality.

Key Concept

Cloud SQL Point-in-Time Recovery (PITR) using gcloud instances clone
Question 910Question

Your organization is deploying a non-critical, fault-tolerant batch processing workload on Google Compute Engine and needs to grant operational management access to a team member. Which TWO actions should you take to satisfy cost optimization guidelines and enforce the principle of least privilege?

Select all that apply

Show answer & explanation

Answer: Deploy the workload instances using Spot VMs to take advantage of significantly discounted compute pricing for fault-tolerant tasks.; Grant the team member the Compute Instance Admin (v1) predefined role (roles/compute.instanceAdmin.v1) to allow full operational management of VM instances.

Answer

Deploy the batch workload on Spot VMs for cost savings, and assign the Compute Instance Admin (v1) predefined role to enforce least privilege access control.
Deploying fault-tolerant batch workloads on Spot VMs maximizes cost efficiency because these workloads can handle VM preemption gracefully. Assigning the predefined Compute Instance Admin (v1) role provides full administrative control over VM instances while maintaining security compliance under the principle of least privilege.

Step-by-Step Solution

1
Analyze workload requirements for compute instance selection.
Identified the batch workload as fault-tolerant and non-critical, making it a perfect fit for Spot VMs.
Spot VMs lower compute costs significantly while allowing preemption when capacity is needed elsewhere.
2
Evaluate IAM access control options for VM operational management.
Selected the predefined role roles/compute.instanceAdmin.v1 for the team member.
Predefined Compute Engine roles restrict permissions specifically to VM operations, adhering to least privilege.

Key Concept

Compute Engine Resource Management and IAM Role Scoping
Question 911Question

A lead cloud engineer needs to deploy a new production Cloud SQL for PostgreSQL database instance named `analytics-db` in the `us-east1` region using the `gcloud` CLI. Corporate security policies require that the database instance communicate exclusively over private IP addresses within a Virtual Private Cloud (VPC) named `production-vpc`, and that no public IPv4 address is assigned to the database instance. Which `gcloud` command correctly deploys the database instance to satisfy these security and network requirements?

Show answer & explanation

Answer: gcloud sql instances create analytics-db --database-version=POSTGRES_15 --tier=db-custom-4-16384 --region=us-east1 --network=projects/my-project/global/networks/production-vpc --no-assign-ip

Answer

The command 'gcloud sql instances create analytics-db --database-version=POSTGRES_15 --tier=db-custom-4-16384 --region=us-east1 --network=projects/my-project/global/networks/production-vpc --no-assign-ip' correctly provisions the private Cloud SQL instance without a public IP.
The option specifying `--network=projects/my-project/global/networks/production-vpc` and `--no-assign-ip` is correct because `--network` connects the Cloud SQL instance to the VPC network via Private Service Access, and `--no-assign-ip` explicitly prevents Google Cloud from assigning a public IPv4 address to the instance.

Step-by-Step Solution

1
Identify database engine requirements
Cloud SQL for PostgreSQL requires using the `gcloud sql instances create` command group.
The scenario requires a managed PostgreSQL relational database instance.
2
Configure network and private IP flags
Pass `--network=projects/my-project/global/networks/production-vpc` to specify the private VPC.
Connecting Cloud SQL to a private network requires establishing private service access via the `--network` parameter.
3
Enforce zero public IP exposure
Include the `--no-assign-ip` flag in the provisioning command.
By default, Cloud SQL assigns a public IP unless explicitly suppressed with `--no-assign-ip`.

Key Concept

Deploying Cloud SQL instances with Private IP connectivity and suppressing public IP allocation via the gcloud CLI
Question 912Question

An enterprise application utilizing Cloud SQL for PostgreSQL experienced data corruption due to an accidental table deletion at 14:15:00 UTC. Point-in-time recovery (PITR) via write-ahead logging is active on the instance `db-main`. You must restore the database to its exact state at 14:14:00 UTC into a new instance and cut over production traffic while retaining the original instance for post-mortem inspection.

In what order should you execute these operational recovery steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of operations is: 1) Identify the target pre-corruption timestamp (14:14:00 UTC), 2) Clone the instance to `db-recovery` at that point in time using the `gcloud sql instances clone` command with the `--point-in-time` flag, 3) Perform data integrity validation on `db-recovery`, and 4) Update application connection parameters to redirect production traffic to `db-recovery`.
Point-in-Time Recovery (PITR) in Cloud SQL for PostgreSQL is performed by cloning the source instance into a new target instance using `gcloud sql instances clone` with the `--point-in-time` parameter. The workflow requires identifying the timestamp prior to corruption first, running the clone command second, validating data integrity on the new instance third, and updating application connection strings fourth.

Step-by-Step Solution

1
Determine target timestamp
Target timestamp identified as 14:14:00 UTC.
PITR requires specifying a precise timestamp prior to the failure event.
2
Provision cloned instance using gcloud CLI
Created new instance `db-recovery` containing the state at 14:14:00 UTC.
In Cloud SQL, PITR is accomplished by executing `gcloud sql instances clone` with the `--point-in-time` parameter.
3
Validate restored data integrity
Confirmed the deleted table and records are intact on `db-recovery`.
Validation prevents switching application traffic to an incomplete or flawed database state.
4
Cut over application traffic
Production workloads successfully connect to `db-recovery`.
Finalizes the recovery process by restoring active service functionality.

Key Concept

Cloud SQL Point-in-Time Recovery (PITR) and Instance Cloning Workflow
Question 913Question

A healthcare analytics application hosted on Compute Engine requires a managed database service to store high-throughput, real-time IoT device telemetry metrics. The application processes high volumes of non-relational time-series data with unpredictable write spikes and requires sub-millisecond write latency without needing complex relational joins. Which Google Cloud database service should you recommend to meet these performance requirements with minimal operational overhead?

Show answer & explanation

Answer: Cloud Bigtable

Answer

Cloud Bigtable is the recommended service for high-throughput, low-latency, non-relational time-series telemetry metrics.
Cloud Bigtable is Google Cloud's fully managed NoSQL wide-column database service optimized for petabyte-scale, high-throughput analytics, time-series data, and real-time streaming metrics with microsecond-to-millisecond latency.

Step-by-Step Solution

1
Analyze the workload requirements
Identified key constraints: high-throughput time-series data, non-relational key-value access pattern, sub-millisecond write latency, and minimal operational overhead.
Matching technical requirements to the appropriate Google Cloud storage/database solution ensures optimal performance and cost-efficiency.
2
Evaluate database engine paradigms
Cloud Bigtable is built specifically for large-scale NoSQL key-value and time-series data under high read/write load.
Relational databases like Cloud SQL struggle to deliver scalable sub-millisecond write latency for massive IoT streaming metrics without severe performance degradation or high cost.

Key Concept

Selecting Cloud Bigtable for high-throughput, non-relational time-series and IoT telemetry workloads.
Question 914Question

A data engineering team needs to provision a new Cloud SQL for PostgreSQL instance named `analytics-db` in the `us-central1` region. Security policy specifies that if a public IP is enabled on the instance, connectivity must be restricted exclusively to the corporate network IP range `198.51.100.0/24`. Furthermore, to avoid database outage caused by running out of disk space, automatic storage capacity expansion must be configured during deployment. Which `gcloud` command correctly deploys the database instance according to these requirements?

Show answer & explanation

Answer: gcloud sql instances create analytics-db --database-version=POSTGRES_15 --region=us-central1 --authorized-networks=198.51.100.0/24 --storage-auto-increase

Answer

The command 'gcloud sql instances create analytics-db --database-version=POSTGRES_15 --region=us-central1 --authorized-networks=198.51.100.0/24 --storage-auto-increase' correctly provisions the Cloud SQL for PostgreSQL instance in us-central1, limits public network ingress to 198.51.100.0/24, and enables dynamic storage capacity expansion.
The correct option executes 'gcloud sql instances create' with '--region=us-central1', specifies '--authorized-networks=198.51.100.0/24' to restrict public connectivity to the corporate CIDR range, and sets '--storage-auto-increase' to automatically scale storage capacity when needed.

Step-by-Step Solution

1
Identify the managed database service required by the workload.
Cloud SQL for PostgreSQL requires using the 'gcloud sql instances create' group command.
Cloud SQL is the managed relational database service in Google Cloud for PostgreSQL workloads.
2
Specify network access restrictions for public IP endpoints.
Pass '--authorized-networks=198.51.100.0/24' to limit incoming connections to the corporate network.
Without authorized network CIDR restrictions, instances with public IP addresses permit access from any source IP.
3
Configure storage autoscaling flags during creation.
Include the '--storage-auto-increase' flag in the deployment command.
This setting allows Google Cloud to automatically expand disk storage when available capacity drops low, avoiding database outages.

Key Concept

Provisioning Cloud SQL instances via gcloud CLI with network access controls and automatic storage growth.
Question 915Question

A financial operations analyst needs to create and manage spend budgets and budget threshold email alerts for a company's primary Google Cloud Billing account. To adhere to the principle of least privilege, the analyst must not be granted permissions to modify payment details, link or unlink projects, or manage billing account IAM roles. Which IAM role should be assigned to the analyst on the Cloud Billing account?

Show answer & explanation

Answer: Billing Account Costs Manager (roles/billing.costsManager)

Answer

Billing Account Costs Manager (roles/billing.costsManager)
The Billing Account Costs Manager role (roles/billing.costsManager) grants the precise permissions required to create, update, and manage budgets and budget alerts on a Cloud Billing account. It does not grant broader administrative privileges such as managing payment accounts or assigning roles, satisfying the least-privilege requirement.

Step-by-Step Solution

1
Identify the resource level where budgets and budget alerts are created in Google Cloud.
Budgets are defined and managed at the Cloud Billing account level, not at the project level.
Cloud Billing budgets track expenditure across billing account scopes or linked project subsets, requiring billing account IAM permissions.
2
Evaluate the required administrative actions against the requested restrictions.
The user needs to create/edit budgets, but must not manage payment instruments or user permissions.
Applying the principle of least privilege requires choosing a role tailored specifically to cost management tasks.
3
Select the least-privilege predefined role matching these capabilities.
Billing Account Costs Manager (roles/billing.costsManager) fits the exact requirement.
This role explicitly permits managing budget thresholds and cost reports while restricting full administrative operations on the billing account.

Key Concept

Cloud Billing IAM Roles and Least-Privilege Budget Management
Estimated Time:1m 15s
Question 916Question

An online video processing platform is designing a Google Kubernetes Engine (GKE) cluster architecture to support two distinct workloads:

1. A real-time web API serving client requests where the operations team requires fully managed infrastructure with zero node provisioning or cluster node maintenance overhead.
2. A stateless frame-rendering batch processing pipeline that is fault-tolerant and requires significant cost reduction on compute resources.

Which TWO architectural choices should you combine to meet these workload requirements while minimizing operational complexity and compute expense?

Select all that apply

Show answer & explanation

Answer: Deploy a GKE Autopilot cluster for the real-time web API workload.; Provision a node pool composed of Spot VMs in GKE Standard for the stateless batch rendering workload.

Answer

Deploy a GKE Autopilot cluster for the real-time web API workload, and provision a Spot VM node pool for the stateless batch rendering workload.
Combining GKE Autopilot for the web API workload and a Spot VM node pool for the batch workload satisfies all requirements. Autopilot offloads all node management and infrastructure maintenance to Google Cloud, matching the zero-node-management constraint for the web API. Spot VMs offer up to 60-90% savings for stateless, fault-tolerant batch workloads where preemption does not cause data loss.

Step-by-Step Solution

1
Analyze the web API requirements
GKE Autopilot is selected because Google fully manages the underlying nodes, scaling, security hardening, and OS maintenance.
The requirement explicitly asks for zero node management and maintenance overhead.
2
Analyze the stateless batch rendering workload requirements
Spot VMs are selected to drastically reduce compute costs.
Spot VMs are heavily discounted compute instances ideal for stateless, fault-tolerant batch processing that can sustain preemptions.

Key Concept

GKE Cluster Architectural Modes and Node Pool Selection Strategy
Question 917Question

A cloud engineer must migrate non-critical batch processing workloads on a Google Kubernetes Engine (GKE) Standard cluster named `prod-cluster` to a dedicated Spot VM node pool to lower compute expenses. The engineer must prevent general workloads from being scheduled onto the Spot nodes while ensuring existing batch pods transition smoothly without resource contention. In what chronological sequence should the engineer perform the following operational steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Provision the new Spot VM node pool with a `NoSchedule` taint using `gcloud container node-pools create`; 2) Update the batch deployment manifest with matching tolerations and Spot node selectors; 3) Apply the manifest using `kubectl apply` to launch pods on the Spot pool; 4) Delete the legacy standard node pool using `gcloud container node-pools delete` after verifying migration success.
Order requires establishing the tainted infrastructure first, configuring workload specifications to tolerate the taint, applying those specifications to migrate running pods, and finally deleting the legacy node pool once migration is complete.

Step-by-Step Solution

1
Provision the new Spot node pool with node taints
The GKE cluster receives new Spot VM nodes configured with a `workload=batch:NoSchedule` taint.
Infrastructure must be provisioned and tainted first so that general cluster workloads cannot accidentally schedule on Spot instances.
2
Configure workload manifests with tolerations and selectors
The batch deployment YAML is prepared to allow scheduling past the taint and target the Spot node pool.
Without explicit tolerations in the pod template, Kubernetes scheduler will reject scheduling pods on tainted nodes.
3
Apply updated deployment configuration to the cluster
Kubernetes triggers a rolling update, scheduling batch pods onto the active Spot VM nodes.
Deploying the configuration updates the running workloads without causing downtime.
4
Decommission the redundant standard node pool
The standard node pool is removed and resources are released, preventing unnecessary compute costs.
Legacy nodes should only be decommissioned once all workloads have successfully migrated and verified.

Key Concept

GKE Node Pool Migration and Workload Isolation using Spot VMs, Taints, and Tolerations
Question 918Question

Your company is deploying a proprietary binary communication service hosted on Compute Engine managed instance groups across the us-central1 and europe-west1 regions. The service receives external client traffic over custom non-HTTP TCP connections on port 8443. Your security policy mandates that TLS/SSL encryption must be terminated at the Google Cloud load balancer edge before passing decrypted TCP traffic to backend virtual machines. Which Google Cloud load balancer type should you configure to meet these requirements?

Show answer & explanation

Answer: Deploy a Global External Proxy Network Load Balancer with a Target SSL Proxy.

Answer

Deploy a Global External Proxy Network Load Balancer with a Target SSL Proxy.
The Global External Proxy Network Load Balancer (using a Target SSL Proxy) is designed specifically for external non-HTTP TCP traffic on supported ports such as 8443, and terminates TLS/SSL at the load balancer edge before proxying traffic to backend instance groups.

Step-by-Step Solution

1
Analyze the protocol requirement.
The application uses non-HTTP raw TCP traffic on port 8443.
Layer 7 HTTP(S) load balancers cannot handle non-HTTP TCP protocols.
2
Analyze the security and offloading requirement.
TLS/SSL termination must take place at the load balancer edge.
Passthrough network load balancers do not terminate TLS; proxy load balancers are required for TLS offloading.
3
Select the matching load balancer type.
Choose a Global External Proxy Network Load Balancer configured with a Target SSL Proxy.
This load balancer accepts external non-HTTP TCP traffic globally, terminates TLS at the edge, and proxies connection requests to backend Compute Engine instances.

Key Concept

Selecting GCP Load Balancer types based on protocol (TCP vs HTTP), traffic scope (External vs Internal), and SSL/TLS termination requirements.
Question 919Question

A cloud engineer needs to ensure that a production Cloud SQL for MySQL instance can be restored to a specific point in time in the event of accidental data corruption. Which action should the engineer perform on the instance?

Show answer & explanation

Answer: Enable automated backups and binary logging on the Cloud SQL instance.

Answer

Enable automated backups and binary logging on the Cloud SQL instance.
Enabling automated backups together with binary logging on Cloud SQL for MySQL records all database modifications, allowing the instance to be restored to any exact minute or transaction log state.

Step-by-Step Solution

1
Identify the operational requirement for database recovery.
The requirement calls for point-in-time recovery (PITR) on a Cloud SQL for MySQL database.
Point-in-time recovery allows restoring data to a specific timestamp before corruption occurred.
2
Determine the mandatory GCP Cloud SQL configuration flags.
Automated backups must be enabled along with binary logging.
Binary logging records all write operations between backup snapshots, enabling precise point-in-time restoration.

Key Concept

Cloud SQL Backup and Point-in-Time Recovery Management
Question 920Question

Your organization stores daily transaction log files in a Cloud Storage bucket configured with Uniform Bucket-Level Access. An automated compliance audit script accesses and inspects all log files daily during the first 60 days following their creation. Currently, an Object Lifecycle Management rule immediately transitions all uploaded objects to the Archive storage class upon creation, resulting in substantial retrieval fee charges during the daily compliance audits. You need to reconfigure the operational storage strategy to minimize overall storage and retrieval costs without compromising daily audit access or altering bucket access control policies. Which action should you take?

Show answer & explanation

Answer: Update the Object Lifecycle Management rule to keep objects in the Standard storage class for 60 days before transitioning them to the Archive storage class.

Answer

Update the Object Lifecycle Management rule to keep objects in the Standard storage class for 60 days before transitioning them to the Archive storage class.
Cloud Storage pricing consists of storage capacity fees and operational/retrieval fees. While Archive storage offers the lowest monthly capacity rates, reading data from Archive storage incurs significant data retrieval fees. When data is accessed daily for 60 days, storing it in the Standard storage class during that active 60-day window avoids retrieval charges completely. Setting the lifecycle rule condition `age: 60` before executing `SetStorageClass: ARCHIVE` optimizes total operational expenditure.

Step-by-Step Solution

1
Analyze data access patterns and cost drivers.
Identified that objects are accessed daily for 60 days. Archival storage classes (Nearline, Coldline, Archive) incur significant per-GB retrieval fees when accessed frequently.
Immediate transition to Archive storage causes high data retrieval charges during the 60-day active audit period.
2
Evaluate Object Lifecycle Management lifecycle conditions.
Determined that adding an Age condition of 60 days for the SetStorageClass action retains objects in Standard storage during active reading.
Standard storage has higher monthly capacity costs but zero retrieval fees, making it optimal for active data.
3
Verify compliance with security and operational constraints.
Uniform Bucket-Level Access remains enabled and compliant with organizational access policies.
Lifecycle rules operate independently of bucket-level IAM policies without requiring security policy modifications.

Key Concept

Cloud Storage Object Lifecycle Management cost optimization based on data access patterns
PreviousPage 46 / 80Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin