Skip to main content

Technical Lab: Choose between manual and autoscale

Questions​

Question 1 — Multiple Choice​

An engineering team needs to scale an Azure Application Gateway v2 to support an e-commerce system with predictable traffic spikes during seasonal campaigns. Outside these periods, traffic drops to very low levels. The team wants to minimize operational costs and avoid manual intervention for each campaign.

Which scaling configuration is most appropriate for this scenario?

A) Manual scaling with a fixed instance count high enough to support the maximum predicted peak

B) Autoscale with a low minimum instance value and a maximum value compatible with the expected peak

C) Manual scaling with scheduled adjustment via automation scripts before each campaign

D) Autoscale with minimum value equal to maximum value to ensure stability during peaks

Question 2 — Technical Scenario​

An architect is reviewing the configuration of an Azure Application Gateway v2 in production. He observes that the gateway was configured with autoscale enabled, but the minCapacity property is set to 0.

{
  "sku": {
    "name": "Standard_v2",
    "tier": "Standard_v2"
  },
  "autoscaleConfiguration": {
    "minCapacity": 0,
    "maxCapacity": 10
  }
}

During a period of near-zero traffic during the early morning hours, users report high latency on the first requests when resuming usage in the morning. What is the most likely cause of this behavior?

A) The maxCapacity: 10 value is insufficient to absorb traffic resumption

B) With minCapacity: 0, the gateway can scale down to zero instances and needs time to provision when receiving new requests

C) The Standard_v2 SKU does not support autoscale with minimum value below 2

D) The JSON configuration is malformed and autoscale is not being applied correctly

Question 3 — True or False​

Azure Application Gateway v1 supports native autoscaling in the same way as v2, making the choice of tier purely a cost decision, without impact on the availability of the automatic scaling feature.

Question 4 — Technical Scenario​

A company configures an Azure Application Gateway v2 with manual scaling set to capacity: 2. During a load test, the gateway's maximum throughput is reached and requests begin to be dropped. The responsible engineer increases the capacity to 8 via portal, but notices that the adjustment takes several minutes to take full effect.

What technical conclusion does this scenario illustrate about using manual scaling in variable load environments?

A) Manual scaling is inadequate for any production environment and should always be replaced by autoscale

B) The delay in provisioning additional instances is expected and represents an operational risk in unpredictable loads with manual scaling

C) The problem was caused by incorrect SKU choice; the correct version would eliminate the provisioning delay

D) Increasing capacity via portal applies instances immediately without delay, indicating another problem in the infrastructure

Question 5 — Multiple Choice​

When configuring autoscale in an Azure Application Gateway v2, which statement correctly describes the relationship between minCapacity, maxCapacity and billing behavior?

A) The gateway only charges for instances that are effectively in use at the moment, regardless of the minCapacity value

B) The minCapacity value defines the minimum number of instances always provisioned and billed, even if traffic is zero

C) When minCapacity is 0, there is no charge for instance capacity at any time, including during active traffic

D) The maxCapacity determines the fixed monthly cost, regardless of the actual scaling that occurred

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

Configuring autoscale with low minCapacity and maxCapacity compatible with the seasonal peak is the correct approach for this scenario. Autoscale dynamically adjusts the number of instances based on actual demand, reducing costs during low traffic periods and automatically expanding capacity during campaigns.

Alternative A wastes resources by maintaining idle instances outside of peaks. Alternative C adds operational complexity and risk of human or scheduling failure. Alternative D functionally equals manual scaling, as fixing min equal to max eliminates the benefit of dynamic scaling.

Answer Key — Question 2​

Answer: B

When minCapacity is set to 0, Application Gateway v2 can reduce the number of active instances to zero during periods of insignificant traffic. When usage resumes, there is a cold start time to provision instances, which explains the high latency on the first requests of the morning.

Alternative A is incorrect because maxCapacity: 10 is sufficient for most scenarios. Alternative C is false: the Standard_v2 SKU supports minCapacity: 0 without SKU restriction. Alternative D is incorrect; the JSON is well-formed and the configuration is valid.

The central point is understanding that minCapacity: 0 is a decision of cost versus immediate availability, and not a configuration error.

Answer Key — Question 3​

Answer: False

Application Gateway v1 does not support native autoscaling. Automatic scaling is an exclusive functionality of the v2 tier. In v1, scaling is strictly manual, requiring the operator to define and adjust instance count explicitly.

Therefore, the choice between v1 and v2 is not just a cost decision: it determines whether the autoscale feature is available or not. Environments that require automatic scaling must use the v2 tier.

Answer Key — Question 4​

Answer: B

The scenario illustrates an inherent risk of manual scaling: provisioning new instances is not instantaneous. When capacity is manually increased in response to an already ongoing overload, there is a time window during which the gateway operates beyond its configured capacity, resulting in request dropping or service degradation.

Alternative A is an incorrect generalization: manual scaling has legitimate use cases in environments with stable and predictable load. Alternative C is wrong as the provisioning delay is expected behavior, not a SKU defect. Alternative D is factually incorrect: increasing instances via portal, API or CLI involves provisioning time.

Answer Key — Question 5​

Answer: B

The minCapacity defines a floor of always provisioned capacity, and the corresponding instances are billed continuously, even without active traffic. This occurs because Application Gateway maintains these instances in ready state to ensure immediate availability.

Alternative A is incorrect: the billing model includes instances from minCapacity regardless of traffic. Alternative C is incorrect: even with minCapacity: 0, when the gateway is processing traffic the provisioned instances are billed. Alternative D is incorrect: maxCapacity is an operational limit, not a fixed billing base.

Understanding this model is essential for estimating costs and justifying the choice between minCapacity: 0 (lower cost, possible cold start) and minCapacity >= 1 (minimum fixed cost, guaranteed immediate availability).