Azure architecture decision checklist: identity, networking, governance, resilience

Fri, 25 Sep 2026 08:20:25 +0000

This is a practical pre-design checklist you can run before you commit to an Azure architecture. It’s built for the real world: multiple teams, multiple subscriptions, hybrid constraints, and the need to stay secure and operable.
Use it in two ways:

As an architect: to force clarity on tradeoffs and document decisions
As a lead/admin: to sanity-check that “the design” won’t collapse under operations

1) Identity (who can do what, from where, and how safely)

Tenant & directory decisions

Is there one Entra ID tenant or multiple? Why?
What’s the B2B/guest strategy (partners, contractors, vendors)?
Are there clear boundaries between prod vs non-prod identities?

Authentication & access controls

Is MFA enforced for all privileged access?
Do you have break-glass accounts (tested, monitored, excluded from conditional access where appropriate)?
Are Conditional Access policies designed with: named locations, device compliance requirements (where needed), risk-based controls (if available), and are explicit exclusions documented?

Privileged access model

Are you using least privilege by design (not “everyone is Owner”)?
Are privileged roles managed via PIM (activation, approvals, time-bound access)?
Is there a clear separation between platform team privileges, app team privileges, and security team privileges?

Authorization (RBAC) structure

Are RBAC assignments done at the right scope (MG / subscription / RG / resource)?
Do you have a standard set of role definitions and naming conventions?
Are service principals / managed identities used appropriately (no shared credentials)?

Identity operational readiness

How will access be requested, approved, audited, and removed?
Is there an offboarding process for contractors and vendors?
Do you have an identity logging/alerting baseline for privileged actions?

2) Networking (connectivity, segmentation, and predictable traffic flow)

Topology & segmentation

Hub-and-spoke, vWAN, or flat VNet—what’s the rationale?
What are the segmentation boundaries (by environment, app, data sensitivity, business unit)?
Are you designing for east-west control (not just north-south)?

Name resolution & DNS

What’s the DNS strategy (Azure DNS, custom DNS, hybrid DNS)?
How will private DNS zones be managed across subscriptions?
Are you preventing “mystery DNS” issues (split-brain, conditional forwarders, inconsistent resolvers)?

Hybrid connectivity

VPN vs ExpressRoute—what’s the business requirement and SLA expectation?
Where is routing controlled (UDRs, BGP, route tables)?
Is there a clear plan for failover, bandwidth scaling, and maintenance windows?

Egress control & outbound strategy

How is outbound internet controlled (NAT Gateway, Azure Firewall, third-party NVA)?
Is outbound traffic inspected/logged?
Are you avoiding uncontrolled public egress from workloads that shouldn’t have it?

Ingress & exposure

What is allowed to be public-facing? What must be private-only?
Are you using WAF where appropriate (App Gateway/Front Door)?
Are private endpoints used intentionally (and not breaking DNS/operations)?

Network operations

How will you monitor network health (latency, packet loss, firewall drops)?
Who owns network changes and how are they approved?
Do you have a standard “first 15 minutes” network troubleshooting flow?

3) Governance (guardrails that enable teams without chaos)

Management groups & subscription strategy

Do you have a management group hierarchy aligned to: • environments (prod/non-prod)
business units
compliance boundaries?
Is subscription sprawl controlled (creation process, naming, tagging)?

Policy & standards

What is enforced via Azure Policy vs documented as guidance?
Are you enforcing allowed locations, required tags, encryption requirements, logging/diagnostic settings and secure configuration baselines?
How do you handle exceptions (time-bound, documented, reviewed)?

Resource organization

Are resource groups structured by lifecycle and ownership (not random grouping)?
Do naming conventions support operations (searching, incident response, cost tracking)?

Cost governance (FinOps by design)

Do you have tagging that supports chargeback/showback?
Are budgets and alerts configured per subscription/team?
Do you have rules for reserved instances/savings plans, scaling policies, and “non-prod shutdown” patterns?

Operational governance

Is there change control for network/security baseline changes, identity policy changes, and shared platform components?
Are runbooks and ownership documented for shared services?

4) Resilience (availability, recovery, and operational survivability)

Availability targets

What is the required SLA per workload (business-defined, not guessed)?
Are you designing for: zone redundancy, regional redundancy, and multi-region active/active vs active/passive?
Are dependencies mapped (identity, DNS, network, storage, third-party services)?

Backup & restore (prove it, don’t assume it)

What is backed up, how often, and where?
Are restores tested (not just “backup succeeded”)?
Are RPO/RTO targets defined and validated?

Disaster recovery planning

What is the DR strategy per workload (cold/warm/hot)?
Are failover procedures documented and rehearsed?
Who has authority to declare DR and execute failover?

Monitoring & incident response readiness

What is the minimum monitoring baseline (logs, metrics, alerts) for every workload?
Do you have an incident playbook: triage, comms, escalation, postmortems?
Are you capturing the right signals to reduce MTTR?

“What breaks first?” resilience reality check

Single region dependencies hiding in “multi-region” designs
DNS and identity as silent single points of failure
Manual failover steps nobody has practiced
Backups that restore too slowly to meet RTO
Monitoring that alerts too late (or too noisily)

Decision artifacts (what you should write down)

To avoid architecture-by-memory, capture:

A one-page architecture overview (diagram + intent)
A short list of non-negotiables (security/compliance constraints)
A set of tradeoff decisions (why you chose A over B)
Ownership boundaries (who operates what)
A “day-2 operations” section (how it’s monitored, patched, recovered)

These artifacts are what make the design implementable and supportable.

Train the architect mindset (AZ-104+AZ-305 and AZ-700)

If you want to formalize this decision-making approach and connect it to Microsoft’s architecture expectations, the AZ-104+AZ-305 training path is the cleanest structure. Alternatively, you can investigate the AZ-700 training path for a network depth for architects.

FAQ

Is this checklist only for large enterprises?
No. Smaller orgs benefit even more because a few wrong decisions create long-term operational pain.

Should admins use this too?
Yes, especially to validate that the design includes ownership, monitoring, and recovery (not just diagrams).

What’s the fastest way to improve architecture quality?
Standardize identity boundaries, enforce governance guardrails early, and design networking/DNS intentionally. Most “Azure problems” trace back to those.

Coder Legion - Recent posts tagged cloud-identity