Microsoft AZ-120: Designing SAP Resilience on Azure

An SAP migration can pass an infrastructure checklist and still fall short of what the business actually needs. The new servers may be adequately sized, yet the application tier is too far from the database; a replicated HANA system may survive a node failure, yet the team may not know how long the business can operate after a regional outage. Microsoft AZ-120 concerns those interconnected decisions. It asks architects and engineers to plan and administer Azure environments where SAP performance and continuity are essential.

The exam is Planning and Administering Azure for SAP Workloads. Microsoft’s April 2026 skills outline covers migration, SAP infrastructure, high availability and disaster recovery, and ongoing operations. Use the AZ-120 exam page as the assigned ExamSnap page, alongside the current Microsoft objectives and SAP-on-Azure support documentation.

Sizing begins with the SAP system, not a VM catalog

A finance organization plans to move its SAP landscape into Azure. It knows its current server sizes and annual cloud budget, but those figures alone cannot determine a safe design. Assess SAP components, database size, memory demand, CPU characteristics, I/O patterns, peak business periods and supported deployment configurations. An Azure virtual machine should be selected from SAP-certified options that meet the particular workload requirements, not simply one that resembles the on-premises CPU count.

Storage and network latency matter just as much. HANA’s persistence and log-write behavior impose different requirements than a casual file-sharing workload. Consider disk throughput, caching guidance, striping where supported, Azure NetApp Files where appropriate, and the network path among application and database tiers. Document every performance assumption so validation after migration has a meaningful baseline.

Choose the migration path around business constraints

AZ-120 distinguishes several migration approaches, including lift-and-shift and transformations that incorporate SAP HANA. A simple infrastructure relocation may reduce application changes but retain technical debt. A more ambitious move can unlock an improved target state, yet it introduces additional testing, downtime and integration risk. The sound choice depends on application dependencies, licensing, support conditions and the business’s tolerance for a longer transition.

Imagine a manufacturing company whose SAP transactions control production scheduling. A weekend cutover may be possible on paper, but its reporting and integration jobs could delay validation. Map connected systems, identity flows, batch processes and data migration steps before selecting a cutover strategy. Estimate not only how quickly data transfers but how long functional checks and the fallback decision will take.

RISE with SAP changes the responsibility boundary

Microsoft’s current guide explicitly includes integration with RISE with SAP. This is important because service ownership differs from a fully customer-managed SAP deployment on Azure virtual machines. Know which party administers which layer, how networks connect, and how identity, monitoring, data access and governance interact across boundaries. A design that assumes direct control of every resource can be incorrect when the arrangement delegates responsibilities to a managed service.

For example, an enterprise may need a private connection between an SAP environment and analytics services in its own Azure subscriptions. The architecture must specify routing, DNS, security policy and the operational handoff if a connection fails. It should not imply that a single team can change both sides of a jointly managed service.

Availability, replication and recovery are not synonyms

A high-availability design addresses the loss of a local component; disaster recovery addresses a larger event with a defined recovery target. Both are important, but they solve different problems. SAP Central Services, SAP HANA and supporting databases may require clustering, load balancing, fencing and replication. The examination blueprint includes Pacemaker and STONITH concepts because split-brain prevention is central to reliable failover, not a minor implementation detail. The architectural trade-offs behind recovery promises are explored more broadly in Microsoft AZ-305 recovery architecture, beyond the SAP-specific requirements.

Use a failure scenario to expose assumptions. If one HANA node becomes unreachable, can the surviving node safely take ownership? If the whole region fails, what data can the company afford to lose and how quickly must transactions resume? Recovery point objective measures acceptable data loss; recovery time objective describes the target restoration interval. Backups provide a recovery mechanism, but they do not by themselves create instantaneous failover.

Operations start the day after cutover

Monitoring, patching, backup validation, capacity reviews and incident response determine whether the target platform remains healthy. Azure Center for SAP solutions and deployment automation tooling can help standardize parts of the environment, but administrators still need to understand resource health and SAP-specific signals. A green virtual machine metric is not proof that an SAP business process is completing.

Plan maintenance around dependencies and agreed service windows. Check what happens when an operating-system patch requires a restart, how application tiers recover, and whether the team has rehearsed restoration from backup. The goal is a service that behaves predictably under routine operations as well as under failures.

Prepare through architectural decisions with consequences

Design one SAP landscape with a migration window, a performance requirement and two failure scenarios. Defend your compute and storage selections, show the network and identity boundaries, and describe what the operators will monitor. Then modify the requirement: less downtime, a stricter data-loss target, or a RISE with SAP integration. Explain which decisions must change and which stay valid. That kind of reasoning aligns with all four AZ-120 domains much better than memorizing isolated Azure SKU names.