AZ-120 Azure for SAP Workloads: Designing and Operating Enterprise SAP on Azure

AZ-120, Planning and Administering Azure for SAP Workloads, is a current specialty exam in the Microsoft certifications portfolio. It is aimed at architects and engineers who design and manage SAP landscapes on Azure, not at candidates who only know Azure services in isolation. The work crosses SAP application architecture, database platforms, virtual machines, storage, networking, identity, migration planning, resilience, monitoring, and day-to-day operational control.

Microsoft’s April 17, 2026 skills outline frames the role around four large responsibilities: migrating SAP workloads to Azure, designing and implementing the supporting infrastructure, engineering high availability and disaster recovery, and maintaining the resulting environment. Those categories matter because SAP migration is not a simple virtual-machine relocation. A usable design must respect SAP-supported configurations, HANA sizing, latency requirements, operational dependencies, licensing, business continuity objectives, and the way enterprise teams actually run the landscape after cutover.

As of October 3, 2026, AZ-120 remains current and schedulable. Microsoft strongly recommends Azure Administrator knowledge for candidates, and that recommendation is practical: a SAP specialist still needs confidence with subscriptions, networks, storage, identity, virtual machines, governance, monitoring, backup, and automation. AZ-120 adds the SAP-specific constraints that determine whether those Azure building blocks form a supported, resilient production system.

Start with the SAP workload, not with a catalog of Azure services

SAP landscapes have their own topology, availability, performance, and maintenance assumptions. Before choosing Azure resources, an architect needs to understand which SAP products and database combinations are in scope, how large the systems are, what interfaces connect them, which components are latency-sensitive, and what recovery objectives the business expects. SAP HANA, NetWeaver-based systems, application servers, central services, and non-SAP dependencies do not all scale or fail in the same way.

Sizing is therefore a workload exercise before it becomes an Azure exercise. CPU, memory, storage throughput, IOPS, network bandwidth, database growth, batch windows, and peak dialog load affect the target architecture. Certified VM families and supported deployment patterns narrow the choices further. A design that looks inexpensive on a spreadsheet can become operationally risky if it ignores HANA memory requirements, storage latency, or the time required to restore a large database.

Candidates should be able to explain why a chosen architecture is supported, not merely name an Azure SKU. That distinction also separates AZ-120 from a broader AZ-104 administration perspective: administrators operate Azure resources, while AZ-120 candidates must apply those resources to SAP-specific constraints and service-level objectives.

Migration planning joins technical assessment with business sequencing

A migration plan begins with discovery. Teams need an accurate view of systems, versions, dependencies, data volumes, interfaces, network paths, maintenance windows, and business calendars. That inventory supports decisions about lift-and-shift approaches, database migration, HANA adoption, modernization opportunities, and whether a workload should move in one event or through staged transitions.

Downtime tolerance can change the entire method. A development system may permit a straightforward offline move, while a global production system may require replication, rehearsed cutover steps, tightly controlled DNS or routing changes, and a rollback plan. Test migrations should measure actual throughput and duration instead of relying on theoretical transfer rates. The broader discipline of Azure migration planning is useful here because SAP migration succeeds when technical movement, validation, operating ownership, and business timing are treated as one program.

Cost is also part of the design. Migration tooling, temporary duplicate capacity, network egress, storage snapshots, backup retention, reserved capacity, licensing, and post-migration support all affect the financial model. Candidates should be able to separate one-time transition cost from steady-state operating cost and to identify where overprovisioning is justified temporarily for risk reduction rather than carried forever into production.

Landing zones, identity, and governance create the control plane for SAP

Enterprise SAP rarely lives in an isolated subscription with one administrator. Management groups, subscriptions, resource groups, Azure Policy, role-based access control, naming standards, tagging, resource locks, and cost-management boundaries determine how the environment is governed. An AZ-120 design should make it clear which team can change network controls, who can administer SAP virtual machines, who manages backup, and how privileged access is reviewed.

Identity architecture spans both Azure and SAP-facing components. Microsoft Entra ID can participate in administrator access, enterprise application authentication, managed identities, and integration services, while traditional Active Directory dependencies may remain for Windows-based infrastructure. The important skill is to define boundaries deliberately: service identities should not receive broad subscription rights merely because automation needs access, and interactive administrator accounts should not be reused as application credentials.

Policy can help prevent drift by enforcing locations, approved resource types, diagnostic settings, encryption expectations, or tagging requirements. However, policy should be tested against SAP deployment workflows. A technically correct policy that blocks a supported extension, image, or deployment pattern can delay critical work. Governance is strongest when controls are designed with the platform team, SAP Basis team, security team, and application owners rather than imposed after the environment is built.

Network design must respect both Azure topology and SAP latency

SAP traffic patterns can include user access, application-to-database communication, replication, management, backups, interfaces, and connectivity to on-premises systems or RISE with SAP environments. Address planning and route design must leave room for growth while avoiding overlap with existing enterprise networks. ExpressRoute, VPN connectivity, virtual network peering, DNS, network virtual appliances, and private endpoints may all participate in the end-to-end path.

Candidates should reason about where latency matters. Application servers and databases usually need predictable low-latency communication, while management and backup flows have different priorities. Network security groups and firewalls must restrict traffic without silently breaking SAP ports or replication. The more complex networking perspective covered by AZ-700 can deepen this area, but AZ-120 still expects architects to recognize when a network choice threatens supportability, resiliency, or performance.

RISE with SAP adds another integration boundary. Azure-hosted services and customer-managed resources may need to communicate with SAP-managed environments through carefully designed connectivity and identity patterns. The architect has to know which side owns each component, which routes and security controls are available, and how operational teams will diagnose a failure that crosses organizational boundaries.

Storage and compute choices are tied to SAP certification and performance

General Azure advice such as “choose premium storage for important workloads” is too vague for SAP. Database log volumes, data volumes, shared files, application binaries, backups, and temporary areas can have different throughput and latency requirements. Disk layout, caching, striping, managed-disk type, shared storage technology, and snapshot or backup behavior must be matched to the supported SAP and database design.

Compute sizing has similar constraints. Architects should verify supported VM families, understand vertical and horizontal scaling options, and plan capacity for failover. A production pair that runs near maximum capacity in normal operation may not have enough headroom when one node carries extra work during maintenance or failure. Availability-zone placement can improve fault isolation, but it also requires awareness of inter-zone latency and service dependencies.

Capacity planning should include growth and operational events. Month-end processing, large data loads, upgrades, system copies, and backup windows can expose bottlenecks that average monitoring misses. A good design establishes a performance baseline and a review process rather than assuming the initial size will remain correct for years.

High availability and disaster recovery solve different failure scopes

High availability is usually about keeping a service running through component or localized failures; disaster recovery addresses larger outages and the ability to restore service in another location or from protected data. SAP architects need to map both to business requirements for recovery time and recovery point. Those objectives then drive clustering, replication, backup, secondary-region capacity, DNS, automation, and testing decisions.

Database high availability, SAP central services, application tiers, shared storage, and network paths may each require a separate mechanism. A system is not highly available merely because its database replicates. If the central services layer, load-balancing path, identity dependency, or shared file location remains a single point of failure, the overall service can still stop. This is why the broader practice of disaster-recovery planning matters: recovery has to be designed and exercised as an end-to-end service, not as a collection of protected components.

Testing should include planned failover, unplanned failure scenarios, recovery from backup, and return-to-normal procedures. Documentation must identify who declares a disaster, who initiates technical actions, which validation proves the system is usable, and how dependent interfaces are restored. An untested runbook is a hypothesis, not a recovery capability.

Operations depend on monitoring, backup, automation, and clear ownership

After migration, teams need visibility across Azure infrastructure and SAP behavior. Azure Monitor, logs, metrics, alerts, SAP-specific monitoring, database tools, and application telemetry should produce signals that operators can interpret. Alert design should emphasize actionable conditions such as capacity pressure, replication health, backup failure, availability problems, or unusual resource behavior instead of overwhelming teams with every transient event.

Backup policies need to align with database-consistent protection and business retention requirements. Recovery testing is essential because a successful backup job does not prove that the required data can be restored inside the recovery window. Security controls should cover encryption, privileged access, patching, vulnerability management, and the separation of duties appropriate to regulated enterprise workloads.

Automation through Azure Resource Manager or Bicep, scripting, and repeatable operational procedures reduces configuration drift. The purpose is not to automate every action; it is to make important changes predictable and reviewable. When an SAP landscape spans many systems and environments, a controlled template for networks, monitoring, or policy is easier to audit than a sequence of undocumented portal clicks.

Prepare by connecting SAP architecture decisions to Azure consequences

Strong AZ-120 preparation uses scenarios. Given a migration requirement, choose the supported approach and explain downtime, dependency, and rollback implications. Given a resilience target, trace every component needed for service recovery. Given a performance complaint, separate compute, storage, network, database, and application evidence before changing resources. Given a security requirement, identify the control point and its operational effect.

AZ-120 SAP on Azure makes the most sense when paired with hands-on work in real or lab environments. Candidates should practice reading architecture diagrams, validating route and DNS behavior, reviewing VM and storage metrics, applying role assignments, and thinking through failover. Memorizing product names is not enough when several technically possible services have different support and recovery implications.

AZ-120 ultimately tests whether a specialist can make Azure infrastructure serve SAP requirements rather than the other way around. Candidates who can connect SAP workload behavior with Azure governance, networking, storage, compute, resilience, monitoring, and operational ownership are preparing for the role the exam actually represents. The broader Microsoft certification ecosystem can provide adjacent administration, architecture, networking, and security depth, but AZ-120 remains specifically about running enterprise SAP successfully on Azure.