Home Microsoft Exams Google Cloud Exams

Loading page

Curious about new developments and updates? Follow our social media.

Get a free certification question every week.

Microsoft Exams

AZ-104 Administrator
AZ-204 Developer
AZ-900 Fundamentals
All Microsoft Exams

Google Cloud Exams

Associate Data Practitioner
All Google Cloud Exams

Terms Privacy Cookies About Pricing

© 2026 StudyCerts. All rights reserved.

StudyCerts is an independent service and is not affiliated with, endorsed by, or sponsored by any certification body or cloud provider.

Loading page

Home
Google Cloud Exams
Professional Cloud DevOps Engineer
Autoscaling (e.g., managed instance groups, Cloud Run, GKE)
A DevOps engineering team operates a data ingestion service …

Professional Cloud DevOps Engineer

Professional Cloud DevOps Engineer

Advanced

Prepare and test your skills

Description
Sample Question
Free Trial
Practice Test

Advanced

Prepare and test your skills

Description
Sample Question
Free Trial
Practice Test

Mig Autoscaling Scale In Controls Stabilization

Section: Autoscaling (e.g., managed instance groups, Cloud Run, GKE)

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

...

...

...

...

...

Explanations

...

View source documentation

Related questions

Keep the momentum going with these hand-picked practice scenarios

AdvancedProfessional Cloud DevOps Engineer

You are architecting an autoscaling strategy for a latency-critical event processing application deployed on Google Kubernetes Engine (GKE) Standard. The application experiences sudden spikes in message volume from a Google Cloud Pub/Sub subscription and variable memory usage during payload deserialization. You need to scale the container replicas based on queue depth, optimize container resource sizing without metric contention, and ensure the underlying cluster infrastructure dynamically provisions compute capacity when Pods cannot be scheduled. Which autoscaling configuration should you implement?

Autoscaling (e.g., managed instance groups, Cloud Run, GKE)

AdvancedProfessional Cloud DevOps Engineer

An SRE team manages a latency-critical e-commerce checkout API deployed on Google Cloud Run. The API experiences unpredictable, spiky traffic patterns throughout the day. During traffic surges, the service frequently breaches its 99th percentile (P99) latency Service Level Objective (SLO) due to cold-start overhead when new container instances spin up. Performance profiling shows that each container instance is thread-safe and can handle up to 40 concurrent requests without performance degradation. You need to optimize the Cloud Run autoscaling configuration to eliminate cold-start latency for baseline traffic and handle rapid bursts efficiently, while minimizing infrastructure costs. Which configuration should you apply to the Cloud Run service?

Autoscaling (e.g., managed instance groups, Cloud Run, GKE)

AdvancedProfessional Cloud DevOps Engineer

An e-commerce checkout flow spans three microservices instrumented with OpenTelemetry: frontend-service, payment-service, and inventory-service. Users intermittently experience 504 Gateway Timeout errors during high-traffic flash sales. You examine Cloud Trace in the Google Cloud console and observe the following pattern on failing requests: The root span (frontend-service: /checkout) has a duration of 30,000 ms. Child span 1 (payment-service: /charge) executes concurrently and completes successfully in 250 ms. Child span 2 (inventory-service: /reserve) remains active for 29,750 ms before returning an HTTP 500 error status. You need to isolate the critical path bottleneck and determine the root cause of the failure using integrated Google Cloud Observability tooling. What should you do?

Utilizing tracing frameworks (e.g., OpenTelemetry)

AdvancedProfessional Cloud DevOps Engineer

Your enterprise is establishing an end-to-end software supply chain security architecture for containerized microservices deployed to Google Kubernetes Engine (GKE). Your design must satisfy the following requirements: Automatically and continuously scan container images stored in Artifact Registry for newly discovered vulnerabilities. Generate cryptographic build provenance and verify security attestations throughout the CI/CD pipeline. Enforce that only verified, non-vulnerable container images are admitted into the GKE clusters at deploy time. Continuously monitor running GKE Pods to detect policy violations if new vulnerabilities or invalid attestations emerge post-deployment. Which strategy should you implement?

Security of CI/CD tooling

AdvancedProfessional Cloud DevOps Engineer

An enterprise e-commerce platform processes terabytes of raw clickstream events daily. The architecture ingests data into Cloud Storage and loads it into BigQuery for analytical processing. The FinOps team identifies escalating storage and compute expenses and establishes the following requirements: Cloud Storage: Raw event objects must remain in high-performance storage for 30 days, transition to a lower-cost tier for infrequent monthly access between days 31 and 90, and move to the lowest-cost archival tier after 90 days for long-term compliance retention. BigQuery Storage & Query Optimization: Analytical queries primarily filter on daily event timestamp boundaries and frequently filter or aggregate by specific user IDs and event types. Full table scans must be eliminated to drastically curb processed byte volumes. BigQuery Compute Cost Management: The team requires predictable billing limits and wants to prevent runaway query costs caused by concurrent ad-hoc analysis, replacing unpredictable on-demand processing fees. Which combination of actions should the DevOps engineer implement to meet these architectural and financial goals?

Optimizing resource usage for cost and efficiency

AdvancedProfessional Cloud Data Engineer

A data engineering team is designing a streaming pipeline using Apache Beam running on Cloud Dataflow to process financial transactions and sink transformed account balances into Google Cloud Spanner. During disaster recovery and worker failure testing, the team observes that pipeline tasks retry and fail with com.google.cloud.spanner.SpannerException: ALREADY_EXISTS exceptions, causing the Dataflow job to crash. Which mutation strategy should the team implement in their Apache Beam transformation logic to ensure resilient and idempotent writes to Cloud Spanner?

Defining data transformation and orchestration logic

Want more questions like this?

Get a free certification question every week.

Last updated August 28, 2026

Are you ready for the Professional Cloud DevOps Engineer?

50 questions in the full practice test

More Autoscaling (e.g., managed instance groups, Cloud Run, GKE) practice questions

Get a free certification question with a full explanation every week.

Professional Cloud DevOps Engineer

Provider: Google Cloud
Passing score: 70%
Questions: 50
Duration: 90 minutes

Other sections in this exam

Bootstrapping and maintaining a Google Cloud organization
Building and implementing CI/CD pipelines, including continuous testing, for application, infrastructure, and machine learning workloads
Applying site reliability engineering practices
Implementing observability practices and troubleshooting issues
Optimizing performance and cost

Ask Scout

Still curious? Scout, our AI tutor, can explain this concept further and answer your follow-up questions.

A DevOps engineering team operates a data ingestion service running on a Compute Engine regional Managed Instance Group (MIG). The worker instances process tasks pulled from a Cloud Pub/Sub subscription.

During high-volume periods, incoming message traffic fluctuates rapidly with intermittent 2-to-3-minute lulls between bursts. The team observes the following issues:

VM Thrashing: The MIG autoscaler repeatedly scales out during bursts and scales in during short lulls, causing high instance churn and initialization overhead.
Work Disruption: Instances are deleted while still finishing active message processing.

Which autoscaler configuration should the team implement to resolve these issues?

Increase the autoscaler cool-down period to 30 minutes to suppress metric collection while instances are running.

Configure scale-in controls with a stabilization period and set max scaled-in replicas to restrict the rate of instance removal.

Set the autoscaling mode to 'Only scale out' and configure a Cloud Scheduler job to issue periodic scale-in API requests.

Enable predictive autoscaling in 'Optimize for availability' mode and switch the target metric from Cloud Pub/Sub queue depth to CPU utilization.

Increase the autoscaler cool-down period to 30 minutes to suppress metric collection while instances are running.

Configure scale-in controls with a stabilization period and set max scaled-in replicas to restrict the rate of instance removal.

What scale-in controls and stabilization periods are

Scale-in controls in Compute Engine Managed Instance Groups (MIGs) allow administrators to regulate the pace at which the autoscaler removes VM instances. By defining a stabilization period (a lookback window up to several hours) and a max scaled-in replicas constraint (either a fixed number or percentage), the autoscaler prevents rapid, abrupt reductions in capacity during transient drops in load.

How it meets the requirements

Mitigates VM thrashing: During short traffic lulls (e.g., 2–3 minutes), the stabilization window keeps the autoscaler evaluating the peak load observed across the specified lookback window rather than reacting instantly to momentary troughs. This prevents instances from being torn down immediately before the next traffic burst arrives.
Prevents work disruption: Setting maxScaledInReplicas restricts the rate of instance deletions per time unit, providing a gradual scaling curve that gives running instances adequate time to finish inflight messages and drain workloads cleanly.

Key advantages

Smooth capacity transitions: Eliminates the "sawtooth" pattern of rapid provisioning and deprovisioning in bursty environments.
Cost and performance predictability: Balances compute resource costs against the overhead and latency penalty of frequent VM cold starts.
Customizable lookback windows: Allows teams to set stabilization periods from 0 to 3,600 seconds (or longer depending on configuration) based on workload burst cycles.
Native control plane integration: Operates entirely within the managed MIG autoscaling policy without custom orchestration code.

Why this is optimal

Scale-in controls are purpose-built in Google Cloud to handle bursty workloads where short-term metric drops would otherwise trigger premature scale-in events, directly eliminating VM thrashing while protecting in-progress tasks.

Set the autoscaling mode to 'Only scale out' and configure a Cloud Scheduler job to issue periodic scale-in API requests.

Enable predictive autoscaling in 'Optimize for availability' mode and switch the target metric from Cloud Pub/Sub queue depth to CPU utilization.