Correct: B — Availability set

Why B: Availability sets distribute VMs across Fault Domains (protect against rack/hardware failure) and Update Domains (protect against planned maintenance rolling restarts). Both requirements are satisfied within a single datacenter.

Why not A: Availability zones protect against datacenter-level failures (separate power/cooling/networking). The question says single-datacenter tolerance is acceptable and doesn't require multi-datacenter protection. Zones are overkill and more expensive.

Why not C: VMSS with manual scaling doesn't inherently provide the same FD/UD distribution guarantees as an availability set (it can, but that's not the primary purpose of manual scaling mode).

Why not D: Azure Site Recovery is a disaster recovery tool for replicating VMs to another region — not for local hardware/maintenance protection.

Correct: B — The D: drive is the temporary disk

Why B: On Windows Azure VMs, the D: drive (and /dev/sdb on Linux) is the temporary disk — a local SSD on the physical host. It is reset (data lost) when a VM is deallocated (stopped), resized, or migrated to a new physical host during maintenance. It is not a persistent managed disk.

Why not A: The OS restart doesn't touch the D: drive unless a disk formatting script was intentionally run.

Why not C: Locks operate on the Azure management plane — they don't affect data written inside the OS.

Why not D: Disk SKUs don't change on restart.

Exam tip: The temp disk is fast and cheap but non-persistent. Use it only for scratch data, swap, and temp files. Never for application data.

Correct: C — Standard (S1)

Why C: Deployment slots require Standard tier or above. Standard plans support up to 5 slots.

Why not A/B: Free and Basic plans support neither deployment slots nor autoscaling.

Why not D: Premium supports up to 30 slots and is a valid answer, but it is not the minimum — Standard is sufficient.

Exam tip: Standard tier unlocks: deployment slots, autoscale, custom domains with TLS, daily backups. Memorize this tier as the "production-ready" minimum for App Service.

Correct: C — az deployment group what-if

Why C: The what-if command shows exactly which resources will be created, modified, or deleted — a pre-deployment preview with color-coded output. No actual changes are made.

Why not A: validate only checks the template for syntax and basic structural errors — it does not compare against existing resources to show delta changes.

Why not B: --dry-run is not a valid flag for az deployment group create.

Why not D: preview is not a valid subcommand.

Exam tip: Know these three commands and their purpose:

• validate = syntax/schema check
• what-if = preview changes vs current state
• create = actually deploy

Correct: B — Without a scale-in rule, the scale set only grows

Why B: Autoscale rules are independent — scale-out and scale-in are separate rules you define. If you only define scale-out, the system adds instances when load is high but never removes them. Instances accumulate until the maximum count is reached.

Why not A: There is no default scale-in behavior. Azure does not assume you want to scale in at a symmetric CPU threshold.

Why not C: Cooldown periods control the frequency of scaling actions, not the direction.

Why not D: The configuration is valid — it just has no scale-in rule, which is a logical gap, not a configuration error.

Exam tip: Always configure autoscale in pairs — a scale-out rule and a corresponding scale-in rule with a lower threshold.

Correct: B — Incorrect subnet name

Why B: Azure Bastion requires the subnet to be named exactly AzureBastionSubnet — case-sensitive, no spaces, no variations. Any other name causes immediate validation failure at deployment time.

Why not A: Bastion itself gets the public IP (Standard SKU required on the Bastion resource) — the VNet doesn't need a public IP. VMs behind Bastion specifically do NOT need public IPs.

Why not C: The /24 VNet isn't the issue — Bastion's dedicated subnet needs a minimum /26 CIDR, but the VNet size is separate.

Why not D: Bastion connects to VMs over their private IPs — NSG on the VM subnet is not required (Bastion handles the RDP/SSH termination). Though good practice, it's not a deployment blocker.

Correct: B — Rolling update across Update Domains

Why B: VMSS supports rolling upgrade policies. In rolling mode, instances are updated in batches (by Update Domain) to maintain availability. In automatic mode, all instances are updated as quickly as possible. In manual mode, you control when each instance is updated using az vmss update-instances.

Why not A: Immediate deletion of all instances would cause downtime — that's the "Automatic" upgrade policy with no batching configured.

Why not C: Image changes apply to all instances based on the upgrade policy — they don't only affect new instances (that would be a new VM from a different image, not a scale set image update).

Why not D: VMSS fully supports image updates.

Exam tip: Know the three VMSS upgrade policies: Automatic (fast, less control), Rolling (batched, maintains availability), Manual (you control timing per instance).

Correct: C — Azure Container Instances (ACI)

Why C: ACI bills per second of CPU and memory consumed. When the container finishes and stops, billing stops completely. No cluster to pay for, no idle VMs. For a short-lived, scheduled container workload with no need for orchestration, ACI is the most cost-effective choice.

Why not A: AKS requires a node pool running continuously (you pay for the VMs in the node pool even when no pods are scheduled). Unless you configure virtual nodes (ACI integration), there's always idle cost.

Why not B: VMSS always has a minimum instance count incurring cost, even in autoscale configurations.

Why not D: App Service "scale to zero" is available only on Consumption and Elastic Premium App Service plans, not standard App Service. Also, App Service is optimized for web apps, not batch container workloads.