Step-by-Step Guide to AZ-120 Planning and Administering Microsoft Azure for SAP Workloads

Preparing for Microsoft AZ-120 is easier when each study topic becomes an operational decision about an SAP landscape rather than a list of Azure product names. The April 17, 2026 Microsoft study guide covers migration, supporting infrastructure, high availability and disaster recovery, and ongoing SAP operations. The exam is about a supported SAP solution that can be moved, operated and restored, not merely about configuring a large virtual machine. A useful study project should therefore prove those relationships with a consistent example.

Use one fictional organization throughout your preparation: an SAP application tier depends on a central service, a database, corporate identity, several overnight integrations and a strict end-of-month reporting window. It must move from an on-premises site to Azure. Define its support constraints and business recovery targets before selecting resources. The exercises below are planning and nonproduction validation tasks; they are not instructions to interrupt a real SAP system.

Step 1 — Map the landscape and define success

Record the SAP product and release, operating system, database version, application servers, central services, external integrations, batch schedules and business owners. Determine what is supported by the current SAP and Azure certification or support material. A VM shown in a general Azure price list is not automatically supported for a particular SAP HANA configuration. Likewise, a database may require a specific deployment pattern or storage arrangement that a generic cloud diagram does not reveal.

Write a concrete acceptance statement. For example, ‘The finance close must finish within its existing processing window, users must complete a defined transaction after failover, and an outage must not exceed the signed-off recovery time and recovery point objectives.’ Separate facts measured on the existing estate from estimates based on interviews. Capture peak CPU and memory, data size and growth, I/O throughput, latency, connection dependencies and maintenance requirements. Average CPU alone is not an SAP sizing method.

Step 2 — Build a support-first Azure architecture

Choose only VM families, database combinations, storage and operating-system images supported for the selected SAP workload. Check subscription quotas and actual zonal or regional capacity, not just a marketing specification. Design identity, networking, storage, monitoring and deployment ownership together. If the chosen database needs very low storage latency, a fast compute SKU will not compensate for an unsuitable data and log layout.

Produce a one-page diagram showing the application tier, central services, database, backup target, identity service, network ingress and outbound integration paths. Mark which components have single points of failure and which are intentionally accepted risks. Keep a table of assumptions that would change the design: peak business load, software license rights, recovery objectives, network latency, and supported Azure service combinations.

Step 3 — Test networking and identity as application dependencies

SAP users and applications can depend on corporate DNS, directory services, load balancing, database connectivity and interfaces outside the SAP environment itself. Document the relevant subnets, routes, address spaces, name resolution and firewall boundaries before moving a component. For hybrid connectivity, inspect whether the chosen VPN or ExpressRoute path has adequate performance and a usable failover. A healthy tunnel indicator is not proof that an SAP transaction can reach every required service.

Construct a small connectivity matrix with source, destination, protocol, port, owner and required test. Validate forward and return paths on nonproduction endpoints. Deliberately make one name resolve incorrectly or one path unavailable, then identify the symptom and the responsible configuration. Preserve the least-privilege principle: granting overly broad access to repair a DNS or routing mistake creates a separate problem.

Step 4 — Choose migration sequencing and a cutover checkpoint

Decide which parts of the SAP landscape will be moved together, which will remain connected across the hybrid boundary and when writes to the original system must stop. Build a dependency order: database preparation, application and central-service changes, interfaces, authentication, monitoring and user traffic switch. Assess the tools and strategies Microsoft and SAP currently support for that source/target configuration rather than assuming one replication method works for every engine.

Define the point at which rollback stops being simple. Once the Azure target accepts new business transactions, returning clients to the old system without data reconciliation can discard legitimate work. Rehearse the cutover on representative data and record duration, row or transaction validations, application checks and the owner authorized to abort. A deployment that boots successfully but cannot reconcile orders or financial records has not passed migration acceptance.

Step 5 — Design high availability by SAP component

Availability zones and redundant VMs are infrastructure building blocks, not an SAP high-availability design. An application server, a central-services component and the database may use different supported failover patterns. Understand the place of clustering, fencing, virtual addresses, supported load-balancer probes, replication and application restart ordering for the chosen SAP stack. Make a separate failure-mode entry for a lost application VM, failed database node, unavailable storage volume and complete site disruption.

When rehearsing high availability, monitor an actual transaction from the client perspective. A database replica reported as healthy may not prove that an application tier has reconnected. Record the sequence of detected failure, service transition, data-consistency check and the point at which the user action works again. Include the failback and maintenance procedures because a working one-direction test is only part of operations.

Step 6 — Demonstrate backup and recovery, not only replication

High availability helps some component failures while backups can recover earlier application data states. A cluster can faithfully reproduce a mistaken deletion or corrupted transaction. Establish the RTO and RPO separately, then choose supported database backup, transaction-log, snapshot and infrastructure protection methods. Verify how encryption keys, secrets, SAP configuration and external dependencies are restored along with the data.

Run a recovery exercise using safe sample records. Restore a recoverable point to an isolated environment and validate the database, selected SAP functions and any essential integrations. Measure the elapsed time until the business-level test succeeds. Include the possibility that the backup is available but permissions, DNS or a supporting identity service are not. Document why the chosen procedure would or would not meet the agreed recovery targets.

Step 7 — Operate and monitor the complete SAP service

Azure infrastructure health and SAP business health are not identical. VM CPU, disk throughput and network metrics help troubleshoot performance, but they should be correlated with SAP transactions, database signals, batch runs and real user behavior. A transaction slowdown may originate in storage latency even when the VM is online. An integration failure may arise from a stale credential rather than a compute shortage.

Create a basic operating runbook: how to respond to a storage latency alert, a failed SAP interface, a maintenance restart and an unexpectedly delayed backup. Record the responsible operator, decisive evidence and permitted corrective change. For planned operating-system, database or SAP updates, respect supported sequencing and test the resulting application functions before returning the service to production. Review Azure cost only after the performance and availability requirements are understood; a smaller VM is not economical if it prevents business processing during the peak window.

Step 8 — Produce one final AZ-120 design-and-operations packet

Microsoft’s April 2026 skills weights are migration 25–30%, infrastructure 25–30%, high availability/disaster recovery 20–25%, and maintenance 20–25%. Use those ranges as a coverage guide, not as a guarantee of the exact number of questions. Your final packet should show support evidence, measured sizing assumptions, a network diagram, chosen migration path, failover behavior, recoverable backup, one monitored incident and a documented cost trade-off.

Ask another engineer to challenge the packet with a changed requirement: the approved downtime becomes shorter, a database grows faster than expected, or a regional service is unavailable. Explain which design assumption breaks and how you would validate a replacement. The ability to revise a supported design under constraints is a stronger indication of AZ-120 readiness than memorizing every Azure feature named by an older course.

The result should also be professionally useful after the exam: a migration and operations plan another team can inspect, reproduce in a safe environment and update from current Microsoft and SAP sources. That is the difference between knowing the names of SAP-on-Azure services and being ready to make defensible decisions about them.

• Category: All Certifications Microsoft
• Tags: AZ-120, azure, microsoft