An architect at Cascade Regional Airlines is documenting the scale-in behavior of the booking site's Virtual Machine Scale Set, which has not had any explicit scale-in policy configured. Which statement correctly describes the behavior that applies by default when the scale set removes instances?
Select an answer to reveal the explanation.
Short Explanation
Leaving the policy unset doesn't mean there's no logic — the Default policy quietly does something sensible on its own. It first keeps fault domains balanced so you don't accidentally strip resilience from one domain, and only then picks among the remaining candidates by instance ID.
Full Explanation
When no explicit scale-in policy is configured on a Virtual Machine Scale Set, the platform applies the Default policy, which first attempts to keep the number of instances balanced evenly across fault domains, preserving the scale set's resilience posture during scale-in events, and then, among the instances that are equally eligible for removal after that balancing step, prefers to remove the instance with the highest instance ID. This behavior is automatic and requires no administrator action, so the claim that scale-in is blocked without a manually configured policy is incorrect — scale sets scale in automatically under Default behavior just as they scale out. The Default policy is also not simply 'oldest instance always removed'; that description matches the explicit OldestVM policy, which is a distinct, separately selectable option from Default. Default scale-in is not random either — the fault-domain balancing and instance-ID tie-breaking are deterministic, repeatable rules rather than an unpredictable selection. As an operational check, an architect can trigger a scale-in event in a test environment and review the removed instance IDs against the fault-domain distribution shown in the scale set's instance view to confirm the balancing-then-highest-ID pattern actually holds.