Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4
5Step 5
AZ-400 Practice Question: Design and implement build and release pipelines
Drag and drop the steps to implement infrastructure as code with Azure Resource Manager (ARM) templates into the correct order.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Define the ARM template, then parameterize, then store in version control, then validate using what-if, then deploy.
The correct order for implementing infrastructure as code with ARM templates is: first define the ARM template, then parameterize it to make it reusable, then store it in version control (e.g., Git) to track changes, then validate the deployment using the what-if operation to preview changes, and finally deploy the template to Azure.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Define the ARM template, then parameterize, then store in version control, then validate using what-if, then deploy.
Why this is correct
The correct workflow starts by authoring the ARM template declaratively, capturing the target Azure resources and their dependencies. Next, parameterize the template to make it reusable across dev, test, and production environments without duplicating code. Committing the template to version control before validation ensures every change is traceable and any deployment can be rolled back to a known good revision. Running `what-if` validation provides a dry-run preview of create/update/delete operations, catching unintended changes before they are applied to real subscriptions, and only then should the validated template be deployed.
- ✗
Define the ARM template, then parameterize, then deploy, then validate, then store in version control.
Why it's wrong here
This sequence is unsafe because it skips both version control and `what-if` validation before deployment, meaning changes go straight to Azure without an auditable record or a dry-run impact check. Deploying first risks modifying production resources based on an unvalidated template, and any errors or observed effects only surface after the fact. Storing in version control after deployment provides no rollback guarantee, since the exact deployed state is never captured as a known-good commit. Validation after deployment is also far more expensive to remediate than the `what-if` check that should have caught issues earlier.
- ✗
Parameterize, then define the ARM template, then validate, then deploy, then store in version control.
Why it's wrong here
Parameterization cannot logically precede template definition because parameters are declared inside the template's `parameters` section and depend entirely on the resource structure you define first; attempting to parameterize before defining the template is impossible. Validating before the template is fully written also means `what-if` runs against an incomplete artifact, so any preview is meaningless. Deploying to Azure before storing the template in version control strips away the ability to link the deployed infrastructure to a specific commit, breaking change tracking and rollback. The correct order must build the template and its parameters before any validation or deployment activity.
- ✗
Define the ARM template, then validate, then parameterize, then deploy, then store in version control.
Why it's wrong here
This order is invalid because `what-if` validation occurs before the template has been parameterized, meaning the validation pass only tests a template with placeholder or missing parameter definitions and cannot accurately model how parameterized values affect the deployment. Additionally, deploying before storing the template in version control prevents you from correlating the released resources with a known revision, which is essential for auditing and rollback. Parameterization should always be done during template authoring, far before validation, so that `what-if` reflects the exact configurations that will be deployed. Once version-controlled and validated, the deployment step is the final, safe action.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Git
Git is a version control system that tracks changes to files so multiple people can work on the same project without overwriting each other's work.
Key term
IaC
Infrastructure as Code (IaC) manages and provisions IT infrastructure through machine-readable definition files, rather than manual hardware configuration.
About these practice questions
Courseiva writes every AZ-400 question from scratch — 823 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.