Microsoft AZ-305: Identity, Governance, and Monitoring

Microsoft AZ-305 architecture starts with the control plane that governs every workload: identity, authorization, resource organization, policy, monitoring, and operational ownership. A technically sound application can still become unmanageable when these foundations are designed as afterthoughts.

Microsoft AZ-305 remains current on October 6, 2026, using Microsoft’s April 17, 2026 blueprint. This article stays tightly focused on identity, governance, and monitoring so it complements the broader infrastructure, practical-exercise, requirements-to-decisions, and study-plan articles already in the cluster.

Translate organizational structure into control boundaries

Management groups, subscriptions, resource groups, and resource scopes should reflect governance and delegation requirements rather than mirror an organization chart mechanically. Given multiple business units and environments, decide where policy inheritance, cost ownership, administrative delegation, and workload isolation require separate boundaries.

The design should remain understandable when teams reorganize, because control scope should follow durable responsibilities.

Subscription design should also account for operational independence. Two workloads may share the same regulatory profile but still need separate subscriptions because different teams own deployment, incident response, cost, or change approval. Conversely, splitting every application into its own subscription can create unnecessary policy and networking overhead. The boundary should follow durable control needs rather than a one-resource-one-subscription habit.

Cost and governance signals should be connected. Tags, budgets, policy compliance, activity logs, and resource inventory can reveal abandoned or incorrectly placed resources before they create security or cost problems. The architect should decide which signals matter at management-group, subscription, and workload level and who is expected to act when those signals drift.

Governance boundaries should also be tested against platform growth. A startup with one subscription may later add regulated workloads, regional teams, or separate production environments. The original hierarchy should make it possible to introduce stronger policy or delegated administration without moving every resource. Designing for that evolution is more valuable than optimizing the hierarchy for the organization’s current size.

Management groups and subscriptions should be separated for durable reasons such as policy inheritance, administrative delegation, billing accountability, regulatory boundaries, or workload isolation. Copying the current org chart into Azure creates brittle boundaries because organizations change more often than governance requirements. A good design survives reorganization without forcing teams to rebuild the control plane.

Design identity around administrative tasks

Architecture should distinguish workforce users, administrators, applications, managed identities, external identities, and emergency access rather than apply one access model to all actors. For each actor, identify authentication assurance, authorization scope, credential lifecycle, monitoring, and recovery expectations.

The result reduces standing privilege and makes exceptional access explicit.

Privileged access needs recovery as well as restriction. Just-in-time administration, scoped roles, and approval reduce standing privilege, but the architecture also needs emergency access for identity or control-plane failure. Emergency accounts should be protected, monitored, tested, and excluded only where necessary so the recovery path does not become an ordinary bypass.

Identity design should distinguish human administrators, workload identities, emergency accounts, external identities, and automation. Those actors have different authentication, credential, privilege, and recovery needs. Privileged human access may require just-in-time elevation and review, while a managed identity may need a narrow resource role and no reusable secret at all.

Choose RBAC scope intentionally

A role assignment is an architectural decision about blast radius and delegation. Assigning at a broad scope may simplify administration while increasing risk and reducing separation of duties. List the actions a team actually needs, choose the narrowest durable scope, and evaluate whether built-in roles or a custom role are justified.

The design should also explain how access is reviewed and how inherited permission is diagnosed.

Use policy to enforce architectural intent

Azure Policy and resource governance can express allowed locations, required configuration, tagging, security requirements, and other organizational rules at scale. For each policy, decide whether the effect should audit, deny, modify, deploy, or exempt, and document how exceptions are approved and retired.

Policy is most useful when it prevents drift from a known architectural standard rather than acting as a collection of unrelated compliance rules.

Operational exceptions need visibility in the same dashboards as normal compliance. If a policy exemption, privileged assignment, or resource lock override exists, the architect should be able to see who approved it, which resources it affects, and when it should be reviewed. Hidden exceptions are one of the fastest ways for governance intent to diverge from the actual environment.

Protect resources from accidental and unauthorized change

Resource locks, privileged workflows, separation of duties, and deployment controls should match the consequence of change. Not every resource needs the same friction. Identify critical resources whose deletion or modification would cause disproportionate impact, then design controls that reduce accidental change without blocking legitimate operations.

Include an emergency and maintenance path so protection does not become an outage during recovery. Those five items make the protect resources from accidental and unauthorized change review more valuable than copied documentation because they explain how the decision operates.

Design monitoring before deployment

Azure Monitor and Log Analytics observability should be designed before workloads go live. Define which metrics, logs, traces, diagnostic settings, workspaces, retention periods, alerts, and action owners are required to show whether the service is healthy and whether the architecture is meeting its objectives.

Monitoring becomes architecture when it is tied to service objectives and operational decisions, not when every available log is collected.

Operational telemetry should include both configuration drift and user impact. A policy can remain technically assigned while a workload becomes unhealthy because of dependency failure, quota pressure, or application behavior. Define which logs and metrics prove the control plane is working, which signals belong to the workload, and who acts on each one. This separation keeps governance dashboards from being mistaken for service-health monitoring.

Separate platform health from workload health

Azure service health, resource health, platform metrics, application telemetry, dependency traces, and custom business signals answer different questions. Design dashboards and alerts so operators can tell whether a failure belongs to Azure infrastructure, a workload component, an external dependency, or the application’s own logic.

That separation shortens incident diagnosis and prevents teams from escalating the wrong problem. For this separate platform health from workload health checklist, define what proves the control is working, what proves it is not, and which neighboring layer should be investigated next.

Monitoring architecture also needs failure ownership. Platform health, application telemetry, security signals, policy compliance, and business metrics can all indicate a problem, but they answer different questions. The design should make it possible to tell whether the issue belongs to Azure infrastructure, workload code, an external dependency, or an administrative control before teams begin changing configuration.

Design governance evidence for audits and operations

Policy compliance, activity logs, resource configuration, access changes, and monitoring records can prove control operation, but only if retention and ownership are planned. Choose which evidence must be retained, where it is stored, who can access it, and how exceptions are explained without weakening the control.

The same evidence should help operations improve the system rather than exist only for an annual audit.

Policy exceptions deserve architecture, not ad hoc exclusion. When a workload cannot meet a policy immediately, record the business justification, compensating control, owner, scope, expiration or review date, and evidence that the exception remains necessary. An exemption that never expires can quietly become the organization’s real standard while dashboards still report that policy exists.

Exception design should also define who can close an exception. A workload that becomes compliant should not remain permanently exempt simply because nobody owns the cleanup. Review events, policy telemetry, and change records should make it possible to retire temporary exclusions and return the resource to the normal governance path.

Review the control plane as one architecture

The control plane is coherent only when identity, RBAC, policy, resource hierarchy, monitoring, alerting, and exception management reinforce one another. The expectations behind Microsoft Certified: Azure Solutions Architect Expert make that ownership model explicit: every control should have a scope, operator, failure signal, and reason for existing.

A coherent control plane makes later compute, network, data, and application designs easier to secure and operate.

For final review, take one workload and create a single control-plane diagram that shows identity, RBAC, policy inheritance, logging destinations, alerts, and operational ownership together. Then introduce a new regulatory requirement or a subscription reorganization and identify which elements must change. If the diagram survives that change without hidden dependencies, your control-plane reasoning is becoming architectural rather than procedural.

RBAC and Azure Policy solve different control problems. RBAC decides who can perform an action; Policy evaluates whether resources comply with allowed configuration. Architecture is stronger when those layers are separated, because a broad role should not become a substitute for governance and a policy rule should not be expected to replace administrative authorization.

A final control-plane review should trace one production workload through hierarchy, identity, policy, locks, monitoring, and administrative evidence. Change the business ownership or regulatory boundary and identify which scopes must move and which controls should remain stable. Then simulate one policy failure and one privileged-access problem so operators can see whether the architecture exposes the cause at the layer that owns it. This review is valuable because governance decisions are rarely isolated: a change in scope can affect authorization, policy inheritance, alert ownership, and audit evidence at the same time.