Identity, Security & Configuration

Question 7. What is a Managed Identity, how does it differ from a Service Principal, and when do you use system-assigned vs user-assigned?

Answer

A Service Principal is an identity for an app in Microsoft Entra ID, typically authenticated with a client secret or certificate that you must create, store, and rotate. A Managed Identity is a special service principal whose credentials are created and rotated by Azure and never exposed to you — eliminating secrets in code and config.

System-assigned identity is tied 1:1 to a single resource and deleted with it — ideal for a resource that needs its own identity. User-assigned identity is a standalone resource you can attach to many services and that survives them — ideal when several apps share one identity or you want the identity (and its role assignments) to outlive a redeploy.

Example

With DefaultAzureCredential, the same code uses your developer login locally and the Managed Identity in Azure — no secrets, no branching:

var cred = new DefaultAzureCredential();
var client = new BlobServiceClient(
 new Uri("https://acct.blob.core.windows.net"), cred);
// Locally -> az login / VS credential.
// In Azure -> the app's managed identity. Same code.

Analogy

A service principal is a password you have to keep safe and change regularly; a managed identity is a building keycard the facilities team issues, rotates, and revokes for you — you just tap in.

Question 8. Explain Azure RBAC: roles, scope, and assignments.

Answer

RBAC authorization is the triple (security principal, role definition, scope). The principal is a user, group, service principal, or managed identity. The role definition is a set of allowed actions (e.g. Storage Blob Data Reader). The scope is where it applies — management group, subscription, resource group, or a single resource.

Assignments inherit downward: granting a role at the resource-group level applies to every resource inside it. Follow least privilege — prefer fine-grained data-plane roles (Storage Blob Data Contributor) over broad control-plane roles like Owner, and assign at the narrowest scope that works.

Analogy

It's who gets which keys to which doors. A master key (Owner) opens everything in the building; a data-plane role is a key to one specific room. Give people the smallest keyring that does the job.

Question 9. How do you use Azure Key Vault from a .NET app, and what are soft-delete and purge protection?

Answer

Key Vault centrally stores secrets, keys, and certificates behind RBAC/access policies and full audit logging. A .NET app authenticates with a managed identity (no bootstrap secret) and either reads secrets via SecretClient or — better — has Key Vault references injected through App Configuration or app settings so the app never sees the vault directly.

Soft-delete retains deleted vaults/secrets for a recovery window (default on) so an accidental delete is reversible. Purge protection prevents even an admin from permanently purging during that window — protection against malicious or mistaken destruction. Enable both for production.

Example

var client = new SecretClient(
 new Uri("https://myvault.vault.azure.net"),
 new DefaultAzureCredential());
KeyVaultSecret secret = await client.GetSecretAsync("SqlConn");
string conn = secret.Value;

Analogy

Key Vault is a bank vault for secrets; soft-delete is the bank holding your safe-deposit box for 90 days after you 'close' it; purge protection means not even the manager can shred it early.

Question 10. Explain SAS tokens: account vs service vs user-delegation SAS, and the role of stored access policies.

Answer

A Shared Access Signature grants scoped, time-limited access to storage without sharing the account key. An account SAS can cover multiple services and is signed by the account key. A service SAS is scoped to one service (e.g. one container/blob), also signed by the account key. A user-delegation SAS is signed by an Entra ID credential instead of the account key — the most secure option because it ties access to an identity and is independently revocable.

A stored access policy decouples the SAS from its constraints: the policy (on the container) holds the permissions and expiry, and the SAS references it. This lets you revoke or change a SAS after issuing it — otherwise an ad-hoc SAS is valid until it expires and cannot be recalled.

Analogy

A SAS is a temporary guest pass. An account-key SAS is signed with the building master key; a user-delegation SAS is signed with your personal badge (revoke the badge, revoke the pass). A stored access policy is the front-desk rulebook you can edit to invalidate passes already handed out.

Question 11. How does Azure App Configuration differ from Key Vault, and how are they used together?

Answer

App Configuration is a centralized store for non-secret settings and feature flags, with labels (for per-environment values), point-in-time snapshots, and change notifications. Key Vault is for secrets. They complement each other: App Configuration holds the keys and can store Key Vault references so secret values stay in the vault while the app reads everything through one client. This gives you central config + feature management across many services and environments, while secrets remain protected and separately audited. Feature flags let you toggle behavior at runtime without redeploying.

Analogy

App Configuration is the settings menu for all your apps; Key Vault is the locked drawer for passwords. The settings menu can show a 'see locked drawer' pointer without copying the password out of the drawer.