The Azure Well-Architected Operational Excellence Pillar: What Most Teams Skip
The Azure Well-Architected operational excellence pillar exposes manual changes outside IaC, no documented deployment process, and defaults-only monitoring. For platform leads.
Marc Dekeyser |
The Azure Well-Architected Operational Excellence Pillar: What Most Teams Skip
The Azure Well-Architected operational excellence pillar measures whether you can change a system safely and know what happened when you did. The finding that appears in nearly every assessment is the gap between the parts of the environment defined in code and the parts that exist only because someone clicked through the portal — a gap that no diagram shows and no one can fully account for.
Operational excellence is the pillar teams skip because it has no incident attached to it. Security has breaches. Reliability has outages. Cost has a bill. Operational excellence has none of those forcing functions, so the practices that make a system operable — infrastructure as code, safe deployment, real observability, written runbooks — get deferred until something goes wrong and the absence becomes expensive at once.
Key takeaways
- Manual changes made outside infrastructure as code are the most common operational excellence finding. They create drift the code cannot describe and the next deployment may silently revert or collide with.
- “We use Bicep” rarely means the whole estate is in Bicep. The assessment finds the resources that were created in the portal and never brought under code.
- Most environments have monitoring deployed but configured at defaults — Azure Monitor collecting platform metrics, no custom alerts, no actionable thresholds, no one owning the signal.
- Deployment processes are frequently undocumented. The person who knows how to ship is the process, which is a single point of failure with a pulse.
- Operational excellence evidence maps to NIS2 Article 21(2)(f) — policies to assess the effectiveness of risk-management measures. You cannot assess effectiveness you do not measure.
What do the operational excellence design principles require?
The Azure Well-Architected operational excellence pillar requires that operations are deliberate, repeatable, and observable rather than improvised — that you can answer “how does a change reach production?” and “how would we know it broke?” with a process, not a person. The Microsoft Azure Well-Architected Framework expresses this through a set of design principles that each map to a concrete operational artifact.
Adopt infrastructure as code: the environment is defined in version-controlled templates, not assembled by hand. Use safe deployment practices: changes roll out progressively with the ability to halt and roll back. Implement observability: collect the signals that tell you the system is healthy and act on them. Automate and document operations: the knowledge lives in runbooks and code, not in heads.
The findings come from the distance between these principles and how environments actually evolve — incrementally, under delivery pressure, with the portal always one click away when the template would have taken longer.
Why do manual changes outside IaC matter so much?
Manual changes outside infrastructure as code matter because they create a version of the truth that the code does not know about, and the next deployment has to either ignore it or fight it. This is the operational equivalent of configuration drift, and it is the finding that appears most consistently.
Here is how it happens. The estate is defined in Bicep or Terraform — mostly. A production incident hits at an inconvenient hour. An engineer opens the portal and changes a network security group rule, scales up a database, or adds an app setting to resolve it. The incident is fixed. The change is never reflected back in the code. Now the running environment and the source of truth disagree, and nobody has written down where.
The consequences compound. The next terraform apply may revert the emergency fix, reintroducing the incident. Or the drift sits undetected until a region rebuild or a disaster recovery event redeploys from code that no longer matches reality. The assessment surfaces this by comparing the deployed configuration in Azure Resource Graph against what the IaC would produce — the resources with no corresponding template, and the settings that diverge from what the code declares.
The deeper finding is usually that no policy prevents portal changes in the first place. Azure Policy can deny resource modification outside the deployment identity. When it is absent, the portal is an open door and drift is inevitable.
What does “defaults-only monitoring” actually look like?
Defaults-only monitoring looks like a dashboard full of green that tells you nothing, because Azure Monitor is collecting platform metrics nobody chose and firing no alerts anyone would act on. This is the observability finding, and it is more common than no monitoring at all — because the absence of monitoring is obvious, while the presence of useless monitoring passes inspection.
The components are usually deployed. Azure Monitor is on. A Log Analytics workspace exists. Application Insights is instrumented. What is missing is the configuration that turns telemetry into operational awareness.
The specific gaps:
No diagnostic settings on critical resources. Azure Monitor collects platform-level metrics automatically, but resource logs — what a Key Vault, an Application Gateway, or a firewall is actually doing — require diagnostic settings configured to stream to the Log Analytics workspace. The assessment finds critical resources with no diagnostic settings, which means the data that would explain an incident was never collected.
No actionable alert rules. Metrics are gathered; no alert rules are defined against them. There is no rule that fires when latency exceeds the budget, when the failed-request rate climbs, or when a dependency starts timing out. The signal exists. Nothing watches it.
No action groups or ownership. Even where an alert exists, it routes nowhere — no action group, no on-call rotation, no escalation. An alert that fires into an empty inbox is theatre.
Application Insights at defaults. Instrumented but with no custom availability tests, no defined health signal, no distributed tracing for the dependencies that actually fail — the same observability gap the reliability pillar surfaces from the health-modelling angle.
Where are the deployment process and runbooks?
The deployment process and the runbooks are, in most assessed environments, undocumented — they live in the working memory of one or two engineers, which makes those engineers a single point of failure. Operational excellence asks a plain question: if the person who deploys is unavailable, can someone else ship a change and recover from a failure? The honest answer is frequently no.
A documented deployment process states how a change moves from commit to production: the pipeline stages, the gates, the approval, the rollback procedure. Safe deployment practices add progressive exposure — deployment slots in App Service for staged swaps, canary or ring-based rollout, automated rollback on failure. The common finding is a pipeline that deploys straight to production with no staging gate and no rollback beyond “redeploy the last good version and hope.”
Runbooks are the recovery counterpart: the documented, step-by-step response to anticipated failures — the database failover, the certificate rotation, the dependency outage. Architecture Decision Records sit alongside them, capturing why the environment is built the way it is. Both are routinely absent, which means the architecture documentation describes a system that no longer exists and the recovery knowledge evaporates the moment the person holding it leaves.
| Design principle | Finding in nearly every assessment | The artifact that should exist |
|---|---|---|
| Adopt infrastructure as code | Resources created in the portal, not in code | Full estate in version-controlled Bicep/Terraform |
| Use safe deployment practices | Direct-to-production pipeline, no rollback | Staged deployment with automated rollback |
| Implement observability | Diagnostic settings absent on critical resources | Resource logs streaming to Log Analytics |
| Implement observability | Metrics collected, no alert rules | Actionable alerts routed to an action group |
| Document operations | Deployment and recovery knowledge in one person’s head | Runbooks and ADRs in version control |
How does operational excellence map to NIS2 effectiveness assessment?
Operational excellence maps to NIS2 Article 21(2)(f) because that article requires policies to assess the effectiveness of cybersecurity risk-management measures — and you cannot assess the effectiveness of what you do not observe. The operational excellence pillar is, in regulatory terms, the measurement layer.
The connection is concrete. Article 21(2)(f) is not asking whether you have controls. It is asking whether you know they work. That requires telemetry — diagnostic logs streaming to a workspace, alerts that fire when a control degrades, a deployment process that records what changed and when. An environment with defaults-only monitoring cannot demonstrate effectiveness, because it is not measuring it. The diagnostic settings, the alert history, the deployment audit trail — these are the evidence that the effectiveness assessment exists in fact, not just on paper. Operational excellence is the apparatus that lets you prove the rest of your posture is real.
What evidence does an operationally excellent environment produce?
An operationally excellent environment produces evidence by construction: a version-controlled IaC repository that matches the running estate, a deployment pipeline with an audit trail, diagnostic settings on every critical resource, alert rules with a firing history, and runbooks in source control. This material is what an NIS2 auditor accepts as proof that risk-management measures are assessed for effectiveness rather than assumed to work.
The defining property is that none of it is assembled for the audit. The IaC repository exists because the team deploys from code. The deployment audit trail exists because the pipeline records every run. The diagnostic logs exist because observability was configured deliberately. A well-operated environment generates its own evidence as exhaust — which is why the absence of that exhaust is itself the finding.
Platform Architecture Authority reads the running estate through Azure Resource Graph, surfaces the operational excellence gaps — the resources outside IaC, the missing diagnostic settings, the unconfigured alerting — and maps each to the NIS2 article it touches. It generates the remediation as infrastructure-as-code and policy definitions you review and apply. It is read-only; it does not deploy anything itself. A senior platform engineer still decides which alerts genuinely warrant a page and which runbooks the team needs; the platform surfaces the gaps so that judgment is exercised against the real configuration, not a remembered one.
FAQ
What counts as infrastructure as code for the operational excellence pillar? A version-controlled definition of the environment — Bicep or Terraform — that can recreate the resources deterministically. The pillar checks not just that IaC exists but that it matches the running estate. Resources created manually in the portal, with no corresponding template, are the gap the assessment surfaces as drift.
Is Azure Monitor enough for observability? Azure Monitor is the platform, but at defaults it only collects baseline metrics. Real observability requires diagnostic settings streaming resource logs to a Log Analytics workspace, alert rules defined against meaningful thresholds, action groups routing those alerts to an owner, and Application Insights configured with health signals. The platform is necessary; the configuration is what makes it useful.
What is the fastest operational excellence improvement to make? Configuring diagnostic settings on critical resources — Key Vault, firewall, Application Gateway, gateways — to stream to a Log Analytics workspace. It is low-effort, it closes the most common observability gap, and it produces the telemetry that both incident response and NIS2 effectiveness assessment depend on. Alerting on that telemetry is the immediate next step.
Operational excellence is the pillar without a crisis to force it, which is exactly why it is the one most worth doing before the crisis arrives to ask why nobody could see it coming.
