Memory hook: Certified, sized, fenced, recoverable.
Reviewed 10 October 2026. Read this once, then answer the last-pass checks without looking.
Must remember by domain
| Domain | Rapid revision |
|---|---|
| Migration assessment | Inventory SAP versions, databases, OS, interfaces, SAPS/memory/IO and downtime. A generally available VM is not automatically SAP-certified. Lift-and-shift preserves more stack; platform/database migration adds compatibility/conversion work; HANA transformation needs its own supported tooling and validation. |
| Landing zone/RISE | Plan subscription quota, certified regional capacity, licensing, support, Policy/RBAC and cost before cutover. SAP application authorization differs from Azure resource access. RISE assigns different operational responsibilities to SAP/customer; explicitly allocate connectivity, identity, backup, monitoring and change ownership. |
| Compute/network | Use certified VM/OS combinations, SAP extensions and repeatable Bicep/ARM, Deployment Automation Framework or supported Center for SAP solutions workflows. Proximity placement favors low latency; zones favor failure isolation. Accelerated Networking reduces supported network overhead. ExpressRoute private connectivity and DNS need redundant tested paths. |
| Storage | Size database data, logs, shared directories and backups independently. VM-level IO/throughput can cap aggregate disk performance. Disk striping, cache settings and Write Accelerator are workload/support specific. Azure NetApp Files/Azure Files fit supported shared-file scenarios, with protocol, permissions, throughput and backup prerequisites. |
| HA/DR | Availability sets/zones handle infrastructure failure boundaries; Pacemaker/Windows clusters coordinate service ownership. STONITH/fencing prevents split brain. Load-balancer probes, floating service addresses, cluster resources and replication must agree. HANA System Replication/database-native replication addresses database state; ASR is suitable for supported infrastructure tiers. |
| Operations | Correlate SAP transaction response, database/cluster/replication health, guest metrics and Azure platform telemetry. Azure Monitor for SAP solutions adds supported SAP visibility; Network Watcher diagnoses paths. Right-size and archive from evidence before buying commitments. Stop/start order must respect database, central services and application dependencies. |
Cutover and recovery sequence
Assess/support-check → reserve required capacity/quota → build landing zone → rehearse copy/conversion → quiesce and reconcile changes → switch dependencies → validate business transactions → retain rollback. DR drills must verify restored data, keys, interfaces, DNS, capacity and measured RPO/RTO. A login screen and a green VM status do not prove business recovery.
Traps
Do not apply generic disk-cache advice to SAP database logs. Do not choose proximity at the expense of required failure isolation. Replication still needs recoverable history for corruption. Advisor recommendations require SAP supportability review.
Last-pass self-check
1. Why is fencing necessary?
To stop an isolated/failed node from continuing as a conflicting owner.
2. Will more disks always increase throughput?
No. The VM/storage path may already impose a lower aggregate limit.
3. Can ASR universally replace HANA-aware recovery?
No. Match database and application-tier protection to supported patterns.
4. What matters beyond RISE network connectivity?
Responsibility boundaries, identity/security integration, data services and operational ownership.
5. What validates a migration?
Data reconciliation and representative business transactions, interfaces, batch jobs and performance.
Sources
- Official exam scope and version
- Product documentation
- Product documentation
- Product documentation
- Product documentation
- Product documentation
Every topic at a glance
Open any topic to revisit its essential facts, decisions and exam traps. Use the full topic for active recall and supporting references.
01 · Assess and migrate SAP workloads
Memory hook: Supportability before size; dependencies before cutover.
Must remember
- Inventory SAP components, database versions, operating systems, interfaces and business downtime limits. Size from SAP-supported guidance and workload measurements, including memory, SAPS, throughput and growth.
- Choose a supported migration path: move existing infrastructure, combine a platform/database migration, or transform toward HANA. Homogeneous copy and heterogeneous conversion have different tooling, validation and outage requirements.
- Plan subscriptions, quotas, licensing, support plans, region capacity and total cost before scheduling migration. A large VM that exists in Azure is not automatically certified for the intended SAP workload.
- Build landing zones with management groups, subscriptions, resource groups, Policy, RBAC, identity and network ownership. Separate SAP application authorization from Azure control-plane access.
- RISE with SAP changes operational responsibilities and network/identity integration boundaries. Confirm who owns connectivity, backups, monitoring and change approvals; plan integration with customer-managed Azure services and data archiving.
- Rehearse copy, conversion, cutover and fallback. Validate business transactions, interfaces, jobs and performance, not merely that the SAP login screen opens.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Minimal change is required during a move | Evaluate a supported lift-and-shift path with a tested outage window. |
| RISE must exchange data with customer services | Design explicit network, identity and responsibility boundaries. |
Traps
- Azure certification for one SAP configuration does not imply every OS/database combination is supported.
- Cloud administrator access does not replace SAP application permissions.
02 · Compute, networking and deployment
Memory hook: Certified VM, low latency, reproducible build.
Must remember
- Select SAP-certified VM families/sizes and supported OS images. Use Marketplace images or controlled custom images, then configure required extensions and SAP monitoring integration.
- Bicep/ARM templates and the SAP Deployment Automation Framework make infrastructure repeatable. Azure Center for SAP solutions provides supported discovery/deployment and management capabilities; match the tool to the supported scenario.
- Separate application, database and management traffic with intentional subnets, NSGs and route control. Keep administrative paths private or tightly restricted and integrate DNS with existing SAP dependencies.
- Accelerated Networking reduces supported VM network overhead. Proximity placement groups target physical proximity; availability zones target failure isolation. Balance latency against resiliency rather than maximizing one blindly.
- ExpressRoute supports private hybrid connectivity but needs redundant circuits/paths and appropriate encryption design. Private endpoints and service endpoints for Storage have different addressing and access semantics.
- Measure application-to-database latency and test failover paths. Region/zone placement, DNS, firewall rules and name resolution must work during normal operation and DR.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| SAP database latency is critical | Supported nearby placement and measured network performance, balanced against HA requirements. |
| Repeatable multi-system deployment | Reviewed infrastructure code and supported SAP automation tooling. |
Traps
- A proximity placement group is not an availability-zone guarantee.
- A private endpoint does not automatically fix DNS resolution from on-premises.
03 · Storage for SAP databases and files
Memory hook: Latency, throughput, durability, support.
Must remember
- Choose managed disk tiers and file services from the SAP workload’s supported IOPS, throughput and latency requirements. Database data, logs, shared directories and backups can have different needs.
- Disk striping can aggregate performance where supported; simple volumes reduce complexity. Validate limits at both disk and VM levels rather than adding disk IOPS beyond the host’s throughput cap.
- Caching settings and Write Accelerator are workload- and disk-specific. Follow supported SAP/HANA guidance, especially for write-sensitive database logs; a faster benchmark with unsafe caching is not acceptable.
- Azure NetApp Files and Azure Files can supply supported shared-storage scenarios. Plan protocol, permissions, throughput/capacity, snapshots, networking and regional availability.
- Encrypt data with appropriate platform or customer-managed keys and protect access. Key unavailability can become an application outage, so permissions and recovery belong in the storage design.
- Backups and snapshots must be application-consistent where required. Coordinate database state and test restores instead of assuming a storage snapshot is always a valid SAP recovery point.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Need shared SAP directories | A supported Azure Files/NetApp Files design with required availability and permissions. |
| Database log latency is high | Inspect supported disk/caching/Write Accelerator configuration and VM limits. |
Traps
- More disks cannot bypass every VM-level throughput ceiling.
- A crash-consistent snapshot may not meet the required application recovery semantics.
04 · High availability and disaster recovery
Memory hook: Fence before failover; restore before trusting.
Must remember
- Availability sets and zones reduce particular infrastructure failure risks; clustering coordinates application/database failover. Design HANA, SAP Central Services and SQL HA using supported cluster patterns.
- Pacemaker on Linux and Windows clustering have different configuration requirements. STONITH/fencing prevents a failed or isolated node from continuing as a conflicting owner; use supported Azure fence agents or SBD patterns.
- Load balancers, health probes, cluster virtual IPs and storage/replication must agree. A reachable VM is not proof that the SAP service owns the resource safely.
- Use HANA System Replication or the appropriate database-native replication for supported database DR. Azure Site Recovery can protect supported infrastructure tiers but is not a universal replacement for database-aware replication.
- Define RPO/RTO, backup schedules, snapshots, regional placement, DNS and dependency recovery. Test restoration and failover with application validation and a planned failback.
- Document restart order across database, central services and application instances. DR requires credentials, keys, interfaces and capacity in the target region, not only copied disks.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Prevent two isolated nodes acting as primary | Correct fencing and quorum/cluster design. |
| Recover from a regional outage | A rehearsed cross-region plan combining suitable replication, backups and application recovery. |
Traps
- HA protects against some failures; it does not replace backup history.
- Disabling fencing to make a cluster start can risk data corruption.
05 · Operate and optimize the landscape
Memory hook: Correlate SAP, guest and platform health.
Must remember
- Use Azure Monitor for VM, storage and network telemetry; Azure Monitor for SAP solutions adds supported SAP/database/cluster visibility. Network Watcher helps diagnose network paths.
- Monitor HA state, replication lag, disk latency, memory, CPU, application response and backup success together. A green VM metric can coexist with a failed SAP business transaction.
- Azure Center for SAP solutions can manage supported virtual instances and start/stop operations; SAP Landscape Management integration supports broader lifecycle workflows in supported designs.
- Optimize sizing, storage and archiving from measured demand. Savings Plans or reservations can reduce eligible steady compute cost but create commitments; right-size before committing.
- Use Azure Advisor recommendations as inputs, then check SAP supportability and performance. Stopping nonproduction systems can save compute while retained disks and other resources still bill.
- Maintain backup policies, restore drills, patch coordination and change records. Automate with an owner, scoped identity and failure alerting.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Costs rise while workload stays flat | Inspect sizing, storage growth, idle systems and archiving before purchasing commitments. |
| Users report slowness but CPU is low | Correlate storage, network, locks and application/database metrics. |
Traps
- A stopped VM does not mean every associated resource stops billing.
- A generic optimization recommendation may conflict with SAP support requirements.