Azure for SAP Workloads Specialty: AZ-120 in 2026

Microsoft Certified: Azure for SAP Workloads Specialty remains an active certification for architects and engineers who design, migrate, and operate SAP landscapes on Azure. The current AZ-120 exam, Planning and Administering Azure for SAP Workloads, reflects an objective set updated on April 17, 2026. Unlike several neighboring Microsoft certification pages from this period, AZ-120 is not a legacy credential.

The role combines deep SAP knowledge with Azure infrastructure design. Candidates are expected to understand SAP HANA, SAP Business Suite, SAP NetWeaver, virtualization, storage, networking, high availability, disaster recovery, backup, data protection, migration, monitoring, and cost optimization. Microsoft also expects familiarity with Azure Resource Manager and Bicep for managing infrastructure.

This combination is what makes AZ-120 specialized. A strong Azure administrator who has never worked with SAP may not understand application and database dependencies, while an SAP specialist who has never designed cloud infrastructure may miss Azure availability, networking, identity, and operational tradeoffs. Preparation needs both perspectives.

SAP architecture on Azure starts with workload requirements, not VM names

SAP landscapes can contain database, central-services, application-server, web, interface, management, and supporting components. Candidates should be able to map those roles to Azure resources while preserving performance, resilience, and support requirements. The goal is not to memorize one reference architecture but to understand why a particular topology fits a workload.

The AZ-120 SAP workload architecture material is most useful when paired with a concrete landscape. Draw the production, quality, and development tiers; identify which components are stateful; record network dependencies; and determine which failures must be tolerated without business interruption.

Think in terms of business processes as well. A system can be technically online while a critical transaction path is unavailable because one dependent service, interface, or database connection has failed. Validation should therefore include SAP-level behavior, not only Azure resource health.

SAP HANA sizing and storage design require performance evidence

SAP HANA is memory intensive and sensitive to storage and infrastructure design. Candidates need to understand certified VM options, memory and CPU requirements, storage throughput and latency, disk layout, and the relationship between database behavior and Azure resource limits.

Use monitoring data when sizing. Historical CPU, memory, I/O, growth, batch windows, and user activity provide a stronger basis than simply matching an on-premises server specification. Cloud migration is an opportunity to right-size, but aggressive downsizing without workload evidence can create performance problems that appear only during peak periods.

The article on Azure VM data disks provides useful infrastructure context. For SAP, storage choices should also account for database persistence, log behavior, backup, recovery, and any SAP-specific certification constraints.

Networking must support latency, throughput, isolation, and hybrid dependencies

Many SAP-on-Azure deployments remain hybrid. Users, identity systems, interfaces, management tools, or other applications may remain on-premises or in another cloud. Network architecture therefore becomes part of application performance and availability.

Candidates should understand virtual networks, subnets, routing, DNS, network security, private connectivity, load balancing, and high-throughput hybrid links. The article on Azure virtual networks can help reinforce how address space, routing, and segmentation shape connectivity.

Test the whole path. A database connection problem can be caused by name resolution, a route, a security rule, a firewall, hybrid connectivity, or the service itself. Record expected latency and bandwidth for important flows and validate them after changes. For SAP, intermittent network degradation may surface as slow business transactions rather than obvious link failure.

High availability and disaster recovery are separate design problems

The current AZ-120 objectives explicitly include high availability and disaster recovery. High availability keeps services running through local component failures, while disaster recovery restores service after a larger failure or loss of a site or region. They use related technologies but different recovery assumptions.

Design the database, central services, and application tier with their own failure modes. Define recovery time and recovery point objectives, then select mechanisms that can actually meet them. Availability Zones, clustering, replication, backups, and cross-region strategies should be tied to measured requirements rather than added because they sound resilient.

The broader discussion of disaster recovery planning is useful because technology alone does not create recoverability. Runbooks, dependencies, access, DNS changes, credentials, backup integrity, and validation all matter during recovery.

Migration requires sequencing, validation, and a rollback strategy

Moving SAP to Azure can involve database migration, system copy, operating-system changes, connectivity redesign, downtime planning, and integration testing. Candidates should understand that migration risk is managed through sequencing and evidence, not by choosing a single transfer tool.

Inventory the existing landscape before designing the move. Capture versions, database sizes, growth, interfaces, batch schedules, custom code dependencies, authentication, certificates, network paths, and operational procedures. Then identify what must change and what must remain stable during cutover.

Dry runs are especially valuable. Measure transfer time, validate application startup, test interfaces, run representative transactions, and record how long rollback would take. Migration planning should include the people who operate the SAP system, not only the cloud team.

Security and identity should be integrated with SAP operations

Azure provides role-based access, network controls, encryption, secrets management, monitoring, and security posture tools, but candidates need to understand how these controls interact with SAP administration. Separate cloud-platform privileges from SAP application privileges and avoid giving broad Azure access merely because someone supports the application.

The article on Azure RBAC provides useful depth for the platform layer. Apply least privilege, use groups and managed identities where appropriate, and protect sensitive credentials. Record who can change infrastructure, restore data, modify networking, and administer SAP so critical operations remain auditable.

Security changes must also be tested for application impact. Tightening a firewall rule or rotating a certificate can break an interface even though the security control itself is correct. Build validation steps into security operations so protection and availability improve together.

Monitoring and cost optimization are part of sustained SAP operations

Running SAP on Azure requires ongoing observation of compute, memory, storage, networking, database health, application availability, and capacity trends. Candidates should know how Azure monitoring complements SAP-specific tools rather than replacing them.

Correlate infrastructure signals with business symptoms. A storage latency spike may line up with a slow batch process; CPU pressure may appear only during a specific reporting window; network loss may affect one integration path. The article on Azure logging and monitoring is useful for building this evidence chain.

Cost optimization should preserve supportability and performance. Review VM sizing, uptime schedules for nonproduction systems, storage tier, backups, data transfer, reservations or savings options where appropriate, and stranded resources. A cheaper configuration that creates an unsupported or unstable SAP environment is not an optimization.

AZ-120 preparation should combine architecture decisions with hands-on operations

A good study plan starts with the current April 17, 2026 objectives and uses AZ-120 preparation material only as supporting context. Build a small lab where possible, but also practice design on paper because not every SAP component is practical to reproduce in a personal subscription.

For each design scenario, record requirements before selecting services: availability, recovery, latency, throughput, data protection, security, support, cost, and operational ownership. Then explain why the chosen architecture meets those requirements and what happens when one component fails.

Broader Azure knowledge matters. The active Azure Administrator Associate material is useful for infrastructure operations, while Azure Solutions Architect Expert provides related design context. AZ-120 remains distinct because it applies those Azure disciplines to the performance, availability, migration, and operational realities of SAP.

Before scheduling the exam, be able to trace an SAP business service through application, database, compute, storage, network, identity, monitoring, backup, and recovery layers. That end-to-end view is the real skill the specialty is designed to validate.

Backup and restore design should be verified at the SAP workload level. Confirm what is protected, how frequently backups occur, where they are stored, how long they are retained, and which credentials or network paths are needed during recovery. Test a restore into an isolated environment and measure the elapsed time. A backup that has never been restored is only an assumption about recoverability.

The 2026 objectives also reference RISE with SAP, which means candidates should understand that some deployments involve shared operational responsibilities among Microsoft, SAP, the customer, and partners. Clarify who owns the operating system, database tasks, Azure resources, connectivity, backup, and monitoring for the specific deployment model. Many incidents become harder when teams assume another party owns a layer.

Infrastructure definitions can improve consistency across SAP environments. Use ARM or Bicep to make network, storage, compute, and supporting resources reviewable and repeatable where the workload model allows it. Parameterize environment differences rather than maintaining unrelated copies. Treat changes to infrastructure code as production changes with validation and rollback, particularly when a shared template can affect multiple systems.

Performance troubleshooting should begin with a timeline that combines SAP and Azure evidence. Correlate slow transactions with VM CPU, memory pressure, storage latency, network behavior, database waits, and application-server load. Avoid changing several layers at once. A disciplined sequence makes it possible to prove which resource was limiting the workload and whether the correction improved the business process.

Maintain a runbook for critical operations such as planned failover, emergency restart, storage expansion, certificate rotation, and regional recovery. Include prerequisites, expected duration, validation, and rollback. AZ-120 rewards candidates who can think through these operating details because a production SAP landscape is judged by continuity of business service, not by whether individual Azure resources are configured correctly in isolation.

Capacity planning should include growth rather than only current demand. Record database growth, peak memory use, seasonal transaction patterns, backup duration, and network utilization, then project when the current design will approach service limits. Revisit those assumptions after major SAP releases or business acquisitions. Cloud elasticity helps only when scaling decisions are anticipated and tested before a peak arrives.