Deploy and manage Azure compute resources practice questions

Answer: A) Credit-based disk bursting, which is enabled by default on this disk

Premium SSDs of 512 GiB (P20) and smaller get credit-based bursting by default at no extra cost, which suits short spikes such as VM startup. On-demand bursting (disks larger than 512 GiB, extra cost) and performance-tier changes are for other scenarios.

• ACorrect. Credit-based bursting is on by default for Premium SSDs of 512 GiB (P20) and smaller and adds no cost. Credits build up while the disk runs below its target and are spent on short bursts, such as at boot (a P4 can burst to 3,500 IOPS).
• BIncorrect. On-demand bursting is only available for Premium SSDs larger than 512 GiB, and it adds an hourly enablement fee plus charges for each burst transaction.
• CIncorrect. Changing the performance tier raises baseline performance at a fixed extra cost. It suits workloads that would otherwise burst constantly, and the requirement rules out changing the tier.
• DIncorrect. Only Premium SSDs and Standard SSDs support bursting. A Standard HDD would also lower performance.

Answer: A) Set the scale set's upgrade policy mode to Rolling

The Rolling upgrade policy mode applies scale set model changes in batches, with settings that keep a minimum number of instances available. Automatic mode might upgrade all instances at once, and Manual mode requires you to start each upgrade yourself.

• ARolling mode upgrades instances in batches and uses settings such as batch size and max healthy percentage to keep enough instances available. Microsoft recommends it for production workloads.
• BIn Automatic mode, the scale set makes no guarantees about the order in which VMs are brought down and might take them all down at the same time. That fails the availability requirement.
• CIn Manual mode, existing instances don't change when the model changes. You have to decide when to upgrade each instance yourself.
• DInstance protection is used to keep specific instances from being upgraded with the rest. It doesn't roll out the new model in batches.

Answer: A) A Recovery Services vault with an Azure VM backup policy assigned to the VMs

Use Azure VM backup with a Recovery Services vault and a VM backup policy. It provides scheduled recovery points with configurable retention, and you can restore the full VM or individual files. Azure Disk Backup and Site Recovery can't meet both restore requirements.

• ACorrect. Azure VM backup runs jobs on the schedule in the backup policy, keeps recovery points for the retention you set, and stores them in a Recovery Services vault. From those recovery points you can restore a whole VM or its disks, or use File Recovery to mount a recovery point and copy individual files.
• BIncorrect. Azure Disk Backup takes crash-consistent incremental snapshots of individual managed disks and restores them as disks. Microsoft says to use Azure VM backup instead when you need to restore an entire VM or recover files and folders.
• CIncorrect. Site Recovery replicates VMs so you can fail over to another region during a disaster. It isn't a scheduled backup with 30-day retention and doesn't provide file-level recovery.
• DIncorrect. Lifecycle management policies move blobs between access tiers or delete them based on rules. They don't create recovery points for VMs or managed disks and can't restore files or VMs.

Answer: A) The pricing tier (Free, Shared, Basic, Standard, Premium, Isolated)

• AThe tier sets the compute resources, instance count limits, and which features (custom domains, autoscale, slots, VNet integration) are unlocked.
• BThe resource group is an organizational container and does not affect App Service capabilities.
• CA spending limit caps cost but does not define plan features.
• DZone count affects resilience options, not the plan's feature set.

Answer: A) An availability set

• AAvailability sets distribute VMs across fault domains and update domains so planned maintenance or a rack failure does not take down the whole workload.
• BA zone is a datacenter-level construct; within a zone, spreading across racks/updates still uses availability sets or zone-redundant deployment patterns.
• CProximity placement groups pack VMs close together for low latency, the opposite intent.
• DNSGs filter traffic and have nothing to do with physical placement.

Answer: A) Purchase Azure Reserved VM Instances (1- or 3-year) for that VM size and region

• AReservations give a large discount over pay-as-you-go for committed, always-on capacity; the discount is applied automatically to matching running VMs with no operational change.
• BSpot is cheapest per hour but the VMs can be evicted at any time — unsuitable for a steady 24/7 production workload.
• CA bigger SKU costs more, not less, and doesn't address pricing for steady usage.
• DDedicated Hosts add cost for physical isolation; they don't reduce spend for a normal multi-tenant workload.

Answer: A) An autoscale setting with metric-based scale-out and scale-in rules

Metric-based autoscale rules on a scale set compare a metric such as average Percentage CPU against thresholds over a duration, and scale the instance count out or in automatically.

• AAutoscale rules can use the host metric Percentage CPU with an aggregation (such as Average), a threshold, an operator and a duration, then raise or lower the instance count. One scale-out rule and one scale-in rule meet both requirements.
• BSchedule-based rules scale at fixed times for demand you can predict. They don't respond to the actual CPU load, and the stem says demand is unpredictable.
• CAutomatic instance repairs replace instances that are reported as unhealthy. They don't change the instance count in response to CPU usage.
• DMoving to a larger VM size scales each instance up (vertical scaling). It doesn't add or remove instances as CPU changes.

Answer: A) Flexible orchestration mode

Only Flexible orchestration lets you attach existing VMs, mix Spot and on-demand instances, and manage instances as standard VMs that support Azure Backup. The orchestration mode is set when you create the scale set and can't be changed afterward.

• ACorrect. Flexible scale sets manage standard Azure IaaS VMs. They support attaching existing VMs (when, for example, the fault domain count is 1 and singlePlacementGroup is false), allow Spot and regular-priority instances in the same set, and support Azure Backup.
• BIncorrect. Uniform instances are scale set–specific VMs managed through the scale set VM APIs. You can't add an existing VM to the group, all instances must be Spot or all must be Regular, and Azure Backup isn't supported.
• CIncorrect. Turning off the single placement group doesn't change what Uniform supports: you can attach VMs only to Flexible scale sets, and Uniform still doesn't support mixing Spot and Regular instances or Azure Backup.
• DIncorrect. An availability set isn't a scale set orchestration mode. It doesn't support autoscaling or Spot instances, and an existing VM can't be added to one after creation.

Answer: A) Stop (deallocate) the VM, then resize it — it can then be allocated on a cluster that offers the size

Sizes not offered on the current host cluster become available after the VM is stopped (deallocated) and can be placed elsewhere.

• ADeallocating releases the VM from its current host; on the next start Azure can place it on hardware that supports the requested size.
• BA running VM can only be resized within the sizes its current host cluster supports; there is no automatic live migration for a resize.
• CResizing is fully supported; deleting the VM is unnecessary and risks losing configuration.
• DAvailability sets don't have a size allow-list; this isn't how size availability works.

Answer: A) Mark the connection string as a deployment slot setting

App settings and connection strings swap with the code by default. To keep a value in its slot, mark it as a deployment slot setting. Auto swap, cloning and the legacy override don't do this.

• ACorrect. Connection strings swap by default, but if you select Deployment slot setting, App Service treats the value as specific to the slot. It stays in its slot when the code is swapped.
• BIncorrect. Auto swap only swaps automatically after a code push and warm-up. It doesn't change which settings move during the swap, so the connection string would still swap.
• CIncorrect. Cloning copies app settings and connection strings into the new slot as editable values. It doesn't stop those values from moving during a swap.
• DIncorrect. This setting goes back to the legacy swap behavior, which makes certain settings that stay in their slot by default (such as IP restrictions and Always On) swappable. It doesn't make a connection string stay in its slot.