Arm Deployments

arm-deployments

arm-deployments is the infrastructure-change-history command for HarrierOps Azure.

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

ho-azure arm-deployments --output table

For a saved structured artifact:

ho-azure 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.

Loot Behavior

Loot currently keeps the top-ranked rows for this command. That ordering is useful, but it is not yet a shipped semantic high / medium / low analyst contract unless the command explicitly labels rows with a defended priority contract.

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.