The four AZ-305 domains make more sense when they are mapped as one architecture lifecycle. Identity and governance define who controls and uses resources. Monitoring provides evidence. Storage defines where state lives. Business continuity protects that state and compute from failure. Infrastructure choices determine how applications run, communicate, scale, migrate, and reach users. Each design decision changes the constraints on the others.
The current AZ-305 weights—25–30% identity/governance/monitoring, 20–25% data storage, 15–20% business continuity, and 30–35% infrastructure—show that infrastructure is the largest block, but it cannot be designed correctly without the control and data layers around it.
Business requirements sit above all four domains
Before choosing Azure services, define security, compliance, availability, performance, data, migration, operational, and cost requirements. The Azure Well-Architected Framework and Cloud Adoption Framework provide structure for those trade-offs.
The AZ-305 architecture foundation is most useful when candidates start from the requirement and then map it into controls and services. Product-first design can optimize the wrong problem.
Management hierarchy connects governance to every resource
Management groups, subscriptions, resource groups, tagging, policy, and compliance create the administrative structure underneath compute, storage, and networks. A governance decision at a high scope can influence every workload below it.
The map should therefore place hierarchy before resource selection. If regulated workloads require different policy or billing, the subscription structure may need to reflect that before applications are deployed.
Identity and secrets connect users and workloads to resources
Authentication, authorization, hybrid access, managed identities, secrets, certificates, keys, and role assignments define which principals can act. Workload identity should be treated as seriously as human identity because applications often need access to data, queues, APIs, and Key Vault.
A Key Vault design connects credential protection to application architecture. Secret storage alone is not enough; applications still need a secure identity and appropriate authorization to retrieve or use the secret or key.
Monitoring turns design assumptions into operational evidence
Logging, log routing, monitoring, metrics, alerts, and diagnostics should be designed alongside the workload. Monitoring is how teams know whether identity failures, network issues, data latency, resource saturation, or availability problems are actually occurring.
The Azure Monitor layer should connect to service-level indicators and ownership. A dashboard that collects data without telling the right team what action to take is not operationally complete.
Storage choices determine state, scale, protection, and recovery
Relational, semi-structured, and unstructured storage options differ in transactions, consistency, schema, query pattern, latency, scale, compatibility, and administration. Those choices also affect backup, replication, high availability, and disaster recovery.
A Cosmos DB design, for example, can provide globally distributed nonrelational behavior but introduces partitioning, consistency, throughput, and cost decisions. A relational design may provide different transaction and compatibility benefits.
Business continuity maps failure domains to recovery objectives
High availability protects against localized failures, while disaster recovery protects against larger outages and backup protects recoverability from corruption or deletion. These mechanisms can overlap but are not interchangeable.
RTO and RPO should be drawn beside each critical component. If the database requires minutes of recovery while the application can tolerate hours, the architecture is misaligned regardless of how resilient the compute tier looks.
Compute selection changes network, identity, deployment, and operations
Virtual machines, containers, serverless services, and batch platforms expose different control surfaces. VM-based systems require more operating-system management. Containers introduce orchestration and image lifecycle. Serverless can reduce infrastructure ownership but introduces runtime and integration constraints.
The Azure compute decision should therefore be mapped with team skills, deployment method, networking, identity, scaling, and monitoring rather than treated as a standalone platform choice.
Messaging and events create failure boundaries inside applications
Queues, topics, event services, and asynchronous patterns can decouple components so a downstream outage becomes delayed work rather than an upstream failure. That changes retry, ordering, idempotence, monitoring, and recovery requirements.
Azure Service Bus is a useful example because durable messaging introduces operational state. The architect must know how dead-lettering, retries, and backlog affect the business process.
APIs, caching, and configuration shape application behavior at runtime
API Management, caching, configuration stores, and deployment pipelines sit between code and users. APIs need authentication, throttling, versioning, and observability; caches improve latency but introduce consistency and invalidation; configuration changes can alter behavior without code changes.
API Management and Azure Cache for Redis illustrate why runtime architecture includes more than compute. Supporting services can become critical dependencies that need their own availability and monitoring design.
Networks and migration connect the architecture to the outside world
Internet connectivity, hybrid networks, virtual networks, load balancing, routing, performance, security, migration, and the Cloud Adoption Framework define how the new solution fits existing systems and users.
Compliance adds another arrow across the map. A regulatory requirement can influence subscription placement, region selection, identity, encryption, logging, retention, backup, and even which managed service is acceptable. The architect should avoid treating compliance as a final checklist after the infrastructure has already been chosen.
Tagging connects governance with operations and cost. A consistent tagging strategy can support ownership, chargeback, automation, lifecycle, and incident routing. Tags are not a substitute for hierarchy or RBAC, but they can make large estates easier to understand when every resource carries useful business and operational context.
Secrets and certificates also connect to business continuity. If a key or certificate expires, is deleted, or becomes inaccessible during failover, the application can remain unavailable even when compute and data recover successfully. Recovery planning should therefore include credential and key dependencies alongside infrastructure and data.
Data-protection design should be mapped to workload tier. A mission-critical relational database may justify zone redundancy and regional failover, while an archival dataset may rely mainly on durable storage, lifecycle, and backup. The map should show that protection intensity follows business value and recovery targets rather than being uniform across all data.
Event-driven architecture links compute scale with application resilience. A sudden burst can be absorbed by an event or queue layer while serverless or containerized consumers scale. This pattern can reduce tight coupling, but it introduces ordering, deduplication, retry, and dead-letter requirements that must be visible in the architecture.
Configuration management connects deployment with runtime behavior. A centralized configuration change can alter multiple application instances without a full release. That makes configuration versioning, access control, validation, and rollback part of application architecture. The map should show configuration as another production dependency rather than a developer convenience.
Network design also affects data and continuity. Private endpoints can reduce exposure, but DNS and routing must be designed correctly. Cross-region replication consumes network capacity and can add cost. Hybrid applications may need resilient VPN or ExpressRoute paths. Network topology is therefore an input to storage, recovery, and application decisions.
Migration links old and new architectures during transition. Temporary hybrid connectivity, duplicate data, synchronization tools, and staged cutovers can exist for months. Those transitional components need monitoring, security, ownership, and removal plans so that the organization does not accumulate permanent temporary infrastructure.
Operational ownership closes the map. The architecture should identify which team owns identity, networking, data, applications, monitoring, and recovery. When a dependency crosses teams, escalation and evidence should be clear. Many design failures become support failures because ownership was never defined.
Use the objective map in final revision by tracing a single customer request from authentication to network path, compute, cache or message layer, API, database, monitoring, backup, and recovery. If every arrow has an owner and a reason, the four exam domains have become one architecture rather than four study lists.
Cost creates another cross-domain connection. Subscription hierarchy affects cost visibility, storage tiers affect recurring spend, replication and failover add redundancy cost, network topology adds transfer cost, and compute operating models change idle capacity. The map should show cost as a consequence of architecture rather than a separate optimization phase after deployment.
Security boundaries also follow data flow. A workload may use managed identity to retrieve a secret, private networking to reach a database, API Management to control client access, and logging to prove authorization decisions. Each control protects a different step. Layered security is effective when the boundaries are explicit and independently testable.
Hybrid design connects identity, networking, migration, and business continuity. An on-premises dependency can influence authentication, DNS, data replication, latency, and disaster-recovery sequencing. The architect should map those hybrid dependencies early because they often become the hidden reason a cloud solution cannot fail over or migrate cleanly.
Automated deployment connects application architecture to governance. A deployment pipeline can enforce validation, approvals, environment configuration, and rollback, while governance controls ensure the pipeline itself has only the permissions it needs. The map should show release automation as a governed production dependency, not only a developer tool.
Finally, use the map to separate steady state from transition state. Production architecture, disaster recovery, migration, failover, and rollback may use different paths and resources. Many scenario errors come from assuming the normal path and the recovery or migration path are identical.
Resilience also connects to application architecture. A message queue can absorb downstream outages, a cache can reduce dependency load, and API versioning can protect consumers during release. Business continuity is therefore influenced by component interaction, not only by backup and regional replication.
Data integration connects observability with correctness. Pipelines need evidence about source arrival, transformation success, latency, duplicates, and downstream delivery. A pipeline that “ran” is not necessarily healthy if the data is stale or incomplete. Monitoring should follow the data contract as well as infrastructure status.
Use the final map to mark which controls are preventative, detective, and corrective. Policy and RBAC can prevent actions, monitoring can detect problems, backup can correct data-loss events, and failover can restore service. A mature design usually combines all three control types instead of relying on one layer.
The map is complete when you can trace one business transaction across identity, network, application, data, logging, and recovery—and explain how migration will move the organization to that target state. The AZ-305 design perspective should always return to those cross-domain dependencies.