AZ-120 Practice Questions

Azure shared disks are a feature of Azure Managed Disks that allow a disk to be attached to multiple virtual machines simultaneously. This provides a shared block storage solution suitable for clustered applications like SAP ASCS/SCS. For the goal of cost reduction, Azure shared disks are typically more cost-effective than alternatives like Azure NetApp Files (a premium service) or building and managing a separate cluster for a Scale-Out File Server or NFS share. It simplifies the high-availability architecture by eliminating the need for additional infrastructure for storage replication, thereby lowering the total cost of ownership (TCO).

A. Azure NetApp Files: This is a premium, high-performance file storage service. While it is a valid and supported solution for SAP shared storage, it is generally more expensive than using Azure shared disks, making it a less optimal choice for a cost-reduction initiative.

C. Azure Data Share: This service is designed for securely sharing data with external organizations. It is not a shared storage solution for high-availability clustering and is irrelevant to the technical requirements of an SAP ASCS instance.

D. Storage Spaces Direct: This is a Windows Server feature for building software-defined storage using local disks. It adds complexity and cost by requiring multiple dedicated VMs for the storage cluster, making it less cost-effective than the more direct Azure shared disks solution.

1. Microsoft Learn

High availability for SAP NetWeaver on Azure VMs on SUSE Linux Enterprise Server with Azure shared disk for SAP applications: This document presents Azure shared disks as a solution for SAP ASCS/ERS high availability. It states

"Azure shared disk is a new offering from Azure Managed Disks. It will help you to simplify your SLES high availability cluster." Simplification of architecture directly contributes to cost reduction. (See the "Introduction" section).

2. Microsoft Learn

Azure shared disks: This documentation describes the feature and its intended use cases. It notes

"Shared disks offer shared block storage that can be accessed from multiple VMs... A common use case is for SAP ASCS/SCS...". It positions the feature as a direct solution for this scenario. (See the "Workloads" section).

3. Microsoft Learn

SAP workloads on Azure: planning and deployment checklist: In the storage section

this guide discusses various storage options. While it lists Azure NetApp Files as a high-performance option

Azure shared disks are presented as a native

integrated solution for clustering

which implies a lower TCO compared to more complex or premium services. (See the "Decide on a storage type" section).

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

Box 1: five minutes

Window Size is 5 minutes.

Box 2: admins action group will be emailed

The admins1 actiongroup will be executed.

Reference:

https://docs.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-metric-overview

To achieve the goal of migrating an SAP database from Oracle to SQL Server as quickly as possible using the SQL Server Migration Assistant (SSMA), the Server Side migration method is required. Unlike the Client Side engine, which processes data through the SSMA client machine, the Server Side engine (utilizing the SSMA Extension Pack) runs as a background process on the target SQL Server instance. It uses high-performance bulk load mechanisms, which significantly reduce data transfer time, especially for multiple iterations in a Proof of Concept (PoC). The Default migration mode is the standard configuration for SSMA projects, ensuring that all Oracle schemas and objects are correctly mapped and converted according to the pre-defined SAP-to-SQL type mappings without the overhead of experimental or overly restrictive custom configurations.

Microsoft Documentation: SQL Server Migration Assistant for Oracle (OracleToSQL) - Setting Project Options (Migration). This section details that the Server-side data migration engine is recommended for large datasets and performance-critical migrations.

Microsoft Documentation: SQL Server Migration Assistant for Oracle - Installing SSMA Components on SQL Server (OracleToSQL). Explains the use of the SSMA Extension Pack for server-side processing to enhance migration speed.

SAP on Azure Best Practices: SAP Database Migration Guide - Oracle to SQL Server. Highlights the use of SSMA with the server-side engine to minimize downtime and maximize throughput during the data load phase.

Microsoft Learn (AZ-120): Plan and Implement a Migration of SAP Workloads to Azure. Confirms that for repeatable PoCs and large-scale migrations, optimizing the data migration engine in SSMA is a key performance factor.

The SAP HANA Quick Sizer is a tool designed for estimating the hardware requirements for new SAP HANA implementations. It calculates CPU, memory, and disk needs based on business-oriented inputs, such as anticipated transaction volumes and user counts. It does not connect to an existing system to collect or analyze historical performance data. To gather actual CPU metrics from a running SAP HANA instance, you would use monitoring tools like SAP HANA Cockpit, SAP Solution Manager, or by querying the system's internal monitoring views (e.g., in the SYSSTATISTICS schema).

A. Yes: This is incorrect because the Quick Sizer's function is for forward-looking estimation and planning, not for collecting historical performance data from an active system.

1. Microsoft Docs

SAP workload planning and deployment checklist

Sizing section: "For new SAP implementations in Azure (greenfield implementation)

use the SAP Quick Sizer to calculate the hardware requirements of your SAP production systems." This source explicitly states the Quick Sizer is for new implementations.

2. SAP Help Portal

Quick Sizer for SAP HANA: "The Quick Sizer is a Web-based tool designed to make the sizing of SAP Applications easier and faster. It helps you to translate business requirements into hardware requirements." This official SAP documentation confirms the tool's purpose is to translate business requirements

not to analyze existing system metrics.

3. Microsoft Docs

Azure Virtual Machines SAP workload planning and deployment checklist

Current source system analysis section: "If you're migrating an existing application to Azure (brownfield implementation)

analyze the resource consumption of the existing infrastructure to help determine the resource requirements in Azure." This highlights that for migrations

analysis of the current system is required

a task for which Quick Sizer is not designed.

Azure Backup is the recommended solution as it is a native, managed service that minimizes administrative effort through policy-based automation. Crucially, it provides recoverability if the entire file share is deleted. When you configure backup for an Azure file share, the data is stored in a Recovery Services vault, separate from the source storage account. Azure Backup also enables a soft delete feature at the storage account level, which retains the backup data for a configurable period (14 days by default) even after the source file share is deleted, allowing for a full restore. This directly addresses both requirements of the question.

A. AzCopy: AzCopy is a command-line utility for data transfer, not a managed backup service. Using it would require custom scripting and scheduling, which increases administrative effort.

C. fpsync: Similar to AzCopy, fpsync is a file synchronization tool. It is not an integrated backup solution and would require significant manual configuration and management.

D. snapshots: While Azure Backup uses snapshots, snapshots alone are insufficient. If the Azure file share is deleted, all of its associated snapshots are also permanently deleted, failing the requirement for recoverability from share deletion.

1. Microsoft Docs

Azure Backup Documentation

"About Azure file share backup": "Azure Backup for Azure Files is a native

cloud-based backup solution... It also helps you protect your file shares against accidental deletion by enabling the soft delete feature on a storage account level and taking a backup of file shares. The backup data is stored in a Recovery Services vault

which is a separate fault and management domain."

2. Microsoft Docs

Azure Storage Documentation

"Prevent accidental deletion of Azure file shares": "When soft delete for Azure file shares is enabled for a storage account

if a file share is deleted

it transitions to a soft deleted state instead of being permanently erased... You can restore a soft deleted share at any time during the retention period." This confirms the mechanism that protects against share deletion.

3. Microsoft Docs

Azure Files Documentation

"NFS file shares in Azure Files"

Section: Data protection: "You can back up your NFS file shares by using Azure Backup. Azure Backup supports both snapshot-based backups and vaulted backups... Vaulted backups copy your snapshots to a Recovery Services vault for off-site protection and longer retention." This explicitly recommends Azure Backup for NFS shares and highlights the vaulted backup feature for protection.

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).

The Near-Zero Downtime (NZDT) method is a specialized service and methodology from SAP specifically designed to minimize the business downtime required for a migration to the lowest possible level, often just minutes. It uses advanced techniques like cloning and trigger-based data replication to perform the majority of the migration work while the source system remains online. The final cutover involves a very brief downtime period. While the Database Migration Option (DMO) is also a downtime-optimized approach, NZDT provides an even shorter downtime window, making it the superior choice for the goal of causing the least amount of downtime.

A. Use the Database migration Option (DMO) to migrate to SAP HANA and Azure During the same maintenance window.

DMO is a downtime-optimized tool, but NZDT is a specialized service designed to achieve even lower downtime, making DMO not the option with the least downtime.

C. Migrate SAP to Azure, and then migrate SAP ECC to SAP Business Suite on HANA.

This two-step approach requires two separate projects and two distinct maintenance windows (one for the Azure migration and one for the HANA migration), resulting in significantly more cumulative downtime.

D. Migrate SAP ECC to SAP Business Suite on HANA an the migrate SAP to Azure.

Similar to option C, this is a two-step migration that involves two separate downtime windows, which increases the total business outage compared to a combined, optimized approach.

1. Microsoft Tech Community Blog

"SAP S/4HANA Migration to Azure – Part 2 – Migration Approaches": This article explicitly compares migration methods. It states

"For customers with very large databases and a very low downtime tolerance

SAP offers a service called near-Zero Downtime (NZDT)... NZDT can reduce the downtime to less than an hour." This confirms NZDT as the option for the lowest downtime.

2. SAP Help Portal

"Downtime-Optimized DMO": This official SAP documentation describes the DMO process. It details how DMO minimizes downtime by performing tasks in uptime

but it still requires a distinct downtime phase for migration and cutover

which is typically longer than an NZDT cutover.

3. Microsoft Learn

"SAP workload - Azure migration scenarios": This document discusses the DMO tool as a method to "combine several migration steps into one tool and one downtime window

" highlighting its efficiency over two-step migrations. However

it positions DMO as a standard optimized path

while NZDT is recognized as a more advanced solution for extreme downtime constraints.

The goal is to ensure the network virtual appliance (NVA), which acts as a firewall, is not a single point of failure. Deploying an Azure Standard Load Balancer is a necessary component for an NVA high-availability (HA) architecture, but it is insufficient on its own. A complete solution requires deploying at least two NVA instances, placing them in the load balancer's backend pool, and configuring User-Defined Routes (UDRs) to direct traffic to the load balancer's frontend IP address. Since the proposed solution is incomplete and does not, by itself, provide high availability for the single NVA, it does not meet the goal.

A. Yes: This is incorrect because deploying only a load balancer without multiple NVAs in its backend pool and correctly configured routing does not create a highly available firewall solution.

1. Microsoft Azure Documentation

Reference Architectures

"Highly available network virtual appliances." This document explicitly details the required architecture for NVA high availability. It states

"To make the NVAs highly available

deploy them behind an Azure Load Balancer." The accompanying diagrams and text clarify that this involves multiple NVA virtual machines

an internal Standard Load Balancer

and User-Defined Routes pointing to the load balancer's frontend IP. The deployment of the load balancer is just one part of the overall solution.

Source: https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/dmz/nva-ha

Section: "Architecture".

2. Microsoft Azure Documentation

"What is Azure Load Balancer?"

"High availability ports overview." This document explains the HA Ports feature of the Standard Load Balancer

which is specifically designed for scenarios like NVA high availability. It clarifies that the feature works by distributing flows to a pool of backend instances (i.e.

multiple NVAs)

which is essential for failover. A single NVA with a load balancer provides no HA.

Source: https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-ha-ports-overview

Section: "NVA high availability".

3. Microsoft Azure Documentation

"SAP workload on Azure: planning and deployment checklist." In the networking section

for ensuring resilient connectivity

the guidance points towards using highly available NVAs. The implementation links back to the standard architecture requiring multiple NVAs fronted by a load balancer.

Source: https://learn.microsoft.com/en-us/azure/sap/workloads/deployment-checklist

Section: "Networking".

SAP licenses are bound to a Hardware Key. On Windows, the SAP hardware key is primarily derived from the network computer name (hostname). Therefore, changing the hostname immediately invalidates the existing license. On Linux (and other Unix-based systems), the hardware key is derived from a unique hardware identifier (UUID). While deallocating or redeploying a VM in Azure typically maintains this ID, deleting and recreating the VM resource generates a new hardware ID for the underlying virtual hardware, even if the original OS disks are attached, causing the license to become invalid.

SAP Note 1031096: Installing a license key on Windows. This note specifies that the hardware key on Windows is generated based on the hostname.

SAP Note 117868: NetWeaver License Keys. Details the derivation of hardware keys and the requirements for requesting new keys when hardware identifiers change.

Microsoft Learn: SAP NetWeaver on Azure Virtual Machines planning and implementation guide. Section: "Licensing," which notes that the hardware key remains stable during deallocation but changes if the VM is deleted/recreated.

SAP Help Portal: License Keys for SAP Systems. Documentation on "Hardware ID" explains the platform-specific generation of the unique identifier used for license requests.

For SAP HANA deployments on Azure NetApp Files (ANF), NFSv4.1 is the officially required and supported protocol for data and log volumes due to its support for strong security and parallel I/O. To ensure the lowest possible latency between the SAP HANA application layer and the storage layer, Azure utilizes Proximity Placement Groups (PPG). The Application Volume Group (AVG) feature for SAP HANA is specifically designed to deploy all necessary volumes (data, log, shared) in a single workflow, ensuring they are physically co-located with the compute resources within the same PPG, thereby meeting SAP's strict performance and latency requirements.

Microsoft Learn (Official Azure Documentation): "Azure NetApp Files application volume group for SAP HANA," Section: Concepts, Link to Documentation.

SAP Note 2822499: "SAP HANA on Microsoft Azure NetApp Files," (Specifies NFSv4.1 requirements and performance best practices).

Microsoft Azure Architecture Center: "SAP HANA on Azure NetApp Files," Section: Storage, Link to Architecture.

Microsoft Learn: "Deploy SAP HANA with application volume group," Section: Proximity Placement Groups, Link to PPG details.