Azure CLI Practice Simulator is part of Practice Tools. Sign in or create an account, then subscribe for ₦4,000/month to unlock it.
Step-by-step exercises for Azure CLI Practice Simulator - read them here, then practice live in the tool above.
Your first hands-on pass through the Azure CLI Practice Simulator — logging in, understanding subscriptions, and managing your first resource group. No prior Azure experience required.
Confirms the simulated CLI is installed and shows which extensions are loaded, just like a real terminal.
✓ Checkpoint — a version table prints with azure-cli at the top.
In the simulator this completes instantly with a demo account — in real Azure it opens a browser window to sign in.
✓ Checkpoint — a JSON array prints listing at least one subscription with "isDefault": true.
The --output table flag reformats the same data into a human-readable table instead of raw JSON.
✓ Checkpoint — you can name your subscription's ID and state (Enabled) from the table.
Scroll the output and pick a region close to you (for example westeurope or southafricanorth) to use for the rest of this lab.
✓ Checkpoint — you've written down one region name to reuse in later commands.
A resource group is a container that holds related Azure resources — almost everything you create later must belong to one.
✓ Checkpoint — JSON prints with "provisioningState": "Succeeded".
The --query flag uses JMESPath to filter results — a core CLI skill you'll reuse constantly.
✓ Checkpoint — the filtered query returns exactly one result matching myFirstRG.
Read the error message closely — it names the missing resource and a status code, the same pattern every Azure error follows.
✓ Checkpoint — you can explain, in one sentence, what the error told you and why it happened.
Run these before trying an unfamiliar command in later labs — it's faster than searching online and always matches your installed version.
✓ Checkpoint — you can name two flags az group create accepts besides --name and --location.
--yes skips the confirmation prompt and --no-wait returns control immediately instead of blocking until deletion finishes.
✓ Lab complete — running az group list --output table a minute later no longer shows myFirstRG.
| Command hangs with no output | Some commands block until the operation finishes. Add --no-wait or wait — the simulator will time out safely after a minute. |
| "Please run az login" keeps appearing | Your simulated session expired. Re-run az login to refresh it. |
| Output is unreadable raw JSON | Append --output table to almost any command for a cleaner view. |
--query returns nothing | Check quoting — JMESPath expressions need to be wrapped in quotes matching your shell. |
You've logged in, created and inspected a resource group, filtered results with --query, and deleted the resource group cleanly.
Provision a virtual machine, a storage account, and basic networking, then chain commands together with variables and JMESPath queries the way you would in a real deployment script.
✓ Checkpoint — "provisioningState": "Succeeded" in the JSON response.
✓ Checkpoint — the response includes a subnets array with labSubnet listed.
Storage account names must be globally unique — appending $RANDOM avoids a naming collision in the shared simulator environment.
✓ Checkpoint — JSON shows "statusOfPrimary": "available".
This is the slowest command in the lab — the simulator mimics real Azure provisioning time.
✓ Checkpoint — the response includes a publicIpAddress field with a non-empty value.
--output tsv strips quotes and formatting, making a value safe to store directly in a shell variable.
✓ Checkpoint — echo $IP prints a plain IP address with no surrounding quotes.
Opening a port creates a network security group rule — in production, always scope this to a specific source IP range, not *.
✓ Checkpoint — the returned NSG rule shows "access": "Allow" and "destinationPortRange": "22".
✓ Checkpoint — the table lists at least the VM, vnet, storage account, and NSG.
Tags don't change how a resource behaves — they exist purely to organize and filter resources later, especially for billing reports.
✓ Checkpoint — az vm show now includes both tags under a "tags" object.
Deleting the resource group removes the VM, vnet, storage account, and NSG together — the same "blast radius" logic real teams rely on for cleanup.
✓ Lab complete — az group list no longer shows labInfraRG once deletion finishes.
| VM creation fails with a name conflict | Another session may already use that VM or storage name. Add a random suffix and retry. |
$IP is empty | The VM may still be provisioning. Re-run az vm show after a short wait. |
| Port-open command errors on priority | NSG rule priorities must be unique per network security group; try a different number like 1002. |
| Tags don't appear | Confirm you used tags.key=value pairs, not a single tags="..." string. |
A VM is deployed inside your custom vnet, SSH is reachable via an opened port, resources are tagged, and the resource group deletes cleanly in one command.
Deploy infrastructure from a Bicep template, manage access with RBAC, automate a recurring task, and query monitoring data — the workflow real cloud teams run day to day.
✓ Checkpoint — "provisioningState": "Succeeded" in the response.
The simulator preloads main.bicep, which declares a storage account and an App Service plan. Read it before deploying — declarative infrastructure should always be reviewed like code, because it is code.
✓ Checkpoint — you can name the two resource types the template will create.
validate checks the template and parameters without creating anything — always run it before a real deployment.
✓ Checkpoint — the command returns no errors and reports the template is valid.
✓ Checkpoint — "provisioningState": "Succeeded", and both resources from the template now exist in the group.
Scoping the role to a single resource group, not the whole subscription, is the least-privilege pattern used in real CI/CD pipelines.
✓ Checkpoint — the output includes appId, password, and tenant — save these securely, they print only once.
✓ Checkpoint — a row shows role Contributor scoped to labIacRG only.
Auto-shutdown schedules are a simple, common cost-control automation — this same pattern extends to Logic Apps and Automation Runbooks for more complex jobs.
✓ Checkpoint — the response confirms a shutdown schedule at 19:00.
✓ Checkpoint — a time series of data points prints, even if usage is currently near zero.
Exporting existing resources into a template is how teams bring manually created infrastructure under version control after the fact.
✓ Checkpoint — exported-template.json exists and contains a "resources" array.
Always revoke service principal credentials before deleting the resources they were scoped to — cleaning up in the wrong order can leave orphaned credentials.
✓ Lab complete — the service principal no longer appears in az ad sp list, and the resource group is gone.
| Bicep validate fails on parameters | Check main.bicep for required parameters and pass them with --parameters key=value. |
create-for-rbac permission denied | Your simulated account needs Owner or User Access Administrator rights at the target scope — narrow the --scopes value and retry. |
| Auto-shutdown time rejected | Use 24-hour HHMM format with no colon, e.g. 1900 not 19:00. |
| Metrics query returns empty | New resources can take a few minutes before metrics populate — retry shortly after creation. |
Infrastructure deployed from Bicep, a scoped service principal created and later revoked, an automated shutdown scheduled, and the live environment exported back to a template.