Exam AZ-303 topic 5 question 107 discussion

Taken current number of instances: 3, instances after scale in: 2 we have: 3x60 = 180 / 2 = 90.0% (>80%, no scale in occurs) 3x55 = 165 / 2 = 82.5% (>80%, no scale in occurs) 3x50 = 150 / 2 = 75.0% (<80%, scale in) 3x45 = 135 / 2 = 67.5% (<80%, scale in) Answer is B: B. 45% and 50% only

B is the correct answer as per below https://docs.microsoft.com/en-us/azure/azure-monitor/platform/autoscale-best-practices

Answer is B

B is correct for sure. see what Azure doc says. Before scaling down, autoscale tries to estimate what the final state will be if it scaled in. For example, 575 x 3 (current instance count) = 1,725 / 2 (final number of instances when scaled down) = 862.5 threads. This means autoscale would have to immediately scale out again even after it scaled in, if the average thread count remains the same or even falls only a small amount. However, if it scaled up again, the whole process would repeat, leading to an infinite loop. To avoid this situation (termed "flapping"), autoscale does not scale down at all. Instead, it skips and reevaluates the condition again the next time the service's job executes. The flapping state can confuse many people because autoscale wouldn't appear to work when the average thread count was 575. Read carefully: https://docs.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-best-practices

Correct if you know how to count.

100% B is the right answer

seaman29 has said it best B is the answer

brilliant seaman29

B is correct Explained in https://docs.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-best-practices#choose-the-thresholds-carefully-for-all-metric-types

The answer is B: 45% and 50% only. Autoscale will not scale in for 60% or 55% because that would immediately put resources in a "scale out" state. This infinite loop behavior is referred to as "flapping." Please see link below for Microsoft's explanation. Quoting seaman29 for the math: Taken current number of instances: 3, instances after scale in: 2 we have: 3x60 = 180 / 2 = 90.0% (>80%, no scale in occurs) 3x55 = 165 / 2 = 82.5% (>80%, no scale in occurs) 3x50 = 150 / 2 = 75.0% (<80%, scale in) 3x45 = 135 / 2 = 67.5% (<80%, scale in) https://docs.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-best-practices#:~:text=To%20avoid%20this%20situation%20(termed,time%20the%20service's%20job%20executes.

B. 45% and 50% only. Before scaling in, autoscale tries to estimate what the final state will be. When the CPU is utilized for 55% with 3 instances, scaling in would immediately cause scaling out: 55% x 3 = 165% => 165% / 2 = 82.5%. If it scaled out again, the whole process would repeat, leading to an infinite loop. To avoid this situation (termed "flapping"), autoscale does not scale in at all. Instead, it skips and reevaluates the condition again the next time the service's job executes. https://docs.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-best-practices

Answer is D, even 60% will trigger it but not present so.

The question is framed with a trick and the answer here is correct. all the utilizations given in options can cause Scale in. so Answer is D.

Great explaination on this page. https://docs.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-best-practices Before scale-in happens, the "after State" is calculated first.. Like if at 3 instances with 60% usage are there, scale-in is triggered, but does not happen. Because, 60*3 = 180 and if 3-1 =2 happens, the resulting usage will be 180/2 = 90% which will result in scale-out immediately, aka Flapping.. therefore 45 and 50% are the only 2 where scale-in will happen.

Correct Answer: B As it considers the average CPU utilization post scale down. Check this: https://docs.microsoft.com/en-us/azure/azure-monitor/platform/autoscale-best-practices Assume there are 2 instances to start with. If the average CPU% across instances goes to 80, autoscale scales out adding a third instance. Now assume that over time the CPU% falls to 60. Autoscale's scale-in rule estimates the final state if it were to scale-in. For example, 60 x 3 (current instance count) = 180 / 2 (final number of instances when scaled down) = 90. So autoscale does not scale-in because it would have to scale-out again immediately. Instead, it skips scaling down. The next time autoscale checks, the CPU continues to fall to 50. It estimates again - 50 x 3 instance = 150 / 2 instances = 75, which is below the scale-out threshold of 80, so it scales in successfully to 2 instances.

Looks like B. Autoscale does not scale-in if it has to scale-out again immediately because of scale-out rule. Instead, it skips scaling down.

None of the provided answers is correct. As the configured scale-in rule is "CPU time less or equal to 60%", plus the app is configured to run between 2 to 5 instance with 3 as initial instance. Therefore, scale-in will occur once at 60% to 2 instance and no more scale-in will occur as it hits minimum instance #.