A town finance committee expects a library app's VMs to run continuously for three years and wants lower compute rates than month-to-month pay-as-you-go. Which cost factor are they evaluating?
Select an answer to reveal the explanation.
Short Explanation
Commit longer, often pay less per hour — like a transit annual pass versus daily tickets. Reserved capacity trades commitment for discounted rates compared with pure pay-as-you-go. Choosing that purchasing model is itself a cost factor.
Full Explanation
Purchasing model is a distinct Azure cost factor. Pay-as-you-go meters continuous library VMs at on-demand rates with no term commitment. When a town finance committee expects three years of steady runtime and wants lower effective compute rates, reserved capacity (or similar commitment-based purchasing) is the model under evaluation: commit for a term, typically receive a discounted rate versus always paying as you go. That decision is independent of cosmetic portal settings and of whether tags exist on a virtual network.
Tags on a virtual network aid organization and cost allocation reporting; they do not change the compute purchasing model. Azure Monitor alert rule naming conventions affect operational hygiene, not reservation versus pay-as-you-go pricing. Portal theme and dashboard layout preferences are user interface choices with no impact on VM rates.
Exam caveat: reservations reduce rate for covered usage but do not remove the need to right-size SKUs or shut down truly idle capacity—commitment is not a substitute for waste reduction. Also confirm scope (subscription, resource group, or shared) and VM family eligibility before promising savings to council. Operational check: model the same VM size for three years in the pricing calculator under pay-as-you-go versus reserved options, then verify in Cost Management after purchase that utilization of the reservation remains high enough to realize the expected discount.