Azure PowerShell never really went away, but the way it’s used has changed a lot.
If you still think of it as a provisioning tool, or something that lives in old Automation Accounts, you’re probably missing where it actually fits in modern Azure environments.
This isn’t about scripts for creating resources. It’s about operating and governing Azure safely once infrastructure already exists.
PowerShell Isn’t Competing With IaC
Terraform and Bicep are very good at declaring infrastructure.
PowerShell is very good at reasoning about what already exists.
That distinction matters.
In real-world platforms, PowerShell is usually used after deployment:
- validating configurations
- checking compliance
- coordinating changes across subscriptions
- enforcing standards that can’t be expressed cleanly as declarations
Trying to replace Terraform with PowerShell creates fragile automation.
Trying to replace PowerShell with Terraform creates blind spots.
Mature teams use both, intentionally.
Where Azure PowerShell Still Shines
PowerShell tends to show up in places where context matters.
It’s commonly used for:
- subscription and tenant-level visibility
- identity-aware automation using managed identities
- guardrails that detect drift rather than constantly rewriting state
- controlled operational changes where “just apply” would be risky
These problems are procedural by nature. PowerShell handles them well.
Why Old PowerShell Got a Bad Reputation
Most complaints about Azure PowerShell come from outdated patterns:
- long, stateful scripts
- manual authentication
- hard-coded assumptions
- automation that can’t be safely re-run
Those approaches don’t survive modern governance or security expectations.
Today, PowerShell automation is usually:
- stateless
- identity-first
- read-heavy and conservative about changes
- designed to fail safely
When used that way, it scales surprisingly well.
PowerShell vs Azure CLI: The Real Difference
Most comparisons focus on syntax or preference, but that’s not what matters in practice.
Azure CLI is optimised for direct execution. It works best when the task is clear, linear, and short-lived. That makes it a good fit for ad-hoc operations and simple automation.
PowerShell is better at reasoning about state. Its object-based approach makes it easier to inspect resources, apply conditions, and handle edge cases as automation grows more complex.
This difference becomes obvious over time. CLI scripts tend to stay small. PowerShell scripts tend to evolve into tools that are maintained by teams, not individuals.
That’s why many mature Azure environments use both: CLI for speed, PowerShell for automation that needs to last.