Before we meet the tools, we need to see the problem they solve and the family of ways Azure can be controlled.

What is Azure, and what does “managing” it mean?

Microsoft Azure is a cloud platform, which means Microsoft owns huge data centers around the world and rents out pieces of them: virtual computers, storage space, databases, networks, and hundreds of other services. Launched publicly in 2010, it is today one of the big three cloud providers alongside Amazon Web Services and Google Cloud.

Renting is only the first step. Someone must then manage what they rented: create a server, resize it, give it a network address, back it up, switch it off at night, and delete it when the project ends. Every one of those actions is a request that you send to Azure.

Four ways to send a request

Azure accepts your requests in several ways. They all end up in the same place, but they feel very different to use.

• The Azure portal. A website with menus, buttons, and forms. It is friendly and visual, great for exploring and learning.
• The command line. You type short text instructions and press Enter. The Azure CLI is the best-known tool of this kind.
• Code libraries. Developers can call Azure from inside a program written in Python, Java, JavaScript, or other languages.
• Template files. You describe the whole setup you want in a file, and Azure builds it for you. Bicep, Microsoft’s template language, and Terraform are common examples.

Where the CLI and Cloud Shell fit

The Azure CLI took shape as a modern, cross-platform tool around 2017, replacing an older one that was built on a different technology. Cloud Shell arrived about the same time, first with a Bash terminal and later with PowerShell, so that you could use the command line even from a computer where nothing was installed. Together they became the everyday toolkit for people who run Azure.

Every command you will ever type refers to a few core Azure ideas. Learn them once, and everything else becomes easier to read.

The building blocks

The front door: Azure Resource Manager

Whichever way you send a request, it reaches a service called Azure Resource Manager, usually shortened to ARM. ARM is the front desk of Azure. It checks who you are, checks whether your role allows the action, and then passes the job to the right service behind the scenes, such as the one that creates virtual machines.

This is very good news for learners. Because the portal, the CLI, Cloud Shell, and the code libraries all talk to the same front desk, they behave consistently. Something you create with the CLI shows up in the portal a moment later, and something you change in the portal can be seen from the CLI.

The Azure CLI is a single program that understands hundreds of Azure instructions, and it works the same way on Windows, macOS, and Linux.

What it is

CLI stands for command-line interface. It is a way of talking to a computer by typing short lines of text rather than clicking. The Azure CLI is Microsoft’s official command-line tool for Azure. You start every instruction with the two letters az, then say what you want. It is open source, which means anyone can read its code and suggest improvements, and Microsoft publishes regular new versions.

It exists for three reasons. First, speed: an expert can do in one line what takes ten clicks. Second, repeatability: a typed instruction can be saved in a file and run again exactly the same way tomorrow. Third, automation: programs and pipelines cannot click buttons, but they can run commands.

How a command is shaped

Azure CLI instructions follow a simple sentence pattern: a program name, a group that names the kind of thing, an action that says what to do with it, and some options that give the details. In plain words, it reads like “azure, virtual machine, create, with this name and this size.”

• Group: the topic, such as group for resource groups, vm for virtual machines, storage for storage, or network for networks.
• Action: usually a simple verb: create, list, show, update, or delete. Once you learn these five verbs, you can guess most commands.
• Options: labeled details that start with two dashes, such as a name, a location, or a size.

Where you can get it

Getting help inside the tool

The CLI explains itself. Add a help option to any group or action, and it lists what is available with a short description of each option. There is also a find feature that suggests commands based on a plain-language question, and an interactive mode that shows hints and auto-completion as you type. For a learner, this built-in help is like having a manual that is always open at the right page.

A few small habits make the CLI feel comfortable. Here are the ones people use every day.

Signing in and choosing a subscription

Before the CLI can do anything, it needs to know who you are. The sign-in command opens a web page in your browser where you log in with your Microsoft account, usually including a second proof such as a phone approval. Once you finish, the CLI keeps a temporary pass so you do not have to log in for every command.

If your account can see several subscriptions, you pick the active one with the account commands. Doing this first is very important, because every create or delete command acts on the active subscription. Always check which one is selected before you change anything.

Output formats: choosing how answers look

By default the CLI prints answers as JSON, a structured text format that programs read easily but people find noisy. You can ask for friendlier shapes with the output option.

Filtering answers with a query

A single Azure resource can have dozens of properties, and most of the time you only want one or two. The --query option lets you pick exactly the pieces you need, using a small language called JMESPath. It works like a filter on a coffee machine: lots of water goes in, but only the part you want comes out. Combined with the table or tsv formats, it turns a wall of text into a tidy answer.

Saving defaults to type less

If you always work in the same resource group or region, you can store that as a default in the CLI’s configuration. After that you can leave the option out and the tool fills it in for you. Defaults live in a hidden folder named .azure in your home directory, together with your sign-in information and settings.

Extensions and long jobs

• Extensions are add-on packs that teach the CLI new tricks, often for services that are new or specialized. You install one when you need it and remove it when you do not.
• Long-running operations such as creating a large database can take several minutes. By default the CLI waits and shows nothing until done. A no-wait option returns control immediately, and a wait command lets you check back later.
• Exit codes are small numbers a command leaves behind to say whether it worked. Zero means success, and any other number means something went wrong. Scripts use them to decide what to do next.

Cloud Shell gives you a working command line in a few seconds, from any device with a web browser.

What it is

Azure Cloud Shell is a browser-based terminal that Microsoft hosts for you. You open it from the Azure portal by clicking the terminal icon, from its own web address, or from the Azure mobile app. In a few seconds, a command prompt appears. The Azure CLI is installed, a recent version is guaranteed, and you are already signed in with the same account you used for the portal.

It exists because setting up tools takes time and breaks easily. Think of the hassle: install the tool, install the right version, fix a broken update, sign in, repeat on a second computer. Cloud Shell removes all of that. It is especially handy on a borrowed computer, a tablet, a locked-down work laptop where you may not install software, or in an emergency at midnight.

Two flavors: Bash and PowerShell

When you first open Cloud Shell, you choose a style. Bash is the classic shell of Linux and Mac systems, loved for short commands and easy scripting. PowerShell comes from the Windows world and works with structured objects rather than plain text. Both can run the Azure CLI. PowerShell also has its own Azure command set, called Azure PowerShell. You can switch between the two at any time.

What is already installed

One thing to know: Cloud Shell does not run a Docker engine, so you cannot build container images in the usual way inside it. For that, use a local machine or a build service.

Storage: your locker

The machine in Cloud Shell is temporary, but your files do not have to be. On first use, Cloud Shell offers to create a small storage account and a file share in Azure Files. A folder is saved there and mounted as your home folder every time, and a disk image of about five gigabytes keeps your files and settings. Your scripts, notes, and downloaded tools remain between sessions. A newer option lets you choose an ephemeral session with no storage at all, which is cleaner and cheaper but forgets everything when the session ends.

Sessions and limits

• Idle timeout: at the time of writing, a session closes after about twenty minutes without typing. Your saved files remain; the running programs do not.
• Not for very long jobs: a job that must run for hours belongs in a pipeline or on a server, not in a browser tab.
• Handy extras: you can upload and download files through the toolbar, and a built-in editor lets you open and change a script without leaving the page.
• Private networking: organizations with strict rules can place Cloud Shell inside their own virtual network so it can reach private resources.

Azure has several ways to do the same job. Knowing how they compare helps you pick the right one without second-guessing.

The tools compared

Azure CLI versus Azure PowerShell

These two are often confused. Both are official, both can do almost everything in Azure, and both work in Cloud Shell. The main difference is style. The CLI uses short commands that print text, which feels natural to people from Linux or web backgrounds. Azure PowerShell uses longer, verb-and-noun commands called cmdlets that pass around structured objects, which feels natural to Windows administrators. Neither is better. Choose the one your team already knows, and stay consistent.

How they connect

flowchart LR
    You["You"] --> Portal["Azure Portal website"]
    You --> Local["Azure CLI on your computer"]
    You --> Shell["Cloud Shell in the browser"]
    Pipe["Automation pipeline"] --> Local
    Local --> ARM["Azure Resource Manager"]
    Shell --> ARM
    Portal --> ARM
    ARM --> Auth["Sign-in and permission checks"]
    Auth --> Svc["Azure services: compute, storage, network, databases"]
    Svc --> Res["Your resources in data centers"]

Read the diagram from the left. You can enter through the portal, a local CLI, or Cloud Shell, and an automation pipeline can use the CLI as well. All of those paths join at Azure Resource Manager. There the request is checked, and only then handed to the specific service that performs the work. This is why a mistake made from any tool has the same effect, and why a good permission setup protects you no matter which tool you use.

Now let us open both tools and see what parts are inside and how they connect.

Inside the Azure CLI

The Azure CLI is written mostly in the Python language, and the installer carries its own copy of Python so you do not need to install one yourself. The program is built from layers, each with a clear job.

flowchart TB
    Cmd["Your command"] --> Launcher["az launcher"]
    Launcher --> Core["CLI core: parser, settings, help, output"]
    Core --> Mods["Command modules: vm, storage, network, and more"]
    Core --> Ext["Optional extensions"]
    Mods --> SDK["Azure SDK for Python"]
    Ext --> SDK
    Core --> Auth["Sign-in library and token cache"]
    SDK --> Auth
    SDK --> HTTPS["HTTPS requests"]
    HTTPS --> ARM["Azure Resource Manager"]

Here is the story in words. Your command first meets the launcher, the small program that starts everything. The core reads your words, works out which command you meant, applies your saved settings, and decides how to print the answer. The core then hands the real work to a command module, a block of code that knows one area of Azure, such as virtual machines. If you installed an extension, it plugs in the same way. Modules use the Azure SDK, which is a library that knows how to build correct requests, and a sign-in library that supplies proof of your identity. The result is a secure web request that goes to Azure Resource Manager.

Inside Cloud Shell

Cloud Shell is a managed service. When you open it, Azure prepares a small Linux container, which is a lightweight, isolated computer environment, just for you. Your browser connects to it through a live two-way channel so what you type appears instantly and the output streams back.

flowchart LR
    Browser["Your browser"] --> Portal["Portal or shell.azure.com"]
    Portal --> Svc["Cloud Shell service"]
    Svc --> Box["Temporary Linux container"]
    Box --> Tools["Preinstalled tools: Azure CLI, PowerShell, Terraform, kubectl, git"]
    Box --> Tok["Token service using your identity"]
    Box --> Home["Home folder"]
    Home --> Files["Azure Files share in your storage account"]
    Tok --> ARM["Azure Resource Manager"]
    Tools --> ARM

Follow the arrows. Your browser talks to the portal or the Cloud Shell web address. The Cloud Shell service finds or creates a container for you. Inside that container are the preinstalled tools. A small token service inside the container hands out proof of your identity, so the tools never ask you to sign in again. Your home folder is not stored in the container itself; it is connected to a file share in a storage account in your own subscription. That is why your scripts survive when the container is thrown away.

A single typed line sets off a surprising chain of events. Let us walk along it.

The journey of one command

Tokens in plain words

A token is like a wristband at a festival. You show your ticket once at the gate, and you get a wristband that lets you walk in and out for the day without showing the ticket again. Access tokens in Azure last roughly an hour and then expire, which limits the damage if one is ever stolen. The refresh token is a longer-lasting way to get a new wristband without logging in again. Both are kept in your local profile folder, so protecting that folder matters.

What Resource Manager does

Azure Resource Manager is a busy front desk. For each request it authenticates the caller, authorizes the action using role-based access control, validates the input, records the action in a log, and routes the job to a resource provider. A resource provider is the service that owns one family of resources. For example, one handles compute, another storage, another networks. Before you can use a family in a new subscription, it must be registered, which is a one-time switch. If you see an error that a provider is not registered, that is the reason, and the fix is to register it.

Rate limits and retries

Azure protects itself from overload by limiting how many requests one account can send in a period. If a script sends too many too fast, Azure answers with a “slow down” signal, known as throttling. The CLI automatically retries after a short pause in many cases, but a badly written loop can still hit the wall. Good scripts group their work and avoid asking the same question hundreds of times.

What happens inside Cloud Shell

When you press the Cloud Shell button, the service picks a data center near you, finds a free container, mounts your file share as the home folder, and arranges for the tools in the container to receive tokens for your identity. When you close the window or stay idle too long, the container is discarded. The next time you open it, you may land in a different container on a different machine, but with the same home folder. Because containers are replaced often, anything you install outside your home folder is gone next time.

Let us follow two stories: how data flows when you sign in and run a command, and how a Cloud Shell session lives and dies.

Sign-in and first command

sequenceDiagram
    participant U as You
    participant C as Azure CLI
    participant B as Browser
    participant E as Microsoft Entra ID
    participant M as Resource Manager
    U->>C: Run the sign-in command
    C->>B: Open the login page
    B->>E: You enter your account and second proof
    E-->>C: Access token and refresh token
    C->>C: Save tokens in local cache
    U->>C: Run a list command
    C->>M: HTTPS request with access token
    M->>E: Verify the token
    E-->>M: Token is valid
    M->>M: Check your role permissions
    M-->>C: Results as data
    C-->>U: Formatted output

The most important detail here is who sees your password. The CLI opens a Microsoft sign-in page in your browser, and you type your credentials into that page. Microsoft Entra ID, the identity service, checks them and hands the CLI two tokens. The CLI never sees your password. After that, every command carries the access token, and Resource Manager double-checks it with Entra ID before touching anything.

The life of a Cloud Shell session

The life of a resource you create

Resources also have a life story. You create one with the CLI. Azure records the intended state, builds it step by step, and reports “succeeded” when done. You can then show it, update it, move it, tag it with labels, or lock it against deletion. Later you delete it, and Azure tears it down and stops the billing. Two practical points: some deleted items, such as certain secrets and databases, enter a soft-delete holding period before they vanish for good, and leftover disks or addresses from a deleted server may keep costing money until you remove them too.

Where your own data sits

On your local computer the CLI keeps a hidden folder in your home directory. It holds your tokens, your list of subscriptions, your saved defaults, and optional log files. In Cloud Shell the same folder exists inside the temporary container and is rebuilt as needed. Treat this folder as sensitive, because anyone who can read your tokens can act as you until they expire.

There is more than one way to prove who you are to Azure. The right choice depends on whether a person or a program is asking.

Ways to sign in

Who may do what: roles and scope

Signing in answers “who are you?” A different system answers “what may you do?” This is role-based access control, shortened to RBAC. You are given a role at a certain scope, and the permission applies to that scope and everything beneath it.

• Scope is the level where the role applies: a management group, a subscription, a resource group, or a single resource.
• Reader may look but not change anything.
• Contributor may create and change resources, but cannot hand out permissions to others.
• Owner may do everything, including giving other people access.
• Specific roles exist for narrow jobs, such as only managing virtual machines or only reading storage data.

Permissions flow downward. A role given on a subscription applies to every resource group and resource inside it. This is convenient, but it is also why giving a broad role at a high level is risky.

A command line is fast, and fast tools can cause fast damage. A few habits keep you and your cloud safe.

The main risks

Protective habits

• Least privilege. Give people and programs the smallest role at the smallest scope that lets them do their job.
• Just-in-time elevation. Use Privileged Identity Management so powerful roles are switched on only when needed and switch off automatically afterwards.
• No stored secrets. Prefer managed identities and federated sign-in. When a secret is unavoidable, keep it in Azure Key Vault, a secure safe for keys and passwords, and fetch it only at the moment of use.
• Guard rails. Azure Policy can forbid unsafe settings, such as public storage or unapproved regions, even if someone tries them. Resource locks can block accidental deletion of important items.
• Sign out on shared computers. Use the sign-out command, and close Cloud Shell on machines that are not yours.
• Review the audit trail. Every change made through the CLI or Cloud Shell is recorded in the Activity Log, as we will see next.

The Cloud Shell safety net

Cloud Shell has a safety advantage. Because it is managed by Microsoft, the tools are always patched and clean, and no leftover tokens remain on your laptop. For companies with strict rules, it can run inside a private network and can be turned off for users who should not have it. These controls let security teams enjoy the convenience without giving up oversight.

When something changes in your cloud, you want to know who did it, when, and from where. Azure keeps that diary for you.

The Activity Log: the cloud’s diary

Every change sent to Azure Resource Manager, whether it came from the portal, the CLI, Cloud Shell, or a pipeline, is recorded in the Activity Log. Each entry says who did it, what they did, which resource it touched, when, and whether it succeeded. By default the log is kept for about ninety days, and you can send a copy to a long-term store called a Log Analytics workspace for longer storage, searching, and alerts.

flowchart LR
    Act["Any change from CLI, portal or pipeline"] --> ARM["Azure Resource Manager"]
    ARM --> Log["Activity Log"]
    Log --> LA["Log Analytics workspace"]
    LA --> Alert["Alert rules"]
    Alert --> Team["Security or operations team"]
    LA --> Dash["Dashboards and reports"]

You can read the log in the portal or ask for it from the CLI. A security team might create an alert such as “tell us whenever someone deletes a resource group” or “tell us when a new Owner role is assigned.” Because every tool passes through the same front desk, these alerts cover everything.

Seeing what the CLI itself is doing

Metrics and cost

The CLI is not only for building things; it can also read the health of your resources. Monitor commands fetch numbers such as processor use for a virtual machine, and query commands let you search your logs. For money, cost and budget commands let you see spending and create budgets with alerts. Scripts can use exit codes to report success or failure to a scheduler, which turns your commands into something you can monitor too.

Every tool has strengths and limits. Knowing both lets you use each one where it shines.

The Azure CLI

Cloud Shell

The main trade-offs

Scripts versus templates

The biggest trade-off is between commands and templates. A CLI script says “do step one, then step two.” A template says “make the world look like this.” Templates are better at keeping a large environment correct over time because they describe the end state and can find drift. CLI scripts are better for quick tasks, glue between systems, and one-off fixes. Mature teams use both, each where it fits.

A pattern is a recipe that has worked many times. An anti-pattern is a mistake so common it earned a name.

Patterns that work

Anti-patterns to avoid

These habits separate calm Azure users from stressed ones.

Habits worth building

Common mistakes

• Acting on the wrong subscription. The tool will happily obey. It cannot know you meant a different one.
• Forgetting to register a provider. A new subscription may reject a command until the matching provider is registered.
• Mixing up region names. Each region has a short name without spaces, such as “centralindia,” and a display name with spaces, such as “Central India.” Using the short form in scripts avoids quoting problems and typos.
• Believing “succeeded” means “secure.” A resource can be created successfully and still be wide open to the public.
• Leaving the storage account for Cloud Shell unmanaged. Tag it, secure it, and include it in your reviews.
• Ignoring throttling. Looping through thousands of resources one by one can hit limits. Ask for lists in bulk instead.
• Copying commands from the internet without reading them. A snippet that worked for someone else may delete, expose, or cost more than you expect.

These tools are woven into the products and workflows of many well-known platforms. Here are some places you meet them.

Everyday scenarios

The following are typical, illustrative situations rather than reports about particular companies.

• The nightly cost saver. An online retailer’s team writes a small script that stops test servers each evening and starts them each morning, run by a scheduler. The test bill drops sharply with almost no effort.
• The midnight fix. An on-call engineer gets an alert on a phone, opens Cloud Shell from the Azure mobile app, scales up a database, and goes back to sleep. No laptop was needed.
• The locked-down laptop. A consultant joins a client whose laptops forbid installing software. Cloud Shell in a browser lets the consultant work from day one.
• The audit request. A security officer asks for every storage account that allows public access. One query across all subscriptions returns the list in a table, ready to share.

A typical learning-to-production journey

A newcomer usually starts in the portal, clicking to see what exists. Then they discover Cloud Shell and run a few list commands, because it is one click away. Soon they save useful commands in a script on their file share. Next they install the CLI locally for faster work and add it to a pipeline. Finally, as the environment grows, they move the long-lived parts into templates and keep the CLI for checks and glue. Nearly everyone who works with Azure follows a version of this path.

With so many ways to reach Azure, a simple decision path keeps you from overthinking.

flowchart TD
    Start["You need to change something in Azure"] --> Q1{"Is it a one-time look or small change?"}
    Q1 -- Yes --> Q2{"Do you prefer buttons and menus?"}
    Q2 -- Yes --> Portal["Use the Azure portal"]
    Q2 -- No --> Q3{"Is your own computer set up with the CLI?"}
    Q3 -- Yes --> Local["Use the local Azure CLI"]
    Q3 -- No --> Shell["Use Cloud Shell"]
    Q1 -- No --> Q4{"Are you building a whole environment to keep correct over time?"}
    Q4 -- Yes --> Tmpl["Use a template such as Bicep or Terraform"]
    Q4 -- No --> Pipe["Use CLI scripts, run by a pipeline or scheduler"]

A simple learning path

Quick answers to the questions people ask most.

The whole guide in a few lines.