A change-control reviewer at Cascade Regional Airlines asks the platform team to re-run last week's ARM template deployment against the same resource group, unchanged, to confirm it is safe to include in the standard build runbook. After the re-run, the resource group contains the same resources it did before, with no duplicates and no errors. What property of the template deployment does this behavior demonstrate?
Select an answer to reveal the explanation.
Short Explanation
Idempotent is a fancy word for "do it once or do it ten times, you land in the same place." Redeploying an unchanged ARM template shouldn't create duplicate resources or errors — it should just confirm everything already matches what's declared.
Full Explanation
Idempotency means that applying the same declarative template multiple times against the same target converges on the same end state rather than accumulating duplicate resources or throwing errors on the second run. Resource providers under ARM evaluate the desired state in the template against what already exists and only apply the delta, which is what makes a repeat run a no-op when nothing has changed. Calling this a failure gets the direction backward: refusing to re-run would be the unusual and undesirable behavior for infrastructure as code. Deployment mode, Incremental versus Complete, controls whether resources absent from the template get deleted from the resource group; it is a separate setting from idempotency and does not by itself cause or prevent repeatable runs. Choosing Bicep over raw ARM JSON changes the authoring syntax, not the underlying deployment engine's idempotent behavior, since Bicep compiles down to the same ARM template format. A reasonable operational check is to review the deployment operations after a repeat run and confirm each resource reports no change rather than a fresh create.