From Planning to Execution: AZ-120 Planning and Administering Microsoft Azure for SAP Workloads
Moving an SAP landscape to Azure is not equivalent to lifting a conventional web application onto virtual machines. Database throughput, supported operating systems, tightly coupled application tiers, network latency and business continuity all affect whether a deployment can be supported by SAP and operated within the organization’s service commitments. The Microsoft AZ-120 exam covers planning and administering Azure for SAP workloads. It belongs to Microsoft’s Azure for SAP Workloads Specialty pathway; it is an exam, not a separate credential named ‘AZ-120 certification.’
Microsoft’s April 2026 AZ-120 study guide includes migrating SAP workloads, designing and implementing infrastructure, high availability and disaster recovery, and maintaining operations. A successful candidate must connect Azure infrastructure decisions with SAP-specific requirements. The core discipline is to verify supported configurations and workload measurements before sizing services or promising recovery outcomes. This discussion focuses on the technical decisions that matter in real SAP-on-Azure projects rather than on exam-day rituals.
Baseline the SAP system before choosing Azure resources
Start with an inventory of the SAP products, release levels, database engine, operating system, connected applications and licensed components. Record current CPU utilization, memory behavior, database size and growth, storage throughput, latency-sensitive operations and peak business cycles. A production system may have short transaction bursts and long batch windows; average utilization can hide both. Map interface dependencies and identity services that must remain reachable after migration. The baseline becomes the reference for architecture acceptance tests.
Confirm the target configurations against current SAP support material and Azure’s workload certification guidance. A virtual machine size appearing in a price calculator does not establish that its combination of operating system, database and SAP product is supported. The same applies to particular storage approaches and high-availability arrangements. SAP certification notes and Microsoft guidance are essential when evaluating a proposed combination. Do not interpret generic cloud compatibility as a substitute for product-specific support requirements.
For the migration itself, determine which periods allow downtime and which data must stay synchronized until cutover. Database migration, application server rebuild, DNS and interface changes may have different schedules. Document how writes will be frozen or reconciled, which validation reports must match and who authorizes production traffic to switch. A rollback plan must acknowledge when changes to the new database can no longer be reversed without losing legitimate transactions. An architecture is incomplete if its cutover procedure relies on an unrealistic promise of zero downtime.
Design compute, storage and network as one performance envelope
SAP system sizing should reflect certified compute options and the measured resource needs of the chosen database and application stack. Memory is particularly consequential for SAP HANA, and CPU sizing must consider real concurrency and batch processing patterns. Avoid simply applying a generic ‘scale out if needed’ principle to tightly coupled stateful components. Capacity decisions should include growth headroom, maintenance and failover behavior, not just normal-day resource consumption.
Storage architecture requires measured IOPS, throughput and latency objectives. Database data, logs and backups may have different performance and retention needs. The selected Azure disks or other supported storage option must meet the relevant SAP and database requirements, including backup and recovery operations. A highly provisioned storage tier is not automatically appropriate if the guest configuration or application path becomes the bottleneck. Test representative workloads after provisioning and preserve performance baselines for later diagnosis.
A network design must identify application-server-to-database paths, corporate clients, SAP interfaces and administrative access. Latency and name resolution can affect business transactions even when every Azure resource reports healthy. Azure virtual machine configuration is one component of this design, not its entire security or performance story. Subnet boundaries, effective routes and access controls should be tested with actual required traffic, and hybrid connectivity should include return paths and failover behavior.
Define high availability at the SAP-component level
SAP application servers, central services and the database do not share identical failover mechanisms. A redundancy design needs to account for the supported cluster and availability patterns of each component, including where state is stored and how clients reconnect after failover. Deployment across availability zones may improve tolerance to specified infrastructure failures, but only when the chosen SAP stack, storage, cluster configuration and network design support it. Distributing VM instances alone does not produce a valid SAP high-availability solution.
Plan the role of load balancing carefully, especially for central services and other cluster-managed endpoints. Ensure the relevant cluster probe, virtual hostname, service address and dependency behavior match the supported pattern. Operators should know what symptoms indicate a failed application server versus a database replica or a connectivity issue. An engineer who can explain the failover state transitions is better equipped to troubleshoot than one who knows only that a second VM exists.
Regional disaster recovery requires its own recovery-time and recovery-point objectives. A customer may require continuity after a local node fault but permit a longer restoration period after a regional disruption. Do not solve those different risks with one vague claim of ‘geo-redundancy.’ Consider data replication mode, recovery sequence, application configuration and the time needed to establish connectivity in the alternate location. Azure regions and availability zones define useful failure boundaries, but service-specific support and recovery testing determine the actual behavior.
Design backup and restore around transactional consistency
Backups must be consistent with the database’s supported methods and integrated with the SAP recovery procedure. Taking a snapshot without considering in-flight transactions or log management can give a false sense of recoverability. Document where database backups and logs reside, how frequently they are captured, the retention and encryption requirements, and who has permission to restore sensitive business information. The restore process needs to include the relevant system identifiers, configuration and application dependencies.
Rehearse recovery with a nonproduction copy and confirm more than the existence of files. Can the database be recovered to the intended point? Do application servers reconnect? Are critical transactions readable and the required interfaces functional? Azure backup and recovery concepts can inform the design, but SAP database and product requirements must still govern which mechanism is valid. Record elapsed restoration time and the business steps needed for a complete service recovery.
A disaster-recovery test also needs a return path. If the organization fails over to another location, determine how it will re-establish a normal operating configuration, reconcile data and plan failback without an unexpected second outage. Communication with the application owner is part of the runbook: technical indicators alone cannot determine that financial postings, batch jobs and external integrations are safe to resume.
An SAP recovery design also depends on organizational testing authority. A technical team may be able to fail over a database in isolation, but business owners must confirm that the application is consistent for real processes such as purchase orders, invoicing or payroll. Define which nonproduction test transactions will prove the system functional and which external interface teams must participate. In a tightly integrated enterprise, the recovery time of the slowest essential dependency can determine when service can resume, even after SAP components appear healthy.
Monitor the business service, not only the virtual machines
Azure infrastructure monitoring should be correlated with SAP and database signals. VM availability and CPU metrics may look healthy while application response time deteriorates because of storage latency, a blocked interface or a database bottleneck. Azure Monitor alerting can deliver relevant infrastructure signals to responders, but its effectiveness depends on thresholds, ownership and the additional SAP-specific evidence available. Design alert routing so a support team knows what to investigate next.
Maintenance planning must also account for supported patching sequences and the organization’s business calendar. Host operating system updates, database patches and SAP upgrades can have dependencies and validation requirements. A patch process that works for a standalone VM can break an SAP service if the cluster, interface or database state is ignored. Keep a documented baseline, test in a representative environment, establish rollback boundaries and obtain approval for any business outage.
Cost optimization should follow measurements and support constraints. Downsizing a database VM based on average CPU can cause failures during peak posting cycles, while excessive standby capacity may be difficult to justify where recovery objectives are modest. Include storage, network connectivity, backup retention, licensing assumptions and operational staffing in the estimate. Validate changes against workload evidence, not a generic cloud-savings percentage.
Prepare for AZ-120 through supported, testable decisions
A practical examination scenario might ask how to migrate a large SAP HANA system within a constrained outage window, keep central services available across a fault, or restore transactions after storage failure. The strongest answer names the decisive support and recovery conditions, explains why an alternative does not meet them, and identifies what would be tested before production cutover. Work through current Microsoft and SAP documentation with a real deployment diagram, not a memorized list of Azure services.
For every design, keep a short evidence register: supported configuration reference, resource-sizing assumption, measured baseline, recovery objective, migration sequence and responsible operator. That record is useful both in AZ-120 preparation and in an actual change review. The goal is not to make SAP administration look simple; it is to make the unavoidable complexity visible, supported and recoverable. The specialty path becomes meaningful when a candidate can defend those decisions and explain how the deployed SAP environment will remain safe to operate.
- Category: All Certifications Microsoft
- Tags: SAP Workloads
