Azure • Governance & Compliance • End-to-End Automation

Cloud Policy Compliance Dashboard

An end-to-end Azure governance solution that defines policies as code, groups them into initiatives, assigns them at subscription level, detects policy DENY events in real-time, and visualises violations in an Azure Monitor Workbook – all deployed automatically using Bicep and a GitHub Actions CI/CD pipeline.

Phase 1–2: Policy & Initiatives Phase 3: Alerts & KQL Phase 4: Bicep Automation Phase 5: GitHub CI/CD

View project on GitHub

Scope

Subscription-level governance baseline

Policy Coverage

Public network access auditing

Alerting

Policy-based DENY activity

Deployment

Bicep + GitHub Actions

Designed to model how an Azure platform team can roll out a governance baseline, detect risky changes, and keep visibility through a single compliance dashboard – with everything version-controlled.

Azure Policy Policy Initiatives Log Analytics Azure Monitor Alerts Workbooks Bicep GitHub Actions

Context

Problem & Outcome

As cloud estates grow, it becomes hard to answer simple questions like: “Which resources still allow public network access?” or “Where are our policies actually denying traffic?”. The portal shows individual policy assignments, but not an end-to-end story.

I built the Cloud Policy Compliance Dashboard to demonstrate a full governance flow:

Define a custom Azure Policy that audits public network access.
Group the policy into a reusable initiative and assign it at subscription scope.
Capture policy-driven DENY activity into Log Analytics using AzureActivity.
Create an Azure Monitor alert that fires when policy DENY events occur.
Build a Workbook dashboard that visualises violations over time and by resource group/caller.
Automate everything with Bicep modules and a GitHub Actions pipeline.

From Phase 1 to Phase 5, the project moves from manual clicks in the portal to a fully automated, repeatable governance baseline that can be re-deployed to any subscription.

Governance core resource group with policy, alert and workbook resources

Final state: a governance resource group containing the Log Analytics workspace, alert rules, action group, and Cloud Policy Compliance Workbook – all created via Bicep.

rg-governance-core law-governance Policy-Deny-Activity-Detection Cloud Policy Compliance Dashboard

Phase 1 & 2

Policy Definition, Initiative & Assignment as Code

Phase 1 – Custom Policy: Audit Public Network Access

The foundation is a custom policy stored in policies/policy.bicep. It inspects the networking configuration of storage accounts and audits those where public network access is still allowed:

Type: Custom policy.
Category: Network.
Rule: if Microsoft.Storage/storageAccounts/networkAcls. defaultAction == 'Allow' then effect = 'audit'.

The policy is deployed at subscription scope and its ID is passed to the next phase as output.

Phase 2 – Initiative & Subscription Assignment

Next, the policy is wrapped into an initiative (policies/initiative.bicep) so it can be extended later with additional governance rules. An assignment module (assignments/assignment.bicep) applies this initiative at the subscription scope with a friendly display name Cloud-Governance-Baseline-Sub.

All three resources – policy, initiative, and assignment – are wired together in main.bicep using modules, giving a clear, reusable pattern for adding more policies later.

Policy compliance blade showing Audit Public Network Access initiative compliant

After deployment, the Audit-Public-Network-Access-Assignment initiative shows as compliant once public network access is disabled on the affected resources.

Custom Policy Policy Initiative Subscription Assignment

Phase 3

Detecting Policy DENY Activity with KQL & Alerts

Log Analytics Query

To detect enforcement in action, the project uses the AzureActivity table in a Log Analytics workspace called law-governance. A KQL query filters for policy operations where the result was a failure:

AzureActivity
| where CategoryValue == "Policy"
| where ActivityStatusValue == "Failure"
| where OperationNameValue contains "DENY"
| order by TimeGenerated desc

This query shows each DENY event, including the caller, resource group, and subscription. For the alert we summarise the count of events within a time window.

Alert Rule: Policy-Deny-Activity-Detection

A metric alert called Policy-Deny-Activity-Detection is deployed via Bicep. It fires when the count of policy DENY events is greater than zero in the last 10 minutes:

Signal: custom metric based on the KQL aggregation.
Frequency: evaluated every 5 minutes.
Threshold: 0, Operator: GreaterThan.
Action group: policy-alerts (email + push notification).

Email notification for Policy-Deny-Activity-Detection alert

Mobile email notification showing the Policy-Deny-Activity-Detection alert firing when a policy DENY was logged in AzureActivity.

Azure Monitor alert blade showing policy deny detection

Azure Monitor alert details: why the alert fired, the affected resource, and direct links into Logs for investigation.

Phase 4

Full Environment as Bicep Modules

Modular Bicep Design

The project is structured as a set of small, focused Bicep files:

policies/policy.bicep – custom policy definition.
policies/initiative.bicep – initiative that groups the policy.
assignments/assignment.bicep – subscription-level assignment.
alerts/policy-deny-alert.bicep – metric alert tied to Log Analytics and the action group.
workbooks/policy-dashboard.bicep – deployment of the Cloud Policy Compliance Workbook from JSON.
main.bicep – orchestration file wiring all modules together.

Parameters keep the module reusable – for example workspace name, resource group, subscription ID and action group name. The alert module only needs the workspace resource ID and action group ID to plug into any environment.

Running az deployment sub create with main.bicep provisions: the policy, initiative, assignment, Log Analytics alert, and the Workbook – all in one deployment.

VS Code showing main.bicep wiring modules for policy, initiative, assignment and alerts

main.bicep orchestrates the policy, initiative, assignment, alert and workbook modules – giving a single entry point for the entire governance baseline.

Modular Bicep Subscription Deployment Idempotent Infrastructure

Phase 4 (Workbook)

Cloud Policy Compliance Workbook

Visualising Non-Compliance

The Workbook turns raw AzureActivity entries into an opinionated dashboard. I built it directly in the portal using several queries and then exported the JSON, which is now deployed with Bicep.

Donut chart – count of policy DENY events by caller.
Bar chart – number of DENY events per resource group.
Line chart – DENY events per hour over time.
Table – detailed log of individual DENY operations, with caller and subscription.

Cloud Policy Compliance Workbook summarising policy deny events

Workbook view showing donut + table of policy DENY events for the Cloud Policy Compliance Dashboard.

Workbook bar and line charts for policy deny events over time and by resource group

Additional workbook visuals – bar chart by resource group and line chart of deny events over time – deployed automatically from the exported JSON.

Phase 5

GitHub Actions CI/CD for Cloud Governance

Workflow Overview

The final phase moves everything into a proper CI/CD pipeline using GitHub Actions and OpenID Connect (OIDC) to log in to Azure without secrets.

Trigger: on push or PR to the main branch.
Setup: check out the repo, install the Azure CLI and Bicep CLI.
Build: run bicep build main.bicep to validate syntax.
What-if: optional az deployment sub what-if to preview changes.
Deploy: az deployment sub create targeting the cloud-governance-baseline subscription deployment.

This guarantees that every governance change is: version-controlled, validated before deployment, and repeatable across environments.

GitHub Actions workflow running Bicep build and Azure deployment

GitHub Actions pipeline stages: build Bicep, (optional) what-if, and deploy the Cloud Governance Baseline to the subscription.

OIDC Authentication Bicep Build Subscription Deployment GitOps for Governance

Reflection

What I Learned

This project took a single governance requirement – “audit and visualise public network access and policy DENY events” – and pushed it through the full lifecycle: design, policy as code, monitoring, visualisation, and automation.

How to design a policy / initiative / assignment strategy at subscription scope.
How policy evaluations and DENY actions surface in AzureActivity and how to query them with KQL.
How to use Azure Monitor alerts and action groups to turn log events into real notifications.
How to structure Bicep modules to keep policy, alerts, and workbooks reusable and composable.
How to wire Bicep into GitHub Actions with OIDC for secure, repeatable deployments.

This Cloud Policy Compliance Dashboard is now a reusable pattern I can extend with more policies, more dashboards, and additional environments – and a strong example of governance automation for an Azure Cloud Engineer role.