Examkin

All practice questions

1591 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 921Question →

A DevOps engineer is preparing a `gcloud` command to deploy a batch-processing worker VM instance on Compute Engine. The workload is stateless and fault-tolerant, so it should be deployed using Spot VM pricing to minimize costs. The instance must also execute an initialization script stored in a Cloud Storage bucket (`gs://prod-scripts/setup.sh`) during its initial boot sequence. Which TWO `gcloud compute instances create` command parameters must be included to meet these operational and cost requirements?

Select all that apply

Show answer & explanation

Answer: Include `--provisioning-model=SPOT` to deploy the instance as a Spot VM for fault-tolerant batch execution.; Include `--metadata=startup-script-url=gs://prod-scripts/setup.sh` to configure the instance startup agent to run the script on boot.

Answer

The correct parameters are specifying `--provisioning-model=SPOT` to provision the instance under the Spot VM model for fault-tolerant workloads, and `--metadata=startup-script-url=gs://prod-scripts/setup.sh` to direct the guest startup agent to download and run the initialization script from Cloud Storage.
Specifying `--provisioning-model=SPOT` configures Compute Engine to allocate preemption-eligible capacity at reduced cost suitable for fault-tolerant batch jobs. Specifying `--metadata=startup-script-url=gs://prod-scripts/setup.sh` utilizes the native guest environment metadata key `startup-script-url` to download and execute the initialization script from Cloud Storage at instance boot.

Step-by-Step Solution

1
Determine the correct flag for configuring Spot VM provisioning model.
Identify `--provisioning-model=SPOT` as the valid flag for creating Spot instances in gcloud compute instances create.
Spot VMs are designed for fault-tolerant batch workloads and require specifying SPOT as the provisioning model.
2
Determine the correct flag for executing a Cloud Storage startup script upon VM creation.
Identify `--metadata=startup-script-url=gs://...` as the valid key-value pair under the metadata flag.
Compute Engine guest environment reads the `startup-script-url` metadata key on boot to fetch and execute scripts directly from Cloud Storage buckets.
3
Evaluate and rule out incorrect flags.
Reject `--scopes` for script locations because scopes define API access, and reject `--on-host-maintenance=MIGRATE` because Spot instances require host maintenance policy to be `TERMINATE`.
Invalid flag usages produce syntax errors or deployment policy violations.

Key Concept

Compute Engine gcloud VM provisioning flags and guest metadata configuration
Estimated Time:2m 0s
Question 922Question →

Your team needs to grant a newly hired developer access to manage Compute Engine virtual machine instances (create, start, stop, and delete) within a specific Google Cloud project. The developer must not be granted permissions to modify project firewall rules, VPC networks, or IAM policies. Following the principle of least privilege, which IAM role should you grant to the developer at the project level?

Show answer & explanation

Answer: Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1)

Answer

Grant the predefined Compute Instance Admin (v1) role (roles/compute.instanceAdmin.v1) at the project level.
The Compute Instance Admin (v1) role (roles/compute.instanceAdmin.v1) grants full control over Compute Engine instances while omitting permissions for networking, security, and other GCP services, satisfying the principle of least privilege.

Step-by-Step Solution

1
Identify the required operational capabilities.
The user needs to manage Compute Engine instances (create, start, stop, delete).
Determining exact job requirements allows matching with the most granular IAM role available.
2
Select a role aligned with the principle of least privilege.
The Compute Instance Admin (v1) role provides full instance management without granting network administration or broad project permissions.
Predefined service roles target specific resource management needs, whereas primitive roles (Editor, Owner) grant overly broad permissions.
3
Identify the correct resource hierarchy scope.
Apply the role binding at the specific project level.
Permissions bound at higher levels (Folder or Organization) inherit downward to all child projects.

Key Concept

Least Privilege and IAM Predefined Roles
Estimated Time:1m 0s
Question 923Question →

A cloud engineer needs to configure least-privilege access by creating a custom IAM role for specific virtual machine operations and assigning it to an operator in a Google Cloud project using the gcloud CLI. Place the following operational steps in the correct sequential order from start to finish.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of operations is: first, create the local YAML role definition file specifying the required permissions; second, run 'gcloud iam roles create' to instantiate the custom role in the project; third, run 'gcloud projects add-iam-policy-binding' to bind the custom role to the user; and fourth, run 'gcloud projects get-iam-policy' to audit and confirm the binding.
The workflow follows standard Google Cloud IAM administration procedures: defining role permissions in a configuration file, creating the custom role resource in the target project, binding the created role to the desired user identity, and verifying the policy change via policy retrieval commands.

Step-by-Step Solution

1
Draft the custom role specification file containing the required permissions.
A local YAML configuration file ready for CLI creation commands.
Permissions must be defined prior to registering the custom role resource in Google Cloud.
2
Run 'gcloud iam roles create' referencing the YAML definition file.
The custom role is registered under the project's IAM role scope.
A role must exist in GCP IAM before any principal can be bound to it.
3
Run 'gcloud projects add-iam-policy-binding' to assign the custom role to the user.
The IAM policy binding links the user principal to the custom role resource.
Granting permissions requires binding the identity member to the role path at the appropriate hierarchy level.
4
Run 'gcloud projects get-iam-policy' to inspect the updated project policy.
An output listing current policy bindings confirming successful role assignment.
Verifying policy state ensures security compliance and confirms administrative changes were committed.

Key Concept

Custom IAM Role Creation and Policy Binding Lifecycle via gcloud CLI
Estimated Time:1m 30s
Question 924Question →

A company is integrating their on-premises data center with a Google Cloud Virtual Private Cloud (VPC) network via Cloud Interconnect. Internal application servers hosted in the VPC reside within a Cloud DNS private zone named internal.example.com. On-premises client machines need to resolve hostnames within this private DNS zone over the hybrid connection. Which Cloud DNS configuration should be planned to satisfy this requirement?

Show answer & explanation

Answer: Configure a Cloud DNS inbound DNS forwarding policy on the VPC network to allow on-premises systems to query Cloud DNS entry points.

Answer

Configure a Cloud DNS inbound DNS forwarding policy on the VPC network to allow on-premises systems to query Cloud DNS entry points.
Inbound DNS forwarding allows networks connected to a VPC (such as on-premises networks via Cloud Interconnect or VPN) to send DNS queries to Cloud DNS entry point IP addresses inside the VPC, resolving records in private zones.

Step-by-Step Solution

1
Identify the DNS resolution direction.
On-premises clients need to resolve names configured in a Cloud DNS Private Zone inside Google Cloud.
Traffic flows from on-premises to Google Cloud over the hybrid connection (Cloud Interconnect).
2
Select the appropriate Cloud DNS feature for on-prem-to-GCP DNS resolution.
An Inbound DNS forwarding policy provisions regional entry point IP addresses in the VPC network.
On-premises DNS servers forward queries for internal.example.com to these entry point IP addresses.

Key Concept

Cloud DNS Inbound DNS Forwarding for Hybrid Environments
Estimated Time:1m 30s
Question 925Question →

A Cloud Engineer needs to safely deploy an OS image update to a production Managed Instance Group (MIG) serving critical web application traffic. To minimize operational risk, the engineer must execute a canary rollout using the gcloud command-line interface, testing the updated configuration on a subset of 10% of the instances before initiating a full deployment. In which sequential order should the engineer execute these steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for conducting a canary rollout on a Managed Instance Group is: 1) Create a new instance template with the updated disk image, 2) Configure the MIG to target 10% size for the new template version, 3) Start the rolling update action to replace canary instances, 4) Monitor application logs and metrics on the canary subset, and 5) Promote the new instance template to 100% target size to complete the full update.
The correct operational sequence adheres to Google Cloud best practices for risk-mitigated deployments. A new instance template must be created first before it can be referenced. The group configuration is then updated to assign a 10% target size to the new template. Executing the rolling action replaces only the instances necessary to meet the 10% canary threshold. Monitoring telemetry validates that the new image performs reliably. Finally, assigning 100% target size to the new template rolls out the update to all remaining instances.

Step-by-Step Solution

1
Define the target configuration by creating a new Compute Engine instance template.
A new versioned template resource becomes available in the project for instance creation.
Managed Instance Groups instantiate virtual machines based on instance templates; changes cannot be applied directly to running instances without a template update.
2
Set the MIG update policy to include the new template as a canary version targeting 10% of total instances.
The MIG metadata is updated to maintain two versions (original version at 90%, canary version at 10%).
Canary deployments require specifying a target size or percentage so that GCP knows how many instances to transition initially.
3
Execute the gcloud rolling action update command.
Compute Engine automatically terminates old instances and provisions new instances using the canary template until 10% capacity is reached.
The rolling update action triggers the actual infrastructure replacement process in accordance with the specified update policy.
4
Inspect Cloud Monitoring metrics and application log streams for canary instances.
Verification data confirms whether the updated OS image operates cleanly under live conditions without unhandled exceptions or performance degradation.
Testing in production with limited exposure ensures bugs are detected prior to impacting all users.
5
Update the MIG version configuration to assign 100% target size to the new template.
The MIG replaces all remaining instances with the new template, completing the update cycle.
Once the canary passes validation, promoting the template brings the entire instance group to the latest configuration.

Key Concept

Managed Instance Group Canary Updates
Question 926Question →

A cloud engineer needs to execute a gradual canary rollout of a new container image for an existing Cloud Run service named `order-processor`. The rollout must first direct 10% of live traffic to the new revision using a revision tag for testing, verify stability, and finally route 100% of traffic to the new revision. Arrange the following deployment and traffic management steps in the correct operational sequence.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Deploy the container image with `--no-traffic` and `--tag canary-v2`, 2) Split 10% of production traffic to `canary-v2` using `gcloud run services update-traffic`, 3) Analyze metrics and error rates in Cloud Logging for `canary-v2`, 4) Shift 100% of traffic to the verified revision using `--to-latest`.
The deployment sequence begins by isolating the new revision using `gcloud run deploy` with `--no-traffic` and `--tag canary-v2`. Next, a canary split is established with `gcloud run services update-traffic --to-tags canary-v2=10`. Telemetry and error logs are then monitored in Cloud Logging specifically for the canary revision. Once stability is verified, all live production traffic is promoted to the new revision using `--to-latest`.

Step-by-Step Solution

1
Deploy container image with traffic suppression and revision tagging
A new Cloud Run revision is created receiving 0% of production traffic, exposed via a dedicated revision tag `canary-v2`.
Deploying with `--no-traffic` prevents unvalidated code from serving main production requests immediately.
2
Configure canary traffic split via gcloud CLI
The Cloud Run service routes 10% of incoming production requests to the revision tagged `canary-v2`.
`gcloud run services update-traffic` with `--to-tags` sets explicit percentage allocations for specific revision tags.
3
Analyze revision telemetry in Cloud Operations
Container instance behavior, HTTP 5xx rates, and request latencies for the canary revision are verified.
Empirical log verification ensures the revision can sustain production load without errors before full promotion.
4
Promote the verified revision to serve 100% of traffic
The service updates its main endpoint to direct 100% of live traffic to the latest fully-validated revision.
Using `--to-latest` completes the canary deployment by promoting the tested revision to full production.

Key Concept

Cloud Run revision tagging, traffic splitting, and canary release workflows
Question 927Question →

A cloud architect at a gaming startup is using the Google Cloud Pricing Calculator to model monthly Compute Engine expenses for dedicated matchmaking backend servers that run continuously 24 hours a day, 7 days a week. The architect wants to evaluate cost reduction mechanisms for uninterrupted VM workloads without incurring a 1-year or 3-year committed financial obligation. Which pricing feature does the Google Cloud Pricing Calculator automatically factor in for sustained Compute Engine instance usage?

Show answer & explanation

Answer: Sustained Use Discounts (SUDs), which automatically apply discounted hourly rates when Compute Engine instances run for more than 25% of a billing month.

Answer

Sustained Use Discounts (SUDs), which automatically apply discounted hourly rates when Compute Engine instances run for more than 25% of a billing month.
Sustained Use Discounts (SUDs) are automatic discounts offered by Google Cloud for Compute Engine instances (such as N1, N2, and vCPUs/memory in supported machine families) when instances run for more than 25% of a billing month. The Google Cloud Pricing Calculator incorporates SUDs automatically into monthly workload estimates without requiring users to sign up for multi-year financial commitments.

Step-by-Step Solution

1
Analyze the workload requirements given in the scenario
The workload requires running Compute Engine VMs continuously (24/7) throughout the month without committing to a 1-year or 3-year term contract.
Understanding operational constraints helps narrow down applicable pricing models in GCP.
2
Evaluate GCP discount mechanisms available in the Google Cloud Pricing Calculator
Sustained Use Discounts (SUDs) automatically reduce the incremental hourly cost of Compute Engine instances when used for more than 25% of a billing month, without any contractual commitments.
SUDs are automatic baseline discounts for uncommitted continuous Compute Engine usage.
3
Compare against incorrect alternatives
CUDs require a 1- or 3-year commitment contract. Spot VMs are preemptible and unfit for production matchmaking servers. Cloud Run is a separate serverless product.
Verifying constraints confirms that only automatic Sustained Use Discounts meet all requirements.

Key Concept

Sustained Use Discounts vs Committed Use Discounts in Google Cloud Pricing Calculator
Question 928Question →

A site reliability engineer is tasked with establishing automated long-term billing analytics by exporting daily granular resource usage and pricing data into BigQuery. Which prerequisite requirements and access permissions must be configured before enabling this billing export? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Create a destination BigQuery dataset in a Google Cloud project within the organization.; Ensure the user configuring the export has the Billing Account Administrator or Billing Account Costs Manager role on the Cloud Billing account.

Answer

To configure a Cloud Billing export to BigQuery, you must create a target BigQuery dataset within a project and possess either the Billing Account Administrator or Billing Account Costs Manager role on the Cloud Billing account.
Enabling BigQuery billing export requires two distinct prerequisites: a destination BigQuery dataset within a Google Cloud project to store the exported usage data, and sufficient billing IAM permissions (Billing Account Administrator or Billing Account Costs Manager) on the Cloud Billing account to authorize the export setup.

Step-by-Step Solution

1
Identify the storage container requirement for Cloud Billing exports.
A target BigQuery dataset must be created in a project to house the billing export tables.
Cloud Billing exports write structured data tables directly into a specified BigQuery dataset.
2
Determine the required IAM permissions on the Cloud Billing account level.
The identity enabling the export must hold the Billing Account Administrator or Billing Account Costs Manager role.
Exporting billing data modifies billing account settings, which requires explicit IAM permissions on the Cloud Billing account itself, not just project-level roles.

Key Concept

BigQuery Cloud Billing Export Prerequisites and IAM Roles
Question 929Question →

A DevOps engineer operates a Google Kubernetes Engine (GKE) Standard cluster running a monolithic batch processing job that requires 18 hours of continuous, uninterrupted execution and cannot recover from unexpected pod evictions. A team member proposes migrating the cluster's worker node pool from Standard VMs to Spot VMs to lower compute costs. Which operational decision should the DevOps engineer make to guarantee that the workload completes successfully?

Show answer & explanation

Answer: Retain standard Compute Engine instances for the node pool because Spot VMs can be reclaimed by GCP at any time with a short termination notice, making them unsuitable for non-fault-tolerant, long-running batch jobs.

Answer

Retain standard Compute Engine instances for the node pool because Spot VMs can be reclaimed by GCP at any time with a short termination notice, making them unsuitable for non-fault-tolerant, long-running batch jobs.
Spot VMs are provisioned from spare compute capacity and can be reclaimed by Google Cloud with a 30-second notice. Workloads that run for long durations without built-in fault tolerance or state checkpointing cannot run reliably on Spot instances and must use standard Compute Engine node pools.

Step-by-Step Solution

1
Analyze workload requirements
Identified that the batch job requires 18 hours of continuous, uninterrupted execution and lacks fault-tolerance mechanisms for pod evictions.
Understanding workload tolerance to interruption determines compute resource selection.
2
Evaluate Spot VM compute characteristics in GKE
Recognized that Spot VMs provide discounted compute but can be preempted by Google Cloud at any time with only a 30-second termination notice.
Spot instances are designed exclusively for stateless, fault-tolerant, or checkpointed workloads.
3
Select appropriate infrastructure management policy
Determined that standard Compute Engine node pools must be maintained to ensure job completion without loss of state.
Cost optimization strategies must not compromise core workload availability constraints.

Key Concept

Selecting appropriate GKE node pool VM types based on workload fault tolerance and operational continuity requirements.
Question 930Question →

A cloud engineer needs to configure a Google Kubernetes Engine (GKE) workload to securely access Google Cloud Storage using Workload Identity. Arrange the administrative and deployment steps in the correct sequential order from start to finish.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with creating the Google Service Account (GSA) and assigning GCP IAM permissions, followed by creating the Kubernetes Service Account (KSA) in GKE. Next, grant the Workload Identity User IAM role to allow the KSA to impersonate the GSA. Then, annotate the KSA with the GSA email address. Finally, deploy the application manifest referencing the annotated KSA.
To configure Workload Identity correctly, you must first provision the Google Service Account (GSA) and grant it GCP IAM roles. Next, create the Kubernetes Service Account (KSA) in the cluster namespace. Then, grant the Workload Identity User role on the GSA to the KSA so GCP permits token impersonation. Fourth, annotate the KSA with the GSA's email address so GKE metadata server routes authentication requests properly. Finally, deploy the application manifest configured to use the annotated KSA.

Step-by-Step Solution

1
Create a Google Service Account (GSA) and assign required GCP IAM roles.
A GCP-level identity with Cloud Storage permissions is provisioned.
Workload Identity bridges Kubernetes identities to GCP Service Accounts, which hold actual GCP IAM permissions.
2
Create a Kubernetes Service Account (KSA) in the cluster namespace.
An in-cluster identity is defined for the workload.
Pods run under a KSA identity inside the Kubernetes cluster namespace.
3
Add an IAM policy binding granting `roles/iam.workloadIdentityUser` on the GSA to the KSA.
The GSA authorizes the KSA member `PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]` to act on its behalf.
Without this IAM binding, token exchange between GKE and GCP IAM will be rejected.
4
Annotate the KSA with the GSA email address.
The annotation `iam.gke.io/gcp-service-account` instructs GKE metadata server to issue tokens for the GSA.
The annotation tells GKE which GSA identity should be associated with pods using this KSA.
5
Deploy the application Pod or Deployment specifying `serviceAccountName` as the KSA.
The workload runs under the annotated KSA and securely authenticates to Google Cloud APIs.
When the application pod starts, its SDK calls the local GKE metadata server to obtain short-lived GSA credentials.

Key Concept

Configuring Workload Identity for GKE workloads
Question 931Question →

You manage a production Cloud SQL for MySQL instance named `prod-mysql`. To comply with disaster recovery policies, you need to enable point-in-time recovery (PITR) for the instance. On Cloud SQL for MySQL, PITR requires binary logging to be enabled. Which `gcloud` command should you run to enable binary logging on this instance while preserving all existing configurations?

Show answer & explanation

Answer: gcloud sql instances patch prod-mysql --enable-bin-log

Answer

Execute `gcloud sql instances patch prod-mysql --enable-bin-log` to enable binary logging on the Cloud SQL for MySQL instance.
For Cloud SQL for MySQL instances, point-in-time recovery relies on binary logging. The `gcloud sql instances patch prod-mysql --enable-bin-log` command correctly updates the instance parameters to enable binary logging without modifying other settings.

Step-by-Step Solution

1
Identify the target database engine and operational requirements.
The target instance `prod-mysql` runs Cloud SQL for MySQL, which requires binary logging to support point-in-time recovery (PITR).
Different database engines in Cloud SQL utilize engine-specific flags to control transaction log retention and recovery.
2
Select the correct `gcloud sql` sub-command for configuration modification.
`gcloud sql instances patch` is the standard command for updating specific configuration properties of an existing instance.
`patch` updates only the specified attributes while leaving all other instance configurations untouched.
3
Apply the correct flag for enabling binary logging on MySQL.
The `--enable-bin-log` flag activates MySQL binary logging.
Binary logs record database mutations and allow restoring MySQL databases to a precise point in time.

Key Concept

Cloud SQL Instance Configuration and Backup Management
Question 932Question →

A cloud engineer needs to configure Private Service Access within a custom Virtual Private Cloud (VPC) network named `corp-vpc` and provision a high-availability Cloud SQL for MySQL instance hosting an application database named `sales_db`. What is the correct sequence of `gcloud` CLI operations required to successfully complete this deployment?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct deployment sequence is: 1) Allocate an internal IP address range in the VPC network (`gcloud compute addresses create`), 2) Establish a VPC peering connection to Google services (`gcloud services vpc-peerings connect`), 3) Deploy the Cloud SQL instance configured with private IP (`gcloud sql instances create`), and 4) Create the logical database inside the provisioned instance (`gcloud sql databases create`).
Setting up a private Cloud SQL instance using Private Service Access requires four dependent steps in precise order: first, reserve a named IP address range inside the customer VPC network (`gcloud compute addresses create`); second, establish a peering connection between the VPC and `servicenetworking.googleapis.com` (`gcloud services vpc-peerings connect`); third, provision the Cloud SQL instance linked to that network while suppressing public IP (`gcloud sql instances create`); and finally, create the target database schema inside the active instance (`gcloud sql databases create`).

Step-by-Step Solution

1
Allocate an IP range for VPC Peering
An IP range with purpose VPC_PEERING is reserved in corp-vpc.
Google Private Service Access requires an allocated IP range to assign private IP addresses to managed service instances.
2
Establish VPC Peering Connection
The VPC network is connected to Google's Service Networking tenant project.
Private Service Access uses VPC Peering between the customer VPC and Google's internal service network.
3
Provision the Cloud SQL Instance
The Cloud SQL instance is deployed without a public IP address.
The instance configuration references the peered VPC network and uses an IP address from the allocated range.
4
Create the Application Database
The sales_db database is initialized on the instance.
Database resources can only be created within an existing, fully provisioned Cloud SQL instance.

Key Concept

Sequence of steps for establishing Private Service Access and deploying private Cloud SQL instances
Question 933Question →

An operations engineer manages a Google Cloud Storage bucket named finance-records that has Object Versioning enabled. To comply with corporate retention policies while controlling costs, noncurrent object versions must be transitioned to Archive storage 30 days after becoming noncurrent, and permanently deleted 90 days after becoming noncurrent. Current object versions must remain untouched in Standard storage. Which configuration strategy correctly implements this lifecycle policy?

Show answer & explanation

Answer: Define an Object Lifecycle Management policy with two rules: one with action SetStorageClass to ARCHIVE using the daysSinceNoncurrentTime condition set to 30, and another with action Delete using the daysSinceNoncurrentTime condition set to 90.

Answer

The lifecycle policy must be configured using the daysSinceNoncurrentTime condition with SetStorageClass to ARCHIVE at 30 days and Delete at 90 days.
Configuring an Object Lifecycle Management rule using daysSinceNoncurrentTime explicitly targets noncurrent object versions created when Object Versioning is active. Setting SetStorageClass to ARCHIVE at 30 days and Delete at 90 days fulfills the exact retention policy without affecting current versions.

Step-by-Step Solution

1
Identify the target objects and lifecycle lifecycle triggers.
The requirement specifies operating strictly on noncurrent object versions generated by Object Versioning without affecting live/current objects.
Standard age conditions evaluate object creation timestamp, whereas daysSinceNoncurrentTime specifically evaluates time elapsed since an object version became noncurrent.
2
Select the lifecycle action for the 30-day requirement.
Action SetStorageClass to ARCHIVE triggered when daysSinceNoncurrentTime equals 30.
This moves noncurrent object versions to lower-cost Archive storage 30 days after replacement.
3
Select the lifecycle action for the 90-day requirement.
Action Delete triggered when daysSinceNoncurrentTime equals 90.
This permanently removes noncurrent versions once they reach the 90-day post-replacement threshold.

Key Concept

Cloud Storage Object Lifecycle Management for Noncurrent Versions
Estimated Time:2m 0s
Question 934Question →

A financial technology company is planning to migrate an automated compliance auditing pipeline to Google Cloud. The team is using the Google Cloud Pricing Calculator to establish a baseline monthly cost estimate. The workload requires Compute Engine virtual machines running continuously 24/7, persistent storage for raw transaction logs, and regular data exports sent to an external auditor's system. Which of the following parameters must be factored into the pricing calculator to obtain an accurate baseline cost estimate? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Compute Engine machine specifications (vCPUs and RAM) alongside applicable sustained use discounts or committed use discounts for 24/7 operations.; Persistent Disk storage capacity and performance tier, along with estimated outbound external network egress data transfer volume.

Answer

Accurate pricing estimation requires including Compute Engine machine specs with applicable Sustained Use or Committed Use Discounts for continuous workloads, as well as accounting for Persistent Disk storage costs and external network egress transfer volumes.
To create a comprehensive baseline estimate using the GCP Pricing Calculator, architects must account for VM machine types with continuous usage discounts (SUDs/CUDs) and all secondary costs such as attached Persistent Disk storage tiers and internet/external network egress volumes.

Step-by-Step Solution

1
Evaluate compute execution profile and discounts
Identified that 24/7 continuous Compute Engine instances qualify for automatic Sustained Use Discounts (SUDs) or Committed Use Discounts (CUDs), which must be modeled in the pricing calculator.
Baseline compute pricing without continuous usage discounts will overestimate the actual monthly VM cost.
2
Identify auxiliary billable resource components
Included persistent disk provisioned storage capacity/type and external egress network traffic.
Google Cloud charges separately for disk volume provisioned and network egress traffic leaving Google Cloud network per gigabyte.

Key Concept

Accurate GCP Cost Estimation with the Pricing Calculator
Estimated Time:1m 30s
Question 935Question →

An organization runs a high-throughput backend service on a Compute Engine Managed Instance Group (MIG) configured with CPU utilization autoscaling. During peak traffic events, newly provisioned VM instances require approximately 5 minutes to start application dependencies and warm up local data caches. During this warm-up phase, CPU usage spikes temporarily, causing the autoscaler to continuously launch redundant VM instances before the existing new instances can handle traffic. Which action should the Cloud Engineer take to prevent premature and excessive scaling during instance startup?

Show answer & explanation

Answer: Configure an appropriate cool-down period in the MIG autoscaling policy to allow instances to fully initialize before their metrics are evaluated.

Answer

Configure an appropriate cool-down period in the MIG autoscaling policy to allow newly created instances to complete their application startup before their CPU metrics are included in scaling decisions.
Configuring a cool-down period (also known as the initialization period) in the Managed Instance Group autoscaling policy specifies how long the autoscaler must wait after an instance boots before incorporating its usage metrics into autoscaling decisions. By setting this duration to cover the 5-minute startup and cache-warming window, metrics generated during initialization are ignored, preventing continuous, redundant instance provisioning.

Step-by-Step Solution

1
Analyze the cause of premature autoscaling during instance startup.
Identified that high CPU usage during application boot and cache warming causes the autoscaler to misinterpret initialization load as sustained demand.
Without a delay, metrics collected during startup trigger immediate, unnecessary scale-out events.
2
Identify the Google Cloud recommended mechanism for handling VM initialization timing in MIGs.
The cool-down period (initialization period) parameter defines how long the autoscaler waits before assessing telemetry from a new instance.
Setting the cool-down period to match or exceed the 5-minute boot time ensures new instances reach steady-state operation before contributing to autoscaling calculations.
3
Evaluate the autoscaler configuration change.
Configuring the cool-down period stabilizes the instance count during scale-out events without distorting baseline target utilization thresholds.
This maintains appropriate autoscaling responsiveness while preventing instance thrashing.

Key Concept

Compute Engine MIG Autoscaler Cool-Down Period Configuration
Estimated Time:2m 0s
Question 936Question →

A cloud administrator needs to set up an automated cost-control mechanism that caps spending by triggering a Cloud Run service whenever a project's monthly expenditure exceeds $5,000. Which action should the administrator take when configuring the Cloud Billing budget to enable this automated workflow?

Show answer & explanation

Answer: Publish budget notifications to a Cloud Pub/Sub topic configured to trigger the Cloud Run service.

Answer

Publish budget notifications to a Cloud Pub/Sub topic configured to trigger the Cloud Run service.
Publishing budget notifications to a Cloud Pub/Sub topic enables event-driven cost governance. When threshold events occur, Cloud Billing publishes a message to Pub/Sub, which can automatically invoke a Cloud Run service to perform custom capping logic, such as disabling billing or stopping resources.

Step-by-Step Solution

1
Identify Cloud Billing budget capabilities
Recognize that GCP budgets only issue notification emails or publish messages to Cloud Pub/Sub.
Cloud Billing budgets do not natively stop resources or cap spend automatically.
2
Configure programmatic notifications
Connect the budget to a Cloud Pub/Sub topic.
When threshold rules are breached, Cloud Billing publishes JSON payloads to the designated Pub/Sub topic.
3
Connect automation endpoint
Configure the Cloud Run service to be triggered by the Pub/Sub topic messages to execute capping logic.
This establishes an automated event-driven cost governance architecture.

Key Concept

Programmatic Budget Notifications via Cloud Pub/Sub
Estimated Time:1m 30s
Question 937Question →

Your engineering team is deploying an internal microservice on Compute Engine instances located in a Virtual Private Cloud (VPC) named `prod-vpc`. The service must be accessible privately from both `prod-vpc` and a peered VPC named `analytics-vpc` using the custom hostname `api.internal`. You plan to use an Internal Application Load Balancer. Which TWO actions must you perform to successfully deploy the load balancer and enable name resolution for both VPCs?

Select all that apply

Show answer & explanation

Answer: Allocate a proxy-only subnet in the region where the Internal Application Load Balancer is deployed.; Create a Cloud DNS private zone for `api.internal`, add an A record pointing to the load balancer's IP address, and authorize both `prod-vpc` and `analytics-vpc` on the zone.

Answer

To deploy an Internal Application Load Balancer and enable DNS resolution across peered VPCs, you must create a regional proxy-only subnet for Envoy proxy allocation and configure a Cloud DNS private zone containing an A record that authorizes both VPC networks.
Deploying an Internal Application Load Balancer in Google Cloud requires a regional proxy-only subnet to deliver proxy connections to backends. Additionally, for private hostnames to resolve across multiple VPCs, the Cloud DNS private zone containing the A record must explicitly authorize all target VPC networks.

Step-by-Step Solution

1
Identify prerequisite subnets for regional internal application load balancing
An Internal Application Load Balancer relies on regional Envoy proxies, requiring a dedicated proxy-only subnet in the target region.
Proxy-only subnets provide private IP addresses used exclusively by Envoy proxies to forward client requests to backends.
2
Configure internal DNS resolution across multiple VPCs
A Cloud DNS private zone is created for the internal domain and authorized for both the host VPC and peered VPCs.
Private DNS zones are isolated to authorized VPC networks; adding both networks ensures instances in either VPC can resolve the internal hostname to the load balancer IP.

Key Concept

Internal Application Load Balancer Proxy Subnets and Cloud DNS Multi-VPC Authorization
Question 938Question →

A software development company is planning the cluster architecture for a new web service on Google Kubernetes Engine (GKE). The application consists of stateless microservices running standard containers. The infrastructure team requires an architecture that completely eliminates the operational overhead of managing, provisioning, and patching underlying compute nodes, while charging only for the requested Pod resources. Which GKE cluster architecture best fulfills these operational requirements?

Show answer & explanation

Answer: Deploy a GKE Autopilot cluster.

Answer

Deploy a GKE Autopilot cluster.
GKE Autopilot is a fully managed cluster mode where Google handles the entire underlying node infrastructure, including node creation, scaling, security hardening, OS upgrades, and repairs. Users only configure workloads at the Pod level and pay specifically for requested Pod resources, making it the ideal choice when node management overhead must be completely eliminated.

Step-by-Step Solution

1
Analyze operational requirements
The requirements demand zero node management overhead (no manual or automated node pool configuration) and Pod-based billing.
Identifying key constraints narrows down GKE operational modes.
2
Evaluate GKE Autopilot vs. GKE Standard
GKE Autopilot fully provisions, configures, auto-repairs, and patches nodes automatically while billing based on Pod CPU/memory requests.
Autopilot satisfies the zero-node-overhead and Pod-level billing criteria.
3
Compare against GKE Standard options
GKE Standard, even with Cluster Autoscaler or Spot VMs, requires node pool design, node configuration management, and bills at the underlying VM node level.
Standard mode retains node-level operational responsibilities.

Key Concept

GKE Autopilot vs. Standard Operational Boundaries
Estimated Time:1m 30s
Question 939Question →

A Cloud Engineer is tasked with provisioning a Cloud SQL for MySQL database instance that must communicate exclusively using a Private IP address within an existing custom VPC network named `prod-vpc`. Security policy strictly prohibits assigning public IP addresses. In what order should the engineer execute the configuration and deployment steps to establish Private Service Access and successfully create the database instance?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with allocating an IP address range for VPC peering, followed by establishing the private service connection, then creating the Cloud SQL instance with `--no-assign-ip`, and finally creating the database on the instance.
Configuring Cloud SQL with Private IP requires establishing a Private Service Access connection first. This is a prerequisite two-step process: allocating an IP range (`gcloud compute addresses create ... --purpose=VPC_PEERING`) and creating the peering connection (`gcloud services vpc-peerings connect`). Only after this network foundation is in place can the instance be created with `--network` and `--no-assign-ip`. Logical database creation follows instance provisioning.

Step-by-Step Solution

1
Reserve internal IP allocation
A named IP block is allocated for VPC Peering within the target VPC network.
Cloud SQL Private IP relies on Service Networking, which requires an explicit IP allocation before establishing the peering connection.
2
Connect the VPC network to Service Networking
VPC Network Peering is configured between the user's VPC and Google's service producer VPC.
This step provisions the underlying network routing infrastructure necessary for Google-managed database instances to receive internal IP addresses.
3
Provision the Cloud SQL instance
The Cloud SQL instance is deployed with a private IP address and no public IP.
The Cloud SQL instance deployment command verifies that Private Service Access has been configured for the specified VPC network.
4
Create the database inside the instance
The target database schema is instantiated within the active Cloud SQL instance.
Databases are logical objects housed within a database instance and can only be created after instance deployment completes.

Key Concept

Deploying Cloud SQL with Private IP via Private Service Access
Question 940Question →

A cloud engineer is managing a Google Kubernetes Engine (GKE) Standard cluster named `app-cluster` in zone `us-east1-b`. During a peak traffic period, the engineer scales up a web service Deployment, but several new Pods remain stuck in a `Pending` state with `Insufficient cpu` event messages. The existing node pool named `web-pool` has reached its current node limit, and node autoscaling is disabled. The engineer needs to enable node autoscaling specifically for `web-pool` so that GKE dynamically provisions additional underlying Compute Engine instances when Pods cannot be scheduled, establishing a minimum limit of 2 nodes and a maximum limit of 8 nodes. Which `gcloud` command must the engineer execute to resolve this issue?

Show answer & explanation

Answer: gcloud container node-pools update web-pool --cluster=app-cluster --zone=us-east1-b --enable-autoscaling --min-nodes=2 --max-nodes=8

Answer

Execute `gcloud container node-pools update web-pool --cluster=app-cluster --zone=us-east1-b --enable-autoscaling --min-nodes=2 --max-nodes=8`.
The correct command uses `gcloud container node-pools update` targeted at the `web-pool` node pool in cluster `app-cluster`. Providing `--enable-autoscaling` along with `--min-nodes=2` and `--max-nodes=8` configures GKE Cluster Autoscaler to automatically adjust the node count when pending Pods require additional compute resources.

Step-by-Step Solution

1
Identify the root cause of the `Pending` Pods.
Pods are unschedulable because the node pool lacks available CPU resource capacity, and node autoscaling is currently disabled on the cluster's node pool.
Cluster Autoscaler must be enabled on the node pool level to automatically provision new Compute Engine nodes when unschedulable Pods are detected.
2
Differentiate between Horizontal Pod Autoscaler (HPA) and Cluster Autoscaler.
HPA scales Pod replica counts, whereas Cluster Autoscaler scales the underlying Compute Engine VM nodes within node pools.
Because Pod replicas are already scaled up and waiting for node capacity, Cluster Autoscaler configuration is required.
3
Select the correct `gcloud` CLI command and flags for node pool autoscaling.
`gcloud container node-pools update web-pool` combined with `--enable-autoscaling`, `--min-nodes=2`, and `--max-nodes=8` properly targets the specific node pool and defines its scaling boundaries.
Node pool autoscaling bounds must be set at the node pool resource level rather than the cluster resource level.

Key Concept

Configuring GKE Cluster Autoscaler on node pools to resolve unschedulable Pod resource constraints.
Estimated Time:2m 0s
PreviousPage 47 / 80Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin