Free guides, interview Q&As, and job responsibility breakdowns — curated by industry veterans to help you crack MNC interviews
• Azure Resource Manager (ARM) is Azure's management layer for deploying, organizing, and controlling resources.
• An ARM template is a declarative JSON document that describes the Azure resources and configuration that should exist.
• ARM templates support Infrastructure as Code (IaC), allowing infrastructure to be defined in files rather than configured only through the portal.
• Declarative deployment describes the desired end state; Azure Resource Manager determines how to create or update the required resources.
• ARM templates can deploy multiple resources as one repeatable deployment instead of creating each resource manually.
• The main sections of a classic ARM template include $schema, contentVersion, parameters, variables, resources, and outputs.
• Parameters make a template reusable by allowing values such as location, VM size, names, and administrator inputs to be supplied at deployment time.
• Variables store reusable values or expressions so the template is easier to maintain and less repetitive.
• The resources section is the core of the template because it defines the Azure resources and their configuration.
• Outputs return useful values after deployment, such as a resource ID, hostname, storage endpoint, or other deployment result.
• API version is specified for resource types so ARM knows which resource-provider schema and behavior the template targets.
• Resource dependencies can be represented with dependsOn when one resource must be created or configured after another.
• ARM template expressions use functions such as parameters(), variables(), resourceId(), concat(), format(), and uniqueString() to build dynamic values.
• Copy loops allow multiple similar resources to be created from one template definition instead of repeating the same resource block.
• Nested or child resources can represent resources that logically belong to a parent resource, such as sub-resources of a storage account or virtual network.
• Template deployments can be performed through the Azure portal, Azure CLI, Azure PowerShell, REST APIs, and automation pipelines.
• The what-if operation previews the resource changes that a deployment is expected to make before the deployment is executed.
• Template validation checks whether the deployment request is syntactically and structurally valid, but successful validation does not guarantee that every runtime condition will succeed.
• Incremental deployment updates or creates resources defined by the template without deleting unrelated resources that are not in the template.
• ARM template deployments can be scoped to a resource group, subscription, management group, or tenant depending on the type of deployment being performed.
• Deployment parameters can be supplied directly, from parameter files, or through automation tools, making the same infrastructure definition reusable across environments.
• Bicep is an Azure-native Infrastructure as Code language that provides a simpler authoring experience and compiles to ARM template JSON.
• Automation can combine ARM/Bicep with Azure CLI or PowerShell scripts and CI/CD pipelines to make infrastructure provisioning repeatable.
• Idempotent infrastructure design aims for repeated deployments to converge on the intended configuration rather than creating uncontrolled duplicates.
• ARM templates improve standardization, repeatability, auditability, and deployment consistency across development, testing, and production environments.
Figure 2: Core sections commonly used in an ARM template
Azure Resource Manager (ARM)
Definition: The Azure management layer that provides a consistent way to deploy, update, organize, and manage Azure resources.
Day-to-Day Example: Like a building-management office that coordinates construction, changes, ownership, and records for every building in a complex.
ARM Template
Definition: A declarative JSON file that defines the resources and configuration Azure should deploy.
Day-to-Day Example: Like a construction blueprint that lists what rooms, doors, wiring, and equipment a building should contain.
Infrastructure as Code (IaC)
Definition: The practice of defining infrastructure in machine-readable files so it can be versioned and deployed consistently.
Day-to-Day Example: Like keeping an exact digital recipe for setting up an office instead of relying on someone's memory.
Declarative Deployment
Definition: A deployment approach in which the desired end state is described rather than every individual command required to reach it.
Day-to-Day Example: Like telling a contractor, 'the finished office must contain these rooms and systems,' rather than describing every hammer movement.
Parameter
Definition: An input value supplied to a template at deployment time to make the template reusable.
Day-to-Day Example: Like a form field where you enter the project name, region, or VM size before submitting an order.
Parameter File
Definition: A separate file containing values for template parameters, commonly used to keep environment-specific values outside the main template.
Day-to-Day Example: Like keeping separate order forms for Development and Production while using the same master design.
Variable
Definition: A reusable value or expression defined inside a template.
Day-to-Day Example: Like giving a frequently used address or calculation a short name so it does not have to be rewritten.
Resource
Definition: An Azure service instance managed by ARM, such as a virtual machine, storage account, or virtual network.
Day-to-Day Example: Like an actual physical item installed in an office rather than the instruction sheet describing it.
Resource Type
Definition: The provider/type identifier that tells ARM what kind of Azure resource is being deployed.
Day-to-Day Example: Like specifying that an item in a purchase list is a laptop, printer, or network switch.
API Version
Definition: The resource-provider API version targeted by a resource declaration in the template.
Day-to-Day Example: Like specifying which edition of a technical specification the construction team must follow.
dependsOn
Definition: An ARM template property used to explicitly define a dependency between resources or deployments.
Day-to-Day Example: Like requiring the foundation to be completed before the building walls can be installed.
Expression
Definition: A template expression that calculates or retrieves a value during deployment.
Day-to-Day Example: Like a spreadsheet formula that produces a value from other cells.
Function
Definition: A built-in ARM template operation used inside expressions to manipulate strings, IDs, arrays, numbers, or deployment information.
Day-to-Day Example: Like a standard calculator function that performs a repeatable operation.
Copy Loop
Definition: A template mechanism used to create multiple similar resources or properties from one definition.
Day-to-Day Example: Like printing 50 identical employee badges from one badge design.
Output
Definition: A value returned by a deployment after the resources have been processed.
Day-to-Day Example: Like a receipt that gives you the final order number after an order is completed.
What-If
Definition: A deployment analysis operation that shows the expected create, modify, delete, or no-change results before applying the deployment.
Day-to-Day Example: Like a preview of changes before you click 'Apply.'
Deployment
Definition: An ARM operation that submits an infrastructure definition and parameters to Azure Resource Manager.
Day-to-Day Example: Like submitting a construction plan to the building authority for execution.
Incremental Deployment
Definition: A deployment mode in which resources in the template are created or updated while unrelated existing resources are not removed merely because they are absent from the template.
Day-to-Day Example: Like updating a room according to a new plan without automatically demolishing every other room not shown on the plan.
Bicep
Definition: An Azure-native declarative IaC language that is compiled into ARM template JSON for deployment through ARM.
Day-to-Day Example: Like writing a shorter, cleaner source document that is converted into the formal blueprint format.
Azure Automation
Definition: An Azure service used for process automation and runbook-based operational tasks; it is different from ARM templates, which primarily define infrastructure deployments.
Day-to-Day Example: Like an operations assistant that performs recurring procedures rather than a blueprint that defines the building itself.
Figure 3: Recommended validation and what-if workflow before deployment
ARM Template vs. Bicep
Feature ARM Template Bicep Syntax JSON Dedicated declarative language Authoring More verbose More concise and readable Deployment Native ARM deployment Compiles to ARM template JSON and deploys through ARM Typical use Existing JSON templates, generated/standardized artifacts New Azure IaC authoring where concise syntax is preferred
Parameters vs. Variables
Feature Parameters Variables Value source Usually supplied by the deployment Defined inside the template Purpose Customize a deployment Reuse or calculate values Example Environment, VM size, location Common name prefix or computed resource ID
Template vs. Parameter File
Feature Template Parameter File Contains Infrastructure definition Environment-specific parameter values Reusability Same template can serve many environments Different files can provide different environment values Typical example main.json dev.parameters.json / prod.parameters.json
What-If vs. Validation
Feature What-If Validation Main purpose Preview expected resource changes Check whether deployment is valid before execution Shows changes? Yes, expected create/modify/delete/no-change results Not primarily a change-preview report Deployment applied? No No
dependsOn vs. Resource Reference
Feature dependsOn Resource reference/expression Purpose Explicitly declares ordering dependency Retrieves or references a resource/value Main concern Deployment sequencing Resource identification or value access Use Force a resource to wait for another Use resourceId(), reference(), or other expressions when appropriate
Incremental vs. Complete-Style Deployment Concepts
Feature Incremental Complete-style behavior Core behavior Create/update resources in template; unrelated resources remain Historically used to reconcile resources at a scope more aggressively Risk Lower risk of unrelated deletion Potentially destructive if scope and template are not carefully controlled Operational focus Add/update infrastructure consistently Reconciliation of a broader defined set; use current Azure guidance carefully
ARM Deployment vs. Azure Automation
Feature ARM Deployment Azure Automation Primary purpose Deploy/configure Azure infrastructure Automate operational processes and runbooks Typical artifact ARM JSON/Bicep deployment Runbook, schedule, automation job Example Deploy a VM and VNet Start/stop VMs on a schedule
Copy Loop vs. Repeated Resource Blocks
Feature Copy Loop Repeated Blocks Definition One resource definition generates multiple instances Each resource is written separately Maintainability Higher for large repeated sets More verbose Use case Many similar resources Small number of intentionally different resources
Deployment Scope: Resource Group vs. Subscription
Feature Resource Group Scope Subscription Scope Target Resources inside a resource group Subscription-level resources or governance-related deployments Typical example Deploy VM, VNet, storage account Deploy role assignments, policies, resource groups Blast radius More limited Broader
Declarative IaC vs. Imperative Scripting
Feature Declarative IaC Imperative Scripting Focus Describe desired state Specify actions/steps Example ARM/Bicep template PowerShell script issuing commands Strength Repeatable infrastructure definition Flexible procedural operations and custom logic
Figure 4: Common ARM template deployment and automation entry points
Q1. What is Azure Resource Manager (ARM)?
Answer: Azure Resource Manager is Azure's management layer for deploying and managing resources consistently. It provides a common control plane for resource deployment, organization, access, and management operations.
Q2. What is an ARM template?
Answer: An ARM template is a declarative JSON file that describes Azure resources and their configuration. It enables repeatable Infrastructure as Code deployments.
Q3. What is Infrastructure as Code (IaC), and how do ARM templates support it?
Answer: IaC means defining infrastructure in machine-readable code or configuration files. ARM templates support IaC by storing the desired Azure infrastructure definition in a reusable, version-controlled file.
Q4. What are the major sections of an ARM template?
Answer: Common sections include $schema, contentVersion, parameters, variables, resources, and outputs. Each section has a distinct purpose in defining, customizing, and reporting the deployment.
Q5. Why are parameters important in ARM templates?
Answer: Parameters allow the same template to be reused with different deployment values, such as location, environment name, VM size, or administrator input, without changing the core infrastructure definition.
Q6. What is the difference between a parameter and a variable?
Answer: A parameter is normally an input supplied to the deployment, while a variable is defined within the template to store a reusable or calculated value.
Q7. What is the purpose of the resources section?
Answer: The resources section defines the Azure resources that ARM should create or update, including their resource type, API version, name, location, properties, and relationships.
Q8. What is dependsOn used for?
Answer: dependsOn explicitly tells ARM that a resource or deployment depends on another resource or operation. This controls deployment ordering when an implicit dependency is not sufficient.
Q9. What are ARM template expressions and functions?
Answer: Expressions are evaluated during deployment and can use built-in functions to construct names, IDs, strings, numbers, arrays, and other values dynamically.
Q10. What is the purpose of the what-if operation?
Answer: What-if previews the expected changes from a deployment before the changes are applied. It helps administrators review potentially disruptive changes and detect unexpected modifications.
Q11. What is an incremental deployment?
Answer: Incremental deployment creates or updates resources defined in the template while not deleting unrelated resources simply because they are absent from the template.
Q12. What are outputs in an ARM template?
Answer: Outputs are values returned after deployment. They can expose useful information such as resource IDs, hostnames, or endpoints for use by people or automation.
Q13. What is a parameter file?
Answer: A parameter file stores values for template parameters separately from the infrastructure definition. This is useful when the same template is deployed to multiple environments with different settings.
Q14. What is Bicep and how is it related to ARM templates?
Answer: Bicep is an Azure-native declarative Infrastructure as Code language designed to make Azure resource definitions easier to author. Bicep is compiled to ARM template JSON for deployment.
Q15. How can ARM templates be used in automation?
Answer: Templates can be deployed through Azure CLI, Azure PowerShell, the Azure portal, REST APIs, or CI/CD pipelines. This enables repeatable infrastructure provisioning with minimal manual configuration.
Q1. An organization needs to create the same VNet, NSG, storage account, and VM structure in Development, Testing, and Production. What approach should be used?
Answer: Create a reusable ARM template and supply environment-specific parameters or parameter files for each environment. This keeps the infrastructure definition consistent while allowing controlled differences.
Q2. An administrator is about to deploy a template that modifies an existing production environment and wants to see the expected changes first. What should be used?
Answer: Use the ARM what-if operation before deployment. Review the proposed create, modify, delete, and no-change results before deciding to apply the deployment.
Q3. A template contains a VM and a network interface, but the deployment order must ensure the required dependency is handled correctly. What ARM feature can explicitly control ordering?
Answer: Use dependsOn when an explicit deployment dependency is required. Where possible, ARM can also infer dependencies from resource references.
Q4. A company wants the same infrastructure template to deploy in different Azure regions without editing the template every time. What should be used?
Answer: Use a location parameter and supply the appropriate region during each deployment. This separates reusable infrastructure logic from environment-specific input.
Q5. A team has one ARM template and needs different VM sizes and names for Development and Production. How can this be handled cleanly?
Answer: Keep the template unchanged and use parameters or separate parameter files for the environment-specific values, such as VM size, naming prefix, and other settings.
Q6. An administrator manually created 30 similar storage resources and wants a more maintainable template-based approach. What ARM feature can reduce repeated resource definitions?
Answer: Use a copy loop to generate multiple instances from one resource definition when the resources follow a repeatable pattern.
Q7. A team wants infrastructure changes to happen automatically whenever approved code is merged into the main branch. What approach fits?
Answer: Place the ARM template or Bicep source in version control and connect it to a CI/CD pipeline that performs validation, optional what-if review, and deployment after the required approval gates.
Q8. A company is considering Azure Automation for infrastructure provisioning and assumes it is the same thing as an ARM template. What is the distinction?
Answer: ARM templates define and deploy Azure infrastructure declaratively. Azure Automation is a separate service focused on operational automation such as runbooks, scheduled jobs, and recurring administrative processes; the two can be used together.
