Arm Deployments

arm-deployments

arm-deployments is the infrastructure-change-history command for AzureFox.

Use it when you need to understand how the current environment was created or modified, not just what resources exist right now.

What This Command Answers

• Which recent ARM deployments shaped this estate?
• Which deployment paths deserve review first?
• Which changes look most likely to explain the current risk or resource posture?

Run It

azurefox arm-deployments --output table

For a saved structured artifact:

azurefox arm-deployments --output json

Example Table Output

deployment	scope	state	outputs	linked refs
app-failed	rg:rg-app	Failed	0	-
sub-foundation	sub:...2222	Succeeded	2	template=example.blob.core.windows.net/...
kv-secrets	rg:rg-secrets	Succeeded	1	parameters=example.blob.core.windows.net/...

When To Use It

• when static inventory alone does not explain why the environment looks the way it does
• when you suspect recent infrastructure changes matter more than long-lived baseline resources
• when a risky resource may be maintained by a repeatable deployment path

What To Look For

• recent or repeated deployments
• broad-scope or subscription-scope deployments
• providers and resource families tied to sensitive services
• deployment history that explains where infrastructure changes are coming from

Why It Matters

Deployment systems can shape large parts of the environment very quickly.

If the interesting path is a deployment identity, a repeated change wave, or infrastructure code that can reintroduce risky state, then the deployment path matters as much as the resource itself. arm-deployments helps you connect current posture back to the change activity that created it.

What Should Stand Out First

• failed or otherwise unusual deployments
• linked templates, linked parameters, or richer outputs
• scope and outcome context that explain why a deployment matters
• repeated or broad-scope deployments that likely shaped a large part of the estate

If You See..., Go Next To...

• If you see a failed deployment with providers=['Microsoft.Web'], go next to app-services or functions because those commands show the workload posture the deployment was trying to create or change.
• If you see a deployment with providers=['Microsoft.KeyVault'] or a parameters link into a vault-related path, go next to keyvault because it shows the vault posture that deployment left behind.
• If you see repeated subscription-scope deployments, go next to inventory because it shows which service families that deployment path shaped most heavily.

What To Do Next

• Treat suspicious or repeated deployments as first-class investigation targets.
• Use deployment history to decide whether the next question is about workload posture, vault posture, or overall estate shape.
• Do not stop at the resource if the deployment path looks like the real source of risk.

Boundary

arm-deployments is a change-history triage command.

It should expose meaningful deployment history and enough context to drive follow-up. It is not a full template expansion engine or a full activity-log forensics platform.