Microsoft Certified: Azure for SAP Workloads Specialty — Practice Set 5

Question 1

Before starting a migration project, an SAP Basis team wants to run an automated tool against their existing SAP system to identify custom code compatibility issues, add-on compatibility, and simplification item relevance for a future move to S/4HANA on Azure. Which SAP tool should be used first?

Accepted Answer

SAP Readiness Check analyzes an existing SAP system (ECC or Business Suite) and produces a report covering custom code compatibility, add-on compatibility, simplification items, and sizing estimates relevant to converting to S/4HANA — a standard first step in migration assessment before infrastructure planning on Azure. SLT (B) is a real-time data replication tool for landscape transformation projects, not a readiness assessment tool. Solution Manager Change Request Management (C) manages change/transport processes, not readiness analysis. SAP GUI Scripting (D) automates UI interactions and is unrelated to readiness assessment.

Question 2

An organization is converting its SAP ECC system running on an AnyDB (non-HANA) database to S/4HANA on Azure, combining the OS/DB migration and the application upgrade into a single, minimized-downtime procedure. Which SAP tool is used to perform this combined database migration and application conversion?

Accepted Answer

SUM with the Database Migration Option (DMO) combines the S/4HANA conversion (or release upgrade) and the database migration to SAP HANA into a single, integrated procedure, reducing overall project duration and downtime compared to running them sequentially. LaMa (B) automates operational tasks like system copies and VM start/stop, not the conversion/migration procedure itself. Azure Migrate (C) assesses and migrates general server workloads to Azure but does not perform SAP application-layer database migration. SAP HANA Cockpit (D) is an administration and monitoring tool for HANA, not a migration tool.

Question 3

A retailer cannot tolerate more than 4 hours of downtime for its SAP ERP migration to Azure, but the database is 8 TB and a standard export/import would take over 24 hours. The team wants to minimize business downtime by migrating and synchronizing the bulk of the data before the cutover window, then only replicating the delta during a short final window. Which migration technique should be used?

Accepted Answer

Near-Zero Downtime Migration (NZDM) is SAP's recommended technique for large databases with tight downtime windows: bulk table data is migrated ahead of time while the source system remains live, database triggers capture ongoing changes, and only the accumulated delta is replicated and applied during a short final cutover window, dramatically reducing business downtime versus a classical migration. Classical R3load export/import (A) performed entirely within the downtime window does not fit an 8 TB database into a 4-hour window. A full backup/restore (C) still requires downtime proportional to database size and does not address the requirement. HSR (D) is a HANA-to-HANA replication technology for HA/DR, not a heterogeneous AnyDB-to-HANA migration technique.

Question 4

An SAP ECC system still running in a non-Unicode code page needs to be migrated to Azure. Before or during the migration, the system must also be converted to Unicode, since S/4HANA requires a Unicode-only code page. What is the recommended approach to minimize the number of separate technical projects?

Accepted Answer

Because both a classical OS/DB migration and a Unicode conversion require a full export and reimport of the database, SAP and Microsoft guidance recommends combining these into a single combined transition to avoid two separate downtime-intensive projects. Treating Unicode conversion as an entirely separate multi-year project (A) wastes an opportunity to combine downtime windows. S/4HANA requires Unicode — non-Unicode is not supported (C is false). Running production in a mixed-Unicode state (D) is not a supported or recommended end state.

Question 5

An architect is sizing an Azure VM for an SAP HANA scale-up OLTP (S/4HANA) workload and must select a VM SKU that respects SAP's certified core-to-memory ratio for this workload type, rather than simply picking the SKU with the most total memory. Why does the core-to-memory ratio matter for this sizing decision?

Accepted Answer

The SAP HANA Hardware Directory certifies VM SKUs against specific core-to-memory ratios that differ for OLTP (e.g., S/4HANA, denser ratio) versus OLAP (e.g., BW/4HANA, less dense ratio) workloads. Choosing a SKU with enough total memory but the wrong ratio for the workload type can be an unsupported and uncertified configuration, so the architect must select from the SKU list certified for that specific workload category. Core-to-memory ratio affects certification and performance, not merely billing (A is incomplete). It applies to overall VM sizing, not just the log volume (C). Azure does not dynamically alter a VM's vCPU-to-memory ratio at runtime (D).

Question 6

An SAP migration project is finalizing its cutover plan for the production go-live weekend. Which TWO activities are recommended best practices to reduce cutover risk? Choose 2.

Accepted Answer

Best practice cutover planning includes running one or more full mock/dress-rehearsal cutovers with production-like data volumes to validate timing, uncover bottlenecks, and refine the plan, and building a detailed, minute-by-minute runbook with named owners, dependencies, and defined go/no-go checkpoints. Skipping mock cutovers (B) in favor of a paper review alone is a recognized risk factor and is not a best practice. Claiming a rollback is 'never possible' (D) is false — most cutover plans define a rollback/fallback procedure, and omitting one is a project risk, not a recommendation. Notifying business users only after completion (E) removes their ability to prepare and is not standard practice — communication plans typically precede and follow cutover activities.

Question 7

During a migration project, an architect requests a specific number of Mv2-series vCPUs but discovers that even though the subscription's overall regional vCPU quota is sufficient, the deployment still fails with a quota error. What is the most likely cause?

Accepted Answer

Azure enforces vCPU quotas both at the overall regional level and per VM series family (e.g., Mv2-series vCPUs specifically). Even when the total regional quota is sufficient, a specific family quota (which often starts very low or at zero for specialized SKUs like Mv2) must be separately requested and increased via Azure Support before deployment succeeds. HANA-certified series are not exempt from quota enforcement (B is false). Resource group count limits (C) are unrelated to vCPU quota errors. The scenario describes a quota-specific error, not a policy assignment issue (D).

Question 8

A regulated customer requires that SAP production VMs run on physical Azure servers dedicated exclusively to their organization, with no other tenants' VMs sharing the same underlying hardware, to satisfy a compliance requirement. Which Azure service meets this requirement?

Accepted Answer

Azure Dedicated Host provides physical servers dedicated to a single subscription, ensuring that no other customer's VMs are co-located on the same hardware — meeting compliance and isolation requirements sometimes mandated for regulated SAP workloads. Azure Reserved Instances (B) is a billing/discount construct and has no bearing on hardware isolation. Availability Sets (C) distribute VMs across fault/update domains within shared hardware, not dedicated hardware. Spot Instances (D) are discounted, evictable capacity on shared hardware and offer no isolation guarantee.

Question 9

An SAP HANA scale-out cluster with four active worker nodes requires a dedicated, low-latency network specifically for internode data redistribution and communication between worker nodes, separate from the client-facing network used by application servers. How should this be implemented on Azure?

Accepted Answer

For SAP HANA scale-out deployments, Microsoft's recommended architecture places a second NIC on each worker node VM, connected to a dedicated internode-communication subnet, combined with a proximity placement group and Accelerated Networking to achieve the low latency and high throughput needed for internode data redistribution — separate from the client-facing network. Azure does not automatically prioritize traffic types on a single shared NIC for this purpose (B). ExpressRoute (C) is designed for hybrid on-premises-to-Azure connectivity, not intra-cluster VM-to-VM traffic within the same region. Azure Front Door (D) is a global HTTP(S) reverse proxy/CDN service, entirely unsuited to low-latency internal database cluster traffic.

Question 10

An SAP Basis team mounts the /hana/shared volume from Azure NetApp Files onto multiple HANA scale-out nodes using NFSv4.1. During testing, a temporary network blip causes one node's mount to hang indefinitely rather than retrying and eventually failing over. Which NFS mount option set is recommended by SAP and Microsoft for HANA-related ANF volumes to avoid this specific problem?

Accepted Answer

SAP and Microsoft guidance for mounting Azure NetApp Files NFS volumes for SAP HANA specifies 'hard' mounts (not 'soft') because a soft mount can silently return an I/O error to the application after a timeout, risking data corruption for database files. The documented option set uses hard mounts with tuned rsize/wsize and timeo/retrans values engineered to recover from transient network issues without hanging indefinitely or silently failing. A soft mount (A) is explicitly discouraged for HANA data-integrity reasons. Using only noatime with OS defaults (C) does not address timeout/retry tuning needed for reliability. Disabling file locking with nolock (D) is not a supported or recommended configuration for HANA shared volumes.

Question 11

An organization plans to consolidate three SAP HANA databases for three different SIDs into a single SAP HANA instance using Multitenant Database Containers (MDC), each tenant requiring 1.5 TB of active memory. Which statement correctly describes how this affects Azure VM sizing and certification?

Accepted Answer

With SAP HANA Multitenant Database Containers, all tenant databases run within a single system (one set of OS-level resources, one VM), so the underlying Azure VM must be sized — and be SAP HANA certified — for the combined total memory required by all tenants together, not any single tenant in isolation. MDC tenants share the same VM/OS instance; they are not independently placed on separate VMs (A is false). Hardware certification still applies to the VM hosting the MDC system (C is false). All tenants' memory requirements count toward total sizing, not just the largest (D is false).

Question 12

An architect wants to enable Accelerated Networking on the network interfaces of newly deployed SAP application server VMs to reduce latency and jitter. Which statement correctly describes a prerequisite for enabling this feature?

Accepted Answer

Accelerated Networking requires a VM size that supports it (generally VM sizes with 2 or more vCPUs from supported families) and an operating system/kernel with the necessary SR-IOV network driver support; it must typically be enabled either during VM creation or while the VM is stopped/deallocated, not on a running VM in most cases. It is not universally available on every size/OS combination (A is false). It is not enabled by default on all VMs (C is false), and it is not restricted to VMs in Availability Zones — it is a networking feature independent of zonal placement (D is false).

Question 13

An architect is designing the Azure infrastructure for a large SAP HANA scale-out cluster to meet SAP's required latency and throughput KPIs between nodes. Which TWO infrastructure elements are required as part of this design? Choose 2.

Accepted Answer

A SAP HANA scale-out cluster requires a proximity placement group to physically co-locate all worker and standby nodes and minimize inter-VM latency, along with a dedicated subnet/NIC pair for internode communication, isolated from client-facing traffic, to meet SAP's throughput and latency KPIs for data redistribution between nodes. Azure Front Door (C) is a global HTTP reverse-proxy/CDN service and is irrelevant to internal database cluster traffic. Public IP addresses on worker nodes (D) are neither required nor recommended — these are private, internally addressed VMs. Placing an Azure Firewall between worker node pairs (E) would add unacceptable latency and is not part of any recommended scale-out cluster design.

Question 14

An organization stores its SAP HANA /hana/data and /hana/log volumes on Azure NetApp Files in the primary region and wants an efficient, storage-level way to maintain a continuously updated copy of these volumes in a secondary Azure region for disaster recovery, without relying solely on HANA System Replication. Which Azure NetApp Files capability should be used?

Accepted Answer

Azure NetApp Files Cross-Region Replication (CRR) provides storage-level, asynchronous volume replication to a paired secondary region on a configurable schedule, giving a storage-native DR copy of HANA data/log volumes that complements (or can serve as an alternative storage-level mechanism alongside) HANA System Replication. Weekly backup-vault restores (A) do not provide a continuously updated, low-RPO copy. Azure Site Recovery does not replicate Azure NetApp Files volumes directly at the block level (C) — ASR targets VM disks, not ANF volumes. Manual robocopy/rsync jobs (D) are not a supported, SAP-recommended, or efficient mechanism for replicating HANA data volumes.

Question 15

A non-production SAP HANA system does not have a business requirement for automatic sub-minute failover, but the customer still wants the HANA database service to restart automatically on the same VM if the hdbdaemon process or HANA service crashes, without deploying a full Pacemaker cluster. What provides this capability?

Accepted Answer

SAP HANA includes built-in service auto-restart behavior through sapstartsrv/hdbdaemon that can automatically restart a crashed HANA service process on the same host, which is sufficient for many non-production systems that don't justify the complexity and cost of a full Pacemaker HA cluster. A full Pacemaker cluster with STONITH (B) is recommended for production systems with strict RTO requirements but is not mandatory for every non-production system. Azure Site Recovery (C) is a DR replication service, unrelated to restarting a crashed local service. While manual restart is possible, it is not the only option — the built-in auto-restart capability exists precisely to avoid needing manual intervention (D is false).

Question 16

In a Pacemaker cluster managing SAP HANA System Replication, two custom resource agents work together to monitor and control the HANA database across cluster nodes. What is the distinct role of the SAPHanaTopology resource agent compared to the SAPHanaController (or SAPHana) resource agent?

Accepted Answer

In SAP HANA Pacemaker clusters, SAPHanaTopology runs as a cloned resource on every cluster node and continuously gathers and exchanges information about HANA system replication status and topology, while SAPHanaController (formerly SAPHana) uses that information to perform the actual control actions — starting, stopping, promoting, and demoting the HANA instance during failover. Fencing (B) is handled by a separate STONITH resource (such as the Azure Fence Agent), not by either of these agents. They are distinct resource agents with different responsibilities, not the same agent (C is false). Neither agent directly manages the load balancer health probe or VIP configuration — those are configured as part of the load balancer and cluster IP resource setup, separate from these two HANA-specific agents (D is false).

Question 17

An SAP landscape runs SAP HANA and SAP Central Services (ASCS/ERS) as two separate Pacemaker clusters on the same pair of Azure availability zones. During a single zonal outage test, both clusters attempt to fail over simultaneously, causing a brief period of contention for Azure API calls used by the fence agents on both clusters, which delays fencing completion beyond the expected time. What is the most effective architectural adjustment to reduce this contention risk in future tests?

Accepted Answer

When independent HA clusters share the same nodes/zones, simultaneous fencing actions can create contention for the Azure Fence Agent's REST API calls. A well-established mitigation is to combine tightly related SAP components into a single cluster where practical to reduce the number of independent fencing decisions, and where separate clusters must remain, to use fencing priorities/delays so that fence actions are staggered rather than issued simultaneously. Disabling STONITH on one cluster (B) removes split-brain protection entirely and is a serious safety regression, not an appropriate fix. Removing the Azure Fence Agent and relying only on watchdog timers (C) does not reliably fence a remote failed node in Azure and is not the SAP/Microsoft-recommended approach. Azure regions typically provide three availability zones, and simply adding zones (D) does not address simultaneous API contention between two independently fencing clusters.

Question 18

A business defines the following requirement for its SAP HANA production database: 'The database must automatically fail over within the same region in under 2 minutes with zero data loss, and must also be recoverable in a secondary region within 4 hours after a full regional disaster, accepting up to 15 minutes of data loss in that disaster scenario.' Which combination of technologies satisfies both parts of this requirement?

Accepted Answer

This requirement describes a classic combined HA+DR architecture: a synchronous HANA System Replication pair (managed by Pacemaker with automatic failover) satisfies the sub-2-minute, zero-data-loss intra-region HA requirement, while a separate asynchronous replication leg (either a second HSR target or ANF Cross-Region Replication) to a secondary region satisfies the 4-hour RTO / 15-minute RPO DR requirement. A single asynchronous pair spanning two regions (B) cannot meet the zero-data-loss intra-region requirement, since asynchronous replication does not guarantee zero data loss and would also leave no local HA protection. Azure Backup alone (C) cannot achieve a sub-2-minute automatic failover. Azure Site Recovery replicating HANA VM disks at the block level (D) is not a database-consistent replication method for HANA and does not provide automatic sub-minute failover for the HA leg.

Question 19

Northwind Traders requires sub-minute automatic HA failover for SAP HANA within the primary region, plus an independent DR copy of the database in a second region, all replicated directly from a single production HANA primary node (rather than replicating from the local HA secondary to avoid a single point of failure in the replication chain). Which HANA System Replication topology satisfies this requirement?

Accepted Answer

Multi-target (also called multitier or fan-out) HANA System Replication allows a single production primary node to replicate directly and independently to two or more secondary targets — for example, a synchronous local secondary for sub-minute HA failover and a separate asynchronous secondary in another region for DR — without introducing a dependency where the DR target's data depends on the HA secondary staying online. Chained/cascading replication (B) has the DR node depend on the local HA secondary in the replication chain, which is a real HANA topology but does not match the stated requirement that the DR copy be replicated directly and independently from the primary. A manual nightly export/import (C) provides neither continuous replication nor the required RPO/RTO. Azure Site Recovery block-level VM disk replication (D) is not a database-consistent method for HANA and does not achieve the required automatic sub-minute HA failover.

Question 20

An SAP Basis team is preparing to install a Pacemaker cluster to manage SAP HANA System Replication failover on SUSE Linux Enterprise Server for SAP Applications in Azure. Which TWO SAP/cluster-specific components must be installed and configured on the cluster nodes, beyond the base Pacemaker/Corosync cluster stack? Choose 2.

Accepted Answer

A SAP HANA Pacemaker cluster on SUSE requires the SAPHanaSR (or its newer SAPHanaSR-angi) package, which supplies the SAPHanaTopology and SAPHana/SAPHanaController resource agents used to track replication state and drive failover actions, along with the Azure-specific fence agent from the fence-agents package configured as the STONITH resource so the cluster can reliably fence a failed node via the Azure REST API. SQL Server Always On (C) is unrelated to a HANA Linux cluster. AKS (D) is a container orchestration service and has no role in a HANA Pacemaker cluster. WSFC (E) is the Windows clustering feature, not applicable to a Linux-based SAP HANA cluster.

Question 21

An SAP operations team wants to patch the operating system of a fleet of SAP VMs on a defined monthly schedule, with the ability to review and approve which updates are applied and to view compliance status across the fleet from a single place in the Azure portal. Which Azure service should be configured?

Accepted Answer

Azure Update Manager (the evolution of Azure Automation Update Management) provides scheduled, fleet-wide OS patch management with the ability to define maintenance windows, review/approve updates before they are applied, and report on patch compliance across many VMs from a single Azure portal experience — well suited for maintaining SAP VM fleets. Azure Site Recovery (B) is a DR replication service unrelated to OS patch scheduling. Azure NetApp Files Backup (C) protects storage volumes, not OS patch compliance. SAP LaMa (D) automates SAP-specific operational tasks like system copies and VM start/stop but is not an OS patch management service.

Question 22

An organization has existing Red Hat Enterprise Linux for SAP Applications subscriptions with active support that they want to bring to Azure and apply to their SAP VMs, rather than paying for a new PAYG RHEL image billed hourly through Azure. Which approach allows them to do this?

Accepted Answer

Red Hat Cloud Access (and equivalent BYOS programs) allows customers with existing, active RHEL subscriptions to register those subscriptions against cloud VMs — including Azure VMs deployed from BYOS images — so they are not billed again for the OS license through Azure's PAYG hourly rate, while continuing to receive Red Hat support. Simply deploying PAYG and ignoring the existing subscription (A) results in duplicate licensing cost. RHEL subscriptions are not converted directly into Azure Reserved Instances by Red Hat (C) — Reserved Instances are an Azure compute pricing construct, unrelated to OS subscription mobility. RHEL subscriptions with cloud access programs are explicitly designed to extend to public cloud VMs, so option D is false.

Question 23

An SAP Basis team has configured Azure Monitor for SAP solutions (AMS) to collect HANA memory utilization metrics. They want to be proactively warned before the HANA database approaches its certified memory ceiling for the VM, rather than discovering the issue only after an out-of-memory condition impacts production. What should be configured to achieve this?

Accepted Answer

Azure Monitor for SAP solutions surfaces HANA memory utilization as a queryable metric; proactive warning requires explicitly configuring a metric alert rule with a threshold set below the VM's certified memory ceiling (e.g., 85-90%), linked to an action group (email, webhook, ITSM integration) so the operations team is notified before the database approaches capacity. AMS does not automatically page anyone without an alert being configured (B is false) — alerting is opt-in and must be defined. Azure Cost Management (C) tracks spend, not HANA memory utilization, and manual daily review does not provide proactive, timely warning. Azure Advisor (D) provides cost/performance/reliability recommendations generally but is not the mechanism for real-time HANA memory threshold alerting — that is done through Azure Monitor alert rules on the AMS metrics.

Question 24

An SAP operations team backs up its production SAP HANA database daily using Azure Backup with the Backint interface, and wants to be confident that backups are actually restorable and meet the required RTO if needed. Which TWO practices should be implemented to validate this? Choose 2.

Accepted Answer

Validating a backup strategy requires periodically performing actual test restores of HANA backups to a non-production system to confirm the backup is genuinely restorable, the restored database is consistent, and the time taken meets the defined RTO — a 'completed' backup job status alone does not guarantee restorability. It also requires reviewing the configured retention policy and point-in-time recovery windows against the business's RPO requirements to ensure the right recovery points are actually retained long enough. Relying solely on job 'Completed' status (B) is an incomplete practice — corruption or restore failures can occur even when the backup job itself reports success. Disabling alerts (D) removes visibility into backup failures and is a risk, not a validation practice. Testing restores only once at initial implementation (E) does not account for configuration drift, software updates, or changes in data volume over time — periodic re-testing is the recommended practice.

Question 25

An SAP QA system registered with Azure Center for SAP solutions (ACSS) is being permanently decommissioned after a project completes. What is the correct sequence of actions to properly retire the system?

Accepted Answer

The correct decommissioning sequence is to first deregister the system from Azure Center for SAP solutions so ACSS stops actively managing and monitoring a system that will no longer exist, and then delete or archive the underlying Azure resources according to the organization's decommissioning and data retention requirements (e.g., retaining final backups per policy before deletion). Deleting VMs and resource groups directly without deregistering first (A) can leave ACSS referencing resources that no longer exist and skips the organization's controlled retirement process. ACSS does not automatically delete resources for indefinitely stopped/deallocated VMs (C is false) — deallocated VMs continue to exist (and continue to incur storage charges) until explicitly deleted. Renaming a resource group alone (D) does not stop monitoring, release compute/storage costs, or satisfy a proper decommissioning process.

AZ-120 — Azure for SAP Workloads Specialty