Cloud CLI commands are fast, which also makes it easy to run one against the wrong subscription or resource group. Building a habit of checking which account scope a change will affect matters more than memorizing the command itself.
Inspect the current context first
In both Azure CLI and PowerShell, inspect the current context before identifying the subscription, resource group, and target resource. Separate similarly named environments before running a change.
Both tools have a signed-in account and a selected subscription context. Before creating or changing a resource, list the current subscription, target resource group, and region. Tags and naming conventions help distinguish similar development, review, and production environments.
az account show --query '{name:name,id:id}' -o json
az group list --query '[].name' -o tableThese commands read the selected subscription and visible resource groups. The output includes the real subscription ID, so redact identifiers before sharing a screen or pasting logs. In a PowerShell environment, Get-AzContext and Get-AzResourceGroup provide similar scope checks.
Separate read commands from change commands
Use listing and inspection commands to verify the target before creating, modifying, or deleting anything. Before a hard-to-reverse deletion, review the confirmation procedure and backup status. Do not embed subscription IDs, secrets, or personal tokens in scripts; use a secure configuration and authentication boundary.
When automating a human check, stop immediately if the selected scope is not the expected one. The following example reads the subscription without changing resources and compares it with a value supplied by the execution environment.
current_subscription="$(az account show --query id -o tsv)"
if [ -z "$EXPECTED_SUBSCRIPTION_ID" ] || [ "$current_subscription" != "$EXPECTED_SUBSCRIPTION_ID" ]; then
printf 'Unexpected subscription; stopping.\n' >&2
exit 1
fiProvide the real subscription ID through the execution environment rather than writing it in the script or article. In PowerShell, read the current context and similarly refuse to proceed when it does not match the expected value.
Make automation repeatable and handle failures
Decide whether rerunning the same script could create duplicate resources, and what state remains after a partial failure. Output from one command may become input to the next, so validate its format instead of relying only on a table designed for human reading.
Do not run a change command if the query returns an unexpected subscription or group. For automation, require exactly one intended target; stop if the result contains zero or multiple matches. That is safer than creating resources in the wrong environment.
Key takeaways
For Azure CLI and PowerShell, inspect scope before choosing a command. Query the current subscription and resource group, then separate read, change, and deletion stages. Include repeatability, failure handling, and secret separation in production automation.
