Sample questions
Azure Compute Vm AppserviceDifficulty 1
A team needs a VM size family for a dev/test workload that is mostly idle but occasionally needs short CPU bursts. Which VM series is designed for exactly this pattern?
- aD-series, Azure's general-purpose balanced CPU-to-memory family
- bB-series (burstable), which accrues CPU credits while idle.✓
- cF-series, optimized for sustained high CPU workloads like batch processing
- dE-series, optimized for large in-memory workloads like databases and caches
Explanation:B-series VMs are the burstable family: they run at a low baseline CPU performance most of the time, accruing credits, and can burst above baseline using those credits when a short spike in demand occurs — a good cost fit for mostly-idle workloads. D-series is general-purpose (a is wrong), F-series targets sustained compute-heavy workloads (c is wrong), and E-series targets memory-heavy workloads (d is wrong).
Azure Compute Vm AppserviceDifficulty 1
What is the primary purpose of an Availability Set in Azure?
- aTo spread VMs across separate fault domains and update domains within a datacenter.✓
- bTo automatically scale the number of VM instances up or down based on CPU metrics over time.
- cTo replicate VM disks synchronously to a paired region for disaster recovery
- dTo load balance HTTP traffic across VM instances at layer 7
Explanation:An Availability Set distributes VMs across fault domains (distinct racks/power/network) and update domains (groups that get patched/rebooted at different times) within one datacenter, so a single rack failure or a host maintenance cycle doesn't take out every instance simultaneously. It doesn't scale instance count (b, that's VMSS autoscale), doesn't do cross-region replication (c), and isn't a load balancer (d).
Azure Compute Vm AppserviceDifficulty 2
How does an Availability Zone differ from an Availability Set?
- aThey are the same feature with two different names used interchangeably in the Azure portal
- bAn Availability Zone only protects against software failures, while an Availability Set protects against hardware failures
- cAn Availability Zone spreads resources across separate datacenters in a region, while an Availability Set spreads them within a single datacenter.✓
- dAn Availability Zone requires a separate Azure subscription for each zone
Explanation:Availability Zones are physically separate datacenters within the same Azure region, each with independent power, cooling, and networking, giving protection against a whole-datacenter-level failure — a stronger guarantee than an Availability Set, which only spreads VMs across fault/update domains inside one datacenter. They are distinct features (a is wrong), both address hardware/facility-level failure scenarios rather than a software/hardware split (b is wrong), and zones don't require separate subscriptions (d is wrong).
Azure Compute Vm AppserviceDifficulty 1
What is a Virtual Machine Scale Set (VMSS)?
- aA single large VM with more CPU cores than a normal VM size offers
- bA billing construct that groups multiple VMs for a single consolidated invoice
- cA feature that lets one VM run multiple independent operating systems simultaneously for testing purposes.
- dA group of identical, load-balanced VMs managed as a set, with automatic scale in/out.✓
Explanation:A VMSS lets you deploy and manage a set of identical, auto-scaling, load-balanced VMs as a single resource — you define an instance template once, and the scale set can grow or shrink the instance count automatically (or manually) in response to demand. It's not a single oversized VM (a), not a billing grouping (b), and not a multi-OS single VM (c).
Azure Compute Vm AppserviceDifficulty 2
A VMSS has an autoscale rule configured to add an instance when average CPU exceeds 70%. What kind of autoscale trigger is this?
- aA schedule-based trigger, since it runs on a recurring check interval
- bA metric-based trigger, since scaling is driven by a resource metric crossing a threshold.✓
- cA manual trigger, since an operator must approve each scale event
- dA webhook-based trigger, since it depends on an external HTTP callback to fire
Explanation:Autoscale rules driven by a resource metric (CPU, memory, queue length, custom metrics, etc.) crossing a defined threshold are metric-based triggers — the scaling decision is a direct function of observed load. A schedule-based trigger instead scales at fixed times/dates regardless of load (a is wrong); this rule requires no manual approval (c is wrong) and doesn't depend on an external webhook to initiate the scale action itself (d is wrong, though webhooks can be attached as a notification after scaling).
Azure Compute Vm AppserviceDifficulty 1
What is the difference between 'scaling up' and 'scaling out' for a compute resource?
- aThey are two names for exactly the same operation
- bScaling up means adding more instances; scaling out means increasing the size of one instance permanently.
- cScaling up increases an instance's size/SKU; scaling out adds more instances of the same size.✓
- dScaling up only applies to storage; scaling out only applies to compute
Explanation:Scaling up (vertical scaling) means moving an existing instance to a bigger SKU (more vCPUs, more memory); scaling out (horizontal scaling) means adding more instances at the same size to share the load. They are distinct operations (a is wrong), the definitions in (b) are swapped, and both apply broadly across compute and other resource types, not split the way (d) claims.