Secure an Azure VM with Managed Identity

Authenticate an Azure VM to Key Vault using managed identity, no credentials needed.

Introduction

30 Second Summary

Every time a password or API key gets hard-coded into a server, it becomes a target. Leaked credentials are one of the most common causes of cloud security breaches.

In this project, you will deploy a Linux virtual machine on Azure that authenticates to a secret store using only its identity. No passwords, no API keys, no certificates stored anywhere in your code or configuration.

What You'll Build

A secure Azure infrastructure where a Linux VM retrieves secrets from Azure Key Vault using a managed identity instead of stored credentials.

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

  • A resource group containing an Azure Key Vault with a stored secret and a Linux VM.
  • A system-assigned managed identity on your VM, granted least-privilege access through Azure RBAC.
  • A verified secret retrieval from inside the VM proving the entire identity chain works with zero stored credentials.
  • Secret Mission: Create a user-assigned managed identity, attach it to the VM, and prove identity-level permission isolation.

Are there any prerequisites?

None. This project includes setup for all required tools, including the Azure CLI and an Azure free account. You just need a Mac running macOS 13 or higher with Terminal access.

Set Up Your Environment

Before you can deploy a VM or store secrets, you need the tools to talk to Azure from your local machine.

In this step, you will install the Azure CLI on macOS using Homebrew, create a free Azure account, and sign in so that every command you run later targets your subscription automatically.

In this step, get ready to:
  • Install Homebrew and Azure CLI on macOS.
  • Create an Azure free account and sign in.
  • Verify your subscription is active and set a default location.
Install Homebrew and Azure CLI

Azure CLI is a command-line tool that lets you create and manage Azure resources directly from your terminal. On macOS, the recommended way to install it is through Homebrew, a package manager for macOS.

  • Press Cmd+Space to open Spotlight Search.
  • Type Terminal and press Enter to open it.
  • Check if Homebrew is already installed by running this command:
brew --version

✔️ I see a version number

Homebrew is already installed. Move on to the Azure CLI install below.

ⓧ Command not found

Homebrew is not installed yet. Install it by running this command:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

What does this command do?

This downloads and runs Homebrew's official install script. The script will explain each action it takes and ask for your confirmation before proceeding.

Follow the post-install instructions

After Homebrew finishes installing, it prints shell configuration instructions in your terminal. Follow those instructions exactly to add Homebrew to your PATH. If you skip this, brew commands will not be found.

  • Install the Azure CLI by running this command:
brew update && brew install azure-cli

What does this command do?

The brew update part refreshes Homebrew's package list so you get the latest version. Then brew install azure-cli downloads and installs the Azure CLI package.

  • Verify the installation by running:
az version

✔️ I see version 2.87.0 or higher

Azure CLI is installed and ready. You will see a JSON block with azure-cli showing 2.87.0 or a higher number. Move on to the next substep.

ⓧ I see an older version

Your Azure CLI is outdated. Upgrade it by running:

brew update && brew upgrade azure-cli

After the upgrade completes, run az version again to confirm you see 2.87.0 or higher.

ⓧ Command not found

The install may not have completed, or Homebrew is not in your PATH. Try these steps:

  • Close your terminal and open a new one.
  • Run brew --version to confirm Homebrew works.
  • Re-run brew update && brew install azure-cli and try az version again.

Still having trouble?

Make sure you followed Homebrew's post-install shell configuration instructions. If you are on macOS 13, Homebrew requires Xcode Command Line Tools. Run xcode-select --install if prompted.

help me install Azure CLI on macOS

Create an Azure free account and sign in

Azure's free account gives you $200 in credit to use within 30 days. This is more than enough for everything in this project.

Why do I need a payment method?

Azure requires a credit card for identity verification, but you will not be charged during the free trial. The $200 credit covers everything in this project.

  • Once your account is ready, return to your terminal and sign in to the Azure CLI by running:
az login

What happens when you run this?

This opens a browser window where you sign in with your Microsoft account. After successful authentication, the browser confirms you are signed in and you can close it. Your terminal displays your subscription details.

Azure requires multi-factor authentication (MFA) for all CLI sign-ins. Make sure your Microsoft account has MFA configured. You will be prompted to approve the sign-in on your phone or authenticator app.

Browser didn't open?

If the browser does not open automatically, the terminal displays a URL and a device code. Open the URL manually, enter the code, and sign in from there.

help me sign in to Azure CLI

Verify your subscription and set a default location

Every Azure resource lives in a subscription and a region. Setting defaults now means you will not have to type them on every command.

  • Confirm your subscription is active by running:
az account show

What should I see?

You should see a JSON object with your subscription name, ID, and "state": "Enabled". This confirms Azure CLI is connected to an active subscription.

  • Set a default location so future commands automatically target a region by running:
az configure --defaults location=eastus

Why East US?

East US is one of Azure's largest regions with full service availability. You can choose a different region closer to you if you prefer. Run az account list-locations -o table to see all available options.

Seeing a subscription error?

If az account show returns an error about no subscriptions, your free account may not be fully activated. Return to the Azure portal in your browser and check that the subscription setup completed.

help me fix my Azure subscription issue

Your environment is ready. Next up, you will create an Azure Key Vault and store your first secret inside it.

Create the Key Vault and Store a Secret

Your Azure CLI is signed in and your subscription is confirmed. Now you need a secure place to store secrets that your VM will eventually retrieve.

In this step, you will create a resource group to hold all your project resources, then create an Azure Key Vault configured for RBAC authorization. Finally, you will store a secret inside the vault so there is something for the VM to fetch later.

In this step, get ready to:
  • Create a resource group to organize your Azure resources.
  • Create a Key Vault with RBAC authorization enabled.
  • Grant yourself permissions and store a secret in the vault.
Create a resource group

A resource group is a container that holds related Azure resources together. Everything you build in this project will live inside a single resource group so you can manage and delete it all in one place.

  • Create your resource group by running this command:
az group create --name "az104-identity-rg" --location "EastUS"

What does this command do?

  • --name sets the name of your resource group to az104-identity-rg.
  • --location places your resources in the East US data center region.
  • You should see a JSON response in your terminal with "provisioningState": "Succeeded" confirming the group was created.

Seeing a location error?

Make sure you typed EastUS exactly as shown (no space between East and US). If your account restricts certain regions, try WestUS2 instead.

Help me troubleshoot this error

Create a Key Vault with RBAC authorization

Azure Key Vault is a managed service for storing secrets, keys, and certificates securely. You will configure it to use RBAC authorization, which means access is controlled through role assignments instead of legacy access policies.

  • Create your Key Vault by running this command:
az keyvault create --name "[[KVNAME="your-unique-vault-name"]]" --resource-group "az104-identity-rg" --enable-rbac-authorization true --enable-purge-protection true

What does this command do?

  • --name is the globally unique name for your vault. It must be 3 to 24 characters, using only letters, numbers, and hyphens.
  • --resource-group places the vault inside the resource group you just created.
  • --enable-rbac-authorization true tells Azure to use role-based access control for this vault instead of access policies.
  • --enable-purge-protection true prevents the vault from being permanently deleted immediately, adding a safety net.

Pick a unique vault name

Key Vault names must be globally unique across all of Azure. Try a pattern like kv-yourname-identity to avoid conflicts. Keep it between 3 and 24 characters using only letters, numbers, and hyphens.

  • You should see a JSON response containing your vault's URI (something like https://your-vault-name.vault.azure.net/) confirming it was created.

Vault name already taken?

If you see a conflict error, the name is already in use by someone else on Azure. Try adding random numbers or your initials to make it unique.

Help me fix my Key Vault creation error

Why RBAC instead of access policies?

Azure Key Vault supports two permission models. Access policies are the legacy approach. RBAC is the modern default and what the AZ-104 exam tests.

With RBAC, you manage vault access using the same role assignment system as every other Azure resource. This gives you consistent, fine-grained control in one place.

Grant yourself permissions and store a secret

When RBAC is enabled on a Key Vault, even the vault creator does not automatically get data-plane access. You need to explicitly assign yourself the "Key Vault Secrets Officer" role before you can store or read secrets.

  • Grant yourself the Key Vault Secrets Officer role by running this command:
az role assignment create \
  --role "Key Vault Secrets Officer" \
  --assignee-object-id $(az ad signed-in-user show --query id -o tsv) \
  --scope $(az keyvault show --name "[[KVNAME="your-unique-vault-name"]]" --query id -o tsv)

What does this command do?

  • --role specifies the "Key Vault Secrets Officer" role, which allows you to create, read, update, and delete secrets.
  • --assignee-object-id automatically looks up your signed-in user's object ID using az ad signed-in-user show.
  • --scope targets this specific Key Vault by fetching its resource ID automatically.

Role propagation takes a moment

Role assignments can take a minute or two to propagate through Azure. If the next command fails with a Forbidden error, wait 60 seconds and try again.

  • Store a secret in your Key Vault by running this command:
az keyvault secret set --vault-name "[[KVNAME="your-unique-vault-name"]]" --name "MySecret" --value "SuperSecretPassword123"

What does this command do?

  • --vault-name targets your Key Vault.
  • --name sets the secret's identifier to MySecret.
  • --value is the secret content. In a real project, this would be a database password or API key.
  • Verify your secret is stored by retrieving it:
az keyvault secret show --name "MySecret" --vault-name "[[KVNAME="your-unique-vault-name"]]" --query "value"
  • You should see "SuperSecretPassword123" printed in your terminal, confirming the secret is stored and retrievable.

Seeing a Forbidden error?

This means the role assignment has not propagated yet. Wait 60 seconds and run the az keyvault secret set command again.

If it persists after waiting, confirm the role assignment exists by running:

az role assignment list \
  --assignee $(az ad signed-in-user show --query id -o tsv) \
  --scope $(az keyvault show --name "[[KVNAME="your-unique-vault-name"]]" --query id -o tsv)

Help me troubleshoot my Forbidden error

Your Key Vault is live and holding a secret. Next up, you will deploy a Linux VM with a managed identity that can authenticate to this vault without any stored credentials.

Deploy a Linux VM with Managed Identity

Your Key Vault is set up and holding a secret. Now you need something that can retrieve that secret without using any passwords or API keys.

In this step, you will deploy a Linux virtual machine with a system-assigned managed identity enabled from the start. This identity is what the VM will use to prove who it is when requesting secrets from Key Vault.

In this step, get ready to:
  • Deploy a Linux VM with a system-assigned managed identity.
  • Verify the managed identity was created and note the principal ID.
Create a Linux VM with a system-assigned managed identity

A system-assigned managed identity is tied directly to the VM's lifecycle. When you delete the VM, Azure automatically deletes the identity too. This makes it the simplest option for resources that only need their own identity.

  • Deploy the VM by running this command:
az vm create \
  --resource-group az104-identity-rg \
  --name identity-vm \
  --image Ubuntu2204 \
  --size Standard_B1s \
  --assign-identity \
  --admin-username azureuser \
  --generate-ssh-keys

What does this command do?

  • --resource-group az104-identity-rg places the VM inside the same resource group as your Key Vault.
  • --name identity-vm names the virtual machine.
  • --image Ubuntu2204 deploys Ubuntu 22.04 LTS as the operating system.
  • --size Standard_B1s selects a small burstable VM that stays within Azure's free tier (750 hours/month for 12 months).
  • --assign-identity enables a system-assigned managed identity at creation time.
  • --generate-ssh-keys creates an SSH key pair so you can connect to the VM later.

Why create the identity at VM creation time?

You can enable a managed identity on an existing VM later, but doing it at creation time is cleaner. The VM boots with its identity already active, so there is no window where the VM exists without one.

This command takes 1-2 minutes to complete. Azure provisions the VM, a virtual network, a network security group, a public IP address, and an OS disk automatically.

  • When the command finishes, you will see a JSON response in your terminal. Look for the publicIpAddress field and note it down. You will need this IP to SSH into the VM in a later step.

Seeing a SkuNotAvailable error?

Some Azure regions restrict B1s availability for free-tier subscriptions. Try deploying in a different region by adding --location eastus (or another region) to the command.

If you see a permission error, make sure your account has the Contributor role on the subscription.

Still stuck? Help me troubleshoot my az vm create error.

Cost warning

The B1s VM size is within Azure's free tier (750 hours/month for 12 months). If you leave it running beyond that allowance, it will consume your $200 credit. You will learn how to deallocate it in the Before You Go section.

Verify the managed identity

The VM is deployed, but you should confirm that its managed identity is active before moving on. The identity's principal ID is what you will use in the next step to grant it access to Key Vault.

  • Check the VM's identity by running this command:
az vm identity show --name identity-vm --resource-group az104-identity-rg

What should I see?

The output is a JSON object with these key fields:

  • principalId contains the unique ID of the VM's managed identity. Copy this value somewhere safe.
  • type shows SystemAssigned, confirming a system-assigned identity is active.
  • userAssignedIdentities is null because you have not attached any user-assigned identities yet.
  • Copy the principalId value from the output. You will use it in the next step to create a role assignment.

Not seeing any output?

If the command returns an empty response, the identity was not enabled during VM creation. You can enable it after the fact by running az vm identity assign --resource-group az104-identity-rg --name identity-vm and then re-running the show command.

Also double-check that you spelled the VM name identity-vm and resource group az104-identity-rg correctly. Names are case-sensitive.

Need more help? Help me verify my VM's managed identity.

Your VM is running with its own identity. Next, you will wire up the permissions so this identity can actually read secrets from your Key Vault.

Configure RBAC Access to Key Vault

Your VM has an identity, and your Key Vault has a secret. Right now, these two things exist independently with no connection between them.

In this step, you will create an RBAC role assignment that grants the VM's managed identity permission to read secrets from the Key Vault. This is the critical link that makes credential-free authentication work.

In this step, get ready to:
  • Retrieve the VM's managed identity principal ID.
  • Create an RBAC role assignment for the Key Vault Secrets User role.
  • Verify the role assignment exists.
Retrieve the VM's managed identity principal ID

To grant the VM's identity access to Key Vault, you need its principal ID. This is the unique identifier that Azure RBAC uses to represent the managed identity in role assignments.

  • Retrieve and store the VM's principal ID by running this command:
# Store the VM's managed identity principal ID in a variable
PRINCIPAL_ID=$(az vm identity show --name identity-vm --resource-group az104-identity-rg --query principalId --output tsv)

# Display it so you can confirm it looks right
echo $PRINCIPAL_ID

What does this command do?

The az vm identity show command retrieves identity information for your VM. The --query principalId flag extracts just the principal ID from the JSON output.

Wrapping it in $(...) stores the result in a shell variable so you can reuse it in the next command.

  • You should see a long string of characters (a GUID) printed to the terminal. This is your VM's identity.

Seeing an empty output?

Make sure you are using the exact resource group name az104-identity-rg and VM name identity-vm. If you named yours differently in a previous step, replace them accordingly.

Help me troubleshoot why my principal ID is not showing

Create the role assignment

The principle of least privilege means granting only the minimum permissions needed. The Key Vault Secrets User role allows reading secrets but nothing else. It cannot create, delete, or modify secrets.

  • Retrieve your Key Vault's resource ID for the scope by running:
# Get the Key Vault resource ID to use as the RBAC scope
KV_ID=$(az keyvault show --name [[KVNAME="your-key-vault-name"]] --resource-group az104-identity-rg --query id --output tsv)

Why do you need the resource ID?

Azure RBAC scopes role assignments to specific resources. By scoping to the Key Vault's full resource ID, you grant access only to this particular vault. The VM's identity cannot access any other Key Vault in your subscription.

  • Create the role assignment by running this command:
# Assign the Key Vault Secrets User role to the VM's managed identity
az role assignment create \
  --role "Key Vault Secrets User" \
  --assignee-object-id $PRINCIPAL_ID \
  --assignee-principal-type ServicePrincipal \
  --scope $KV_ID

What does this command do?

This az role assignment create command connects three pieces together: WHO gets access (the VM's principal ID), WHAT they can do (read secrets via the Key Vault Secrets User role), and WHERE (scoped to your specific Key Vault).

The --assignee-principal-type ServicePrincipal flag tells Azure this is a managed identity. This avoids potential replication delays that can happen if Azure tries to look up the identity in the directory first.

  • You should see a JSON response with roleDefinitionName showing "Key Vault Secrets User" and principalId matching the GUID you stored earlier.

Seeing a permissions error?

If you see a message about insufficient privileges, confirm you are logged in with the account that owns the subscription. Run az account show to check which account is active.

If you see an error about the principal not being found, wait 30 seconds and try again. Newly created managed identities can take a moment to replicate across Azure regions.

Help me troubleshoot the role assignment error

Verify the role assignment

Confirming the role assignment exists proves the identity chain is properly configured before you attempt to use it.

  • List the role assignments for your VM's principal ID by running:
# Verify the role assignment exists
az role assignment list \
  --assignee $PRINCIPAL_ID \
  --scope $KV_ID \
  --output table

What should I see?

The output table should show one row with the role "Key Vault Secrets User" assigned to your VM's principal ID, scoped to your Key Vault. This confirms the RBAC configuration is complete and the VM will be able to authenticate to Key Vault using only its managed identity.

  • Confirm you see a row showing Key Vault Secrets User in the output.

Seeing an empty table?

If the table shows no results, make sure the $PRINCIPAL_ID and $KV_ID variables are still set. Run echo $PRINCIPAL_ID and echo $KV_ID to check. If either is empty, re-run the commands from the beginning of this step.

Help me troubleshoot empty role assignment results

Your RBAC configuration is complete. The VM's managed identity now has the exact permissions it needs to read secrets from your Key Vault. Next up, you will SSH into the VM and prove this identity chain works by retrieving the secret with zero credentials.

Retrieve the Secret from Inside the VM

You have all the pieces in place. The Key Vault holds your secret, the VM has a managed identity, and the RBAC role assignment connects them.

Now it is time to prove the whole chain works. You will SSH into your VM, install the Azure CLI inside it, and retrieve the secret using nothing but the VM's managed identity. No passwords, no API keys, no certificates.

In this step, get ready to:
  • SSH into the Linux VM using its public IP address.
  • Install Azure CLI on the VM and authenticate with the managed identity.
  • Retrieve the Key Vault secret from within the VM to prove credential-free access.
SSH into the VM

To run commands inside the VM, you need a remote terminal session. SSH (Secure Shell) gives you an encrypted connection directly into the VM's command line.

  • Connect to your VM by running this command (replace the IP with the public IP you noted from the VM creation output):
ssh azureuser@[[VM_PUBLIC_IP="your VM public IP address"]]

What does this command do?

This connects you to the VM as the azureuser account (the admin username you specified during VM creation). Azure automatically configured SSH key authentication when you used --generate-ssh-keys in the earlier step.

  • If prompted to confirm the host fingerprint, type yes and press Enter.

Your terminal prompt changes to show azureuser@identity-vm, confirming you are now inside the VM.

Connection refused or timed out?

  • Double-check the public IP address matches the one from your VM creation output.
  • Make sure the VM is still running. You can verify from your local terminal (in a new tab) with az vm show -g az104-identity-rg -n identity-vm --query powerState.
  • The Network Security Group created with the VM allows SSH (port 22) by default. If you modified it, ensure port 22 is open.

Help me troubleshoot my SSH connection to the Azure VM.

Install Azure CLI and authenticate with the managed identity

The VM is a fresh Ubuntu machine with no Azure tools installed. You need the Azure CLI inside the VM so it can talk to Key Vault. The critical difference here is how you authenticate. Instead of az login with a username and password, you will use az login --identity to authenticate through the managed identity.

  • Install Azure CLI on the VM by running this command:
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

What does this command do?

This downloads and runs Microsoft's official install script for Ubuntu/Debian. It adds the Microsoft package repository, imports the signing key, and installs the azure-cli package in one step.

The installation takes 1-2 minutes. Wait for it to finish before continuing.

  • Verify the installation succeeded by running:
az version

You should see a JSON object showing the installed Azure CLI version.

  • Authenticate using the VM's managed identity by running:
az login --identity

Why no username or password?

When you run az login --identity, the CLI contacts the Azure Instance Metadata Service (IMDS) running at http://169.254.169.254 on the VM. IMDS issues a token for the VM's managed identity without any credentials.

This is the core pattern that eliminates hard-coded secrets. The identity is verified by Azure's infrastructure itself, not by a password the VM stores.

You should see JSON output containing your subscription details, confirming the managed identity authenticated successfully.

Seeing a managed identity error?

  • If you see a message about the identity not being found, wait 1-2 minutes. RBAC role assignments can take a short time to propagate.
  • Confirm the VM's managed identity is enabled by running az vm identity show --name identity-vm --resource-group az104-identity-rg from your local terminal.

Help me fix the managed identity authentication error on my Azure VM.

Retrieve the secret from Key Vault

This is the moment of truth. The managed identity is authenticated, and the RBAC role assignment grants it the "Key Vault Secrets User" role. You can now retrieve the secret without any credentials in the command.

  • Retrieve your secret from Key Vault by running this command (replace the vault name with your Key Vault's name):
az keyvault secret show --name "MySecret" --vault-name [[VAULT_NAME="your Key Vault name"]] --query "value"

What does this command do?

This asks Key Vault to return the value of MySecret. The --query "value" flag filters the output to show only the secret's value instead of the full JSON response.

Behind the scenes, the Azure CLI uses the token it obtained from az login --identity to authorize the request. Key Vault checks the RBAC role assignment and confirms the VM's identity has permission to read the secret.

You should see your secret value printed in the terminal. This proves the entire identity chain works. The VM authenticated to Azure, Azure verified its identity, and Key Vault authorized the read based on the role assignment.

Getting a forbidden error?

  • RBAC role assignments can take up to 10 minutes to propagate. Wait a few minutes and try again.
  • Verify the role assignment is scoped to your Key Vault (not the resource group or subscription) by running az role assignment list from your local terminal.
  • Double-check the vault name matches exactly. Key Vault names are case-insensitive but must be correct.

Help me fix the forbidden error when accessing Key Vault from my Azure VM.

You just proved that a VM can securely access secrets without storing any credentials. This is the foundation of secure identity management in Azure. Next up, the Secret Mission challenges you to extend this pattern with a second type of managed identity.

Secret mission

Add a User-Assigned Managed Identity

You proved that a system-assigned managed identity can fetch secrets without credentials. Now take it further. Create a user-assigned managed identity, attach it to the same VM, and prove that each identity operates within its own permission boundary.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

The B1s VM is covered under the Azure free tier (750 hours/month for 12 months). Key Vault has no cost while idle. If you exceed the free tier or your 30-day $200 credit expires, charges will apply.

Cost warning

The B1s VM consumes free-tier hours while running. If you leave it running past 750 hours in a month or beyond your 12-month free period, it will start consuming your $200 credit.

If you are not actively using the VM, choose Pause or Delete below to avoid unexpected charges.

Resources you used:

  • Resource group (az104-identity-rg).
  • Azure Key Vault with two stored secrets (MySecret and SecondSecret).
  • Linux VM (identity-vm, B1s size).
  • Associated networking resources (virtual network, network security group, public IP address, OS disk).
  • System-assigned and user-assigned managed identities (no cost).
  • RBAC role assignments (no cost).

Keep everything running

No action needed. Choose this if you are still actively studying or plan to experiment with the VM and Key Vault soon.

  • The B1s VM is free for 750 hours/month (roughly one full month of uptime). Key Vault has no charge while idle.
  • Managed identities and RBAC role assignments have no associated cost.
  • If you still have an active SSH session, you can type exit to close it when you are done.

Pause - I'll come back to this later

Shut down the VM to stop compute charges while keeping all resources intact for later use.

  • If you are still inside the VM via SSH, type exit to return to your local terminal.
  • Deallocate the VM by running this command:
az vm deallocate --resource-group az104-identity-rg --name identity-vm
  • Deallocating stops compute charges entirely. Storage charges for the OS disk still apply but are minimal.
  • Your Key Vault, secrets, managed identities, and role assignments remain intact at no cost.
  • To resume later, run az vm start --resource-group az104-identity-rg --name identity-vm.

Delete - I don't want to use this again

Remove all project resources permanently. This action cannot be undone.

  • If you are still inside the VM via SSH, type exit to return to your local terminal.
  • Delete the entire resource group and everything inside it by running:
az group delete --name az104-identity-rg --yes --no-wait
  • The --yes flag skips the confirmation prompt.
  • The --no-wait flag returns immediately while Azure continues deleting in the background.
  • This permanently removes the resource group, Key Vault, VM, networking resources, managed identities, and all role assignments.

What about Azure CLI on my local machine?

Azure CLI remains installed locally via Homebrew. If you want to remove it, run:

brew uninstall azure-cli

This is optional. Keeping it installed is useful if you plan to do more Azure projects.

Nice Work!

Nice Work!

You just built a production-ready identity architecture on Azure. Your Linux VM now authenticates to Key Vault using only its managed identity. No passwords, no API keys, no certificates stored anywhere in your code or configuration.

You've learned how to:

  • Deploy an Azure Key Vault with RBAC authorization and store secrets securely.
  • Provision a Linux VM with a system-assigned managed identity and configure least-privilege RBAC role assignments.
  • Retrieve a secret from within the VM using only its managed identity for credential-free authentication.
  • Secret Mission: Created a user-assigned managed identity, attached it to the VM, and proved identity-level permission isolation.

Ready to quiz yourself?