AZ-305 contains many Azure services, but the exam is easier when candidates organize them around stable architecture concepts. Governance scope, least privilege, state, failure domains, managed services, loose coupling, recovery objectives, data gravity, observability, migration strategy, and operational ownership connect the four current exam domains.
The current AZ-305 blueprint should therefore be studied through concepts first and services second. When a scenario introduces an unfamiliar service, the candidate can still reason from the architectural problem it is intended to solve.
Concept one: scope changes the meaning of governance
Management groups, subscriptions, resource groups, and individual resources are different policy and role scopes. The same assignment can have very different impact depending on where it is applied.
Architects should design administrative boundaries before resources proliferate because governance is harder to retrofit across an unclear hierarchy.
Concept two: identity and network controls solve different problems
Microsoft Entra, RBAC, managed identities, Key Vault, and workload credentials determine who may act. Virtual networks, private endpoints, routing, firewalls, and load balancers determine where traffic may flow.
A secure solution usually needs both. Network reachability does not imply authorization, and authorization does not create a network path.
Concept three: secrets should be removed from application code
Managed identities and Key Vault reduce the need to distribute long-lived credentials. The architecture should know which workload identity requests access, which secret or key is needed, and who can administer each part.
Secret storage without least-privilege retrieval is incomplete security.
Concept four: state determines recovery complexity
Stateless compute can often be replaced or scaled horizontally, while databases, queues, files, and session stores preserve business state. Recovery planning should therefore identify where the authoritative state lives.
Backup, replication, high availability, and disaster recovery should be designed around that state rather than around the compute tier alone.
Concept five: loose coupling converts some outages into delay
Messaging and event-driven architecture can allow producers and consumers to operate independently. A queue can absorb temporary failure, but it also introduces delivery, retry, idempotence, monitoring, and dead-letter concerns.
Service Bus is a useful example of the operational state created by asynchronous architecture.
Concept six: managed services move the responsibility boundary
PaaS databases, serverless compute, managed messaging, API Management, and caches can remove patching or infrastructure work. They do not remove responsibility for data, access, configuration, cost, monitoring, or business correctness.
The compute choice should therefore include what the team wants Azure to manage and what control the team genuinely needs.
Concept seven: recovery time and recovery point are design inputs
RTO defines how quickly service must return; RPO defines how much data loss is acceptable. Those targets determine whether backup, zone redundancy, regional replication, or active failover is appropriate.
A backup can satisfy recoverability but not necessarily rapid failover. Architecture should not confuse these mechanisms.
Concept eight: data gravity affects migration, network, and analytics
Large datasets are expensive and slow to move. Data location influences migration sequence, integration, network topology, analytical services, backup, compliance, and application latency.
Architects should understand where data is authoritative before deciding how applications and pipelines should move around it.
Concept nine: observability validates architecture after deployment
Metrics, logs, alerts, diagnostics, traces, and dashboards provide evidence that the system meets performance, availability, security, and business expectations.
The Azure Monitor layer should follow critical dependencies so teams can distinguish an identity failure from a network failure or data bottleneck quickly.
Concept ten: migration is a temporary architecture with an exit path
Hybrid connectivity, replication, duplicated environments, temporary credentials, and cutover tooling may exist only during migration. Temporary resources still need security, monitoring, ownership, and removal plans.
Concept eleven: configuration is production state. Feature flags, connection strings, endpoints, and runtime settings can change application behavior without a code deployment. Configuration should therefore be versioned, access-controlled, monitored, and recoverable just like code.
Concept twelve: caches trade freshness for speed. The architecture should define what may be stale, for how long, and how invalidation occurs. A cache can improve latency and reduce database load but also create correctness bugs when ownership of invalidation is unclear.
Concept thirteen: API contracts create long-lived dependencies. Versioning, authentication, throttling, documentation, and lifecycle management become architectural responsibilities once external or internal consumers depend on an API.
Concept fourteen: tagging is metadata for operations. Ownership, environment, cost center, and classification can support policy, automation, billing, and incident routing. Tags are most useful when their meaning is standardized and maintained, not when teams invent unrelated labels.
Concept fifteen: high availability and disaster recovery solve different failure scales. Redundant instances or zones may survive local failure, while regional disasters require a separate recovery design. Backups may protect against corruption or deletion but still take too long for a tight RTO.
Concept sixteen: migration creates temporary risk. During transition, data may exist in two places, traffic may cross hybrid networks, and identity may span old and new systems. Those temporary dependencies need explicit security, monitoring, and retirement plans.
Concept seventeen: operational simplicity has value. A managed platform may reduce patching, backup, scaling, or failover work, but it can also impose limits or service-specific constraints. The right choice balances required control with the operational capability of the team.
Concept eighteen: architecture decisions need measurable evidence. Logging, metrics, recovery tests, load tests, policy audits, and cost reports should confirm whether the design meets its assumptions after deployment.
Concept nineteen: ownership is an architectural property. Every subscription, service, data store, alert, recovery process, and migration task should have an accountable team. Unowned dependencies become slow incidents and governance gaps.
Concept twenty: the Well-Architected Framework is a trade-off framework, not a scorecard to maximize blindly. Security, reliability, performance, cost, and operations can pull in different directions. Architects should explain why the selected balance fits the business context.
Concept twenty-one: failure domains should be named explicitly. Instance, zone, region, identity provider, DNS, storage account, database, queue, and external dependency failures have different scope. Resilient architecture begins by deciding which of those failures the business requires the system to survive.
Concept twenty-two: data protection includes deletion and corruption, not only infrastructure failure. Replication can copy corruption quickly; backup can preserve earlier state. The architect should choose mechanisms that cover both availability and recoverability.
Concept twenty-three: private connectivity adds dependencies. Private endpoints can reduce public exposure, but they introduce DNS, routing, and network integration requirements. The architecture should document those dependencies so private access remains supportable.
Concept twenty-four: asynchronous systems move complexity rather than remove it. Queues reduce coupling, but they create backlog, retry, ordering, idempotence, dead-letter, and monitoring requirements. The benefit is a better failure boundary, not a complexity-free system.
Concept twenty-five: migration decisions should be reversible where possible. Staged cutovers, replication, parallel validation, and rollback reduce the risk of irreversible failure. The target architecture can be modernized later if the migration deadline does not allow every improvement at once.
Concept twenty-six: service-level objectives should influence monitoring. Teams should collect signals that reveal whether users are receiving the required availability, latency, and correctness, not only whether resources are “running.” Operational evidence should follow the business objective.
Concept twenty-seven: cost optimization is constrained design. A cheaper architecture is not better if it violates recovery, security, or performance requirements. Cost work begins after the mandatory constraints are clear and then removes unnecessary spend within those boundaries.
Concept twenty-eight: team capability can invalidate an otherwise good design. A complex Kubernetes or custom VM architecture may be operationally weaker than a managed platform if the organization lacks the skills to run it safely. Architecture includes the people who must operate the system.
Concept twenty-nine: documentation preserves architecture intent. Diagrams, decision records, recovery plans, ownership, data flows, and configuration boundaries help future teams understand why choices were made. Without that intent, later optimization can accidentally remove a control that was protecting a requirement no longer obvious in the resource list.
Concept thirty: architecture evolves. Workload growth, service changes, regulation, cost, team maturity, and migration progress can all make the original decision less suitable. Good designs expose interfaces and ownership clearly enough that change can be made deliberately rather than through emergency exceptions.
Concept thirty-one: policy and architecture should reinforce each other. A policy that bans public endpoints is easier to satisfy when the reference architecture already includes private DNS, endpoints, and network ownership. Governance is strongest when the desired design is the easiest compliant path.
Concept thirty-two: data consistency is a design choice. Distributed databases, caches, replicas, and asynchronous workflows can expose stale or eventually consistent state. The business requirement should define where strong consistency is mandatory and where latency or availability justifies looser consistency.
Concept thirty-three: supportability should influence service selection. Services that expose clear metrics, health state, logs, and recovery procedures are easier to operate. A technically powerful design can still be weak if teams cannot diagnose it during an incident.
Concept thirty-four: interfaces reduce coupling when ownership is clear. APIs, queues, events, and shared data products let teams evolve independently only when contracts, versions, security, and reliability expectations are documented.
Concept thirty-five: recovery testing validates architecture assumptions. A diagram can show geo-replication, but only a test proves DNS, identity, secrets, application configuration, and data all recover within the target. Business continuity is operational evidence, not only resource configuration.
Concept thirty-six: capacity planning includes quotas and downstream limits. An autoscaling application can still fail when a database, queue, API, or regional quota becomes the bottleneck. Elasticity should be evaluated across the entire dependency chain.
The broader Azure Solutions Architect Expert role is about managing these cross-domain consequences. The exam becomes more predictable when every service choice can be explained in terms of scope, trust, state, failure, operations, and transition.