Exam AZ-300 topic 16 question 14 discussion

I believe B is correct for the following: 45*3=135, 135/2=67.5, 67.5 < scale out threshold of 80, so Azure WILL scale in 50*3=150, 150/2=75.0, 75.0 < below scale out threshold of 80, so Azure WILL scale in 55*3=165, 165/2=82.5, 82.5 > scale out threshold of 80, so Azure WILL NOT scale in

D is right. As it considers the avergae 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.

B is correct 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)

Correct Answer is B, since when you scale down you have two instances...if you have this two with the past percentage (55% or 60% ) of usage you will get 82.5% and 90% with this two instances, that automatically will scale out again. So the percentage wich it would scale in and stays like that is 45% and 50%

I can't be the only one looking at these explanations and thinking, in order for the app to SCALE IN, the avg CPO has to be below 60. Looking at all these calculations at no time would the avg CPU percentage be below 60 in order to scale down. (50/3)/2=75(above the 60 threshhold, (45/3)/2=67.5 also above the 60% scale in threshold thus should not scale in. So, I can kind of understand what you are trying to do by these calculations, but the questions states under 60-..not under 80 to scale in. I am probably looking at this incorrectly, but had to throw my .02 out there in case others thought the same way.

the question is not clear according to me, are those readings from the same instance or simultaneous reading from separate instances?

Some great discussions here. Thanks to those who mentioned calculations. Answer is 45 and 50 only.

1st i did not understand the explanation though Answer is B. Then i spne sometime as it require mathematics apart from logic for everyone to understand. Instance Count --> 3 Scale Out --> 80% CPU Utilization Scale In --> Less or Equal to 60% Now the calculation takes place. Assume if all 3 servers utlization is 60% then the average is (60+60+60)/2 [3-1] (Need to reduce by 1 from total instance as part of scale down) which is 90% hence scale in is not possible. You can apply similar calculation for 55 and the answers 165/2 again scale in will not happen. Now, if we do the same for 40 and 45%, the result is lesser than scale-out thresold of 80, so it scales in successfully to 2 instances.

https://docs.microsoft.com/en-us/azure/azure-monitor/platform/autoscale-best-practices We recommend choosing an adequate margin between the scale-out and in thresholds. As an example, consider the following better rule combination. Increase instances by 1 count when CPU% >= 80 Decrease instances by 1 count when CPU% <= 60 In this case 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.

B (45%, 50%)

Why are we computing here? I think we should consider that the numbers given are the utilization of the App itself. Because if the numbers are per instance shouldnt be the choices 4 percentange as well?

Correct answer is B, Any % below (80*2)/3=53.33% will cause the scale in.

Answer B - 45 and 50 - 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.

C is right. there are 3 instances to start.

Based on your reponse the answer should be B. 45% and 50% only because (55X3)/2 > 80.

Sorry, my explanation is right but answer is B. 45 and 50% only. As when utilization is 55% then if scale in the load is to be shared by 2 instances which will bring the load to 82.5% (55*3 = 165 -> 165/2 = 82.5) per instance and immediately it would need to scale out. Hence it will not scale in at 55%.