Identity & Governance

Simulated enterprise user onboarding by provisioning four Entra ID accounts across three security groups, assigning built-in roles at resource group scope using the principle of least privilege, and creating a custom role definition for a Storage Blob Reader Plus permission set that didn't exist in the built-in catalog. Verified the assignments by signing in as each test user and confirming the access boundaries held. Enabled MFA on all accounts and reviewed Entra ID sign-in audit logs.

• Groups, not individual users — Role assignments are on security groups, not individual accounts. Adding a new developer means adding them to grp-developers — no new role assignments required. This is the correct enterprise pattern: manage group membership, not role assignments, as the team evolves.
• Resource group scope, not subscription — Assignments scoped to rg-phase1-lab only. Scoping to subscription would give grp-developers Contributor access to every resource in the subscription — a significant blast radius for a lab. Narrowest scope that satisfies the requirement.
• Custom role for gaps in built-in catalog — No built-in role provided exactly Storage Blob read access without additional permissions. Rather than assigning a broader role than necessary, a custom role was created with exactly the required action. This is the least-privilege approach applied at the permission level.
• Test every assignment before declaring done — Signed in as each test user in a private browser session and verified access boundaries. A role assignment that hasn't been tested is an assumption, not a control.

Built a governance baseline using Azure Policy — three policies bundled into an initiative, deployed with Deny effect to prevent out-of-region resources and enforce required tags, and Audit effect for non-destructive compliance reporting. Verified the controls by deliberately triggering the location policy denial and the resource lock block, capturing both as evidence. Configured budget alerts at 80% actual and 100% forecast to prevent cost overruns. The governance pattern established here was extended in Phase 4: the lab resource group carried 10 active policy assignments throughout all subsequent projects.

• Audit before Deny for new policies — The managed-disk audit policy was intentionally set to Audit rather than Deny. Switching an existing environment to Deny without first understanding the compliance state causes unexpected deployment failures. Audit → review → Deny is the production-safe rollout sequence.
• Initiatives over standalone assignments — Even with three policies, bundling into an initiative made compliance reporting cleaner and assignment to new scopes a single action. Always start with an initiative — standalone assignments don't scale beyond a handful of policies.
• Tag inheritance via policy, not manual tagging — Tags on the resource group propagate automatically to all resources via inherit-tag-* policy assignments. Manual tagging is inconsistent and breaks. Policy-enforced inheritance is the only reliable approach at scale.
• Policy definition IDs — never hardcode — Policy definition GUIDs change between CLI versions. Always query: az policy definition list --query "[?displayName=='Allowed locations'].name" -o tsv. One character difference caused significant debugging time.
• Forecast alert over actual spend alert — A 100% actual spend alert tells you money has already been spent. A 100% forecast alert fires before you hit the limit and leaves time to react. In production the forecast alert is the one that matters.

{
  "name": "initiative-baseline-governance",
  "properties": {
    "displayName": "Baseline Governance Initiative",
    "description": "Location, tagging, and disk compliance",
    "policyDefinitions": [
      {
        "policyDefinitionId": "/providers/Microsoft.Authorization/
  policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4f",
        "parameters": {
          "listOfAllowedLocations": {
            "value": ["westus3"]
          }
        }
      },
      {
        "policyDefinitionId": "/providers/Microsoft.Authorization/
  policyDefinitions/96670d01-0a4d-4649-9c89-2d3abc0a5025",
        "parameters": {
          "tagName": { "value": "environment" }
        }
      },
      {
        "policyDefinitionId": "/providers/Microsoft.Authorization/
  policyDefinitions/06a78e20-9358-41c9-923c-fb736d382a4d"
      }
    ]
  }
}

Policy denial — location blocked

Policy — location assignment

Delete lock — deletion blocked