Skip to main content
  1. Home
  2. >
  3. Azure
  4. >
  5. AZ-104
  6. >
  7. ARM vs Portal for VM Provisioning | Azure AZ-104

ARM vs Portal for VM Provisioning | Azure AZ-104

Jeff Taakey
Author
Jeff Taakey
21+ Year Enterprise Architect | Multi-Cloud Architect & Strategist.

While preparing for the AZ-104: Microsoft Azure Administrator exam, many candidates struggle with understanding the nuances of deploying virtual machines from ARM templates. In the enterprise world, the choice often involves balancing automation efficiency against governance and configuration flexibility. Let’s drill into a simulated migration and VM provisioning scenario.

Scenario
#

Tailwind Traders is a well-established global wholesale distributor facing increasing infrastructure costs and operational overhead from manually configuring Windows Server VMs. As part of their cloud migration journey, they have standardized on Azure Resource Manager (ARM) templates to deploy Windows Server 2019 virtual machines consistently.

Their engineering team created a golden image VM named VM1 running Windows Server 2019 and saved it as an ARM template called TemplateGold. They plan to deploy new VMs for different environments (Dev, Test, Prod) based on this template.

Key Requirements
#

When deploying a new VM named VM3 from TemplateGold, the administrators need to understand which properties they can customize at deployment time to meet environment-specific standards while ensuring governance compliance.

The Options
#

  • A) Operating system details (e.g., Windows vs. Linux)
  • B) Administrator username
  • C) Virtual machine size (e.g., Standard_D2s_v3 vs. Standard_B2s)
  • D) Azure resource group assignment

Correct Answer
#

B) Administrator username


The Architect’s Analysis
#

Correct Answer
#

Option B — Administrator username

Step-by-Step Winning Logic
#

ARM templates for VM deployment typically include the OS image specification hardcoded or linked to a managed image resource, locking the operating system version/type (Option A). Administrator username is declared as a parameter in templates to allow unique identity per VM deployment — critical for operational security and compliance, fitting well with the Authentication and Identity pillar of Microsoft’s Well-Architected Framework.

Virtual machine size (Option C) can be parameterized and customized, but when a VM is saved as a template inside the Azure Resource Manager library (such as a managed image reference), the size is not inherently modifiable within the saved template itself, rather it is specified during deployment commands or portal, but typically requires template adjustment or parameterization before deployment.

Resource group assignment (Option D) happens outside the template—resource groups are a deployment container decision and set by deployment scope, not by the template content. This falls under enterprise governance scope at subscription and management group levels, not VM template parameters.

The Traps (Distractor Analysis)
#

  • Why not A? Operating system details are baked into the VM image or managed image behind the template. Changing OS type at deployment from a template of a particular VM is not feasible—would require a different image/template.
  • Why not C? While VM size can be adjustable if the ARM template is designed with a parameter for size, a generic saved “template” tied to a specific VM image often fixes VM size unless you explicitly edit parameter files before deployment.
  • Why not D? Resource group is a deployment construct and decided at deployment command time outside the ARM template when invoking deployment, not part of the template parameters themselves.

The Architect Blueprint
#

graph TD DevOpsTeam([DevOps Team]) --> ARMTemplate["ARM Template: TemplateGold"] ARMTemplate --> AzurePortal["Azure Portal / CLI Deployment"] AzurePortal --> VM3["New VM deployment (VM3)"] VM3 -. Parameters .-> AdminUsernameParam[Administrator Username] VM3 -. Fixed .-> OSImage["Windows Server 2019 Image"] VM3 -. Deployment Scope .-> ResourceGroup["Resource Group (Set at deployment)"] VM3 -. Deployment Scope .-> VMSize["VM Size (Optional parameter)"] style ARMTemplate fill:#0078D4,stroke:#333,color:#fff style VM3 fill:#5C2D91,stroke:#333,color:#fff style AzurePortal fill:#68217A,stroke:#333,color:#fff

Diagram Note: This flow illustrates how the ARM template defines the OS image locked inside the template, while deployment inputs like administrator username and resource group come from parameters and deployment context.

The Decision Matrix (Mandatory for Associate Level)
#

Option Est. Complexity Est. Monthly Cost Pros Cons
A) Operating System Low Fixed by image Fixed image ensures stability, consistency Cannot change OS type at deployment
B) Administrator Username Low No cost impact Supports secure per-VM identity, best practice for governance Requires managing credential secrets
C) VM Size Medium Varies by SKU (Basic to Premium) Flexible sizing optimizes cost/performance Requires template parameterization, possible errors
D) Resource Group Low No direct VM cost Organizes resources for governance, billing Set outside template, deployment must specify

Note: VM size customization requires template parameters or manual override in deployment commands; resource group is assigned during deployment scope, not within VM template itself.

Real-World Practitioner Insight
#

Exam Rule
#

“For the exam, always pick Administrator username as the configurable deployment parameter when deploying Windows Server VMs from a saved ARM template image.”

Real World
#

“Larger enterprises rely on ARM templates to enforce consistency of OS images, while allowing operators to configure usernames and passwords at deployment to satisfy security policies and audit requirements. The resource group is typically decided by governance teams based on environment.”

Weekly Azure AZ-104 Drills

Master Azure administration from identity to networking.