Part 3: Manage Azure from Cloud Shell

Compare Azure management tools with a repeatable Cloud Shell inventory.

Introduction

30 Second Summary

Clicking through a cloud dashboard works well for a quick check. Repeating those clicks later leaves you without a reusable record.

In this project, you will use Azure Cloud Shell to build a compact management runbook for one temporary resource group. You will compare the same subscription through the Azure portal, Azure CLI, and Azure PowerShell.

What You'll Build

Picture opening one local evidence folder to show the same resource group matched across a portal screenshot, an Azure CLI table, and an Azure PowerShell inventory.

By the end of this project, you'll have:

  • A repeatable Azure inventory you can rerun to compare portal, Azure CLI, and Azure PowerShell evidence for the same resource group.
  • A management-tool decision matrix that recommends the right interface for one-off checks, scripting, administration, declarative deployments, and hybrid management using ARM templates and Bicep.
  • An Azure Arc scenario note that shows how servers outside Azure can appear in Azure Resource Manager without moving their workloads.
  • Secret Mission: Publish a concise portfolio runbook with a West US filtered inventory. Add clear recommendations for each management tool.

Are there any prerequisites?

You need an Azure account with an active subscription plus permission to inspect and manage resources. No existing resource group is required.

Before We Start

This is your moment to commit to inspecting your active Azure subscription through multiple management interfaces. You will compare how the Azure portal, Azure CLI, and Azure PowerShell expose the same Azure Resource Manager state.

Initialize Cloud Shell

Your portal comparison needs a command-line environment that already knows which Azure subscription to inspect. Azure Cloud Shell provides an authenticated browser terminal for that shared starting point.

Cloud Shell includes Azure CLI plus Azure PowerShell. Using an ephemeral session removes local sign-in plus version setup.

In this step, get ready to:
  • Initialize Azure Cloud Shell without creating persistent storage.
  • Confirm the active subscription plus Azure CLI version in Bash.
  • Confirm the same subscription plus Azure PowerShell version in PowerShell.
Start an ephemeral Cloud Shell session

An ephemeral session stores its files only until Cloud Shell ends. This keeps the setup focused on subscription management.

This option does not create a storage account. You avoid persistent storage while completing the project.

  • Visit shell.azure.com in your browser.
  • Select Bash in the shell choice.
  • Choose No storage account required for an ephemeral session.
  • Select your active subscription in the Subscription field.
  • Select Apply.

Cloud Shell opens with a Bash prompt. The environment selector shows Switch to PowerShell.

You have cleared the first setup hurdle. Cloud Shell now has an authenticated Azure context without persistent storage.

Cloud Shell did not start?

  • Open your active subscription in the Azure portal.
  • Select Resource providers in the subscription menu.
  • Search for Microsoft.CloudShell.
  • Register the Microsoft.CloudShell provider.
  • Return to Cloud Shell.
  • Repeat the ephemeral session setup.

Still unable to start the session? Help me troubleshoot Cloud Shell initialization.

Confirm Bash and the Azure CLI version

Bash gives you access to Azure CLI inside the authenticated session. Listing subscriptions proves that the command line can read your Azure account context.

  • List the subscriptions available to your signed-in account by running:
az account list

What does this command show?

This command lists the subscriptions available to your signed-in Azure account. The output lets you confirm that Cloud Shell can inspect your active subscription.

You will see your active subscription in the output. This proves that Bash is using the authenticated Cloud Shell context.

  • Record your active subscription name here: your active subscription name.

Subscription missing from the output?

  • Confirm that your browser uses the Azure account associated with the active subscription.
  • Restart the ephemeral session with the active subscription selected.

Need help finding the subscription? Help me troubleshoot my Azure CLI subscription context.

  • Check the installed Azure CLI version by running:
az --version

What does this version check prove?

This command reports the Azure CLI version installed in the current Cloud Shell image. The September 2026 image includes Azure CLI 2.89.1.

You will see Azure CLI 2.89.1 in the version output.

  • Record the installed Azure CLI version here: 2.89.1.

Version output looks different?

  • Confirm that the output identifies Azure CLI before recording the version.
  • Start a fresh ephemeral session if the version is missing.

Unsure which value to record? Help me identify the Azure CLI version in my Cloud Shell output.

Confirm PowerShell and the subscription context

PowerShell uses Azure PowerShell cmdlets within the same Cloud Shell session. Checking its module version plus account context proves that both shells are ready for the later inventory comparison.

  • Open the Cloud Shell environment selector.
  • Select Switch to PowerShell.

The prompt changes to PowerShell. The environment selector now offers Switch to Bash.

  • Check the installed Az module by running:
Get-InstalledModule -Name Az

What does this module check prove?

The Az module provides Azure PowerShell commands. This check reports the version available in the current Cloud Shell image.

You will see Azure PowerShell 16.2.0 in the module information.

  • Record the installed Azure PowerShell version here: 16.2.0.

Az module not listed?

  • Confirm that the environment selector offers Switch to Bash.
  • Restart the ephemeral session if the module information remains empty.

Still missing the module details? Help me troubleshoot the Azure PowerShell module check.

Before you check the context, consider whether PowerShell will show the same subscription you recorded in Bash.

  • Inspect the Azure PowerShell context by running:
Get-AzContext

What does this context check show?

The Get-AzContext cmdlet returns the account metadata used for Azure Resource Manager requests. This includes the current subscription context.

You will see your active subscription name as the PowerShell subscription context. It matches the subscription you confirmed in Bash.

That is the shared context confirmed. Bash plus PowerShell can now inspect the same active Azure subscription.

PowerShell shows the wrong subscription?

  • Compare the PowerShell subscription name with the name you recorded from Bash.
  • Restart Cloud Shell with the intended active subscription selected if the names differ.

Need help resolving the mismatch? Help me align my Bash and PowerShell subscription contexts.

✔️ I've got everything

Your ephemeral Cloud Shell session has both command-line environments ready. Double-check that you recorded both tool versions.

ⓧ I'd like to double check the session

Initialized at shell.azure.com with no storage account required, active subscription selected, Bash and PowerShell shells available, Azure CLI 2.89.1 confirmed, and Azure PowerShell 16.2.0 confirmed.

Your authenticated Cloud Shell session is ready in both environments. Next, you will create a visual portal baseline to compare with repeatable command output.

Create a Portal Baseline

Your authenticated Azure Cloud Shell session already proves that the command-line tools can reach your active subscription. Now you need a visual reference for that same environment.

The Azure portal provides a guided view of your resources. This step tests whether one portal page leaves you with an inventory you could repeat later.

In this step, get ready to:
  • Create an empty resource group in your active subscription.
  • Refresh the portal to confirm the resource group exists.
  • Save a screenshot locally as your visual baseline.
Create an empty resource group

A resource group is a container in Azure Resource Manager. One empty group gives the portal a controlled object to display without adding a paid workload.

  • Open a new browser tab.
  • Go to https://portal.azure.com.
  • Sign in with the Azure account you used for Cloud Shell.
  • Complete any identity prompt shown by your browser.
  • Enter Resource groups in the search bar.
  • Select Resource groups from the results.
  • Select Create.

Creating something in Azure can feel like a billing decision. This empty resource group contains no paid workload.

  • Select the subscription you confirmed in Cloud Shell under Subscription.
  • Enter MyResourceGroup in the Resource group field.
  • Select West US under Region.
  • Select Review + Create.

The portal checks the resource group settings before creation.

  • Select Create after the checks finish.

You'll see confirmation that the resource group deployment finished.

Solid progress. Your controlled Resource Manager container now exists without any child resources.

Can't create the resource group?

  • Confirm that you selected the active subscription from Cloud Shell.
  • Check that the resource group name is exactly MyResourceGroup.
  • Verify that your Azure account has permission to manage resources in the subscription.

Still blocked? Help me troubleshoot why Azure will not create MyResourceGroup..

Refresh and inspect the baseline

A baseline records a known state that later checks can compare against. Your expected state is one empty resource group in West US.

  • Return to the Resource groups page in the portal.

Before you refresh, do you expect the new resource group to appear immediately in the subscription inventory?

  • Select Refresh.

You'll see MyResourceGroup in the list with West US as its region.

  • Select MyResourceGroup from the list.
  • Confirm that its location is West US.
  • Confirm that provisioning succeeded.
  • Confirm that no child resources are listed.

You now have direct portal evidence of the resource group's name, region, provisioning state, and empty contents.

Save the portal evidence

Your baseline needs a local artifact that remains available after the browser session ends. The screenshot preserves the exact portal state you just verified.

  • Arrange the portal page so the resource group name, location, and provisioning state are visible.
  • Press Windows logo key + Shift + S to open the screenshot overlay.
  • Capture the Azure portal window.
  • Select the screenshot notification to open the image in Snipping Tool.

You'll see the captured portal view ready to save.

  • Select Save as in Snipping Tool.
  • Select Desktop in the Save As dialog.
  • Select New Folder.
  • Enter Manage-Azure-from-Cloud-Shell as the folder name.
  • Select OK.
  • Enter portal-resource-group.png as the file name.
  • Select Save.
  • Open Manage-Azure-from-Cloud-Shell/portal-resource-group.png to verify the saved image.

Your image proves the current state. Recreating this inventory still requires the same portal clicks and manual reading.

Your portal baseline is saved locally. Next, you'll turn this manual check into a repeatable inventory with Azure CLI.

Build the Azure CLI Inventory

The Azure portal gave you a visual baseline for MyResourceGroup. A manual page check cannot produce a reusable inventory another administrator can run later.

Now you will use Azure CLI in Azure Cloud Shell to turn the same Azure Resource Manager state into repeatable evidence.

The table gives you a readable snapshot. The JSON copy preserves detailed fields for later comparison.

In this step, get ready to:
  • Create a readable table inventory of your resource groups.
  • Save a detailed JSON inventory in your local portfolio folder.
  • Distinguish the resource group container from its child resources.
Create a readable inventory

Azure CLI can request the resource groups in your active subscription with one repeatable command. Its table output makes the important fields easy to scan.

  • Return to the Cloud Shell session from earlier.
  • Open the Cloud Shell environment selector.
  • Select Switch to Bash.

Before you run this check, consider whether the group created in the portal will appear in the command-line inventory.

  • Compare the command-line inventory with your portal baseline by running:
az group list --output table

What Does This Command Show?

  • The az group list command requests the resource groups in your active subscription.
  • The --output table option formats selected fields as a readable table.
  • This command turns the portal check into a reusable inventory action.

You will see MyResourceGroup in the table with westus as its location.

Group Missing from the Table?

  • Confirm Cloud Shell is using Bash before rerunning the command.
  • Compare the active subscription in Cloud Shell with the subscription that contains MyResourceGroup.

Still stuck? Help me find why MyResourceGroup is missing from my Azure CLI table.

  • Use the same Windows screenshot workflow from the portal check to save the table as azure-cli-inventory.png inside your existing Manage-Azure-from-Cloud-Shell folder.

Good work. Your portal baseline now has a repeatable command-line match.

Preserve the detailed inventory

Azure CLI returns JSON when you omit the output option. Saving that result locally protects your evidence when the ephemeral Cloud Shell session ends.

You will use Visual Studio Code to store this detailed inventory beside your portal screenshot.

  • Generate the default JSON inventory by running:
az group list

Why Is This Output More Detailed?

  • The az group list command sends the same resource-group request as before.
  • Azure CLI returns JSON because this command has no output option.
  • JSON preserves named fields that scripts can read later.

You will see a detailed inventory for the active subscription. One entry contains MyResourceGroup with westus as its location.

Copying a long JSON result from a browser terminal can feel fiddly because the output spans many lines.

  • Select the complete JSON output in Cloud Shell.
  • Copy the selected output.
  • Press the Windows key to open Windows search.
  • Type Visual Studio Code in Windows search.
  • Press Enter to open Visual Studio Code.
  • Use the folder picker to select the existing Manage-Azure-from-Cloud-Shell folder.
  • Use the file sidebar to create azure-cli-resource-groups.json inside that folder.

You should see azure-cli-resource-groups.json open as an empty file inside your portfolio folder.

  • Paste the copied JSON into azure-cli-resource-groups.json.
  • Save azure-cli-resource-groups.json.
  • Search the saved file for MyResourceGroup.

You will find MyResourceGroup in the saved inventory with the location westus.

Saved File Missing the Group?

  • Check that the saved file contains the complete Cloud Shell selection.
  • Confirm that you pasted the output into azure-cli-resource-groups.json.

Need a hand? Help me fix my saved Azure CLI JSON inventory.

Compare groups with child resources

A resource group is a Resource Manager container. A resource query scoped to that group looks for the resources inside the container.

Before you inspect the group, consider whether the resource group itself counts as one of its child resources.

  • Inspect the resources inside MyResourceGroup by running:
az resource list --resource-group MyResourceGroup

What Does This Query Inspect?

  • The az resource list command requests individual Azure resources.
  • The --resource-group MyResourceGroup option limits that request to resources inside the named group.
  • The empty group gives this command no child resources to return.

You will see an empty result. This proves the group exists as a container while holding no child resources.

Seeing Child Resources?

  • Confirm the command targets MyResourceGroup.
  • Check whether another administrator added resources to the group after it was created.

Need help interpreting the result? Help me understand the resources returned for MyResourceGroup.

Before the final check, predict whether the table will still agree with your portal screenshot and saved JSON inventory.

  • Verify the reusable group inventory by running this command again:
az group list --output table

Why Run This Check Again?

The table gives you a final readable check against both saved artifacts.

You will see MyResourceGroup in westus. The result matches the portal screenshot plus the saved JSON inventory.

Your Azure CLI evidence now captures the subscription in readable and reusable forms. Next up, you will inspect the same Resource Manager state through Azure PowerShell.

Verify Inventory with PowerShell

Your previous Azure portal check shows MyResourceGroup in westus. The Azure CLI inventory confirms the same resource group.

Azure PowerShell closes the CLI-only comparison gap. It reads the same Azure Resource Manager state through PowerShell objects.

In this step, get ready to:
  • Confirm the same active subscription in Azure PowerShell.
  • Produce a formatted PowerShell inventory of your resource groups.
  • Capture local evidence of the output-model comparison.
Switch to PowerShell and confirm the context

The active context determines which subscription a command reads. Your Azure Cloud Shell session already carries the authenticated account from earlier.

  • Select the environment selector at the top of Cloud Shell.
  • Select Switch to PowerShell.
  • Confirm the active Azure context by running this command:
Get-AzContext

What does this context check prove?

  • The Get-AzContext command reads the account context used for Azure Resource Manager requests.
  • The subscription value should match the subscription from your earlier Azure CLI check.

You will see your active subscription in the context output. Good, both command-line tools are now pointed at the same subscription.

Subscription context does not match?

  • Confirm the environment selector shows Switch to Bash. This means PowerShell is active.
  • Compare the subscription in the output with the subscription from your earlier Azure CLI inventory.

Still stuck? Help me compare my Azure PowerShell context with my Azure CLI subscription.

Build the formatted PowerShell inventory

Azure CLI defaults to JSON strings. Azure PowerShell returns objects that can move through a formatting pipeline.

Before you run the inventory, do you expect PowerShell to find the same resource group as the portal and Azure CLI?

  • Build the formatted resource-group inventory by running this pipeline:
Get-AzResourceGroup |
  Sort-Object Location,ResourceGroupName |
    Format-Table -GroupBy Location ResourceGroupName,ProvisioningState,Tags

What does this pipeline do?

  • Get-AzResourceGroup retrieves every resource group in the current subscription.
  • Sort-Object arranges the objects by location first. It uses the resource-group name as the second sorting value.
  • Format-Table groups the view by location. It displays each resource-group name with its provisioning state and tags.

You will see an entry for MyResourceGroup. Its location is westus.

The provisioning state is Succeeded. You have now confirmed the same resource group through a second command-line interface.

Resource group missing from the table?

  • Confirm PowerShell is still active in the Cloud Shell environment selector.
  • Copy the complete pipeline from the code block again to avoid a missing pipe or property name.
  • Check that the active context matches the subscription containing MyResourceGroup.

Need another pair of eyes? Help me troubleshoot why MyResourceGroup is missing from my PowerShell inventory.

Capture and compare the evidence

The Cloud Shell session is ephemeral. Local evidence preserves the comparison after the browser session ends.

  • Capture the formatted table using the same Windows screenshot method from your Azure CLI inventory.
  • Save the image as azure-powershell-inventory.png inside the local Manage-Azure-from-Cloud-Shell folder.

Why keep the evidence local?

An ephemeral Cloud Shell session deletes its files when the session ends. Your local folder keeps the screenshot beside the portal and Azure CLI evidence.

  • Press the Windows key to open the search bar.
  • Type Visual Studio Code and press Enter to open it.
  • Open the existing Manage-Azure-from-Cloud-Shell folder using the folder picker.
  • Create management-tools.md inside the Manage-Azure-from-Cloud-Shell folder.
  • Record that Azure CLI uses concise commands and defaults to JSON strings.
  • Record that Azure PowerShell uses verb-noun cmdlets and returns PowerShell objects.
  • Save management-tools.md.

Why document both output models?

Azure CLI provides concise commands with JSON output. Azure PowerShell provides objects that fit PowerShell pipelines and Windows-oriented administration.

  • Confirm the local file list contains both azure-powershell-inventory.png and management-tools.md.

Before you rerun the inventory, do you expect the PowerShell view to still match your portal and Azure CLI evidence?

  • Perform the final inventory check by running the formatted pipeline again:
Get-AzResourceGroup |
  Sort-Object Location,ResourceGroupName |
    Format-Table -GroupBy Location ResourceGroupName,ProvisioningState,Tags

What does this final check prove?

The repeated pipeline reads the current Azure Resource Manager state. Matching output proves the inventory can be reproduced instead of manually reconstructed.

Your final output includes MyResourceGroup with westus as its location. The provisioning state is Succeeded.

That completes the multi-tool comparison. Your portal, CLI, and PowerShell evidence now points to the same Resource Manager state.

Final inventory does not match?

  • Check that Get-AzContext showed the active subscription from earlier.
  • Copy the complete formatted pipeline from the code block again.

Still seeing a mismatch? Help me compare my portal, Azure CLI, and Azure PowerShell resource-group evidence.

Your matching inventories are now saved locally. Next up, you will place Azure Arc in the management model for hybrid environments.

Map Azure Arc and Management Tools

Your Azure portal screenshot established a visual baseline for MyResourceGroup.

Your Azure CLI inventory made that baseline repeatable. Your Azure PowerShell inventory confirmed the same Azure Resource Manager state.

That inventory currently stops at Azure-hosted resources. Azure Arc extends your management model to supported servers outside Azure.

In this step, get ready to:
  • Inspect Azure Arc resources from Azure Cloud Shell.
  • Evaluate Azure Arc for a hybrid server scenario.
  • Build a five-tool management decision matrix.
Inspect Azure Arc resources

Arc-enabled servers appear in Azure Resource Manager as hybrid compute machine resources. The resource type Microsoft.HybridCompute/machines gives Azure CLI a precise inventory target.

  • In the Cloud Shell session from earlier, select the environment selector.
  • Select Switch to Bash.

Before you run the inspection, do you expect this subscription to contain any Arc-enabled machines? The next result tests your prediction.

  • Inspect the active subscription for Arc-enabled machines by running this command:
az resource list --resource-type Microsoft.HybridCompute/machines

What does this command inspect?

The az resource list command queries resources visible through the active subscription. The --resource-type option narrows the inventory to Microsoft.HybridCompute/machines.

Each returned machine represents a server projected into the Azure management layer through Azure Arc.

If the command returns no machine entries, this subscription has no Arc-enabled servers. If it returns machine entries, the subscription already contains Arc-enabled servers.

  • Switch back to management-tools.md in Visual Studio Code.
  • Record the Arc inspection command from Cloud Shell with its result.

You should now see the Arc inspection result beside your earlier command-line comparison.

  • Save management-tools.md.

Good progress. Your runbook now shows whether Azure Arc already has a footprint in this subscription.

Inspection command failed?

  • Confirm you selected Switch to Bash before running the Azure CLI command.
  • Confirm Cloud Shell still uses the active subscription from earlier.

Still stuck? Help me troubleshoot the Azure Arc resource inspection.

Evaluate the hybrid scenario

Consider a company with two long-lived Windows servers in its datacenter. It also runs one Linux server in another cloud.

The company wants one inventory with consistent governance. Every workload must remain where it runs.

Why Azure Arc fits

Azure Arc projects each supported server into Azure Resource Manager as a manageable resource. Administrators can include those servers in the same Azure inventory without migrating their workloads.

Each connected server is represented as a Microsoft.HybridCompute/machines resource. The workload stays on its current machine.

  • Add an Azure Arc scenario section to management-tools.md.
  • Write a short recommendation using the scenario conclusion above.

Your note should identify Azure Arc as the management-plane fit. It should preserve the current workload locations while representing each connected server as a hybrid compute machine resource.

  • Save management-tools.md.

That decision now connects a realistic hybrid requirement to the right Azure management service.

Build the management-tool matrix

Each Azure management tool suits a different working style. A decision matrix turns those differences into a reusable recommendation.

Which tool fits each job?

  • Azure portal: Guided one-off exploration.
  • Azure CLI: Concise cross-platform scripting.
  • Azure PowerShell: PowerShell object pipelines plus Windows-oriented administration.
  • ARM templates: Declarative repeatable deployments.
  • Bicep: Declarative repeatable deployments with Azure-focused syntax.

Every interface sends management requests through Azure Resource Manager. Azure Arc projects supported non-Azure resources into that shared layer.

  • Add a Management tool decision matrix section to management-tools.md using the five mappings plus the shared management-layer conclusion.
  • Save management-tools.md.

Before you review the finished file, which shared layer do you expect every interface to reach? The review tests your answer.

  • Review the saved management-tools.md file in Visual Studio Code.

What should you see?

  • The original Azure CLI comparison covering concise commands plus JSON strings.
  • The original Azure PowerShell comparison covering verb-noun cmdlets plus PowerShell objects.
  • The Arc inspection command with a recorded outcome for the active subscription.
  • A hybrid scenario recommending Azure Arc without workload migration.
  • A five-tool decision matrix connected through Azure Resource Manager.

That closes the management gap. Your runbook now recommends a tool for each common administration style.

Secret mission

Publish the Inventory Runbook

Your screenshots prove that the Azure management interfaces reached the same subscription. Turn that evidence into a portfolio-ready runbook with a filtered West US inventory, working screenshot links, and clear tool recommendations.

Clean Up Your Resources

Clean Up Your Resources

The expected cost for your empty Azure resource group plus ephemeral Azure Cloud Shell session is $0. Choose whether to keep the inventory target, pause your work, or remove every project resource.

Resources you used:

  • An empty Azure resource group named MyResourceGroup in your active subscription.
  • An ephemeral Azure Cloud Shell session at shell.azure.com with no storage account.
  • A local Manage-Azure-from-Cloud-Shell folder on Windows. It contains README.md, management-tools.md, portal-resource-group.png, azure-cli-inventory.png, azure-cli-resource-groups.json, azure-cli-westus-filtered-inventory.txt, and azure-powershell-inventory.png.

Keep everything running

No action is needed. Choose this if you want to keep the empty resource group for future inventory checks.

  • Keep MyResourceGroup as an empty Azure inventory target.
  • Retain the local Manage-Azure-from-Cloud-Shell folder with your runbook evidence.
  • Leave the Cloud Shell browser tab open while you want to continue using the same ephemeral session.

Pause - I'll come back to this later

Shut down the Cloud Shell session to step away without deleting your empty resource group or local evidence.

  • Return to the Cloud Shell session from earlier.
  • Select Close in the Cloud Shell header.
  • Leave MyResourceGroup in the active subscription.
  • Keep the local Manage-Azure-from-Cloud-Shell folder on Windows.

The ephemeral session ends when you close it. Its temporary files are removed.

Your local folder remains on Windows. MyResourceGroup remains in the active subscription.

Delete - I don't want to use this again

Deleting the group is deliberate. It contains no child resources from this project, so this command removes only the empty inventory target.

Cloud Shell asks for confirmation before the deletion continues.

  • Delete MyResourceGroup from the Bash session from earlier by running this command:
az group delete --name MyResourceGroup

What does this command do?

  • The az group delete --name MyResourceGroup command targets the temporary resource group by name.
  • Deleting a resource group also removes any resources inside it. This project left the group empty.
  • Confirm the deletion in the Cloud Shell prompt.
  • Wait until Bash returns to the command prompt.

Before you check, do you expect the temporary group to appear in the refreshed inventory?

  • Verify the deletion by running this command:
az group list --output table

What does this command show?

The az group list --output table command reads the current resource-group inventory for the active subscription. The refreshed result proves whether the deletion finished.

You should not see MyResourceGroup in the output.

Still see the resource group?

  • Wait for the deletion command to finish before checking the inventory again.
  • Confirm that Cloud Shell is using the same active subscription where you created the group.
  • Check that your Azure permissions allow you to delete resource groups.

Help me troubleshoot the resource-group deletion.

That clears the Azure resource created for this project. The remaining cleanup covers the ephemeral session plus your local evidence folder.

  • Select Close in the Cloud Shell header.

The ephemeral session ends. Its temporary files are removed automatically.

Removing the local folder also removes every runbook file, screenshot, and inventory capture stored inside it.

  • Return to the local location where you saved Manage-Azure-from-Cloud-Shell by using the Windows file browser.
  • Select the Manage-Azure-from-Cloud-Shell folder.
  • Use the folder context menu's delete action.
  • Confirm the folder removal if Windows asks.

You should no longer see the Manage-Azure-from-Cloud-Shell folder in its previous location. That finishes the project cleanup.

Nice Work!

Nice Work!

You did it! Your portfolio runbook now proves that three management interfaces reveal the same Azure Resource Manager state.

You've learned how to:

  • Produced a repeatable resource inventory through the Azure portal. Repeated it with Azure CLI. Confirmed the same subscription state with Azure PowerShell.
  • Captured JSON output as a reusable local inventory. Compared it with PowerShell objects from the formatted resource-group pipeline.
  • Built a five-tool decision matrix for common Azure management tasks. Connected every interface through Azure Resource Manager. Applied Azure Arc to a realistic hybrid inventory scenario.
  • Completed the optional Secret Mission by publishing a portfolio-ready runbook. Its filtered westus inventory proves targeted querying. Three working screenshot links keep the evidence visible.

Ready to quiz yourself?