Microsoft AZ-120: Planning and Running SAP Workloads on Azure

Microsoft AZ-120, Planning and Administering Azure for SAP Workloads, is the current exam for Microsoft Certified: Azure for SAP Workloads Specialty. The English blueprint was updated on April 17, 2026. Microsoft targets architects and engineers who design, migrate, operate, and optimize SAP landscapes on Azure, including SAP HANA, SAP Business Suite, SAP NetWeaver, high availability, disaster recovery, networking, storage, monitoring, and cost management.

This is not a general Azure administration exam with a few SAP terms added. Candidates need substantial SAP infrastructure context and enough Azure depth to translate application and database requirements into supported cloud designs. Within Microsoft certifications, the Azure for SAP Workloads Specialty sits between deep SAP platform knowledge and Azure infrastructure engineering, which is why neither generic Azure study nor SAP-only study is sufficient.

The most productive way to prepare is to think in end-to-end landscapes. An SAP system is a chain of application servers, central services, databases, storage, networks, identity, monitoring, backup, and recovery procedures. A design decision in one layer can create a performance or availability problem elsewhere. AZ-120 therefore rewards candidates who can reason across dependencies rather than memorize isolated Azure features.

SAP sizing begins with workload evidence

Azure offers many VM families and storage choices, but SAP sizing should begin with workload characteristics, certified configurations, database requirements, growth, concurrency, and performance evidence. Oversizing wastes money and can hide poor architecture; undersizing creates operational instability. Candidates should understand that SAP certification and supportability constraints matter in addition to raw Azure capacity.

Build a sizing worksheet for a fictional production system and separate CPU, memory, storage throughput, IOPS, network, and availability requirements. Include a growth assumption and a nonproduction landscape. Then identify which values come from SAP workload evidence and which are Azure design choices. The purpose is to avoid treating a large VM SKU as a substitute for workload analysis.

Network design has to support both SAP traffic patterns and enterprise integration

SAP landscapes communicate across application, database, administration, integration, and user-access paths. Azure virtual networks, subnets, routing, name resolution, firewalls, private connectivity, and hybrid links must support those flows without creating unnecessary latency or exposure. Enterprise environments also need connectivity to identity services, on-premises systems, SaaS platforms, and operational tools.

Use the Azure core networking concepts as a supporting reference and map an SAP landscape onto a hub-and-spoke design. Document required flows between application servers, HANA, management, backup, and on-premises dependencies. Then add a failure in DNS or routing and trace its effect on SAP connectivity rather than assuming every issue is an application problem.

Storage design is tied directly to database behavior

SAP HANA and other supported databases can place demanding requirements on latency, throughput, durability, and recovery. Storage architecture needs to distinguish database data, logs, shared files, backups, and operating-system volumes. Candidates should know why the performance profile of a volume matters and how redundancy or caching choices affect the workload.

Create a diagram that labels each SAP storage function and its performance requirement. Then model what happens during backup, recovery, or peak transaction load. The exercise should explain why a storage configuration that is adequate for ordinary application files may be inappropriate for a database log path. AZ-120 questions often become easier when the candidate first identifies the workload that is actually driving the storage requirement.

High availability must account for every critical SAP component

Availability is more than placing two VMs in different zones. SAP central services, application servers, databases, load balancing, shared storage, and cluster behavior all influence whether the system survives a failure. The design needs to distinguish component redundancy from true service continuity and should account for planned maintenance as well as unexpected outages.

The internal resilient SAP on Azure material is useful for mapping failure domains. For each critical component, identify the redundant instance, the dependency that could still be shared, and the mechanism that moves or reroutes service. Then simulate the loss of one zone and ask which parts of the landscape remain available and which require recovery actions.

Disaster recovery is defined by business recovery targets, not by replication alone

High availability handles local failures; disaster recovery addresses larger loss scenarios. Candidates should understand recovery point objective, recovery time objective, backup strategy, database replication, cross-region design, and the sequencing required to restore dependent SAP services. A replica that exists in another region does not prove that the business can resume within its target.

Write a recovery runbook for one SAP system. Start with the database, central services, application tier, network dependencies, and validation steps. Include who decides to fail over, how DNS or endpoints change, what data loss is acceptable, and how users are returned to service. The business continuity and disaster recovery governance framework helps connect technical replication with ownership, testing, and improvement.

Migration planning should separate technical movement from operational cutover

An SAP migration can involve system copy, database migration, platform change, downtime constraints, interface validation, user readiness, and post-cutover stabilization. Azure resources are only one part of the program. AZ-120 candidates should be able to identify migration dependencies and select approaches that reflect source platform, target architecture, data volume, permitted downtime, and business risk.

Take a landscape with production, quality assurance, development, and several interfaces. Plan the order in which environments move and define what must be proven before production cutover. Include rollback criteria rather than assuming migration success is irreversible. The strongest migration plans create evidence through rehearsal and validation so the final cutover is an execution of a tested process rather than a first attempt.

RISE with SAP changes boundaries but does not remove architecture responsibility

The current audience profile explicitly includes solutions involving RISE with SAP. Managed-service boundaries can shift who operates particular infrastructure layers, yet architects still need to understand networking, integration, identity, performance, resiliency, and responsibility boundaries. A managed platform does not make enterprise dependencies disappear.

For each scenario, identify what the customer controls, what SAP controls, and what still depends on Azure or enterprise connectivity. Then focus monitoring and operational runbooks on the boundaries between those responsibilities. Many real incidents occur not because one platform is completely down, but because an integration across ownership boundaries is misconfigured or degraded.

Monitoring must connect Azure health to SAP behavior

CPU, memory, disk latency, network metrics, database indicators, SAP application health, and platform events should be correlated rather than reviewed in isolation. A user complaint about a slow transaction may begin in the application layer but originate in storage, database contention, network latency, or a recent infrastructure change.

Build an incident scenario with normal VM availability but degraded database storage latency. Identify which metrics would reveal the issue and which SAP symptoms would appear first. Then create an alert that signals the condition before it becomes a full outage. Operational maturity comes from detecting degradation early and connecting infrastructure evidence to application impact.

Automation should make repeatable landscape changes safer

The current blueprint includes Azure Resource Manager and Bicep. Infrastructure as code is valuable in SAP environments because supporting resources, network structures, monitoring, and nonproduction patterns often need repeatable deployment. It also gives reviewers a record of intended configuration and reduces dependence on manual portal changes.

Use Bicep for a small supporting environment rather than trying to automate an entire SAP estate at once. Parameterize environment-specific values, use managed identities where appropriate, and test the deployment in nonproduction. The ARM and Bicep concepts can support the Azure side of this skill even though AZ-120 applies them in a more specialized SAP context.

Cost optimization has to preserve supportability and performance. SAP environments can be expensive, so candidates should understand right-sizing, scheduling nonproduction resources, storage choices, reservations or commitment models where appropriate, and the cost implications of high availability and disaster recovery. Optimization is not simply reducing capacity. A cheaper design that violates support requirements or recovery targets is not an optimization.

Review one landscape and classify costs as production-critical, resilience-related, nonproduction, backup, network, and operational overhead. Identify savings that do not change the required service level. This makes cost a design dimension alongside performance and resiliency rather than a separate finance exercise.

A final AZ-120 capstone should connect these disciplines. Design a production SAP landscape, size it from stated requirements, define networking and storage, specify high availability, write a regional recovery approach, outline monitoring, and explain how the environment is deployed and changed. Then challenge the design with a zone failure, a storage bottleneck, and a migration constraint. If the response can be traced through SAP and Azure layers coherently, the preparation is moving beyond memorization.

AZ-120 remains a specialist credential because the intersection is the skill: candidates need enough SAP knowledge to recognize workload requirements and enough Azure knowledge to implement them safely. General Azure experience, including the operational foundation represented by Azure Administrator Associate, can help, but the specialty is earned by understanding how SAP behaves on Azure specifically.

Change management deserves explicit attention in SAP environments because maintenance windows, kernel or database work, Azure infrastructure changes, and business calendars can constrain when operations occur. Before a change, identify affected SAP components, dependencies, rollback steps, validation transactions, and the monitoring signals that prove the landscape returned to normal. This discipline is particularly important in tightly coupled systems where an infrastructure change can surface later as an application or batch-processing problem.

Backup strategy should be tested against SAP recovery sequencing. Database recovery, file-system restoration, application startup, interfaces, and validation do not necessarily complete at the same time. Run a tabletop exercise in which the database is restored successfully but an interface dependency remains unavailable. The exercise shows why recovery objectives must cover the usable business service rather than the moment one infrastructure component reports healthy.