Azure governance · Policy · RBAC · Bicep

Azure Governance Automation Lab

A safe-by-default, subscription-scoped governance baseline that turns policy, access, cost visibility, and deletion protection into inspectable infrastructure code and guarded operations.

View GitHub Review evidence status

AuthoredModular Bicep, dual-shell lifecycle scripts, tests, diagram, and runbooks

Locally + CI validatedBicep lint/build, parameter compile, static analysis, and offline failure guards

Evidence pendingAuthenticated ARM validation, what-if, deployment, runtime, teardown, and cost

01 · Scenario

Govern one lab subscription before adding workloads

The scenario is a personally owned Azure subscription that needs consistent organization, ownership tags, location controls, visible cost thresholds, bounded read access, and protection from accidental deletion. The implementation avoids pretending that one lab subscription is an enterprise landing zone.

Express subscription governance as repeatable, reviewable Bicep.
Start with audit or disabled effects before introducing writes or denial.
Separate offline CI from privileged Azure validation and deployment.
Design the lab for use only in a verified, personally owned subscription.
Make cleanup exact, ownership-aware, and fail closed.

02 · Architecture

One orchestration layer, deliberately bounded controls

The optimized SVG has a companion editable Mermaid model in the technical repository and reflects the current Bicep modules.

Engineer and offline CI feeding a subscription governance deployment with Azure Policy, a budget and action group, optional bounded RBAC, and a locked governance resource group — Tag inheritance, its managed identity, and remediation are disabled by default. The GitHub OIDC path is documented design, not a deployed identity.

Subscription controls

Three authored policy definitions form an initiative for required resource-group tags, allowed locations, and optional inheritance of missing tags.

Governance resource group

A tagged group contains the action group, an optional group Reader assignment, and a default CanNotDelete lock.

Cost visibility

A monthly subscription budget links actual and forecast thresholds to the action group. It warns; it does not cap or block spending.

03 · Controls and access

Conservative defaults for a broad scope

Policy rollout

Required tags and allowed locations default to Audit. Moving to Deny requires compliance review, service-location checks, exemptions, and rollback planning.

Conditional write access

Tag inheritance defaults to Disabled. Opting into Modify conditionally creates the assignment identity and grants only built-in Tag Contributor at assignment scope.

Bounded human access

The optional reviewer assignment accepts an explicit Microsoft Entra group object ID and grants built-in Reader only on the governance resource group.

Deployment identity design

The documented OIDC model uses protected GitHub environments and short-lived tokens. The published lab contains no federated credential, tenant identifier, or Azure-authenticated workflow evidence.

04 · Automation

Modular Bicep with Bash and PowerShell parity

The subscription entry point composes focused modules. Bash and PowerShell commands verify the active subscription without switching context, perform local checks, require authenticated validation and a complete what-if before deployment confirmation, and consume an exact cleanup manifest.

infra/
├── main.bicep
├── environments/lab.example.bicepparam
└── modules/
    ├── policy-governance.bicep
    ├── subscription-budget.bicep
    ├── notification-group.bicep
    ├── resource-group-access.bicep
    └── resource-group-lock.bicep

scripts/
├── validate + what-if + deploy
└── ownership-checked cleanup

05 · Evidence matrix

What is proven, and what still needs Azure

Capability	Authored	Locally validated	CI validated	Azure / runtime evidence
Subscription-scope Bicep and parameters	Yes	Passed	Passed	ARM validation and what-if pending
Policy, initiative, identity, and RBAC design	Yes	Passed	Passed	Evaluation and access tests pending
Budget, action group, and lock	Yes	Passed	Passed	Notification and lock behavior pending
Deployment and cleanup guards	Yes	Offline guards passed	Passed	Live deployment and teardown pending
Cost result	Guardrails documented	Documentation reviewed	Passed	Billing evidence pending

Read the complete validation plan

06 · Cost, cleanup, and limitations

Designed for a zero-workload lab—not a zero-cost guarantee

Cost boundary

No VM, gateway, database, cluster, storage account, or ingestion workload is created. Subscription offer, notification type and volume, unrelated resources, and pricing still require review; no 0 EGP result is claimed.

Cleanup

Both scripts validate the exact manifest, inventory resource-group resources, descendant locks and role assignments, and deployment records before mutation. They explicitly delete the action group, repeat empty-state and ownership checks before resource-group deletion, then remove deterministic subscription deployment records; live teardown remains untested.

Rollback boundary

Removing remediation does not undo tags already written. After Modify has been disabled, guarded cleanup is required before re-enabling it because Azure can recreate the assignment's system identity with a different principal.

Production gaps

Management groups, landing-zone subscriptions, policy exemptions, identity lifecycle, PIM, centralized logging, networking, Defender plans, and enterprise separation of duties are outside this lab.

07 · Primary references

Design grounded in current platform guidance

Technical source of truth

Inspect the complete governance implementation

The repository contains the Bicep modules, safe example parameters, architecture source, dual-shell lifecycle commands, failure-guard tests, threat and access models, deployment and cleanup runbooks, and evidence template.

Open governance repository Back to catalogue