Azure AZ-120 common mistakes
Azure AZ-120 · Understand the traps and how to avoid them.
Sizing an SAP-certified Azure VM by matching on-paper SAPS to the customer's existing on-premises benchmark without applying the Azure-specific SAPS ratings and the 65% (scale-up) / 75% (scale-out) SAPS-to-vCPU planning caps, then presenting that VM as the target.
Candidates carry over on-premises sizing habits and assume the SAPS figure printed for a processor family applies unchanged in the cloud; Azure publishes its own certified SAPS per VM SKU and SAP's sizing guidance assumes headroom for the hypervisor and burst behaviour, so raw equivalence overstates usable capacity.
What to do instead
Always size from the SAP-certified Azure VM list for the specific database and SAP product, use the published Azure SAPS values for that SKU, and apply the documented utilization cap so the VM has headroom; validate with the SAP Quick Sizer or an SAP-certified sizing report before committing to a SKU.
Assuming Azure Premium SSD or Ultra Disk throughput and IOPS scale linearly with capacity, and therefore picking a smaller disk count that meets GB but not the database's IOPS/latency profile.
On-premises storage arrays are sized by aggregate IOPS, so candidates transfer that mental model and forget that each Azure managed disk SKU has its own IOPS and MB/s ceiling tied to size tier, and that VM-level disk throughput caps can bind before the disks do.
What to do instead
Size storage from three axes simultaneously: capacity, IOPS, and throughput, then check the target VM's max uncached disk IOPS and MB/s to confirm the sum of attached disks is actually reachable; use disk striping or a higher tier where the VM cap is the limiter, and validate with SAP's storage KPI guidance.
Placing the SAP application servers and the database in the same Azure availability zone or the same proximity placement group by default, without reasoning about the latency and failure-domain trade-off.
Candidates learn that proximity placement groups reduce network latency and apply them everywhere, not realizing that PPGs constrain placement and can conflict with zone-level resiliency, and conversely that spreading the DB and app tiers across zones adds cross-zone latency to chatty SAP traffic.
What to do instead
Decide explicitly per tier: keep the database and its tightly coupled application servers in one zone (or one PPG) to protect latency, and use zone-redundant or cross-zone patterns only for components that tolerate the added round-trip; document the latency budget and test it, rather than defaulting to either pattern.
Designing the database high-availability layer with a single standby that is only passive (for example a single secondary in a synchronous commit mode with no automatic failover, or an SAP ASCS cluster without a witness/quorum design), and calling it highly available.
Candidates conflate backup, replication, and HA; a replica that requires manual intervention and has no quorum model is a DR asset, not an HA solution, and cluster designs without a proper witness or disk model can lose quorum and fail to fail over.
What to do instead
For each database, state the HA mechanism explicitly (for example synchronous replication with automatic failover, or a cluster with a cloud witness or file-share witness) and prove the quorum model survives the loss of one node; for SAP central services, design the ASCS/ERS cluster with the documented quorum and probe configuration for that OS and database.
Treating Azure Site Recovery or VM backups as the SAP DR strategy without defining and testing RTO/RPO per tier, and without validating that the recovered landscape starts in the correct order.
Candidates focus on the replication tool as the answer and skip the recovery runbook; SAP landscapes have strict startup dependencies (database, then ASCS/ERS, then application servers), and an untested recovery can meet the VM RPO while missing the business RTO because of sequencing and DNS/IP reconfiguration.
What to do instead
Write RTO and RPO targets per SAP tier, map each to a mechanism (native DB replication, ASR, backup/restore), and produce a tested failover runbook that includes startup order, DNS and load-balancer updates, and SAP kernel-level checks; run at least one non-disruptive DR test and record the measured times.
Migrating SAP workloads with a lift-and-shift tool (ASR, Movere-style discovery, or a third-party appliance) and changing the OS, hostname, or IP addressing during the move without accounting for SAP's hostname and instance-number dependencies.
Candidates treat SAP like a generic server workload; SAP binds the system to the SID, instance number, hostname, and in many cases the IP in profiles and the database, so renaming or re-IPing during migration silently breaks the system and is discovered only at cutover.
What to do instead
Plan the migration so SID, instance numbers, and hostnames are preserved, or execute SAP-supported rename procedures (including the database-specific steps) as an explicit, tested work package; keep IP changes out of the cutover window or update all SAP profile and host-agent references and re-verify connectivity before go-live.
Migrating the database with a physical file copy or a storage-level snapshot to Azure and then attaching it to a newly built database instance, skipping the SAP and database-vendor-specific migration method.
Candidates assume any consistent copy of the data files is portable, but cross-platform database moves (for example to Azure's supported OS and DB versions) usually require a supported export/import, backup/restore, or vendor migration tool, and an unsupported copy produces an instance that will not start or is unsupported.
What to do instead
Choose the vendor-documented migration path for the exact source and target versions (for example a database-native backup and restore, export/import, or the vendor's migration tool), run it in a pilot, and validate with SAP transaction checks and a full consistency check before the production cutover.
Configuring the Azure load balancer for SAP ASCS/ERS or the database tier with the wrong probe, floating IP, or HA ports setting, and assuming the cluster will work because the VMs are healthy.
Candidates configure the load balancer as they would for a web tier; SAP clusters need a specific probe port, Direct Server Return or floating IP configuration, and (for some databases) HA ports, and the cluster resource must be configured to match or failover will hang or split-brain.
What to do instead
Follow the documented reference architecture for the specific OS cluster and database: set the load-balancer rule for the probe port the cluster expects, enable floating IP where required, configure HA ports only when the design calls for it, and test an actual failover rather than only checking probe health.
Leaving SAP monitoring and patching as manual, ad-hoc tasks, and not integrating the Azure-specific signals (VM health, disk latency, backup status, guest OS and SAP host agent) into the operational process.
Candidates treat operations as out of scope for a design exam and describe only the deployment; in production, SAP on Azure fails quietly through disk latency creep, missed kernel and host-agent updates, and unmonitored backup failures, none of which a generic VM dashboard surfaces.
What to do instead
Define a monitoring baseline that includes SAP application metrics, database-specific checks, Azure Monitor metrics and alerts for disk latency and VM availability, and backup job success; schedule SAP kernel, host agent, and DB patching with a documented cadence and a rollback path, and review alerts on a defined interval.
Assuming the SAP-certified VM and the SAP-supported configuration are automatically supported end to end, and skipping validation of the exact OS, database, and SAP version combination against the supported-product matrix.
Candidates see a VM on the certified list and conclude the whole stack is supported, but certification is per VM and per workload, and support also depends on OS release, database release, and SAP kernel level, so an otherwise valid design can be unsupported.
What to do instead
Before finalizing the design, check the Azure SAP-certified VM entry for the specific workload, the SAP supported OS and database releases for that product version, and the required kernel and patch levels; record the exact versions in the design and flag any deviation for review.