---
title: "AZ-120 Study Guide — Azure for SAP Workloads Specialty"
description: "An interactive study guide built on 7 memory techniques to help you pass the Azure for SAP Workloads Specialty exam."
url: "https://lucidlabs.com.au/insights/az-120"
---

# Master the AZ-120

An interactive study guide built on 7 memory techniques to help you pass the Azure for SAP Workloads Specialty exam.

Migrate SAP Workloads to Azure ~25%Design & Implement Infrastructure ~25%High Availability & Disaster Recovery ~25%Maintain SAP Workloads on Azure ~25%

What it covers

Migration paths (classical, DMO, heterogeneous system copy) to Azure, SAP-certified compute (Mv2, Msv3, Mdsv3) and Azure Large Instances, HANA-qualified storage (Azure NetApp Files, Premium SSD v2), networking (ExpressRoute, proximity placement groups), HANA System Replication with Pacemaker/WSFC clustering, Azure Site Recovery, and ongoing operations via Azure Center for SAP solutions, Azure Monitor for SAP solutions, and Azure Backup. Microsoft does not publish per-domain weightings for this exam — the four domains above are treated as roughly equal in emphasis.

Ideal for

SAP Basis administrators, infrastructure architects, and cloud engineers who design, migrate, and operate SAP landscapes on Azure — including RISE with SAP engagements.

Aspire to this if

You run or are moving an SAP HANA / Business Suite / NetWeaver landscape onto Azure and need to prove you can size it, migrate it, keep it highly available, and keep it running — alongside AZ-104 as the recommended foundation.

Section 1 / Spatial Memory

## The Map

Tap any component to see what you need to know for the exam.

**🧮 Sizing & Assessment**

Quicksizer · Azure Migrate · TCO

**🚚 Migration Paths**

Classical · DMO · System Copy

**🤖 Deployment Automation**

ACSS · SDAF · Bicep/ARM

**🖥️ SAP-Certified Compute**

Mv2 · Msv3/Mdsv3 · Large Instances

**💾 Storage for HANA**

ANF · Premium SSD v2 · Ultra Disk

**🌐 Networking**

ExpressRoute · PPG · Peering

**🔄 HANA System Replication**

Sync · Async · Multi-Target

**🐧 Pacemaker Clustering**

SUSE/RHEL · STONITH · Fencing

**🪟 Disaster Recovery**

Azure Site Recovery · Async HSR

**📡 Monitoring**

Azure Monitor for SAP · ACSS

**💽 Backup & Recovery**

Azure Backup for SAP HANA

**🔧 Change & Patch Mgmt**

Maintenance Planner · SUM

Section 2 / Narrative Memory

## The Story

Follow the narrative to build a mental model of how everything connects.

🧮

### Measuring Before You Build

Every SAP-on-Azure project starts with knowing what you’re actually moving. SAP Quicksizer translates business load into SAPS, the currency Azure VM sizing understands. Azure Migrate discovers the on-prem estate and flags readiness gaps. A TCO calculation makes the business case, and every system gets classified by tier — HANA DB, app, or Web Dispatcher — because each sizes differently.

**Exam Intel**Know that HANA sizing is memory-led, not core-led — memory:vCPU ratios on certified VMs are fixed, unlike generic Azure sizing. Quicksizer output feeds VM family selection; Azure Migrate feeds the migration wave plan.

🚚

### Choosing How to Move

Classical migration exports and imports data via R3load — reliable, works across any OS/DB combination, but slow for big databases. DMO inside Software Update Manager folds an upgrade and a HANA migration into one guided project, which is exactly what an S/4HANA conversion needs. Heterogeneous system copy handles a straight OS/DB swap, and near-zero-downtime add-ons shrink the cutover window when the business can’t afford a long outage.

**Exam Intel**DMO = upgrade + migrate combined (S/4HANA conversions). Classical = simpler OS/DB change only, no version jump. Know which tool (SWPM vs SUM) drives each path, and that nZDM/table splitting are downtime-reduction add-ons, not migration methods on their own.

🤖

### Deploying Without Repeating Yourself

Once the target is chosen, deployment shouldn’t be manual clicking. Azure Center for SAP solutions gives a native, portal-driven way to deploy and manage an SAP system as a single Virtual Instance for SAP solutions. SAP Deployment Automation Framework does the same job as code — Terraform for infrastructure, Ansible for configuration — for teams that want pipeline-driven, repeatable landscapes across dev, QA, and prod.

**Exam Intel**ACSS = Azure-native, works for both greenfield deploys and brownfield registration of existing systems. SDAF = infrastructure-as-code, Terraform + Ansible, best for teams standardising many landscapes. Both can coexist — ACSS can manage systems SDAF deployed.

🖥️

### Picking the Right Iron

The HANA database tier needs SAP-certified compute — Mv2 for the largest scale-up systems, Msv3/Mdsv3 as the current generation across most workloads. When even the biggest certified VM isn’t enough, Azure Large Instances step in as bare-metal units for extreme-scale HANA. The application tier, by contrast, runs comfortably on general-purpose VMs, sized separately from the database.

**Exam Intel**Always validate a VM SKU against the SAP Certified and Supported SAP HANA Hardware Directory before proposing it. Constrained-vCPU SKUs are a licensing lever, not a performance one — same memory and I/O, fewer billable/licensable cores. HLI/BMI is the exception, not the default.

💾

### Feeding the Database

HANA is only as fast as its storage. Azure NetApp Files gives the shared, low-latency throughput large HANA databases demand, plus fast snapshot-based backup. Premium SSD v2 and Ultra Disk cover the same latency requirement without ANF’s shared-storage model. Write Accelerator specifically targets the log volume, where every millisecond of commit latency matters.

**Exam Intel**HANA storage is always split by purpose: /hana/data, /hana/log, /hana/shared, backup — each with its own throughput/latency target. HWCCT (HANA Hardware Configuration Check Tool) is the tool that proves the storage meets SAP’s TDI KPIs before go-live.

🌐

### Wiring the Landscape

None of this works without the network underneath it. ExpressRoute carries SAP GUI, RFC, and interface traffic privately from on-prem into Azure. Proximity Placement Groups pull the DB and app-tier VMs close together to cut inter-tier latency, and Accelerated Networking strips overhead off every NIC in the path. Hub-spoke VNets then keep dev, QA, and prod cleanly separated.

**Exam Intel**PPG matters most for latency-sensitive DB–app pairs, not for HA cluster pairs across zones (which need distance, not proximity). Load balancer health probes must be tuned to SAP-specific ports, or failover looks healthy when the SAP service isn’t actually up.

🔄

### Never Losing the Database

HANA System Replication is the heartbeat of SAP high availability — a continuous copy of the primary database streaming to a standby. Synchronous mode holds the primary’s commit until the secondary confirms, buying zero data loss at a small latency cost; asynchronous mode lets the primary commit independently, which is what makes it safe over long distances. But replication alone doesn’t fail over anything — that’s Pacemaker’s job.

**Exam Intel**Sync/syncmem = in-region HA, near-zero RPO. Async = cross-region DR, small RPO. Multi-target HSR chains both from one primary. HSR without a cluster manager is just replication — the exam likes to test whether you remember failover still needs Pacemaker or WSFC.

🐧

### Automating the Failover

Pacemaker and Corosync turn HANA System Replication into real high availability on Linux — detecting a failed primary and promoting the secondary automatically. STONITH, backed by the Azure fence agent, forcibly powers off a misbehaving node through the Azure Fabric so two nodes never both think they’re primary. The same pattern protects SAP’s central services via ASCS/ERS enqueue replication clustering, with a Standard Load Balancer routing traffic to whichever node is active.

**Exam Intel**STONITH/fencing is non-negotiable in the exam’s mental model — no fencing agent means no supported HA cluster. Know that Windows landscapes use WSFC instead of Pacemaker, with the same conceptual role (quorum + failover + resource protection).

🧡

### Surviving a Region

HA protects against a node or zone failing; disaster recovery protects against losing an entire region. Asynchronous HSR keeps a warm HANA standby ready in a second region, while Azure Site Recovery handles the app-tier and non-HANA VMs that don’t need HANA-aware replication. Cross-region ExpressRoute and VNet peering make sure the network path survives the same failover the compute just went through.

**Exam Intel**ASR does VM/disk-level replication — fine for app servers, not guaranteed application-consistent for the HANA DB. That’s why the DB tier leans on async HSR instead. Define RPO/RTO per system tier, and test failover — an untested DR plan is treated as no DR plan on the exam.

📡

### Watching the Whole Estate

Once live, an SAP landscape needs eyes on it around the clock. Azure Monitor for SAP solutions pulls together telemetry that generic Azure Monitor can’t — HANA DB internals, cluster state from Pacemaker, OS metrics, and NetWeaver health — into one purpose-built workspace. ACSS layers quality checks and recommendations on top, and Log Analytics workbooks turn the raw data into an operational dashboard the team actually watches.

**Exam Intel**AMS is a named, purpose-built service — know it by name, not just "Azure Monitor". Its provider model (HANA, cluster, OS, NetWeaver, Prometheus) is how it differs from a generic VM insights setup.

💽

### Keeping the Safety Net Current

Backups close the loop. Azure Backup for SAP HANA integrates via SAP’s Backint interface to take application-consistent full, incremental, and log backups straight into a Recovery Services vault. For the largest databases, ANF snapshot-based backup gets near-instant backup and restore times that streaming backup can’t match. Meanwhile, Maintenance Planner and SUM keep the software itself current — planning and executing patches without breaking SAP’s support compatibility matrix.

**Exam Intel**Backint = the SAP-defined interface Azure Backup uses, so backups are HANA-consistent, not just disk snapshots. Restore testing is as examinable as backup configuration — a backup nobody has restored is an assumption, not a guarantee.

Section 3 / Acronym Memory

## Mnemonic Wall

Memorable acronyms and phrases to anchor key exam concepts in your memory.

🧮

QAT

**Q**uicksizer, **A**zure Migrate, **T**CO calculator

The pre-migration assessment triad. Quicksizer = SAPS load. Azure Migrate = discovery/readiness. TCO = the business case.

🚚

CDH

**C**lassical, **D**MO, **H**eterogeneous system copy

Three SAP migration path patterns. Classical = export/import. DMO = upgrade + migrate combined. Heterogeneous = OS/DB change only.

🤖

A + S

**A**CSS + **S**DAF

The two Azure-native deployment automation routes for SAP. ACSS = portal-driven, manages the VIS. SDAF = Terraform + Ansible, code-driven.

🖥️

MMH

**M**v2, **M**sv3/Mdsv3, **H**LI/BMI

Compute tiers for HANA, from certified VM up to bare metal. Check the SAP HANA Hardware Directory before proposing any of them.

🔄

HSR + P

**H**ANA **S**ystem **R**eplication + **P**acemaker

Replication alone does not fail over. HSR replicates data; Pacemaker (with STONITH) is what actually promotes a secondary automatically.

📡

AMB

**A**MS (monitoring), **M**aintenance Planner, **B**ackint (Azure Backup for HANA)

The three ongoing-operations pillars once a system is live: watch it (AMS), patch it (Maintenance Planner/SUM), and protect it (Backint).

Section 4 / Contrast Memory

## Versus Arena

Side-by-side comparisons to sharpen your understanding of similar concepts.

vs

Large InstancesvsSAP-Certified VMs

Click to compare

#### Compute Options for HANA

| Aspect | Large Instances | SAP-Certified VMs |
| --- | --- | --- |
| Deployment model | Bare-metal dedicated unit | Standard Azure VM |
| Provisioning | Nomination + lead-time process | Self-service via portal, ACSS, or IaC |
| Scale | Extreme-scale, largest single-node HANA | Up to several TB (Mv2), growing with new SKUs |
| Connectivity | ExpressRoute into customer VNet | Native VNet deployment |
| When to use | Beyond current certified VM memory ceiling | Default choice for new SAP-on-Azure deployments |
| Certification list | SAP HANA Hardware Directory (HLI) | SAP-certified Azure VM types list |

Click to flip back

vs

HANA System ReplicationvsAzure Site Recovery

Click to compare

#### Replication & DR Mechanisms

| Aspect | HANA System Replication | Azure Site Recovery |
| --- | --- | --- |
| Layer | Database-level (HANA-aware) | VM/disk-level (infrastructure) |
| Consistency | Application/DB-consistent by design | Crash-consistent unless app-aware |
| Best for | HANA DB tier HA and DR | App tier and non-HANA DB DR |
| Failover automation | Needs Pacemaker/WSFC for automated cutover | Built-in orchestrated failover |
| Typical use | Primary HA/DR strategy for the HANA DB | Complements HSR for the rest of the landscape |
| RPO | Near-zero (sync) to small lag (async) | Minutes, replication-interval dependent |

Click to flip back

vs

Classical MigrationvsDMO

Click to compare

#### SAP Migration Approaches

| Aspect | Classical Migration | DMO |
| --- | --- | --- |
| Method | Export/import via R3load | In-place upgrade + migration combined |
| Downtime | Longer, proportional to DB size | Shorter with near-zero-downtime options |
| Use case | Simple systems, OS/DB change only | S/4HANA conversion or NetWeaver-to-HANA move |
| Tooling | Software Provisioning Manager (SWPM) | Software Update Manager (SUM) |
| Complexity | Lower, well-understood | Higher, but avoids a separate migration step |
| Version change | Not required | Typically bundled with an upgrade |

Click to flip back

vs

SynchronousvsAsynchronous HSR

Click to compare

#### HANA System Replication Modes

| Aspect | Synchronous | Asynchronous HSR |
| --- | --- | --- |
| Data loss (RPO) | Zero to near-zero | Small replication lag possible |
| Distance | Same region, low-latency link | Cross-region, long-distance safe |
| Performance impact | Higher (commit waits for secondary) | Lower (primary commits independently) |
| Typical role | HA within a region/zone | DR across regions |
| Combine as | Primary → sync HA replica | → async DR replica (multi-target) |
| Failover trigger | Automated via Pacemaker | Usually manual/orchestrated DR runbook |

Click to flip back

vs

PacemakervsWindows Server Failover Clustering

Click to compare

#### OS-Level HA Clustering

| Aspect | Pacemaker | Windows Server Failover Clustering |
| --- | --- | --- |
| OS | Linux (SUSE, RHEL) | Windows Server |
| Fencing | STONITH via Azure fence agent | Cloud witness or shared disk quorum |
| Managed via | crm shell / Hawk / corosync.conf | Failover Cluster Manager / PowerShell |
| SAP integration | SAPHana/SAPHanaTopology + SAPInstance resource agents | SAP-specific resource DLLs |
| Typical target | Linux-based HANA and NetWeaver systems | Windows-based NetWeaver/ASCS systems |
| ASCS protection | Enqueue replication (ENSA1/ENSA2) via RA | Enqueue replication via SAP cluster resources |

Click to flip back

Section 5 / Grouping Memory

## Cheat Sheet

Organised reference grouped by exam domain — everything you need on one page.

### Migrate SAP Workloads to Azure

~25%

#### Assessment & Sizing

-   SAP Quicksizer estimates SAPS from business load
-   Azure Migrate discovers and assesses on-prem readiness
-   TCO calculator builds the cost/performance business case
-   Classify systems by tier: HANA DB, ASCS/app, Web Dispatcher

#### Migration Paths

-   Classical migration: SWPM + R3load export/import
-   DMO in SUM: combined upgrade + migration to HANA
-   Heterogeneous system copy: change OS/DB without upgrading
-   nZDM/table splitting: shrink cutover downtime on huge DBs

#### Deployment Tooling

-   ACSS: native deploy/manage/monitor via a VIS
-   SDAF: Terraform + Ansible, code-driven deployment
-   ARM/Bicep provision underlying infra (VM, disk, VNet)
-   ACSS supports brownfield registration of existing systems

#### Landing Zone

-   Hub-spoke VNet design for dev/QA/prod separation
-   Management group/subscription structure for governance
-   Consistent naming and tagging for SAP resources
-   Shared services (DNS, firewall, ExpressRoute) in the hub

### Design & Implement Infrastructure

~25%

#### Compute

-   Mv2/Msv3/Mdsv3: current SAP-certified VM families
-   Constrained-vCPU SKUs cut licensable cores, not memory
-   HLI/BMI Large Instances for extreme-scale HANA
-   Check the SAP HANA Hardware Directory before proposing a SKU

#### Storage

-   Azure NetApp Files for HANA data/log at scale
-   Premium SSD v2/Ultra Disk as the non-shared alternative
-   Write Accelerator cuts log-volume write latency
-   HWCCT validates HANA TDI throughput/latency KPIs

#### Networking

-   ExpressRoute for private hybrid connectivity
-   Proximity Placement Groups for DB–app latency
-   Accelerated Networking on SAP VM NICs
-   Load balancer HA ports + health probes for cluster IPs

#### Provisioning Standards

-   Availability Zones/Sets for baseline resilience
-   Consistent VM/disk naming across the landscape
-   Resource tagging to track SAP system membership
-   Separate resource groups per system/environment

### High Availability & Disaster Recovery

~25%

#### High Availability

-   HANA System Replication (sync/syncmem) for in-region HA
-   Pacemaker + Corosync orchestrate automated failover
-   STONITH via Azure fence agent prevents split-brain
-   ASCS/ERS enqueue replication clustering (ENSA1/ENSA2)

#### Disaster Recovery

-   Async HSR replicates the HANA DB cross-region
-   Azure Site Recovery covers app/non-HANA tiers
-   Multi-target HSR: sync HA replica + async DR replica
-   DR runbooks with regular, tested failover

#### Load Balancing

-   Standard Load Balancer required for HA scenarios
-   Floating/virtual IP fronts the active cluster node
-   HA ports rule load-balances all SAP ports at once
-   Health probes tuned to SAP-specific service ports

#### Resilience Design

-   Availability Zones (zone failure) vs Sets (rack failure)
-   RPO/RTO defined per SAP system tier
-   Redundant ExpressRoute circuits into the DR region
-   Test failover on a schedule, not just at go-live

### Maintain SAP Workloads on Azure

~25%

#### Monitoring

-   Azure Monitor for SAP solutions (AMS) for unified telemetry
-   Providers: HANA, cluster, OS, NetWeaver, Prometheus
-   ACSS quality checks flag config drift and recommendations
-   Log Analytics workbooks/alerts for proactive maintenance

#### Backup & Recovery

-   Azure Backup for SAP HANA via Backint integration
-   ANF snapshot-based backup for near-instant restore
-   Full/incremental/log backup cadence per RPO target
-   Regular restore/recovery testing, not just backup success

#### Patch & Change Management

-   SAP Maintenance Planner plans compatible patch stacks
-   SUM executes upgrades and support package installs
-   Sequenced dev → QA → prod patch windows
-   Respect SAP maintenance/compatibility matrices

#### Operations Governance

-   Azure Policy enforces SAP landscape compliance
-   Reservations/savings plans for M/Mv2/Msv3 VM cost
-   RBAC for management plane, SAP authorisations for data plane
-   Documented runbooks for routine operational tasks

Section 6 / Method of Loci

## The Memory Palace

Walk through themed rooms — each object anchors a concept in spatial memory.

### The Migration Bay

Migrate SAP Workloads — Where the journey to Azure begins

🧮

Quicksizer

SAP tool estimating SAPS load to size target Azure compute correctly before migration

🔍

Azure Migrate

Discovers and assesses on-prem SAP landscape readiness for Azure

🚚

DMO (in SUM)

Combines upgrade and HANA migration into a single guided process

🏗️

ACSS

Native Azure service to deploy, manage, and monitor SAP systems as a VIS

🧩

SDAF

Terraform + Ansible framework for repeatable, code-driven SAP deployment

### The Infrastructure Foundry

Design & Implement Infrastructure — Where compute, storage, and network are forged

🖥️

Mv2/Msv3

Current SAP-certified VM families for HANA and application tiers

🏛️

Large Instances

Bare-metal HLI/BMI for extreme-scale HANA beyond VM memory ceilings

💾

Azure NetApp Files

Low-latency shared storage for HANA data/log volumes at scale

⚡

Write Accelerator

Cuts log-volume write latency on Premium SSD-backed M-series VMs

🌐

ExpressRoute

Private, low-latency link between on-prem SAP users and the Azure landscape

### The Resilience Bunker

High Availability & Disaster Recovery — Where uptime is engineered

🔄

HANA System Replication

Continuous DB replication to one or more standby HANA instances

🐧

Pacemaker

Linux cluster manager automating failover for HANA and ASCS/ERS

🛑

STONITH / Fence Agent

Forcibly powers off a failed node via the Azure Fabric to prevent split-brain

🪟

Azure Site Recovery

Regional DR replication for app-tier and non-HANA VMs

⚖️

Standard Load Balancer

Routes traffic to the active cluster node via floating IP and HA ports

### The Operations Command Centre

Maintain SAP Workloads — Where the estate is kept healthy

📡

Azure Monitor for SAP solutions

Purpose-built telemetry for HANA, cluster, OS, and NetWeaver

💽

Azure Backup for SAP HANA

Backint-integrated, application-consistent backup to a Recovery Services vault

🗓️

Maintenance Planner

Plans compatible OS/DB/kernel patch and support package stacks

🔧

Software Update Manager

Executes upgrades and support package stack installs

✅

ACSS Quality Checks

Flags configuration drift against SAP and Azure best practices

Section 7 / Pattern Recognition

## Pattern Spotter

Decision trees and trigger-answer pairs — see the pattern, know the answer.

Which SAP Compute Tier?

Which SAP Compute Tier?  
  ├── Standard S/4HANA or NetWeaver production HANA DB → Mv2 or Msv3/Mdsv3 SAP-certified VM  ├── Need lower core count for licensing, same memory → Constrained-vCPU variant of the certified VM  ├── HANA scale-up beyond current VM memory ceiling → Azure Large Instances (HLI/BMI)  ├── Dev/test or small sandbox system → Smaller certified VM, right-sized for the workload  └── Non-HANA app/ASCS tier → General-purpose or compute-optimised VM (no HANA cert needed)

Which Migration Path?

Which Migration Path?  
  ├── Upgrading and moving to HANA in one project → DMO within Software Update Manager  ├── Simple OS/DB change, no version upgrade → Classical migration (SWPM/R3load)  ├── Moving between different OS and DB combinations → Heterogeneous system copy  ├── Need to shrink cutover downtime on a huge HANA DB → Near-zero-downtime techniques (table splitting, DMO nZDM)  ├── Need portal-native, guided Azure deployment → Azure Center for SAP solutions (ACSS)  └── Need IaC, pipeline-driven repeatable deployment → SAP Deployment Automation Framework (SDAF)

Which HA/DR Mechanism?

Which HA/DR Mechanism?  
  ├── HANA DB needs automated in-region failover → Synchronous HSR + Pacemaker cluster  ├── HANA DB needs cross-region resilience → Asynchronous HSR to a secondary region  ├── ASCS/ERS single point of failure needs protecting → Pacemaker (Linux) or WSFC (Windows) with enqueue replication  ├── App-tier VMs and non-HANA components need DR → Azure Site Recovery  ├── Protecting against a zone outage, not a full region → Availability Zones  └── Preventing split-brain in a Linux cluster → STONITH via the Azure fence agent

Which Ongoing-Operations Tool?

Which Ongoing-Operations Tool?  
  ├── Need unified SAP telemetry (DB, cluster, OS, NetWeaver) → Azure Monitor for SAP solutions (AMS)  ├── Need HANA-consistent backup direct to a vault → Azure Backup for SAP HANA (Backint)  ├── Need near-instant backup/restore for a huge HANA DB → ANF snapshot-based backup  ├── Planning a patch/upgrade stack → SAP Maintenance Planner  ├── Executing an upgrade or support package install → Software Update Manager (SUM)  └── Checking for configuration drift vs best practice → ACSS quality checks

## Decision Cards

“SAPS” or “sizing the target VM”→SAP Quicksizer output drives VM/compute selection

“combined upgrade and HANA migration”→Database Migration Option (DMO) within SUM

“bare metal” or “beyond VM memory limits”→Azure Large Instances (HLI/BMI)

“low-latency shared storage for HANA”→Azure NetApp Files (ANF)

“zero data loss HA within a region”→Synchronous HANA System Replication (HSR)

“cross-region HANA resilience”→Asynchronous HANA System Replication

“prevent split-brain” or “fencing”→STONITH via the Azure fence agent in a Pacemaker cluster

“single point of failure for central services”→ASCS/ERS clustering with enqueue replication

“purpose-built SAP telemetry service”→Azure Monitor for SAP solutions (AMS)

“application-consistent HANA backup to a vault”→Azure Backup for SAP HANA (Backint integration)

Ready to certify?

## Train with practitioners, not presenters

Lucid Labs delivers Microsoft certification training led by Microsoft Certified Trainers (MCTs) and grounded in real-world project experience. We adapt every session to your team's environment, data stack, and business objectives — because the best exam prep comes from engineers who build these solutions every day.

🎯

SAP-Specific Curriculum

Training built around your actual SAP HANA landscape, VM sizing, and migration plan — not generic Azure slides. Pairs naturally with our SAP on Microsoft Cloud practice.

🛠️

Hands-On HA/DR Labs

Configure HANA System Replication, Pacemaker clustering, and Azure Site Recovery in guided lab environments that mirror production SAP landscapes.

📈

Exam + Real Capability

Pass AZ-120 and walk away able to design, deploy, and operate SAP on Azure — skills your team can apply immediately, backed by our dedicated SAP consulting practice.

[Talk to us about Azure for SAP Workloads (AZ-120) training](https://lucidlabs.com.au/?service=training-consulting&message=I%27m%20interested%20in%20Azure%20for%20SAP%20Workloads%20\(AZ-120\)%20training%20for%20my%20team%20-%20covering%20SAP%20HANA%20infrastructure%2C%20migration%2C%20and%20HA%2FDR%20on%20Azure.#contact)

Custom training for teams & individuals — remote or on-site across Australia

![Keith Oak](https://lucidlabs.com.au/team/koak-400.jpg)

Keith Oak

Chief Technology Officer — Lucid Labs

Microsoft Solutions Partner architect specialising in Fabric, Azure Data & AI, and GitHub Enterprise. 18+ years delivering data platforms for Australian businesses — building the systems these exams test every day.

[LinkedIn ↗](https://www.linkedin.com/in/keithoak/)[lucidlabs.com.au ↗](https://lucidlabs.com.au/)Published 29-03-2026