Free AZ-120 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

The preparation phase for an SAP-to-Azure migration follows a logical infrastructure-readiness path. First, a compatibility assessment (using tools like SAP Readiness Check) is mandatory to identify unsupported OS/DB versions or hardware requirements. Once the requirements are clear, the target environment must be established by deploying core networking components, such as Virtual Networks (VNets) and subnets, which form the "Landing Zone." Finally, an ExpressRoute connection is configured to provide the dedicated, high-bandwidth, low-latency link necessary for transferring large SAP databases and maintaining hybrid connectivity during and after the migration.

Microsoft Official Documentation: SAP on Azure migration guide - Preparation phase. This section details the necessity of assessing source system compatibility before infrastructure deployment.

Microsoft Cloud Adoption Framework (CAF): Azure landing zone for SAP. Explains that network topology (VNets/Subnets) must be deployed as a prerequisite to connectivity services like ExpressRoute.

SAP Support Note 1928533: SAP Applications on Azure: Supported Products and Azure VM types. This is the primary reference for the compatibility assessment step to ensure the target Azure environment supports the specific SAP landscape.

Microsoft Learn (AZ-120): Module: Plan for SAP on Azure - Networking and Connectivity. Specifies that ExpressRoute is the recommended connectivity solution for SAP migrations to ensure reliable data transfer.

The SAP transaction OS07N, the Operating System Monitor, is the correct tool for this task. It provides detailed, real-time, and historical data about the underlying operating system's hardware resource consumption. This includes critical metrics for migration sizing, such as CPU utilization, physical and virtual memory usage, disk I/O, and network statistics. Analyzing this data from the source system is a fundamental step in accurately sizing the target virtual machines in Azure to ensure performance and cost-effectiveness for the migrated SAP workload.

A. SM51: This transaction is used to list and manage the active SAP application server instances within a system, not for monitoring detailed OS-level hardware metrics.

B. DB01: This is a database-specific transaction used to analyze exclusive database lock waits. It does not provide information about OS hardware usage like CPU or memory.

C. DB12: This is a database administration transaction used to display logs and the status of database backups and recovery operations, not for OS performance monitoring.

1. SAP Help Portal

Operating System Monitor (OS07N): "You can use the operating system monitor to check the status of the operating systems of the servers in your system landscape. It displays data such as CPU utilization

memory consumption

and disk and network information." This directly confirms the function of OS07N.

Source: SAP Help Portal

Document: Operating System Monitor.

2. Microsoft Learn

SAP workload planning and deployment checklist: "Size the Azure VMs that will host the SAP application layer and the DBMS layer. For existing SAP systems

SAP provides tools that can help you determine the current resource consumption of your SAP systems." OS07N is a primary SAP tool for gathering this resource consumption data.

Source: Microsoft Learn

Module: Plan for SAP workloads on Azure

Unit: SAP workload planning and deployment checklist.

3. SAP Help Portal

CCMS: System/Server Status (SM51): "This transaction allows you to get an overview of the SAP servers (instances) and to manage them." This confirms SM51 is for managing SAP instances

not OS monitoring.

Source: SAP Help Portal

Document: Displaying and Controlling Servers.

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Microsoft_AZ-120_Dumps/page_39_img_2.jpg?

The process begins by defining the configuration for the core SAP components. You first generate the ASCS parameter file, followed by the application server parameter files, which are combined to represent the application tier. These configuration templates must be added to the BOM so the Ansible-based automation engine knows the specific SID, instance numbers, and parameters to use. Once the BOM is updated and the environment is prepared, the framework executes the playbooks to install the HANA and SCS instances. The final step in the software deployment lifecycle is to load the database content (the SAP export) into the HANA instance to complete the system setup.

Microsoft Azure Documentation: SAP deployment automation framework - SAP application installation. This documentation details the requirements for preparing the configuration files (ASCS and App Servers) and updating the BOM before running the installation playbooks.

Microsoft Learn: Configure the SAP Bill of Materials (BOM). Sections regarding "Application Configuration" specify that parameter files must be generated and referenced in the BOM to enable automated unattended installation.

SAP Deployment Automation Framework GitHub Wiki: Process Flow for SAP Software Installation. It outlines the lifecycle: 1. Configuration Generation -> 2. BOM Update -> 3. Software Deployment (HANA/SCS) -> 4. Database Load.

To protect an SAP HANA High Availability (HA) cluster, you must first prepare the environment by running the preregistration script on all nodes to set up necessary permissions. Next, a custom HANA user must be created on both nodes (synced via replication) so the backup service can access the database. You then add this user's credentials to the hdbuserstore on both nodes; this allows the Azure Backup plugin to connect to whichever node is currently primary without hardcoded passwords. Finally, you trigger Start Discovery in the Azure portal to identify the databases and configure the backup protection. The "Recovery Plan" action is irrelevant as it pertains to Azure Site Recovery, not the initial backup configuration.

Microsoft Learn: "Backup SAP HANA databases in Azure VMs" - Section: Set up backup for SAP HANA High Availability system. Document ID: backup-azure-sap-hana-database.

Microsoft Learn: "Tutorial: Back up SAP HANA databases in an Azure VM" - Section: Prerequisites.

Microsoft Azure Documentation: "SAP HANA backup architecture in Azure Backup" - Detailed steps for HDBUserStore and script execution.

SAP Note 2039883: FAQ regarding SAP HANA System Replication and third-party backup tools (integrating with Backint).

For migrating an existing SAP environment from VMware to Azure, a two-pronged approach is required for accurate resource sizing. Azure Migrate is the primary Microsoft tool designed to discover and assess on-premises environments, including VMware vCenter. It analyzes the performance metrics of the existing virtual machines (CPU, memory, disk I/O) to provide right-sized Azure VM recommendations. To complement this infrastructure data, SAP EarlyWatch Alert (EWA) reports from the source SAP system provide crucial application-specific performance metrics, such as SAPS (SAP Application Performance Standard) consumption, memory usage, and database growth. Combining the infrastructure assessment from Azure Migrate with the application performance data from EWA reports ensures a comprehensive and accurate sizing for the SAP workload in Azure.

B. Azure Site Recovery and SAP Quick Sizer: Azure Site Recovery is primarily a disaster recovery tool, not the recommended assessment tool for migrations. SAP Quick Sizer is used for sizing new (greenfield) SAP implementations, not for analyzing existing systems.

C. SAP Quick Sizer and SAP HANA system replication: SAP Quick Sizer is for new implementations. SAP HANA system replication is a high-availability/disaster-recovery technology for databases, not a sizing or assessment tool.

D. Azure Site Recovery Deployment Planner and SAP HANA Cockpit: The ASR Deployment Planner is for DR planning. While SAP HANA Cockpit provides monitoring, EWA reports are the standard SAP tool for comprehensive performance analysis and sizing reports.

1. Microsoft Docs

Azure Well-Architected Framework

SAP workload on Azure: planning and deployment checklist. This document explicitly states the tools for different scenarios.

Under the "Sizing" section

it recommends: "For existing systems

SAP EarlyWatch reports are very helpful. They help you determine the resources that you use."

It also states: "For new implementations

use the SAP Quick Sizer." This confirms Quick Sizer is for new

not existing

systems.

Reference: https://learn.microsoft.com/en-us/azure/architecture/framework/sap/sap-planning-checklist#sizing

2. Microsoft Docs

About Azure Migrate. This document establishes Azure Migrate as the central hub for migration projects.

"The Azure Migrate: Discovery and assessment tool discovers on-premises VMware VMs... The tool then assesses the discovered servers to check whether they're suitable for migration to Azure

and provides cost estimations."

Reference: https://learn.microsoft.com/en-us/azure/migrate/migrate-services-overview#azure-migrate-discovery-and-assessment-tool

3. Microsoft Docs

Select a VMware assessment tool. This page guides users on choosing the right tool for VMware assessment.

"To assess on-premises VMware VMs for migration to Azure

we recommend you use the Azure Migrate: Discovery and assessment tool."

Reference: https://learn.microsoft.com/en-us/azure/migrate/common-questions-discovery-assessment#what-assessment-tools-can-i-use

For a SAP HANA scale-out configuration that includes a standby node, a shared file system is required for /hana/shared, /hana/data, and /hana/log to ensure all nodes (including the standby) can access the data volumes in the event of a failover. Azure NetApp Files (ANF) is the recommended high-performance storage solution that supports the necessary NFS protocols and provides the low-latency, high-throughput requirements mandated by SAP HANA's Key Performance Indicators (KPIs) for scale-out architectures on Azure. While Azure shared disks are viable for some clusters, ANF is the primary recommendation for production HANA scale-out deployments involving standby nodes due to its native NFS support and performance tiering.

Microsoft Learn: SAP HANA Azure virtual machine storage configurations - Section: "SAP HANA scale-out with standby node using Azure NetApp Files on Red Hat Enterprise Linux."

SAP Note 1900823: SAP HANA Storage Connector API - Details requirements for shared storage in scale-out scenarios.

Microsoft Learn: Azure NetApp Files for SAP HANA - Documentation on performance limits and architectural requirements for /hana/data and /hana/log in scale-out.

SAP Certified Solutions Portal: Certified and Supported SAP HANA Hardware - Listing Azure NetApp Files as a certified enterprise storage solution for HANA scale-out.

The SAP Quick Sizer is the official and mandatory tool provided by SAP for calculating the hardware requirements for SAP applications before installation. When planning a migration to SAP Business Suite on SAP HANA on Azure virtual machines (an IaaS scenario), this tool is used to estimate the necessary CPU (SAPS), memory, and disk resources based on business inputs like user numbers and transaction volumes. This ensures the selected Azure VM types meet the performance and capacity needs of the planned SAP system, which is a critical step in the planning and deployment phase.

A. SAP Quick Sizer for HANA Cloud: This is incorrect because SAP HANA Cloud is a distinct Database-as-a-Service (DBaaS) offering. The question specifies deploying on Azure virtual machines, which is an Infrastructure-as-a-Service (IaaS) model.

B. SAP Cloud Platform Cockpit: This is a management and administration interface for the SAP Business Technology Platform (BTP), not a tool for sizing infrastructure for SAP applications.

C. HANA Cockpit: This is an administration and monitoring tool used after an SAP HANA database has been deployed. It is not used for pre-migration sizing calculations.

1. Microsoft Learn

Azure Docs: In the "SAP workload planning and deployment checklist

" under the "Sizing SAP systems" section

it states

"For sizing of SAP systems

SAP requires using the SAP Quick Sizer tool." This document provides guidance for deploying SAP workloads on Azure

which is the scenario in the question.

Source: Microsoft Docs

SAP workload planning and deployment checklist

Sizing SAP systems section.

2. SAP Note #1793345 - Sizing for SAP Suite on HANA: This official SAP Note provides the guidelines for sizing SAP Business Suite on HANA. It explicitly directs users to the SAP Quick Sizer tool for the sizing process.

Source: SAP ONE Support Launchpad

SAP Note #1793345.

3. SAP Help Portal: The documentation for "Sizing for SAP S/4HANA" (a successor to Business Suite

but the principle and tool are the same) states

"The SAP Quick Sizer tool has been developed by SAP in close cooperation with its platform partners to help you determine the hardware requirements for your SAP applications."

Source: SAP Help Portal

Sizing for SAP S/4HANA

"SAP Quick Sizer" section.

To meet the requirement of migrating the HANA database servers (rehosting/lift-and-shift) to Azure virtual machines while minimizing downtime, Azure Migrate is the appropriate tool.

• SCS (SAP Central Services): This is a server-level component. Azure Migrate (specifically the Server Migration tool) is the standard Azure service used to replicate on-premises virtual or physical servers to Azure VMs with minimal downtime during the cutover.
• HANA: While SAP-native tools like HSR (HANA System Replication) provide the lowest downtime for data, the question specifically asks for a tool to migrate the servers. Azure Migrate performs block-level replication of the entire server to an Azure VM.
• Why not others: Azure Database Migration Service does not support SAP HANA. S/4HANA Migration Cockpit is used for data/object migration, not server migration. HANA Cockpit is an administrative tool, not a migration engine for server-level moves.

Microsoft Documentation: "Migrate SAP workloads to Azure: Migration strategies." This document specifies using Azure Migrate for rehosting (lift-and-shift) SAP application and database servers. Link

Microsoft Learn (AZ-120): Module "Migrate SAP workloads to Azure." It highlights Azure Migrate as the primary hub for assessing and migrating on-premises servers to Azure.

SAP Note 1928533: "SAP Applications on Azure: Supported Products and Azure VM types." Details the support for rehosting existing SAP landscapes using server migration tools.

Azure Documentation: "Azure Database Migration Service - Supported Databases." Confirms that SAP HANA is currently not a supported source or target for Azure DMS. Link

Joining SLES to AD requires Winbind to act as the bridge between Linux and the AD domain controller.

1. Install: You must first install the samba-winbind package to provide the necessary binaries and libraries.
2. Configure: You then modify /etc/krb5.conf to define the Kerberos realm and /etc/samba/smb.conf to define the workgroup, security mode (ADS), and realm. These configurations are prerequisites for authentication.
3. Join: The command net ads join is used to create the computer account in AD. The -U flag specifies an administrator account with permissions to join the domain. net rpc join is incorrect here as it is used for older NT4-style domains rather than Active Directory environments.

SUSE Documentation: SLES 15 SP5 Administration Guide, Chapter: "Active Directory Support," Section: "Joining an Active Directory Domain."

Samba Documentation: Samba Wiki, "Joining a Windows Domain," Section: "Active Directory Domain Join."

Microsoft Azure Documentation: SAP on Azure Architecture Guide, "SLES for SAP Applications on Azure," Section: "Active Directory Integration."

MIT Kerberos Documentation: Kerberos V5 Administrator's Guide, Section: "The krb5.conf File."

To meet the stringent SAP HANA storage Key Performance Indicators (KPIs) for throughput and I/O on Azure, it is necessary to aggregate the performance of multiple Azure Premium Storage disks. This is achieved by creating a striped volume using a software RAID, such as mdadm in Linux. RAID0 (striping) is the recommended configuration for both the /hana/data and /hana/log volumes. It combines the IOPS and throughput of all underlying disks without the performance overhead of parity calculations found in RAID5 or RAID6. The required data redundancy is provided by the underlying Azure Storage platform (Locally Redundant Storage - LRS), which maintains three copies of the data, making OS-level RAID for redundancy unnecessary.

A. RAID1: RAID1 (mirroring) provides redundancy but does not aggregate write performance, failing to meet the high throughput requirements for SAP HANA data and log volumes.

B. RAID5: RAID5 is explicitly not recommended for the write-intensive /hana/log volume due to the significant write penalty associated with parity calculations, which severely impacts performance and latency.

D. RAID6: RAID6 has an even higher write penalty than RAID5 because it calculates and writes two parity blocks, making it the least suitable option for high-performance database workloads like SAP HANA.

1. Microsoft Docs

"SAP HANA Azure virtual machine storage configurations"

Last updated: 01/29/2024.

Section: Linux LVM and mdadm: "For the SAP HANA data and log volumes

we don't recommend any RAID redundancy level. The reason is that Azure Premium Storage already provides a sufficient level of redundancy with three images of the disks... The main purpose of building a RAID volume is to stripe I/O against multiple Azure Premium disks." This statement directly supports using striping (RAID0) and advises against redundancy levels like RAID1

RAID5

and RAID6.

Section: Production recommended storage configuration: This section provides specific examples for different VM types

all of which use multiple disks striped together (RAID0) for /hana/data and /hana/log to achieve the required performance. For example

for an M32ts VM

it recommends "4 x P10" disks in a striped set for /hana/data.

Section: Considerations for the /hana/log volume: "For the /hana/log volume

the usage of RAID 5 is not supported." This explicitly disqualifies RAID5 as a correct answer.

Statement 1: Yes. Accelerated Networking uses Single Root I/O Virtualization (SR-IOV) to offload network processing from the VM’s CPU to the hardware NIC. This reduces the CPU overhead required for packet processing, thereby decreasing overall CPU usage.

Statement 2: No. One of the primary benefits of Accelerated Networking is the reduction of jitter and latency by bypassing the virtual switch and the host's "software" processing path. It provides a more consistent, deterministic network path.

Statement 3: No. This feature is restricted to specific supported VM sizes (typically those with 2 or more vCPUs) and requires specific OS versions (e.g., Windows Server 2012 R2+ or modern Linux distributions).

Microsoft Azure Documentation: "Create a Windows VM with accelerated networking," Section: Benefits, Paragraph 2 & 4. (https://learn.microsoft.com/en-us/azure/virtual-network/create-vm-accelerated-networking-powershell)

Microsoft Azure Documentation: "SAP on Azure: SAP Netweaver on Azure VMs - Accelerated Networking," Section: Performance Recommendations. (https://learn.microsoft.com/en-us/azure/sap/workloads/deployment-guide#accelerated-networking)

Microsoft Azure Documentation: "Accelerated Networking - Limitations and Constraints," Section: Supported VM instances. (https://learn.microsoft.com/en-us/azure/virtual-network/accelerated-networking-overview#limitations-and-constraints)

The most effective method to minimize costs for non-production environments like development and quality assurance is to shut them down during periods of inactivity, such as nights and weekends. Azure Automation runbooks provide a robust and schedulable mechanism to automatically stop (deallocate) and start Azure virtual machines. When a VM is deallocated, Azure stops billing for compute resources (CPU, memory), resulting in significant cost savings. This approach directly addresses the requirement by ensuring the SAP landscapes are only running and incurring costs when they are actively being used.

B. The stopsap command stops the SAP application services running within the OS but does not deallocate the Azure VM, so compute costs continue to accrue.

C. Azure App Service is a Platform-as-a-Service (PaaS) offering and is not used to host the core components of an SAP NetWeaver or S/4HANA environment.

D. Azure Virtual Machine Scale Sets are designed for automatic scaling of identical VMs based on performance metrics, not for scheduled shutdowns of entire landscapes.

1. Microsoft Learn

"Start/Stop VMs v2 overview": This document describes a feature built on Azure Automation specifically for cost optimization. It states

"The Start/Stop VMs v2 feature starts or stops enabled Azure VMs on a schedule. It helps optimize costs for users who want to stop VMs when not in use and then start them when they're needed." This directly supports using automation for the described scenario.

2. Microsoft Docs

"Azure Virtual Machines planning and implementation for SAP NetWeaver"

Section: "General Azure VM deployment": This guide

while not explicitly detailing automation

establishes the foundation that SAP landscapes run on IaaS VMs. The principle of deallocating IaaS VMs to save costs is a fundamental Azure best practice. The document notes

"For non-production systems

you can reduce costs by shutting down the SAP systems and deallocating the VMs." Azure Automation is the primary tool to schedule this deallocation.

3. Microsoft Docs

"Virtual machine states and billing status": This document clarifies that billing for compute resources stops only when a VM is in the Stopped (deallocated) state. This confirms why simply running stopsap (Option B)

which leaves the VM in a Running state

does not save on compute costs

whereas using an automation runbook to deallocate the VM (Option A) does.

The Azure Standard support plan is designed for production workloads and provides 24/7 technical support. For critical business impact incidents (Severity A), it guarantees an initial response time of less than one hour. This meets the primary technical requirement. Among the plans that satisfy this response time (Standard, Professional Direct, and Premier), the Standard plan is the most cost-effective, thereby fulfilling the "minimize costs" requirement.

A. Professional Direct: While this plan also offers a response time of less than one hour for critical incidents, it is more expensive than the Standard plan and thus does not meet the cost minimization requirement.

C. Basic: The Basic support plan is included with all Azure subscriptions but does not offer technical support for production environments or a guaranteed response time for critical incidents.

D. Premier: The Premier (now part of Unified Support) plan offers a much faster response time (e.g., <15 minutes) but is the most expensive option, violating the requirement to minimize costs.

---

1. Microsoft Azure Official Documentation

"Support Plans": This document provides a direct comparison of the features

including response times and target use cases

for all Azure support plans.

Reference: Under the "Compare support plans" table

in the "Technical support" section

the row for "Initial response time" for "Critical business impact (Severity A)" explicitly states "< 1 hour" for both Standard and Professional Direct plans. The cost hierarchy is also evident from the pricing details on the same page.

Source: Microsoft Azure. (n.d.). Azure Support Plans. Retrieved from https://azure.microsoft.com/en-us/support/plans/

2. Microsoft Azure Official Documentation

"How to create an Azure support request": This document details the process of creating a support request and defines the severity levels

confirming that "Severity A" is for critical business impact.

Reference: The section "Severity levels" defines Severity A as "Critical Impact - Production system down". The ability to select this severity is tied to the support plan level.

Source: Microsoft Azure. (2023

October 24). How to create an Azure support request. Retrieved from https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request#severity-levels

The SAP Software Update Manager (SUM) with its Database Migration Option (DMO) feature is the designated SAP tool for this scenario. It combines a system update, conversion, or upgrade with a database migration (e.g., from AnyDB to SAP HANA) into a single, highly optimized procedure. The "DMO with System Move" capability specifically supports migrating to a different infrastructure, such as from on-premises to Azure. This one-step approach significantly minimizes downtime and administrative effort compared to a traditional two-step export/import migration using other tools.

A. SAP Software Provisioning Manager: SWPM is used for new installations or classic two-step migrations (export/import). This method typically involves more downtime and administrative steps than the integrated SUM with DMO process.

C. Azure Migrate: Azure Migrate is an infrastructure migration service for moving VMs and servers to Azure. It does not perform the application-specific database replatforming from SAP AnyDB to SAP HANA.

D. Azure Database Migration Service: This service is for migrating non-SAP databases (like SQL Server, Oracle) to Azure PaaS database offerings. It does not support the application-aware migration required for SAP systems to HANA.

1. Microsoft Docs

Azure Architecture Center

"SAP S/4HANA in Linux on Azure": This document outlines migration strategies. Under the "Migration to S/4HANA" section

it states

"For migrations from an existing SAP ERP system to S/4HANA

the SAP Software Update Manager (SUM) tool is the officially supported and recommended tool. It offers a path that combines the software update and the database migration to SAP HANA (if applicable) in one tool." This confirms SUM as the primary tool for combined updates and HANA migration.

2. Microsoft Docs

Azure Virtual Machines

"SAP workload on Azure: planning and deployment checklist": In the "Migration phase" section

this guide discusses migration methodologies. It explicitly lists "Using SAP Software Update Manager (SUM) with Database Migration Option (DMO)" as a key method for migrating to Azure

highlighting its efficiency for combining tasks.

3. SAP Help Portal

"Database Migration Option (DMO) of Software Update Manager 2.0 SP17": The official SAP documentation describes the tool's purpose: "The Database Migration Option (DMO) of Software Update Manager (SUM) is the process for migration to a different database... DMO can be used to migrate to SAP HANA database... The DMO procedure combines the database migration with the software update." This directly supports its use for minimizing downtime by combining steps.

SAP Central Services (SCS): The SCS layer is a critical but relatively lightweight component of the SAP application layer. It does not require high memory-to-vCPU ratios like a database. D-Series (specifically the Ds-series) VMs are officially supported for SAP production application servers and Central Services, providing a balanced and cost-effective compute solution.

SAP HANA: HANA is an in-memory database requiring high memory performance and strict SAP certification. The M-Series is specifically designed and certified for large-scale, memory-intensive workloads like SAP HANA, offering the necessary RAM and vCPU throughput required for production support.

Microsoft Learn: Use Azure to host and run SAP workload scenarios - SAP workload on Azure: supportable VMs. (Sections: "Application server" and "Database server").

SAP Note 1928533: SAP Applications on Azure: Supported Products and Azure VM types. This note lists certified VM series for SAP production.

SAP Note 2316233: SAP HANA on Microsoft Azure Support Indicators. (Details M-series certification for HANA production).

Microsoft Architecture Guide: SAP NetWeaver on Azure Virtual Machines - Architecture Reference.

Microsoft Azure Documentation: Azure Virtual Machines for SAP HANA - M-series Specifications.

When attaching data disks to an Azure Linux VM for an SAP workload, a stable naming convention is required for automation, as device names like /dev/sdc can change upon reboot. Azure provides a set of stable symbolic links under the /dev/disk/azure/ directory. Specifically, data disks are organized by SCSI controller and LUN. The path /dev/disk/azure/scsi1/ contains symbolic links named lun0, lun1, lun2, etc., which correspond directly to the LUN specified in the ARM template. Running the ls /dev/disk/azure/scsi1 command lists these links, allowing a direct correlation between the LUN and the underlying kernel device name (e.g., sdc), which is the goal of the question.

A. ls /dev/disk/azure/root: This path is a symbolic link to the operating system (OS) disk, not the attached data disks.

C. tree /dev/disk/azure/root: This command also targets the OS disk path. It is used for viewing a directory tree, which is not the intended use for this specific path.

D. tree /dev/disk/azure/resource: This path is a symbolic link to the temporary resource disk, not the persistent data disks used for SAP files.

1. Microsoft Learn

"Configure LVM on a Linux VM in Azure": This document demonstrates using the /dev/disk/azure/scsi1/ path to identify disks by their LUN. Under the "Identify the data disks" section

it shows the command ls -l /dev/disk/azure/scsi1/ and its output

which clearly maps lun0

lun1

etc.

to their corresponding /dev/sd device names.

2. Microsoft Learn

"Azure Virtual Machines storage configuration for SAP NetWeaver": In the "Linux" section

this guide states

"On Linux

the Azure platform creates friendly names in the directory /dev/disk/azure. For your automation scripts

use the devices in the /dev/disk/azure directory." This confirms the recommended practice for SAP workloads is to use this stable path for disk identification.

3. Microsoft Learn

"Troubleshoot Linux VM device name changes": This article explains the problem of non-persistent device names and recommends using persistent naming conventions. It mentions that the Azure Linux Agent creates symbolic links under /dev/disk/azure based on the SCSI address (including LUN) of the disks

reinforcing the reliability of this path for correlation.

Azure AD Connect is the primary Microsoft tool for integrating on-premises Active Directory with Azure AD (now Microsoft Entra ID). It facilitates identity synchronization and configures the chosen authentication method, which could be Password Hash Synchronization, Pass-through Authentication, or Federation with AD FS. To use on-premises identities to administer Azure resources, the foundational step is to synchronize them to Azure AD. Azure AD Connect is the tool that accomplishes this. AD FS is only one of several authentication options and is itself often configured through Azure AD Connect, making Azure AD Connect the more fundamental and initial component to implement.

A. No change is needed: AD FS is an optional federation service, not a mandatory first step. The primary tool for establishing hybrid identity is Azure AD Connect.

C. Azure AD join: This process is for registering devices directly with Azure AD. It is unrelated to synchronizing user identities from on-premises AD for resource administration.

D. Enterprise State Roaming: This feature synchronizes user settings and application data across Windows devices. It is not a foundational component for identity management or resource administration.

---

1. Microsoft Learn

Azure Active Directory Documentation. "What is Azure AD Connect?". This document introduces Azure AD Connect as the tool to integrate on-premises directories with Azure AD. It states

"Azure AD Connect is the Microsoft tool designed to meet and accomplish your hybrid identity goals." It lists "Federation integration" as one of its features

showing that AD FS is a component managed by Azure AD Connect

not a prerequisite for it.

Reference: https://learn.microsoft.com/en-us/azure/active-directory/hybrid/connect/whatis-azure-ad-connect

Introduction section.

2. Microsoft Learn

Azure Active Directory Documentation. "Choose the right authentication method for your Azure Active Directory hybrid identity solution". This document compares the different authentication methods. It presents a flowchart where the decision to use Federation (like AD FS) comes after the initial decision to synchronize with Azure AD

a process managed by Azure AD Connect. This confirms that Azure AD Connect is the starting point.

Reference: https://learn.microsoft.com/en-us/azure/active-directory/hybrid/connect/choose-ad-authn

"Authentication methods" section and diagram.

3. Microsoft Learn

Azure Active Directory Documentation. "What is federation with Azure AD?". This document explains that federation is an option for authentication and explicitly states

"You can configure federation with AD FS by using Azure AD Connect with only a few clicks." This reinforces that Azure AD Connect is the tool used to implement the solution.

Reference: https://learn.microsoft.com/en-us/azure/active-directory/hybrid/connect/whatis-fed

"Federation with Azure AD" section.

For the SAP ERP system, the goal is a simultaneous migration (Oracle to HANA) and a platform shift (On-premises to Azure). The SUM DMO with System Update is the standard tool for "One-Step" migrations, allowing you to upgrade the SAP application version and migrate the database to SAP HANA in a single downtime window.

For the SAP NetWeaver 7.3 Portal, the SUM DMO tool is primarily designed for ABAP stacks. Java stacks (like most portals) or older NetWeaver versions typically require a Heterogeneous System Copy using the Software Provisioning Manager (SWPM). This process exports the source database and imports it into the target HANA database on Azure, effectively handling the change in OS/DB architecture.

SAP Support Portal, SAP Note 2377305: "Case 3: Migration of an SAP system to SAP HANA using DMO." This confirms DMO is the tool for combining upgrade and migration for ABAP-based systems like ERP.

SAP Help Portal - Software Update Manager (SUM) 2.0: Section "Database Migration Option (DMO) of SUM" specifies that DMO is the preferred method for migrating to SAP HANA while performing a release upgrade.

Microsoft Azure Documentation: "SAP NetWeaver on Azure Virtual Machines (VMs) planning and implementation." This documentation outlines using SWPM for heterogeneous copies when moving non-ABAP or specific Java-based Portal components to Azure.

SAP NetWeaver Guide: "System Copy Guide: SAP Systems Based on SAP NetWeaver 7.1 to 7.5 on UNIX/Oracle," detailing the use of Software Provisioning Manager (SWPM) for heterogeneous system copies.

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Microsoft_AZ-120_Dumps/page_31_img_1.jpg?