After Lab 1.2 — Recap

Mitch Mommers18/05/2026About 2 min

In Lab 1.2, you tested the impact of the backend managed identity's permissions.

The goal was not only to prove that the identity had a powerful role.

The goal was to understand what that role allowed, and what it did not allow.

Expected result

You should have observed something like this:

Endpoint	Expected result	Meaning
`/api/impact-demo/tag-self`	Works	The backend can modify an Azure resource
`/api/secret-demo`	Fails	The backend cannot read the Key Vault secret

The backend identity has too much access in one area, but not the correct access in another area.

It can perform broad management actions because it has:

Contributor at resource group scope

But it cannot read the Key Vault secret because it does not have the correct Key Vault data-plane role.

This is a common cloud security problem:

The identity was given a powerful role,
but not the specific role it actually needed.

The fix is not to add even more broad access.

The fix is to remove unnecessary broad access and add the correct narrow access.

Screenshot suggestion

Add a side-by-side screenshot or two separate screenshots:

This makes the contrast clear:

The backend identity should not be able to manage the resource group.

But the backend may legitimately need to read a secret from Key Vault.

So the current model is both:

too broad
and
not specific enough

That is why permission design is not just about reducing access.

It is about matching access to the actual task.

In the next lab, you will improve the access model.

You will move from this:

Backend managed identity
+ Contributor
+ Resource group scope

toward this:

Backend managed identity
+ Key Vault Secrets User
+ Key Vault scope

The goal is to make the legitimate application flow work, while blocking the unnecessary risky action.