Northwind: Proving Least Privilege to an External Auditor
Northwind has 30 Azure Pipelines service connections, 12 of them with subscription-level Contributor. Three personal access tokens with full scope back the release process, and SQL and storage credentials sit as plaintext secret variables in two variable groups. Two people left the company and their access was removed 11 and 26 days later. An external auditor asks three questions: who approved each production deployment, how secrets are rotated against a 90-day policy, and what evidence shows developers are not touching production databases directly. The team is 24 engineers; production is in West Europe for data residency. Nobody can currently answer which pipeline used a given credential.
1. Rank the top risks and sequence remediation. Justify the ordering.
Read the worked answer
Rank by blast radius multiplied by detectability - what is worst if misused, and how little would you see.
- Plaintext SQL and storage credentials in variable groups. Direct data access, no attribution, and the value is already in logs and history. Rotate now, move to Key Vault, link the variable group, then purge or expire exposed values and check historical run logs.
- Twelve subscription-level Contributor connections. One compromised pipeline can delete or exfiltrate anything in the subscription. Reduce to resource-group scope, split per environment.
- Full-scope PATs with no expiry and no owner - cannot be attributed or revoked safely.
- Leaver access at 11 and 26 days - a process defect, fixed with Entra ID groups and access reviews rather than pipeline work.
Sequence matters: rotate live secrets before the multi-week identity refactor, otherwise you spend three weeks designing least privilege while the exposed credential stays valid. Do the scope reduction second because it is the next largest blast radius and can proceed in parallel.
2. Replace the PATs and subscription-Contributor service connections with a least-privilege identity design. What breaks, and how do you migrate safely?
Read the worked answer
Target state: one identity per environment. Use a user-assigned managed identity or workload identity federation on the service connection, granted only the roles that environment's deployment needs on that environment's resource group. No stored secret anywhere. For non-Azure endpoints, prefer federation where supported; otherwise a scoped credential in Key Vault with expiry, never a full-scope PAT.
What breaks: scripts that assume Contributor on the subscription - resource group creation, role assignment changes, policy edits. Give those a dedicated identity with an explicit narrow role rather than widening the deploy identity. Also expect federated credential subject mismatches; pin the subject to the environment or branch and test it in non-production first.
Migration: create new connections alongside old ones, switch via a pipeline variable behind a feature flag, run non-production, then production as a canary. Disable rather than delete the old connection for one release as rollback. Keep an inventory mapping connection to identity to role, and review it quarterly - the current nobody knows which pipeline used this credential is the gap that lets over-privilege persist.
3. Produce the auditor's evidence automatically rather than through screenshot collection. What do you capture, and what are the limits?
Read the worked answer
Evidence should come from systems of record, not people.
- Approvals and deployments: export Environment approval history and deployment audit events on a schedule, joined to artifact ID and commit, into immutable storage. This answers who approved what, and against which build.
- Rotation: set expiry on every Key Vault secret and alert ahead of 90 days; report the count of secrets inside policy directly from Key Vault rather than attesting manually.
- Database access: prove it at the database layer, not from pipeline logs - Entra ID-only authentication, no standing local admin for developers, just-in-time elevation logged. You cannot prove a negative from build logs.
Generate a monthly workbook automatically; a manual deck fails the second audit on repeatability.
Limits and tradeoffs: agree retention with the auditor up front (for example 12 months) instead of storing everything; log export and immutability cost money; and data residency means audit exports containing identifiers must stay in West Europe. Automation that nobody verifies is worse than manual review - add a monthly check that the export ran and row counts look sane.