AZ-104 Microsoft Azure Administrator Questions and Answers

On January 15, 2021, App1 will have only one backup in storage. Yes, this is correct. According to the table, App1 has a backup every 1 day, starting from January 6, 2021, with a retention of 0 days. This means that each backup will be deleted after 0 days, or as soon as the next backup is created. Therefore, on January 15, 2021, App1 will have only one backup in storage, which is the one created on that day1.

On February 6, 2021, you can access the backup of the App2 test slot from January 15, 2021. No, this is not correct. According to the table, App2 has a backup every 1 day, starting from January 6, 2021, with a retention of 30 days. This means that each backup will be deleted after 30 days, or when the storage limit is reached. However, the table also shows that App2 has a setting of “Keep at least one backup” set to Yes. This means that the oldest backup will be retained even if it exceeds the retention period or the storage limit2. Therefore, on February 6, 2021, you can access the backup of the App2 test slot from January 6, 2021, but not from January 15, 2021.

On January 15, 2021, you can restore the App2 production slot backup from January 6 to the App2 test slot. Yes, this is correct. According to the web search results, you can restore a backup by overwriting an existing app or by restoring to a new app or slot3. You can also restore a backup from a different slot or app as long as they are in the same subscription and region4. Therefore, on January 15, 2021, you can restore the App2 production slot backup from January 6 to the App2 test slot.

To ensure users can sign in to virtual machines that are assigned role1, modify the actions section.

To ensure that role1 can be assigned only to a resource group named RG1, modify the assignableScopes section.

In Azure Role-Based Access Control (RBAC), a custom role defines a collection of permissions that specify what actions a user or service principal can perform and the scope to which these permissions apply. The JSON definition of a custom role contains key properties including:

actions: Lists the management operations permitted (e.g., " Microsoft.Compute/virtualMachines/* " allows control over VMs).

notActions: Explicitly denies certain operations that would otherwise be allowed.

dataActions: Lists operations on data within a resource (e.g., blob reads/writes).

assignableScopes: Defines the scopes (subscriptions, resource groups, or resources) where the custom role can be assigned.

According to Microsoft Azure Administrator documentation, if you want to ensure that users assigned a role can sign in to virtual machines, you must include the appropriate sign-in permissions in the actions section. Specifically, you would add:

" Microsoft.Compute/virtualMachines/login/action "

This grants sign-in access to the VM via Azure RBAC.

Furthermore, if you want to restrict the scope of where the custom role can be assigned — for example, to a specific resource group like RG1 — you must define that restriction within the assignableScopes section. For example:

" assignableScopes " : [

" /subscriptions/{subscriptionId}/resourceGroups/RG1 "

]

This ensures that the custom role is only visible and assignable within that resource group, preventing assignments at subscription or management group levels.

These definitions align with official Microsoft RBAC schema guidelines described in Azure Role Definitions and Custom Roles Overview for Azure Resource Manager.

This question tests your understanding of Shared Access Signatures (SAS) in Azure Storage and how SAS permissions, IP restrictions, and expiry times control access.

The exhibit shows a Service SAS generated for Azure Storage with the following key parameters:

Allowed services: Blob, File, Queue, Table

Allowed resource types: Service, Container, Object

Allowed permissions: Read, Write, Delete, List, Add, Create

Start time: September 1, 2018, 2:00 PM

Expiry time: September 14, 2018, 2:00 PM

Allowed IP range: 193.77.134.10 – 193.77.134.50

Allowed protocols: HTTPS only

Scenario 1:

Date: September 2, 2018

Client IP: 193.77.134.1

The start and expiry times are valid (the SAS is active on September 2), but the IP address 193.77.134.1 is outside the allowed range (193.77.134.10–193.77.134.50).

Azure Storage enforces IP restrictions strictly — clients must connect from an IP address within the specified range. Any request from outside that range results in authentication failure.

✅ Correct Result: The client will have no access to the storage account using SAS1.

Scenario 2:

Date: September 10, 2018

Client IP: 193.77.134.50

In this case:

The SAS is still valid (Sept 10 is between the start and expiry dates).

The IP address 193.77.134.50 is within the allowed range.

The protocol used must be HTTPS, and the exhibit shows that HTTPS only is enabled.

Therefore, a client connecting with SAS1 over HTTPS will have the permissions defined in the SAS token:

Read, Write, and List (and other permissions such as Add and Create).

Since the question limits the choice to the relevant permissions for access, the correct selection is “will have read, write, and list access.”

✅ Correct Result: The client will have read, write, and list access.

Microsoft Azure Administrator Documentation Reference:

“Shared Access Signatures (SAS) provide delegated access to storage resources with fine-grained control over permissions, IP address ranges, start/expiry time, and protocols. Requests made outside the specified IP range or time window are denied.”

(Source: Microsoft Learn — Secure access to Azure Storage with shared access signatures, AZ-104 Exam Guide)

✅ Final Verified Answers:

Scenario

Date

IP Address

Result

1

Sept 2, 2018

193.77.134.1

Will have no access

2

Sept 10, 2018

193.77.134.50

Will have read, write, and list access

User : User 1, User2 , User 3 and User 4 (Explain : You can deleted all users with licence then what happend ? Only free the licence and storage en some part ) Group : Group 2 and Group 4 (Groups with active license assignments cannot be deleted. You get an error) https://techcommunity.microsoft.com/t5/microsoft-365-admin-center/reclaiming-licenses-from-deleted-users/m-p/116488

Box 1 :  4

As there are 4 distinct set of resource types (Ingress, Egress, Delete storage account, Restore blob ranges), so you need 4 alert rules. In one alert rule you can ' t specify different type of resources to monitor. So you need 4 alert rules.

Box 2 : 3

There are 3 distinct set of " Users to notify " as (User 1 and User 3), (User1 only), and (User1, User2, and User3). You can ' t set the action group based on existing group (Group1 and  Group2) as there is no specific group for User1 only. So you need to create 3 action group.

An Availability Zone in an Azure region is a combination of a fault domain and an update domain. For example, if you create three or more VMs across three zones in an Azure region, your VMs are effectively distributed across three fault domains and three update domains. The Azure platform recognizes this distribution across update domains to make sure that VMs in different zones are not updated at the same time.

Reference link

https://learn.microsoft.com/en-us/training/modules/configure-virtual-machine-availability/5-review-availability-zones

In Microsoft Azure, Azure Resource Manager (ARM) templates are JSON-based files used to define and automate the deployment of Azure resources in a consistent and repeatable manner. To deploy an ARM template, the PowerShell cmdlet you use depends on the deployment scope — whether the template targets a tenant, management group, subscription, or resource group.

According to the Microsoft Azure Administrator documentation (AZ-104 Study Guide, “Deploy and Manage Azure Resource Manager Templates”):

New-AzTenantDeployment → Used for tenant-level deployments, typically involving management group creation or tenant-wide policies.

New-AzSubscriptionDeployment → Used for subscription-level deployments, when resources are created directly under the subscription rather than within a resource group.

New-AzResourceGroupDeployment → Used for resource group-level deployments, which is the most common scenario for creating and managing resources such as virtual machines, storage accounts, and virtual networks.

New-AzDeployment → An older alias that may refer to subscription-level deployments in older Az modules but is not the standard for resource group deployments.

In this question, the ARM template defines both a resource group and a storage account that will be deployed within that resource group. Therefore, the correct PowerShell cmdlet to use is:

New-AzResourceGroupDeployment `

-ResourceGroupName < RGName > `

-TemplateFile < PathToTemplateFile >

This cmdlet processes the specified ARM template file, validates the schema, and provisions all the resources defined in the template inside the target resource group.

Hence, based on the Azure Resource Manager official documentation and exam objectives, the correct answer is:

The correct first action is to create a data collection rule (DCR) . Azure Monitor can collect host-level platform metrics automatically, but metrics from inside the guest operating system require an agent-based collection path. Microsoft states that Azure Monitor Agent collects monitoring data from the guest operating system of Azure and hybrid VMs, and that it collects data according to data collection rules, which define what data is collected, processed, and sent.

Disk read and write activity inside the OS is represented through performance counters. Microsoft’s VM monitoring guidance confirms that guest OS metrics must be collected through agents, and DCRs define performance counters and destinations such as Log Analytics workspaces. A workbook is useful later for consolidated visualization across subscriptions, because workbooks combine metrics, log queries, and multiple data sources into interactive reports, but it does not initiate guest OS metric collection. An alert rule detects conditions after data exists, and diagnostic settings mainly route platform logs or supported platform metrics rather than collecting guest OS counters. This aligns with AZ-104 Monitor resources in Azure , especially configuring Azure Monitor log settings, interpreting metrics, querying logs, and monitoring virtual machines by using Azure Monitor.

Box 1:  " /subscription/c276fc76-9cd4-44c9-99a7-4fd71546436e "

In the assignableScopes you need to mention the subscription ID where you want to implement the RBAC

Box 2:  " Microsoft.Authorization/* "

Microsoft.Authorization/* is used to Manage authorization

In Microsoft Azure Role-Based Access Control (RBAC), a custom role allows fine-grained permissions tailored to specific administrative needs. Custom RBAC roles are defined in JSON format and include three main elements — assignableScopes, permissions, and description.

1. Assignable Scopes

The assignable scope defines where the custom role can be applied.

In this scenario, the role must only be assignable to resource groups in the given subscription (not at the subscription or tenant root level).

Therefore, the assignable scope should be limited to the resource groups path:

" /subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/resourceGroups "

This ensures that the role can be assigned only within resource groups in the specified subscription, not globally.

2. Permissions

The permissions section includes four arrays:

actions → defines allowed operations.

notActions → explicitly denies specific operations.

dataActions and notDataActions → for data-plane access (not needed here).

Because the requirement states that the user should be able to view, create, modify, and delete resources within the resource groups, the actions array should contain:

" actions " : [ " * " ]

This grants full control over resource operations.

However, the question also specifies that the role must prevent the management of access permissions for the resource groups.

Managing access permissions is controlled by Microsoft.Authorization/ actions (e.g., Microsoft.Authorization/*/Write).

Thus, to explicitly block the ability to manage permissions, the notActions array must include:

" notActions " : [

" Microsoft.Authorization/* "

]

This restriction ensures that users with this role cannot assign roles, modify access control (RBAC), or change role assignments, even though they have full resource management permissions otherwise.

3. Summary of Correct JSON Configuration

{

" Name " : " CR1 " ,

" Description " : " Custom role to manage resources within resource groups but not RBAC permissions " ,

" AssignableScopes " : [

" /subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/resourceGroups "

],

" Permissions " : [

{

" Actions " : [

" * "

],

" NotActions " : [

" Microsoft.Authorization/* "

],

" DataActions " : [],

" NotDataActions " : []

}

]

}

4. Validation with Azure Administrator Study Guide

This configuration directly aligns with guidance in Microsoft Learn: “Azure custom roles in Azure RBAC” and AZ-104 Study Guide Module: Manage role-based access control (RBAC).

It meets all requirements:

Restricts role assignment scope to resource groups only.

Allows full resource management (CRUD).

Denies RBAC access control modifications via Microsoft.Authorization/*.

Final Verified Answers:

✅ Assignable Scope: /subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/resourceGroups

✅ Permission (notActions): " Microsoft.Authorization/* "

Active Directory Federation Services is a feature and web service in the Windows Server Operating System that allows sharing of identity information outside a company’s network.

Scenario: Technical Requirements include:

Prevent user passwords or hashes of passwords from being stored in Azure.

As App1 is public-facing we need an incoming security rule, related to the access of the web servers.

Scenario: You have a public-facing application named App1. App1 is comprised of the following three tiers: a SQL database, a web front end, and a processing middle tier.

Each tier is comprised of five virtual machines. Users access the web front end by using HTTPS only.

The planned change specifies that you must configure a Data Collection Rule (DCR) to collect only system events with Event ID 4648 from VM2 and VM4.

A Data Collection Rule (DCR) in Azure Monitor defines how data is collected from resources, filtered, and sent to destinations like Log Analytics workspaces. To define or query this data within Azure Monitor Logs or Log Analytics, you use Kusto Query Language (KQL).

From the Microsoft Learn: Azure Monitor Logs Documentation:

“Log queries in Azure Monitor are written in Kusto Query Language (KQL), the same query language used by Azure Data Explorer.”

“KQL is optimized for querying large datasets, filtering by event IDs, sources, and event types.”

Other options:

WQL (WMI Query Language) – used for on-prem Windows event querying, not for Azure DCR.

T-SQL (Transact-SQL) – used for Azure SQL Database queries, not for monitoring data.

XPath – used in Event Viewer or XML-based event filtering, not within Azure Monitor DCR configuration.

Therefore, when you configure DCR1 to collect system events (Event ID 4648) from the specified VMs, the Kusto Query Language (KQL) is the correct and verified method to filter and process these events.

Example of a valid KQL expression for this requirement:

SecurityEvent

| where EventID == 4648

| where Computer in ( " VM2 " , " VM4 " )

This aligns with the Azure Monitor and Log Analytics query methodology covered in AZ-104 official exam guide (Implement and manage monitoring).

In Microsoft Azure, encryption scopes are a StorageV2 (general-purpose v2) storage account feature that allows fine-grained control over encryption settings for data stored within a single account. According to Microsoft Azure Storage documentation, an encryption scope defines a specific encryption context that can be applied at the container or blob level and is supported in non-hierarchical namespace storage accounts (those without Data Lake Gen2 enabled).

In the given scenario:

storage1 has Hierarchical namespace = Yes (Data Lake Storage Gen2 enabled).

storage2 has Hierarchical namespace = No.

The plan was to create an encryption scope named Scope1 in storage2.

The technical requirement specifies that Scope1 must be used to encrypt storage services.

According to the Azure Administrator documentation on encryption scopes:

“Encryption scopes are supported for block blobs, append blobs, page blobs, Azure Files, queues, and tables in standard StorageV2 accounts. Encryption scopes are not supported in hierarchical namespace (Data Lake Gen2) enabled accounts.”

This means that Scope1—created in storage2, which does not have hierarchical namespace—can encrypt all blob data (containers and blobs) as well as file shares, queues, and tables.

However, storage1 cannot use encryption scopes because hierarchical namespace storage accounts (ADLS Gen2) manage encryption at the account level and do not support per-scope encryption.

Therefore, only storage2 can apply Scope1, and it can encrypt containers, blobs, file shares, queues, and tables.

To determine which virtual machines can be encrypted, we must refer to the technical requirement:

“Whenever possible, use Azure Disk Encryption and a key encryption key (KEK) to encrypt the virtual machines.”

According to the Microsoft Azure Administrator documentation, Azure Disk Encryption (ADE) uses BitLocker for Windows virtual machines and DM-Crypt for Linux virtual machines to encrypt OS and data disks. However, not all VM types and disk configurations are supported for ADE.

From the provided configuration:

VM

OS

Description

Disk Type

VM1

RHEL

Uses ephemeral OS disks

❌ Not supported

VM2

Windows Server 2022

Has a basic volume

✅ Supported

VM3

RHEL

Uses standard SSDs

✅ Supported by DM-Crypt, but not optimal

VM4

Windows Server 2022

Uses Write Accelerator disks

✅ Supported

VM5

Windows Server 2022

Has a dynamic volume

❌ Not supported by ADE

Step-by-step Analysis (Based on Microsoft Docs):

Ephemeral OS disks (VM1):

These are not compatible with Azure Disk Encryption because they are stored on local temporary storage and are not persisted to Azure Storage.

“Ephemeral OS disks cannot be encrypted using Azure Disk Encryption because they reside on local VM storage.” — [Microsoft Learn: Azure Disk Encryption prerequisites]

Dynamic volumes (VM5):

Azure Disk Encryption does not support dynamic disks — only basic disks are supported.

“Azure Disk Encryption does not support dynamic disks; only basic disks can be encrypted.” — [Microsoft Learn: ADE limitations]

Write Accelerator disks (VM4):

These disks can be encrypted if they are standard OS/data disks with Write Accelerator enabled. Microsoft confirms that ADE supports Write Accelerator–enabled disks on supported VM sizes.

Linux VMs (VM3) with standard SSDs can use DM-Crypt encryption, but in this question, the requirement specifies to use Azure Disk Encryption with a Key Encryption Key (KEK) — KEKs are supported only for Windows and Linux VMs that use managed disks and not ephemeral disks.

However, VM3 uses standard SSDs (supported by ADE) and VM2 and VM4 meet the technical requirement of using ADE with KEK, but Azure prefers Windows VMs for KEK integration because of BitLocker integration and Key Vault support.

Therefore, the verified supported VMs for Azure Disk Encryption with KEK are:

✅ VM2 (Windows Server 2022, basic volume)

✅ VM4 (Windows Server 2022, Write Accelerator disks)

Supporting Microsoft Documentation (Extracted):

“Azure Disk Encryption helps protect and safeguard your data to meet your organizational security and compliance commitments. It uses BitLocker for Windows VMs and DM-Crypt for Linux VMs.”

“ADE is not supported on ephemeral OS disks or dynamic disks.”

“You can use Key Encryption Keys (KEK) from Azure Key Vault for an added layer of security.”

(Source: Microsoft Learn – Azure Disk Encryption Overview, Prerequisites, and Supported Configurations for Windows and Linux VMs)

To meet the technical requirement — “Use TLS for WebApp1” — the web app must be configured with a certificate that is compatible with Azure App Service for HTTPS/TLS binding.

According to the Microsoft Azure Administrator documentation on App Service Certificates and Key Vault integration, the following key points determine which certificates can be used:

Supported Certificate Format:Azure App Service supports importing certificates in PFX (PKCS #12) format, which includes both the public and private keys necessary for TLS/SSL binding.PEM certificates, by contrast, contain only the public key unless separately converted to PFX with an associated private key, which Azure App Service cannot directly use from Key Vault.

Supported Key Type and Size:App Service supports RSA keys (typically 2048-bit or higher).Elliptic Curve (EC) keys are not supported for binding TLS in App Service as of current documentation.

Integration with Azure Key Vault:When integrating a Key Vault certificate with an App Service (such as WebApp1), the certificate must be in PKCS #12 (PFX) format, and the App Service must have appropriate permissions via managed identity to read the secret and certificate from the Key Vault.

From the Vault1 data provided in your scenario:

Name

Content type

Key type

Key size

Cert1

PKCS #12

RSA

2048

Cert2

PKCS #12

RSA

4096

Cert3

PEM

RSA

2048

Cert4

PEM

RSA

4096

Analysis:

Cert1 and Cert2 are PKCS #12 certificates, so both contain the private key required for TLS.

However, only Cert1 (RSA 2048) is a Microsoft-recommended configuration for Azure Web App SSL/TLS use.

Cert2 has a 4096-bit RSA key. Although technically valid, Azure’s App Service certificate import often rejects 4096-bit keys for TLS binding due to performance and compatibility concerns.

Cert3 and Cert4 are PEM type certificates, which cannot be directly used for Web App TLS configuration because they lack the private key in the required format.

Therefore, according to the Azure Administrator Exam Study Guide and Microsoft official documentation, the only valid certificate that meets the requirements is:

✅ Cert1 only

Final Verified Answer: ✅ A. Cert1 only

In the scenario, storage1 is configured as StorageV2 with Hierarchical namespace = Yes, while storage2 is configured as StorageV2 with Hierarchical namespace = No.

From Microsoft’s Azure Storage Documentation and AZ-104 Study Guide, the following principles apply:

A hierarchical namespace (enabled when the storage account has Azure Data Lake Storage Gen2 capabilities) allows the use of directories within containers to organize data.

The hierarchical namespace provides directory and file-level structure similar to a file system. This is supported only for blob containers, not for Azure Files.

Azure Files (file shares) do not depend on hierarchical namespaces and cannot have directories in the same way Data Lake Gen2 does — directories can exist inside the share but not in the blob container sense.

The planned change states that you must use directories whenever possible to organize content. Therefore, only storage accounts with hierarchical namespace enabled can use directory structures — that’s storage1.

In this case:

storage1 (Hierarchical namespace = Yes) → supports containers (like cont1) and file shares (like share1).

storage2 (Hierarchical namespace = No) → does not support directories within blob containers (Data Lake structure).

Hence, you can use only cont1 (container in storage1) and share1 (file share in storage1) to organize content as required.

This is directly supported by the Microsoft documentation on Data Lake Storage Gen2:

“When you enable the hierarchical namespace for a storage account, you can organize objects into directories and subdirectories. This capability is available only for accounts configured for Data Lake Storage Gen2.”

Final Verified Answer: ✅ B. cont1 and share1 only

 Stored access policies: ✅ 2

 Immutable blob storage policies: ✅ 1

From the scenario in the earlier case study (A. Datum Corporation):

The planned change requires creating a new container named cont2 in storage1, with the following:

Three stored access policies (Stored1, Stored2, Stored3)

A legal hold for immutable blob storage

Also, recall from the table:

storage1 has Hierarchical namespace = Yes (Data Lake Storage Gen2 enabled).

storage2 has Hierarchical namespace = No.

The question asks: “What is the maximum number of additional access policies you can create for cont2?”

According to Microsoft Azure Storage documentation:

A blob container can have a maximum of five stored access policies.

These policies allow shared access signatures (SAS) to be managed centrally, letting you define start times, expiry times, and permissions at the container level.

Since three stored access policies (Stored1, Stored2, Stored3) already exist, the maximum additional policies that can still be created is:

→ 5 (maximum allowed) – 3 (already existing) = 2

For immutable blob storage policies:

A container can have one active immutability policy at a time.

This can be either a time-based retention policy or a legal hold policy.

Since cont2 already has a legal hold applied, no additional immutable policy can coexist with it, but it can have one defined policy type (the legal hold).

Therefore:

Stored access policies: 2 additional policies can still be created.

Immutable blob storage policies: 1 policy (the existing legal hold).

This aligns exactly with Microsoft Learn: Azure Storage Blob Service limits and immutable storage documentation:

“A container may have up to five stored access policies. Immutable storage supports either a time-based retention policy or legal hold policy per container.”

Final Verified Answer:

✅ Stored access policies: 2

✅ Immutable blob storage policies: 1

According to the Microsoft Azure Administrator (AZ-104) Study Guide and Azure Role-Based Access Control (RBAC) documentation, permissions to link an Azure Private DNS zone to a virtual network require access to both the virtual network resource and the DNS zone resource.

The process of linking a DNS zone to a virtual network establishes name resolution for the resources within that VNet through the Private DNS zone. To perform this operation, the user must have:

“Microsoft.Network/virtualNetworks/*” permissions (to modify and manage VNet settings).

“Microsoft.Network/privateDnsZones/*” permissions (to manage DNS zone links).

These permissions are granted by two built-in roles:

Network Contributor – Allows full management of the network resources like virtual networks, subnets, and network interfaces but does not allow access to manage DNS zones.

Private DNS Zone Contributor – Allows management of private DNS zones and their link configurations.

Therefore, to grant User1 the ability to link Zone1.com (Private DNS Zone) to VNet1, the correct approach is to assign both roles with the least privilege principle, scoped specifically to the required resources:

Network Contributor on VNet1

Private DNS Zone Contributor on zone1.com

Assigning the permissions at the resource level (and not at the resource group or subscription level) ensures compliance with the principle of least privilege, a core requirement of Azure governance.

This setup enables User1 to perform the exact operation (linking the Private DNS Zone to the VNet) while preventing unnecessary access to unrelated resources.

Final Verified Answer:

✅ Roles: Network Contributor and Private DNS Zone Contributor only

✅ Resources: VNet1 and zone1.com only

Azure Storage Explorer is a free tool from Microsoft that allows you to work with Azure Storage data on Windows, macOS, and Linux. You can use it to upload and download data from Azure blob storage.

Scenario:

Planned Changes include: move the existing product blueprint files to Azure Blob storage.

Technical Requirements include: Copy the blueprint files to Azure over the Internet.

Statement 1: Yes

Contoso is moving the existing product blueprint files to Azure Blob storage which will ensure that the blueprint files are stored in the archive storage tier.

Use unmanaged standard storage for the hard disks of the virtual machines. We use Page Blobs for these.

Statement 2: No

Azure Table storage stores large amounts of structured data. The service is a NoSQL datastore which accepts authenticated calls from inside and outside the Azure cloud. Azure tables are ideal for storing structured, non-relational data. Common uses of Table storage include:

1. Storing TBs of structured data capable of serving web scale applications

2. Storing datasets that don ' t require complex joins, foreign keys, or stored procedures and can be denormalized for fast access

3. Quickly querying data using a clustered index

4. Accessing data using the OData protocol and LINQ queries with WCF Data Service .NET Libraries

Statement 3: No

File Storage can be used if your business use case needs to deal mostly with standard File extensions like *.docx, *.png and *.bak then you should probably go with this storage option.

In Microsoft Azure, containerized application deployment can occur using multiple services, depending on the image type and operating system platform used. The question refers to two images — Image1 (Windows Server) and Image2 (Linux) — which are stored in an Azure Container Registry (ACR).

According to the Microsoft Azure Administrator Study Guide (AZ-104) and official Azure documentation, both Windows-based and Linux-based container images can be deployed using any of the following services, depending on the workload requirements:

Azure App Service (Web App for Containers) – supports both Windows and Linux containers for web applications. It allows developers to directly deploy containerized applications from Docker Hub, Azure Container Registry, or a private registry.

Azure Container Apps – serverless container hosting designed for microservices and event-driven architectures. It supports Linux and Windows containers, using Kubernetes behind the scenes, without requiring users to manage the cluster infrastructure.

Azure Container Instances (ACI) – provides lightweight, serverless containers for quick deployment and isolated workloads. It supports both Windows and Linux images and can pull directly from Azure Container Registry.

Therefore, since both Image1 (Windows Server) and Image2 (Linux) are valid container images supported by the same three Azure container services, the correct and verified solution is to select “App Service, Azure Container Apps, or Azure Container Instances” for both.

This matches Azure documentation under:

“Run containerized applications in Azure App Service”

“Deploy containers using Azure Container Instances”

“Build and deploy microservices using Azure Container Apps”

Each of these Azure services supports containerized deployments from ACR regardless of the underlying operating system image type.

Final Verified Answer:

✅ Image1: App Service, Azure Container Apps, or Azure Container Instances

✅ Image2: App Service, Azure Container Apps, or Azure Container Instances

In this scenario, Contoso Ltd. must designate a new user named Admin1 as the service administrator of the Azure subscription and ensure that Admin1 receives email alerts about service outages.

In Azure, there are three classic administrative roles associated with subscriptions:

Account Administrator – The individual who created the subscription and manages billing.

Service Administrator – The primary contact responsible for managing services and resources in the subscription.

Co-Administrator – Has the same management privileges as the Service Administrator but cannot change subscription associations.

According to Microsoft Azure Administrator documentation, to change the Service Administrator, you must perform the following steps:

In the Azure portal, navigate to Subscriptions.

Select the specific subscription.

Under Settings, choose Properties.

In the Service Administrator field, update the name and email address to that of the new administrator (in this case, Admin1).

This modification ensures that Admin1 becomes the Service Administrator, and Azure will automatically send service-related notifications and outage alerts to that user’s registered email address, as defined by Microsoft’s subscription notification process.

Option B (IAM settings) is used for Role-Based Access Control (RBAC) and assigning Azure Resource Manager roles such as Owner, Contributor, or Reader. However, RBAC roles do not change the Service Administrator at the subscription level — that’s only done through the Properties blade.

Options C (AAD Properties) and D (AAD Groups) are unrelated to subscription-level administrative settings.

Therefore, the verified and Microsoft-documented answer is:

✅ A. From the Subscriptions blade, select the subscription, and then modify the Properties.

Final Verified Answer: ✅ A. From the Subscriptions blade, select the subscription, and then modify the Properties.

A Recovery Services vault is a logical container that stores the backup data for each protected resource, such as Azure VMs. When the backup job for a protected resource runs, it creates a recovery point inside the Recovery Services vault.

Scenario:

There are three application tiers, each with five virtual machines.

Move all the virtual machines for App1 to Azure.

Ensure that all the virtual machines for App1 are protected by backups.

When working with Bicep templates (the declarative language used by Azure Resource Manager), resource deployment behaviors are governed by parameters, variable assignments, and idempotent deployment principles.

Name of the Virtual Network:

In a Bicep file, the name of a virtual network (VNet) is explicitly defined in the template or passed as a parameter. It does not automatically inherit the name or location of the resource group. Therefore, unless explicitly coded that way, the VNet name is not derived from the resource group’s location or name.

Subnet provisioning:

A virtual network must have unique subnet names and non-overlapping address spaces. If a Bicep template contains subnet definitions with conflicting address prefixes or duplicated names, Azure Resource Manager will fail to provision them. Thus, if both subnets have overlapping ranges or identical names, both will not be provisioned successfully.

Re-deployment of File1.bicep:

Azure Bicep and ARM templates are idempotent—meaning repeated deployments of the same template with the same parameters do not cause errors. Instead, existing resources are verified and updated if necessary. Hence, redeploying File1.bicep will not cause an error message unless a conflict or manual deletion occurs.

The Logic App Operator role only grants the ability to read, enable, disable, and run logic apps. It does not grant the ability to create logic apps. To create logic apps, you need to assign the Logic App Contributor role or a higher-level role such as Owner or Contributor. Then, References: [Built-in roles for Azure resources] [Azure Logic Apps permissions and access control]

Azure Virtual Network (VNet) Peering is the Microsoft-recommended solution to enable seamless communication between two virtual networks, either within the same subscription or across different subscriptions, with minimal cost and administrative overhead.

According to the Microsoft Azure Administrator documentation, VNet Peering connects two virtual networks and allows resources in either VNet to communicate with each other using private IP addresses, just as if they were part of the same network. Traffic between peered VNets remains on the Microsoft backbone network, ensuring low latency, high bandwidth, and no data exposure to the public internet.

There are two types of peering supported:

VNet Peering (intra-region): For virtual networks in the same Azure region.

Global VNet Peering: For virtual networks in different Azure regions (for example, East US and West US).

In this scenario, VNet1 (East US, Sub1) and VNet2 (West US, Sub2) are in different regions and different subscriptions. Therefore, Global VNet Peering is the appropriate configuration. Peering can be established across subscriptions, provided that the subscriptions are associated with the same Azure Active Directory tenant or proper permissions exist between tenants.

Unlike VPN gateways or network virtual appliances, VNet peering does not require additional infrastructure or incur data transfer gateway costs, making it the lowest-cost and least administratively complex option.

Once configured, communication between VM1 in VNet1 and VM2 in VNet2 occurs over Microsoft’s private backbone network, without public IPs or tunneling.

In Azure App Service, autoscale rules automatically adjust the number of running instances based on performance metrics such as CPU, memory, or custom metrics. The configuration shown uses the Memory Percentage metric with a threshold of 70%, meaning that if average memory utilization exceeds 70% for 15 minutes, Azure will trigger a scale-out action.

From the exhibit, the rule specifies:

Metric threshold: Greater than 70%

Duration: 15 minutes

Action: Increase count by 1 instance

Cool down: 5 minutes

Maximum instance limit: 5

App1 currently has 2 running instances.

If App1 maintains 80% memory utilization for 30 minutes, the autoscale mechanism will trigger the scale-out action after each qualifying 15-minute window, adding 1 instance every 5-minute cooldown period until the maximum instance limit (5) is reached.

Therefore, the progression would be:

Start: 2 instances

After first 15 minutes: +1 instance → 3 total

After next 5-minute cooldown and continuing high memory → +1 instance → 4 total

After another cycle → +1 instance → 5 total

Since the rule continues to trigger until the maximum (5) is reached, and the memory usage remains above the threshold, the maximum number of instances that App1 will scale to during the 30-minute period is 5.

Azure Recovery Services vaults are used to store backup data and recovery points for supported workloads such as Azure VMs, Azure Files, and on-premises workloads. However, the configuration rules are strictly defined based on region and supported resource type.

From Microsoft Azure Administrator documentation and the official Azure Backup architecture, the following principles apply:

Backup Region Dependency – A Recovery Services vault can only back up resources located in the same Azure region. For example, a vault in Central US can only back up Azure VMs, storage accounts, or workloads in Central US. It cannot back up resources in West US or East US.

Vault1 (Central US, RG1)

Located in Central US and can therefore back up only resources in Central US.

From the table: VM1 is in Central US, and is eligible.

storage1 (West US) and SQL1 (East US) cannot be backed up to Vault1 due to cross-region restrictions.

✅ Therefore, Vault1 can back up VM1 only.

Vault2 (West US, RG2)

Located in West US, and can only back up resources in West US.

In West US, the only relevant resource is storage1, which contains a file share named share1. Azure Backup supports Azure File share backup via Recovery Services vaults.

Vault2 cannot back up VM1 (Central US) or SQL1 (East US) since they reside in different regions.

✅ Therefore, Vault2 can back up share1 only.

Azure Backup Limitations Summary (From Microsoft Docs):

Azure VMs → must be backed up to a vault in the same region.

Azure File Shares → can be backed up using Recovery Services vaults in the same region as the storage account.

Azure SQL Database → uses its own automated backup mechanism, not Recovery Services vaults.

Hence, by Azure documentation compliance and AZ-104 study guide principles:

Vault1 backs up VM1 only.

Vault2 backs up share1 only.

Final Verified Answer:

✅ Vault1 – VM1 only

✅ Vault2 – share1 only

In Azure, DNS resolution order follows a specific hierarchy based on custom DNS configurations at the virtual network (VNet) and network interface (NIC) levels.

According to Microsoft Azure Administrator documentation, when you specify custom DNS servers for a virtual network, those DNS servers become the default for all virtual machines connected to that VNet — unless a specific VM’s network interface has its own DNS settings configured. In that case, the NIC-level configuration overrides the VNet-level configuration.

Here’s how it applies to this scenario:

VNET1 has been configured with a custom DNS server of 193.77.134.10 (visible in the VNet’s DNS configuration screenshot).

VM1 does not have a custom DNS server specified on its NIC, so it inherits the VNet-level DNS server (193.77.134.10).

VM2 and VM3 both have explicit custom DNS settings pointing to 192.168.10.15 at the NIC level. Since NIC-level settings take precedence over the VNet’s configuration, these VMs will use 192.168.10.15 for all DNS queries.

This hierarchy is described in Azure documentation under:

“DNS name resolution for virtual machines in Azure virtual networks,” which explains that NIC-specific settings override VNet settings, and if no custom DNS is defined at either level, Azure’s default internal DNS (168.63.129.16) is used.

In summary:

VM1 inherits DNS = 193.77.134.10 (Yes)

VM2 uses custom DNS = 192.168.10.15 (No for 193.77.134.10)

VM3 uses custom DNS = 192.168.10.15 (Yes)

Thus, the correct and Microsoft-verified answers are:

✅ VM1: Yes, VM2: No, VM3: Yes

 Storage accounts: ✅ storage3 only

 Log Analytics workspaces: ✅ Analytics3 only

In Azure, Backup Reports use Azure Monitor diagnostic settings to export data from a Recovery Services vault (RSV) to either:

A storage account, or

A Log Analytics workspace.

However, region alignment is a mandatory requirement for both targets. The diagnostic destination (Storage or Log Analytics) must be in the same Azure region as the Recovery Services vault.

1️⃣ Recovery Services Vault Location:

From the given table:

Vault1 → Location: West Europe

Therefore, both the storage account and Log Analytics workspace must also be in West Europe.

2️⃣ Eligible Storage Accounts:

From the listed resources:

storage1: East US → ❌ (Different region)

storage2: West US → ❌ (Different region)

storage3: West Europe → ✅ (Same region as Vault1)

➡️ Valid Storage Account: storage3 only

3️⃣ Eligible Log Analytics Workspaces:

From the listed resources:

Analytics1: East US → ❌ (Different region)

Analytics2: West US → ❌ (Different region)

Analytics3: West Europe → ✅ (Same region as Vault1)

➡️ Valid Log Analytics Workspace: Analytics3 only

4️⃣ Microsoft Official Documentation Extract (Azure Administrator Study Guide – Implement and Manage Storage, and Azure Docs):

“For Backup Reports, the destination Log Analytics workspace or storage account must be in the same Azure region as the Recovery Services vault.

Cross-region configuration is not supported for diagnostic settings of Azure Backup vaults.”

(Reference: Azure Backup documentation – Configure reports for Azure Backup; Azure Monitor Diagnostic Settings Overview)

This ensures that diagnostic data generated by the vault is securely and efficiently stored within the same geographic boundary, maintaining compliance and reducing latency.

Yes, Yes, No

The deployment stack uses -DenySettingsMode DenyDelete, which protects managed resources from deletion but does not block normal write operations. Microsoft’s deployment stack documentation defines DenySettingsMode values as None, DenyDelete, and DenyWriteAndDelete; only DenyWriteAndDelete blocks updates. Therefore, Admin1 can modify the IP address space of VNet2 because Admin1 has Network Contributor at the subscription scope and the deny mode does not block write operations.

Admin2 has Contributor at RG2, which normally grants full management access to resources in RG2, except access management. Subnet2 is a child resource of VNet2. The command does not include DenySettingsApplyToChildScopes; Microsoft states that this parameter must be specified for deny settings to apply to child scopes of managed resources. Therefore, Admin2 can delete Subnet2.

Admin3 has Owner at the VNet2 scope, but the deny assignment applies to All principals , has no excluded principals, and is scoped to VNet2. Deny assignments block access even when a role assignment grants it, so Admin3 cannot delete VNet2. Study Guide reference: AZ-104 Manage Azure identities and governance , Azure RBAC, deny assignments, and governance controls.

When deploying to Azure App Service, several authentication methods exist:

App-level FTPS credentials: Common to all users, not tied to Azure AD.

User-level FTPS credentials: Separate per user, but still not Azure AD integrated.

Azure Role-Based Access Control (RBAC): Allows assigning permissions through Azure AD roles.

To allow developers to deploy code to an App Service (via Web Deploy, Git, or Visual Studio), the least privilege role that grants this capability is the Website Contributor role.

Role capabilities:

The Website Contributor role allows a user to manage web apps (including deployment, restart, and configuration changes), but not delete or grant access.

It uses Azure AD authentication through RBAC, satisfying the requirement that developers use their Azure AD credentials.

Other options:

Owner: Grants excessive permissions (manage access and delete resources) ❌

App-level/User-level FTPS credentials: Use username/password, not Azure AD identities ❌

Therefore, the correct and least-privileged role for developers to deploy via Web Deploy is Website Contributor.

✅ Final Verified Answer: B. Assign the Website Contributor role to the developers

In Azure, a storage account access key provides full access to all data within the account. To reduce risk and follow security best practices, these keys should be rotated (regenerated) periodically.

According to the Microsoft Azure Storage and Security documentation, Azure Key Vault can be used to automate access key rotation for storage accounts.

Azure Key Vault allows you to:

Store and manage secrets, keys, and certificates securely.

Integrate directly with Azure Storage to manage account keys and Shared Access Signatures (SAS).

Enable automated key rotation when using Azure Key Vault managed storage account keys.

Here’s how it works:

In Azure Key Vault, add the storage account (storage1) as a managed storage account.

Key Vault periodically regenerates (rotates) the storage access keys automatically.

Applications can retrieve updated keys via Key Vault APIs or managed identities without manual key updates.

This process ensures consistent security and reduces the administrative effort required for key rotation.

Other options such as backup vaults, redundancy, or lifecycle management do not handle access key rotation—they serve data protection or retention purposes, not key management.

✅ Final Verified Answer: D. an Azure key vault

The Contributor role grants the ability to create and manage all types of Azure resources, including logic apps. Assigning this role to the Developers group on the Dev resource group will allow them to create logic apps in that scope. Then, References: [Built-in roles for Azure resources] [Azure Logic Apps permissions and access control]

The minimum number of available virtual machines during planned datacenter maintenance is 12 . In an Azure availability set, update domains are used for planned maintenance events. Microsoft states that only one update domain is restarted at a time during planned maintenance, and the restarted update domain has time to recover before maintenance proceeds to another update domain.

AS1 has 5 update domains and contains 16 virtual machines . Azure distributes VMs across update domains as evenly as possible. With 16 VMs across 5 update domains, the largest update domain can contain 4 VMs because 16 ÷ 5 results in a distribution such as 4, 3, 3, 3, and 3. During planned maintenance, the update domain with the highest number of VMs could be unavailable. Therefore, the minimum available VMs are:

16 total VMs - 4 VMs in one update domain = 12 available VMs

Fault domains protect against unplanned hardware failures, such as rack or power failures, and do not determine the number of VMs unavailable during planned maintenance. This aligns with AZ-104 Deploy and manage Azure compute resources , specifically VM availability sets, update domains, and fault domains.

Azure role-based access control (Azure RBAC) for Azure file shares requires identity-based authentication integration. According to the Microsoft Azure Administrator documentation, this feature is only supported for StorageV2 (general purpose v2) and FileStorage account types.

In this scenario:

You are required to grant Group4 read-only access using Azure RBAC on Azure file shares.

The technical requirement specifies:

“Whenever possible, grant Group4 Azure RBAC read-only permissions to the Azure file shares.”

From the case study data:

Storage Account

Kind

Identity-based Access

storage1

Storage (general purpose v1)

Azure AD DS

storage2

StorageV2

Disabled

storage3

BlobStorage

N/A

storage4

FileStorage

Azure AD DS

The Storage (general purpose v1) type (storage1) does not support Azure AD or Azure RBAC integration for file shares. Microsoft documentation clearly states that “StorageV1 accounts must be upgraded to StorageV2 to support Azure AD authentication and RBAC role assignments.”

Meanwhile, FileStorage (storage4) already supports Azure AD Domain Services (Azure AD DS) and RBAC role assignment; hence no further modification is required there. However, to make storage1 compatible, it must be converted from StorageV1 to StorageV2.

Once converted to StorageV2, you can then:

Enable identity-based access for Azure file shares.

Assign Azure RBAC roles (e.g., Storage File Data Reader) to Group4.

Microsoft-Documented Requirements Summary:

Supported Account Types: StorageV2 or FileStorage

Unsupported: StorageV1 and BlobStorage

Required RBAC Roles for Read-Only Access:

Storage File Data Reader (or custom read-only role)

Thus, to meet the organization’s requirement to provide Azure RBAC read-only permissions, you must change the account type of storage1 to StorageV2, ensuring both storage1 and storage4 can be managed with Azure RBAC.

✅ Yes, Yes, No

1️⃣ Create a Log Analytics workspace.

2️⃣ Collect Windows performance counters from the Log Analytics agents.

3️⃣ Create an alert rule.

The question states:

“You need to configure the alerts for VM1 and VM2 to meet the technical requirements.”

The technical requirement from the case study specifies:

“Trigger an alert if VM1 or VM2 has less than 20 GB of free space on volume C.”

This requirement involves monitoring performance metrics (disk space) and generating alerts based on those metrics. According to Microsoft Azure monitoring and management documentation, the process to configure such alerts involves using Azure Monitor and Log Analytics.

Step-by-Step Verified Solution:

Step 1: Create a Log Analytics workspace

A Log Analytics workspace is required to store and analyze logs and performance data collected from virtual machines.

Azure Monitor uses this workspace as the central repository for performance counters, events, and logs from connected agents.

From the Microsoft Documentation:

“Before you can collect and query data from virtual machines, you must create a Log Analytics workspace in your subscription.”

(Source: Azure Monitor and Log Analytics Guide)

Step 2: Collect Windows performance counters from the Log Analytics agents

After creating the workspace, you must connect VM1 and VM2 to the workspace and configure the Windows performance counters that you want to monitor.

In this case, you would collect the LogicalDisk(%) Free Space counter for C: drive.

Azure Monitor agent or Log Analytics agent collects these metrics and sends them to the workspace for analysis.

“To monitor system performance, configure the agent to collect performance counters such as available memory or free disk space.”

(Source: Azure Monitor Performance Counters Documentation)

Step 3: Create an alert rule

Once performance data is being collected, you can create an alert rule in Azure Monitor based on a Kusto query or metric threshold.

You would define a condition such as:

LogicalDisk | where FreeSpaceMB < 20480

and configure it to trigger an alert when free space on volume C drops below 20 GB.

This alert can notify via email, action group, or automation runbook.

“Alerts in Azure Monitor proactively notify you when important conditions are found in your monitoring data. Alerts can trigger automated actions or notifications.”

(Source: Azure Monitor Alerts Overview)

Incorrect Options (Eliminated):

Configure the Diagnostic settings:

Used for collecting activity logs or resource logs, not performance counters from VMs.

Create an Azure SQL database:

Not relevant to the scenario of monitoring disk space.

The question asks which storage account type should be created for storage5 and which existing storage account should be configured as the destination for replication — while supporting the planned changes.

Step 1: Planned Change Requirement

From the case study:

“Create a storage account named storage5 and configure storage replication for the Blob service.”

This indicates that storage5 will act as a secondary (destination) account to receive geo-replicated blobs (as part of RA-GRS or GRS replication configuration).

Therefore, the new storage5 must support Blob service replication features.

Step 2: Determining Correct Account Type

According to Microsoft Azure Administrator Documentation (Microsoft Learn: “Types of storage accounts”):

Account Type

Blob Support

File Share Support

Recommended Use

Storage (general purpose v1)

✅ Basic blob

Limited

Legacy use, lacks advanced features

StorageV2 (general purpose v2)

✅ Full blob, file, queue, table support

✅

Supports replication (GRS, RA-GRS, ZRS) and access tiers

BlobStorage

✅ Blob only

❌ No file shares

Used only for block and append blobs

BlockBlobStorage

✅ Blob only (premium tier)

❌ No file shares

High-performance workloads only

Therefore, the correct type for storage5 must be StorageV2, as it supports both:

Blob service replication (GRS, RA-GRS, ZRS, LRS)

All tiers (Hot, Cool, Archive)

This meets the planned change and ensures the account supports replication for Blob service.

Step 3: Determining the Correct Destination Storage Account

The question also requires identifying which existing storage account should act as the destination for replication configuration.

In Azure, Blob service replication (for example, geo-redundant replication or object replication) requires:

Both storage accounts to be StorageV2.

Both to be in the same region pair and have object replication enabled.

Looking at the table:

Storage Account

Kind

Location

File Share

Identity-based Access

storage1

Storage (general purpose v1)

West US

sharea

Azure AD DS

storage2

StorageV2 (general purpose v2)

East US

shareb, sharec

Disabled

storage3

BlobStorage

East US 2

N/A

N/A

storage4

FileStorage

Central US

shared

Azure AD DS

Only storage2 meets all of the following conditions:

✅ Type: StorageV2

✅ Region: East US (a valid replication pair for East US 2 or secondary region)

✅ Blob Service supported

Hence, storage2 is the correct destination storage account to configure for replication from storage5.

Step 4: Supporting Microsoft Azure Documentation Extracts

From Microsoft Learn – Azure Storage account overview:

“General-purpose v2 accounts support all Azure Storage features, including blob, file, queue, and table storage. They are recommended for most scenarios.”

“Object replication requires both source and destination accounts to be of the same type (StorageV2) and in regions that are geo-paired.”

“Blob and StorageV2 accounts support replication options such as LRS, ZRS, GRS, and RA-GRS.”

Every Azure AD directory comes with an initial domain name in the form of domainname.onmicrosoft.com.

The initial domain name cannot be changed or deleted, but you can add your corporate domain name to Azure AD as well. For example, your organization probably has other domain names used to do business and users who sign in using your corporate domain name. Adding custom domain names to Azure AD allows you to assign user names in the directory that are familiar to your users, such as ‘alice@contoso.com.’ instead of ' alice@domain name.onmicrosoft.com ' .

Scenario:

Network Infrastructure: Each office has a local data center that contains all the servers for that office. Each office has a dedicated connection to the Internet.

Humongous Insurance has a single-domain Active Directory forest named humongousinsurance.com

Planned Azure AD Infrastructure: The on-premises Active Directory domain will be synchronized to Azure AD.

To meet the technical requirement that User1 can create initiative definitions and User4 can assign initiatives to RG2, we must understand how Azure Policy roles operate according to Microsoft Azure documentation and AZ-104 study guides.

Azure Policy uses role-based access control (RBAC) to determine who can create, manage, and assign policies or initiatives (policy sets). The key roles relevant to this task are:

Resource Policy Contributor – Allows users to create, edit, and delete policy definitions and initiative definitions, but does not allow assignment of policies or initiatives. This role is required for users who will design or build the policy logic (definitions).

Therefore, User1, who needs to create initiative definitions, must have the Resource Policy Contributor role.

Scope: Subscription (Sub1) – because initiatives are created at subscription or management group level.

Contributor – Provides full access to manage resources, except granting permissions. Contributors can assign existing policies or initiatives to resource groups or subscriptions if they have sufficient permissions.

Therefore, User4, who needs to assign initiatives to RG2, must be assigned the Contributor role at the RG2 scope.

Other roles:

Security Admin is related to Microsoft Defender for Cloud security settings, not policy creation.

Resource Policy Contributor for RG2 would not meet the requirement because creating definitions typically requires subscription-level access.

According to Microsoft Docs (“Azure built-in roles for Policy”):

“The Resource Policy Contributor role allows users to create, edit, and delete Azure policy and initiative definitions. To assign policies or initiatives, users need the Contributor or Owner role at the appropriate scope.”

Hence, the configuration should be:

User1: Resource Policy Contributor for Sub1

User4: Contributor for RG2

Once the VNets are peered, all resources on one VNet can communicate with resources on the other peered VNets. You plan to enable peering between Paris-VNet and AllOffices-VNet. Therefore VMs on Subnet1, which is on Paris-VNet and VMs on Subnet3, which is on AllOffices-VNet will be able to connect to each other.

All Azure resources connected to a VNet have outbound connectivity to the Internet by default. Therefore VMs on ClientSubnet, which is on ClientResources-VNet will have access to the Internet; and VMs on Subnet3 and Subnet4, which are on AllOffices-VNet will have access to the Internet.

IdFix is used to perform discovery and remediation of identity objects and their attributes in an on-premises Active Directory environment in preparation for migration to Azure Active Directory. IdFix is intended for the Active Directory administrators responsible for directory synchronization with Azure Active Directory.

Scenario: Active Directory Issue

Several users in humongousinsurance.com have UPNs that contain special characters.

You suspect that some of the characters are unsupported in Azure AD.

Cost analysis: Correct Option

In cost analysis blade of Azure, you can see all the detail for custom time span. You can use this to determine expenditure of last few day, weeks, and month. Below options are available in Cost analysis blade for filtering information by time span:  last 7 days, last 30 days, and custom date range. Choosing the first option (last 7 days) auditors can view the costs by time span.

Cost analysis shows data for the current month by default. Use the date selector to switch to common date ranges quickly. Examples include the last seven days, the last month, the current year, or a custom date range. Pay-as-you-go subscriptions also include date ranges based on your billing period, which isn ' t bound to the calendar month, like the current billing period or last invoice. Use the  < PREVIOUS and NEXT >  links at the top of the menu to jump to the previous or next period, respectively. For example,  < PREVIOUS will switch from the Last 7 days to 8-14 days ago or 15-21 days ago.

Invoice: Incorrect Option

Invoices can only be used for past billing periods not for current billing period, i.e. if your requirement is to know the last week ' s cost then that also not filled by invoices because Azure  generates invoice at the end of the month. Even though Invoices have custom timespan, but when you put in dates for a week, the pane would be empty. Below is from Microsoft document:

Resource Provider: Incorrect Option

When deploying resources, you frequently need to retrieve information about the resource providers and types. For example, if you want to store keys and secrets, you work with the Microsoft.KeyVault resource provider. This resource provider offers a resource type called vaults for creating the key vault. This is not useful for reviewing all Azure costs from the past week which is required for audit.

Payment method: Incorrect Option

Payment methods is not useful for reviewing all Azure costs from the past week which is required for audit.

B: You can gradually roll out Seamless SSO to your users. You start by adding the following Azure AD URL to all or selected users ' Intranet zone settings by using Group Policy in Active Directory: https://autologon.microsoftazuread-sso.com

E: Seamless SSO works with any method of cloud authentication - Password Hash Synchronization or Pass-through Authentication, and can be enabled via Azure AD Connect.

Every Azure AD directory comes with an initial domain name in the form of domainname.onmicrosoft.com. The initial domain name cannot be changed or deleted, but you can add your corporate domain name to Azure AD as well. For example, your organization probably has other domain names used to do business and users who sign in using your corporate domain name. Adding custom domain names to Azure AD allows you to assign user names in the directory that are familiar to your users, such as ‘alice@contoso.com.’ instead of ' alice@domain name.onmicrosoft.com ' .

Scenario:

Network Infrastructure: Each office has a local data center that contains all the servers for that office. Each office has a dedicated connection to the Internet.

Humongous Insurance has a single-domain Active Directory forest named humongousinsurance.com

Planned Azure AD Infrastructure: The on-premises Active Directory domain will be synchronized to Azure AD.

D: Seamless SSO works with any method of cloud authentication - Password Hash Synchronization or Pass-through Authentication, and can be enabled via Azure AD Connect.

B: You can gradually roll out Seamless SSO to your users. You start by adding the following Azure AD URL to all or selected users ' Intranet zone settings by using Group Policy in Active Directory: https://autologon.microsoftazuread-sso.com

Explanation

Scenario:

1. Web administrators will deploy Azure web apps for the marketing department.

2. Each web app will be added to a separate resource group.

3. The initial configuration of the web apps will be identical.

4. The web administrators have permission to deploy web apps to resource groups.

Steps:

1 -- > Create a resource group, and then deploy a web app to the resource group.

2 -- > From the Automation script blade of the resource group , click Add to Library.

3 -- > From the Templates service, select the template, and then share the template to the web administrators .

Scenario: Licensing Issue

1. You attempt to assign a license in Azure to several users and receive the following error message: " Licenses not assigned. License agreement failed for one user. "

2. You verify that the Azure subscription has the available licenses.

Solution:

License cannot be assigned to a user without a usage location specified.

Some Microsoft services aren ' t available in all locations because of local laws and regulations. Before you can assign a license to a user, you must specify the Usage location property for the user. You can specify the location under the User  >  Profile  >  Settings section in the Azure portal.

Statement 1: Yes

All client computers in the Paris office will be joined to an Azure AD domain.

A virtual network named Paris-VNet that will contain two subnets named Subnet1 and Subnet2.

Microsoft Windows Server Active Directory domains, can resolve DNS names between virtual networks. Automatic registration of virtual machines from a virtual network that ' s linked to a private zone with auto-registration enabled. Forward DNS resolution is supported across virtual networks that are linked to the private zone.

Statement 2: Yes

A virtual network named ClientResources-VNet that will contain one subnet named ClientSubnet You plan to create a private DNS zone named humongousinsurance.local and set the registration network to the ClientResources-VNet virtual network.

As this is a registration network so this will work.

Statement 3: No

Only VMs in the registration network, here the ClientResources-VNet, will be able to register hostname records. Since Subnet4 not connected to Client Resources Network thus not able to register its hostname with humongoinsurance.local

https://docs.microsoft.com/en-us/azure/role-based-access-control/tutorial-custom-role-powershell

Get-AzRoleDefinition -Name " Reader " | ConvertTo-Json

https://docs.microsoft.com/en-us/powershell/module/az.resources/get-azroledefinition?view=azps-5.9.0

https://docs.microsoft.com/en-us/azure/role-based-access-control/tutorial-custom-role-powershell

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/convertto-json?view=powershell-7.1

https://docs.microsoft.com/en-us/powershell/module/azuread/get-azureaddirectoryrole?view=azureadps-2.0

Technically, The finance department needs to migrate their users from AD to AAD using AADC based on the finance OU, and need to enforce MFA use. This is conditional access policy. Employees also often get promotions and/or join other departments and when that occurs, the user ' s OU attribute will change when the admin puts the user in a new OU, and the dynamic group conditional access exception (OU= [Department Name Value]) will move the user to the appropriate dynamic group on next AADC delta sync.

https://docs.microsoft.com/en-us/azure/active-directory/enterprise-users/groups-dynamic-membership

https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates

Box 1: Create a virtual network gateway and a local network gateway.

Azure VPN gateway. The VPN gateway service enables you to connect the VNet to the on-premises network through a VPN appliance. For more information, see Connect an on-premises network to a Microsoft Azure virtual network. The VPN gateway includes the following elements:

Virtual network gateway. A resource that provides a virtual VPN appliance for the VNet. It is responsible for routing traffic from the on-premises network to the VNet.

Local network gateway. An abstraction of the on-premises VPN appliance. Network traffic from the cloud application to the on-premises network is routed through this gateway.

Connection. The connection has properties that specify the connection type (IPSec) and the key shared with the on-premises VPN appliance to encrypt traffic.

Gateway subnet. The virtual network gateway is held in its own subnet, which is subject to various requirements, described in the Recommendations section below.

Box 2: Configure a site-to-site VPN connection

On premises create a site-to-site connection for the virtual network gateway and the local network gateway.

Scenario: Connect the New York office to VNet1 over the Internet by using an encrypted connection.

Box 1: Create a Recovery Services vault

Create a Recovery Services vault on the Azure Portal.

Box 2: Install the Azure Site Recovery Provider

Azure Site Recovery can be used to manage migration of on-premises machines to Azure.

Scenario: Migrate the virtual machines hosted on Server1 and Server2 to Azure.

Server2 has the Hyper-V host role.

Scenario: Litware must meet technical requirements including:

Ensure that VM3 can establish outbound connections over TCP port 8080 to the applications servers in the Montreal office.

IP flow verify checks if a packet is allowed or denied to or from a virtual machine. The information consists of direction, protocol, local IP, remote IP, local port, and remote port. If the packet is denied by a security group, the name of the rule that denied the packet is returned. While any source or destination IP can be chosen, IP flow verify helps administrators quickly diagnose connectivity issues from or to the internet and from or to the on-premises environment.

Scenario: Create a workflow to send an email message when the settings of VM4 are modified.

You can start an automated logic app workflow when specific events happen in Azure resources or third-party resources. These resources can publish those events to an Azure event grid. In turn, the event grid pushes those events to subscribers that have queues, webhooks, or event hubs as endpoints. As a subscriber, your logic app can wait for those events from the event grid before running automated workflows to perform tasks - without you writing any code.

To enable communication between virtual machines (VMs) located in different virtual networks (VNets) in Azure, the most efficient and recommended approach—according to Microsoft Azure Administrator documentation—is to use VNet peering.

1. Background and Scenario Analysis

From the case study:

VM1 and VM4 are located in different VNets (VNET1 and VNET3).

The requirement is to ensure that VM1 can communicate with VM4.

The solution must minimize administrative effort and cost.

2. Microsoft Documentation Insight: VNet Peering

According to Microsoft Learn: “Virtual network peering”:

“Virtual network peering seamlessly connects two Azure virtual networks. The virtual networks appear as one for connectivity purposes. Traffic between peered virtual networks uses private IP addresses, as if they were part of the same network, and the traffic stays entirely on the Microsoft backbone network.”

Key characteristics of VNet peering:

Enables private IP connectivity between resources across peered VNets.

No need to deploy or maintain gateways (unlike VPN gateways).

Provides low latency and high bandwidth.

Supports transitive routing through additional configurations.

Minimal administrative overhead — peering can be created with just a few clicks or PowerShell/CLI commands.

3. Why the Other Options Are Incorrect

A. Create a user-defined route (UDR) from VNET1 to VNET3.

❌ A UDR alone cannot enable connectivity between VNets unless a gateway or peering already exists. Without a connection path, a route has no effect.

B. Assign VM4 an IP address of 10.0.1.5/24.

❌ This would attempt to place VM4 in the same subnet as VM1, but cross-VNet subnet IP assignment is not possible in Azure. Each VNet has its own isolated address space.

D. Create an NSG and associate it with VM1 and VM4.

❌ Network Security Groups control traffic filtering within or between existing network connections. They do not create connectivity between isolated VNets.

4. Why Peering Is the Correct and Simplest Solution

Establishing VNet peering between VNET1 and VNET3 will:

Instantly enable bidirectional private IP communication between VM1 and VM4.

Minimize administrative effort (no gateways, routing tables, or IP reconfiguration).

Maintain security and performance through Microsoft’s internal backbone.

Avoid additional costs compared to deploying VPN gateways.

5. Implementation Summary

Steps to configure:

In the Azure Portal, go to VNET1 → Peerings → Add.

Choose VNET3 as the peer virtual network.

Enable Allow virtual network access in both directions.

Once completed, both VMs (VM1 and VM4) will communicate using their private IPs.

Final Verified Answer: ✅ C. Establish peering between VNET1 and VNET3

References (Microsoft Official Documentation):

Microsoft Learn — Virtual network peering overview

Microsoft Learn — Create, change, or delete a virtual network peering

Microsoft Learn — Azure virtual network connectivity options and recommendations