Free AZ-104 Practice Test Questions and Answers (2026)

Remove peering between VNet1 and VNet2: Historically, Azure prevented address space modifications on peered networks, requiring the peering to be removed first. While newer updates allow address space changes while peered, the remote network (VNet2) will not recognize the new routes until the peering is updated. Since the "Sync" action is not an available option in this list, you must perform the manual equivalent: removing the peering connection.

Add the 10.33.0.0/16 address space to VNet1: Once the peering constraint is removed (or as the primary configuration step), you add the new CIDR block to the virtual network's address space.

Recreate peering between VNet1 and VNet2: Finally, you must establish the peering link again. When the peering is recreated, VNet2 will automatically detect the updated address space of VNet1 (including the new 10.33.0.0/16 range) and configure the necessary routing tables to allow communication between hosts.

A. Disassociating the NSG removes all its rules, permitting not blocking Internet access.

B. Inbound rules govern traffic entering the VM; they do not control outbound traffic to

websites.

D. The outbound deny rule already blocks port 80; no modification is required its scope

must simply include both VMs.

Microsoft Learn - Create, change, or delete a virtual network peering: "If you add an address range to a virtual network that is peered with another virtual network, you must sync the peering on the remote virtual network... If the peering status is Connected, you can't edit the peering settings [without syncing or recreating]."

Source: learn.microsoft.com/en-us/azure/virtual-network/virtual-network-manage-peering#resize-virtual-network-address-space

Microsoft Learn - Virtual network peering overview: Explains that address space changes require a peering update (Sync) or recreation to take effect.

Source: learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview

A storage account can be live-migrated to zone-redundant storage only when it is

1. a General-purpose v2 account,

2. configured for Standard performance,

3. currently replicated as GRS or RA-GRS, and

4. located in a region that already offers ZRS.

Among the listed accounts, only storage2 meets every requirement (GPv2, Standard, GRS,

in a ZRS-supported region), so it is the sole candidate for Microsoft-supported live migration

to ZRS.

A. storage1 Uses LRS; migration is supported only from GRS/RA-GRS.

C. storage3 Blob Storage account type; live migration feature supports only GPv2.

D. storage4 GPv1 (not v2) or premium performance (unsupported for live migration).

1. Microsoft Docs Migrate to ZRS or GZRS by requesting a live migration

https://learn.microsoft.com/azure/storage/common/redundancy-migration#prerequisites

(GPv2, Standard, GRS/RA-GRS, ZRS region).

2. Microsoft Docs Change how your storage account is replicated

https://learn.microsoft.com/azure/storage/common/storage-accountmove?tabs=portal#limitations (unsupported for LRS, Blob, Premium, GPv1).

The provided ARM template uses the schema

https://schema.management.azure.com/schemas/2018-0501/subscriptionDeploymentTemplate.json#. This schema indicates that the template is

designed for a subscription-level deployment. Subscription-level deployments are used to

create resources directly within a subscription, such as resource groups, or to deploy

resources across multiple resource groups. The template first defines a resource of type

Microsoft.Resources/resourceGroups to create a new resource group, and then uses a

nested deployment (Microsoft.Resources/deployments) to deploy an Azure Storage account

into that newly created resource group. The New-AzDeployment cmdlet is used to deploy

ARM templates at the subscription scope.

A. New-AzResource: This cmdlet is used to create or update an individual Azure resource,

not to deploy an ARM template that defines multiple resources or control structures.

B. New-AzResourceGroupDeployment: This cmdlet is used to deploy an ARM template to a

pre-existing or specified resource group. Since this template creates the resource group

itself, the deployment must occur at the subscription level.

C. New-AzTenantDeployment: This cmdlet is used for deploying ARM templates at the

tenant scope, which is for resources like management groups or Azure Active Directory

policies, not for creating resource groups and storage accounts in this manner.

Microsoft Learn: "Deploy resources with ARM templates and Azure PowerShell" - This page

describes different deployment cmdlets. New-AzDeployment is used for subscription,

management group, and tenant level deployments. New-AzResourceGroupDeployment is

for resource group deployments.

URL: https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/deploypowershell

Microsoft Learn: "Subscription deployments with ARM templates" - This page explicitly

states to use New-AzDeployment for subscription-level templates.

URL: https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/deploy-tosubscription

Microsoft PowerShell Documentation: New-AzDeployment

URL: https://learn.microsoft.com/en-us/powershell/module/az.resources/new-azdeployment

(States: "The New-AzDeployment cmdlet adds a deployment at the current subscription

scope.")

Microsoft PowerShell Documentation: New-AzResourceGroupDeployment

URL: https://learn.microsoft.com/en-us/powershell/module/az.resources/newazresourcegroupdeployment (States: "Deploys resources to a resource group.")

To automatically scale an Azure App Service plan based on a performance metric like CPU

usage, you must configure autoscale rules. This is achieved within the "Scale out (App

Service plan)" settings by selecting the custom autoscale option, which allows you to define

rules. A rule can be set to trigger a scale-out action (adding more instances) when the CPU

percentage exceeds a specified threshold, such as 80%. This ensures the application has

more resources to handle the increased load automatically.

A. Automatic in the Scale out method settings: While the goal is automatic scaling, the

specific configuration method in Azure for metric-based scaling is defined by rules. "Rules

Based" is the more precise term for this mechanism.

C. Premium P1 in the Scale up (App Service plan) settings: This is a "scale up" operation,

which changes the size and capabilities (CPU, memory) of the instances, not the number of

instances. It does not provide automatic scaling based on load.

D. Standard S1 in the Scale up (App Service plan) settings: This is a "scale up" setting. The

plan is already Standard, and this action does not configure automatic scaling based on

performance metrics.

E. Manual in the Scale out method settings: This requires an administrator to manually

change the instance count and is the opposite of the "automatic" scaling requirement.

Microsoft Azure Documentation: "Get started with autoscale in Azure". This document

explains that custom autoscale operates based on rules that you define. It states, "You can

configure autoscale rules that are based on metrics... For example, you can increase the

number of instances when CPU usage is above 80%."

URL: https://learn.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-get-started

Microsoft Azure Documentation: "Scale instance count manually or automatically". This

guide details the process for App Services, showing that to scale based on a metric, you

must select "Custom autoscale" and "Add a rule".

URL: https://learn.microsoft.com/en-us/azure/app-service/manage-scale-up#scale-instancecount-manually-or-automatically

An Azure alert rule is created for a specific signal on a defined scope. Since there are four

distinct signals to be monitored (Ingress, Egress, Delete storage account, Restore blob

ranges), a minimum of four separate alert rules are required.

An action group is a reusable collection of notification p

and actions. To

determine the minimum number of action groups, we identify the unique sets of users to be

notified:

1. User1 and User3

2. User1 only

3. User1, User2, and User3

These three distinct notification requirements necessitate a minimum of three action

groups. The action group configured to notify User1 and User3 can be reused for both the

"Ingress" and "Restore blob ranges" alert rules.

References:

1. Microsoft Learn, Alert rules in Azure Monitor: This document states, "An alert rule

monitors your telemetry and captures a signal... The rule combines the resources to

be monitored, the signal or telemetry from the resource, and conditions." This

confirms that each unique signal requires its own rule.

o URL: https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alertsoverview#alert-rules

2. Microsoft Learn, Action groups: This documentation explains, "An action group is

a collection of notification preferences... You can use an action group with more than

one alert rule; this allows you to use the same notification methods whenever those

alerts are triggered." This supports the principle of creating reusable action groups

for unique sets of recipients.

o URL: https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/actiongroups

To meet the requirements, the Standard App Service plan is the most appropriate choice.

The Free, Shared, and Basic tiers do not support the required autoscale capability of up to

eight instances. While Premium and Isolated tiers also meet the technical requirements, the

Standard plan is the most cost-effective option that satisfies all conditions, thereby

minimizing costs.

For domain verification, a TXT record is used. Azure provides a unique Domain Verification

ID that must be added as a TXT record to your domain's DNS settings. This process proves

to Azure that you have ownership of the custom domain before it can be associated with the

App Service app. While a CNAME record is used to map a subdomain, the TXT record is a

primary method specifically for the verification step.

•

Azure App Service pricing tiers: The official Azure documentation details the

features available in each App Service plan. The "App Service pricing" page shows

that the Standard plan is the first tier to include autoscale capabilities up to 10

instances and support for custom domains.

o Source: Microsoft Azure Documentation

o URL: https://azure.microsoft.com/en-us/pricing/details/app-service/windows/

(Refer to the feature matrix comparing Free, Shared, Basic, Standard, and

Premium plans).

•

Custom domain verification: The official tutorial for mapping a custom domain to

an App Service app explicitly describes using a TXT record for domain ownership

verification.

o Source: Microsoft Azure Documentation, "Tutorial: Map an existing custom

DNS name to Azure App Service"

o URL: https://docs.microsoft.com/en-us/azure/app-service/app-service-webtutorial-custom-domain

o Specific Section: In the "Get a domain verification ID" and "Create the DNS

records" sections, the procedure outlines creating a TXT record (asuid.your-

subdomain) with the verification ID as its value.

The Azure Custom Script Extension is designed to download and execute scripts on Azure

virtual machines after they are provisioned. This is ideal for post-deployment configuration

tasks, such as installing software like NGINX. When deploying a virtual machine scale set

using an Azure Resource Manager (ARM) template, the Custom Script Extension can be

included in the template to ensure that NGINX is installed on all instances automatically.

A. the Publish-AzVMDscConfiguration cmdlet: This cmdlet is used to package and publish a

PowerShell Desired State Configuration (DSC) script, which is part of using Azure

Automation DSC or the DSC extension. While DSC can install software, the cmdlet itself is

a preparatory step, not the direct mechanism used within the ARM template for execution

on the VMs. The Custom Script Extension is more direct for this specific task.

B. Azure Application Insights: This is an Application Performance Management (APM)

service used for monitoring applications, not for installing software on virtual machines.

D. a Microsoft Endpoint Manager device configuration profile: Microsoft Endpoint Manager

(formerly Intune) is primarily for managing client devices and mobile endpoints. It's not the

standard tool for configuring server software on Azure VMs within a scale set during ARM

template deployment.

Azure Custom Script Extension:

Microsoft Learn: "Custom Script Extension for Windows." "The Custom Script Extension

downloads and executes scripts on Azure virtual machines. This extension is useful for post

deployment configuration, software installation, or any other configuration / management

task."

URL: https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/custom-scriptwindows

Microsoft Learn: "Tutorial: Install applications in Virtual Machine Scale Sets with an Azure

Resource Manager template." This tutorial demonstrates using the Custom Script Extension

to install a web server (IIS, but the principle applies to NGINX).

URL: https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/tutorial-installapps-template (Section: "Use Custom Script Extension")

Azure Desired State Configuration (for option A context):

Microsoft Learn: "Introduction to Azure Desired State Configuration."

URL: https://learn.microsoft.com/en-us/azure/automation/dsc-overview

Azure Application Insights (for option B context):

Microsoft Learn: "What is Application Insights?"

URL: https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview

Microsoft Endpoint Manager (for option D context):

Microsoft Learn: "What is Microsoft Intune?" (Intune is part of Microsoft Endpoint Manager)

URL: https://learn.microsoft.com/en-us/mem/intune/fundamentals/what-is-intune

To manage VM configurations using Azure Automation State Configuration, you must follow this sequence:

1. Upload a configuration: First, you must import the PowerShell DSC configuration script (the logical definition of the desired state) into the Azure Automation account.
2. Compile a configuration: The uploaded script cannot be applied directly. It must be compiled into a MOF (Managed Object Format) file, known as a "Node Configuration," which the Local Configuration Manager (LCM) on the VM can understand and apply.
3. Check the compliance status: Once the configuration is applied to the nodes, you verify and manage ongoing consistency by checking the compliance reports. This tells you if the VM matches the desired state or has drifted.

Assign tags to the virtual machines: Tagging is a mechanism for organizing and

managing Azure resources. It is not a required functional step in the workflow of applying a

DSC configuration.

Create a management group: Management groups are used for enterprise-level

governance and policy management across multiple subscriptions. They are not directly

involved in the process of applying configurations to nodes within an Automation Account.

Microsoft Learn: Get started with Azure Automation State Configuration - Upload a configuration to Azure Automation. (Confirms uploading is the first step).

Section: "Import a configuration".

URL: https://learn.microsoft.com/en-us/azure/automation/automation-dsc-getting-started#import-a-configuration-into-azure-automation

Microsoft Learn: Get started with Azure Automation State Configuration - Compile a configuration. (Confirms compilation is the necessary processing step).

Section: "Compile a configuration into a node configuration".

URL: https://learn.microsoft.com/en-us/azure/automation/automation-dsc-getting-started#compile-a-configuration-into-a-node-configuration

Microsoft Learn: Azure Automation State Configuration overview - View reports. (Confirms checking compliance is the management/verification step).

Section: "View reports".

URL: https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview#view-reports

To configure Azure File Sync on an on-premises server (Server1), you must follow this specific sequence:

1. Install the Azure File Sync agent: This is the primary prerequisite. The agent enables the Windows Server to communicate with the Storage Sync Service in Azure.
2. Register Server1: After the agent installation, the server must be registered with the Storage Sync Service. This establishes a trust relationship between the on-premises server and the Azure resource.
3. Add a server endpoint: Once registered, you add a server endpoint to a Sync Group. This defines the specific path (folder/volume) on the server that will synchronize with the Azure File Share.

Create an Azure on-premises data gateway: This component is used for other services

like Power BI and Logic Apps to access on-premises data; Azure File Sync uses its own

dedicated agent.

Create a Recovery Services vault: This is a component of Azure Backup and Azure Site

Recovery and is not a direct step in the Azure File Sync deployment process.

Install the DFS Replication server role on Server1: Azure File Sync is a distinct

technology from DFS Replication and does not require the DFS-R server role to be installed

to function.

Microsoft Learn. "Deploy Azure File Sync - Install the Azure File Sync agent." Azure Storage, Access Date: November 28, 2025.

Quote: "The Azure File Sync agent is a downloadable package that enables Windows Server to be synced with an Azure file share."

URL: https://learn.microsoft.com/en-us/azure/storage/file-sync/file-sync-deployment-guide?tabs=azure-portal%2Cproactive-portal#install-the-azure-file-sync-agent

Microsoft Learn. "Deploy Azure File Sync - Register Windows Server with Storage Sync Service." Azure Storage.

Quote: "Registering your Windows Server with a Storage Sync Service establishes a trust relationship between your server (or cluster) and the Storage Sync Service."

URL: https://learn.microsoft.com/en-us/azure/storage/file-sync/file-sync-deployment-guide?tabs=azure-portal%2Cproactive-portal#register-windows-server-with-storage-sync-service

Microsoft Learn. "Deploy Azure File Sync - Create a server endpoint." Azure Storage.

Quote: "A server endpoint represents a specific location on a registered server, such as a folder on a server volume."

URL: https://learn.microsoft.com/en-us/azure/storage/file-sync/file-sync-deployment-guide?tabs=azure-portal%2Cproactive-portal#create-a-server-endpoint

While the correct Azure CLI command is upgrade, it is not offered as an option.

Given the choices, updates is the most plausible selection as it conceptually aligns

with the task of performing an upgrade. The core of the question lies in configuring

the upgrade process. The --max-surge parameter is used to specify the number of

additional buffer nodes created during an upgrade to ensure application availability.

Setting --max-surge 2 directly fulfills the requirement to "Deploy two new nodes to

perform the upgrade," allowing for a controlled, rolling update while managing costs.

Note: The official documentation will refer to the correct command upgrade, which

substantiates the use of the --max-surge parameter as described in the scenario.

1. Azure CLI Documentation for az aks nodepool upgrade: This official

source confirms that the --max-surge parameter is the correct mechanism for

controlling the number of buffer nodes during a node pool upgrade.

o Source: Microsoft Learn, Azure Command-Line Interface (CLI)

Documentation.

o URL: https://learn.microsoft.com/enus/cli/azure/aks/nodepool?view=azure-cli-latest#az-aks-nodepool-

upgrade

o Specific Section: Parameter Set, --max-surge.

2. AKS Cluster and Nodepool Upgrade Concepts: This document explains

the surge upgrade strategy. It clarifies that --max-surge is the setting that

controls how many extra nodes are provisioned to facilitate the upgrade

process, which is central to the question's requirements.

o Source: Microsoft Learn, Azure Kubernetes Service (AKS)

Documentation.

o URL: https://learn.microsoft.com/en-us/azure/aks/upgradecluster#customize-node-surge-upgrade

o Specific Section: "Customize node surge upgrade".

The critical factor in this scenario is the SKU mismatch. The table indicates that lb1 is an Azure Standard Load Balancer, while vm1 and vm2 are using Basic public IP addresses.

1. Remove the public IP addresses: A Standard Load Balancer backend pool cannot contain virtual machines that have Basic SKU public IP addresses attached to them. You must dissociate the Basic public IPs from the VMs to add their network interfaces to the Standard Load Balancer's backend pool.
2. Create a health probe and backend pool: Once the IPs are removed, you must define the backend pool (the group of VMs to receive traffic) and the health probe (to monitor the status of the VMs) on the load balancer.
3. Create a load balancing rule: Finally, you create the rule that maps the frontend IP configuration to the backend pool and defines the distribution logic (port 443 for HTTPS) and health probe usage.

•

Remove nsg1: This is incorrect. The Network Security Group (NSG) is required to

allow incoming traffic on port 443 to reach the virtual machines' network interfaces.

The load balancer directs traffic, but the NSG permits it.

•

Create an availability set: This is incorrect. While best practice for high availability,

an availability set is a construct for the VMs themselves and is not a required step to

configure the load balancer to distribute traffic to existing VMs.

Microsoft Learn. "SKU comparison - Azure Load Balancer." Azure Load Balancer.

Quote: "A standalone virtual machine, availability set, or virtual machine scale set resource can be referenced in the backend pool of a specific Load Balancer SKU... If the backend pool members have public IP addresses, they must match the SKU of the Load Balancer."

URL: https://learn.microsoft.com/en-us/azure/load-balancer/skus#skus

Microsoft Learn. "Quickstart: Create a public load balancer to load balance VMs." Azure Load Balancer.

Context: This guide outlines the standard procedure: creating the backend pool, creating the health probe, and then creating the load balancer rule.

URL: https://learn.microsoft.com/en-us/azure/load-balancer/quickstart-load-balancer-standard-public-portal

Microsoft Learn. "Troubleshoot Azure Load Balancer backend pool issues."

Context: Documentation often highlights that mixing Basic Public IPs with Standard Load Balancers is a common configuration error preventing backend pool addition.

URL: https://learn.microsoft.com/en-us/azure/load-balancer/backend-pool-management

The terms "Per Authentication" and "Per Enabled User" refer to the billing models for an

Azure Multi-Factor Authentication (MFA) Provider. Reconfiguring the usage model from

"Per Authentication" to "Per Enabled User" via the Azure CLI primarily changes how the

company is billed for MFA services. This action, by itself, does not enable or enforce MFA

for the new Azure AD users. To ensure employees use MFA, their individual MFA status

must be set to 'Enabled' or 'Enforced' (for per-user MFA), or they must be included in a

Conditional Access policy that mandates MFA. The proposed solution only addresses the

billing/usage model, not the actual enablement of MFA for the users.

1. Microsoft Learn: "How to get Azure AD Multi-Factor Authentication"

URL: https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-mfalicensing

Section: "Azure AD Multi-Factor Authentication provider"

Quote/Content: This section explains that an MFA provider "offers per-user or per-

authentication billing," confirming these terms relate to billing/consumption models, not

direct user enablement mechanisms.

2. Microsoft Learn: "Enable per-user Azure AD Multi-Factor Authentication to secure sign-in

events"

URL: https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-mfauserstates

Content: This document details the process of changing user MFA states (Disabled,

Enabled, Enforced), which is the necessary step for per-user MFA enablement, distinct from

changing a billing model.

3. Microsoft Learn: "Plan an Azure AD Multi-Factor Authentication deployment"

URL: https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-mfadeploy

Content: This guide discusses various ways to enable MFA, primarily focusing on

Conditional Access policies and per-user MFA enablement, neither of which is achieved by

solely changing a billing model.

To use a custom domain suffix (like @contoso.com) for user accounts in an Azure AD tenant, you must follow a specific verification lifecycle to prove ownership:

1. Add a custom name: You must first register the domain name within the Azure AD portal. This action generates the specific values required for verification.
2. Add a record to the public contoso.com DNS zone: Azure provides a TXT (or MX) record containing a unique verification token. You must add this record to the authoritative DNS zone of the domain (managed by your third-party registrar) so it is publicly resolvable.
3. Verify the domain: Once the DNS record has propagated, you initiate the verification check in the Azure portal. Upon success, the domain status becomes "Verified," allowing it to be assigned to users.

Add an Azure AD tenant: This is incorrect because the scenario explicitly states that an

Azure AD tenant already exists.

Configure company branding: This action relates to customizing the appearance of sign-

in pages and is not required for adding or verifying a domain name for user suffixes.

Create an Azure DNS zone: This is not required. Verification can be performed with any

DNS hosting provider; you do not need to host your DNS zone in Azure.

Microsoft Learn - Microsoft Entra ID (formerly Azure Active Directory): "Add your custom domain name using the Microsoft Entra admin center"

Section: "Add your custom domain name" and "Add your DNS information to the domain registrar".

Citation: "After you add your custom domain name... you need to add the DNS entry to your domain registrar... After you add the DNS entry... you can verify the custom domain name."

URL: https://learn.microsoft.com/en-us/entra/fundamentals/add-custom-domain

In Microsoft Azure, a route table is used to control network traffic flow. A route table

contains a set of rules, called routes, that specify how packets should be directed. A route

table can be associated with one or more subnets within a virtual network. It cannot be

associated directly with a virtual network (VNet) or a network interface (NIC). Therefore,

among the given options, the route table RT1 can only be associated with Subnet1.

References:

Microsoft Learn | Virtual network traffic routing: "You can create custom route tables that

control where packets are routed for each subnet. ... You can associate a route table to

zero or more subnets."

URL: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udroverview#association-of-a-route-table-to-a-subnet

Microsoft Learn | Create, change, or delete a route table: "A route table can be associated

to zero or more subnets. A route table can't be associated to a virtual network."

URL: https://learn.microsoft.com/en-us/azure/virtual-network/manage-routetable#associate-a-route-table-to-a-subnet

Microsoft Learn | Virtual network traffic routing: "You can create custom route tables that

control where packets are routed for each subnet. ... You can associate a route table to

zero or more subnets."

URL: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udroverview#association-of-a-route-table-to-a-subnet

Microsoft Learn | Create, change, or delete a route table: "A route table can be associated

to zero or more subnets. A route table can't be associated to a virtual network."

URL: https://learn.microsoft.com/en-us/azure/virtual-network/manage-routetable#associate-a-route-table-to-a-subnet

1. Yes: The network access control list (ACL) for storageaccount1 has the

defaultAction set to "Allow". Since the ipRules and virtualNetworkRules arrays

are empty, there are no restrictions in place. Therefore, traffic from any public

IP address, including 131.107.103.10, is permitted by default.

2. Yes: The storage account is of the kind: "StorageV2" (General-purpose V2).

GPv2 accounts support all blob access tiers (Hot, Cool, and Archive) and

allow for setting the tier at the individual blob level. While the default account-

level accessTier is "Hot", individual blobs can be moved to the Archive tier

after upload.

3. No: Accessing an Azure file share with Azure AD credentials requires

enabling an identity-based authentication source on the storage account,

such as Azure Active Directory Domain Services (Azure AD DS), and

assigning appropriate Azure RBAC roles (e.g., Storage File Data SMB Share

Contributor) to the user. Being a Global Administrator in Azure AD does not

inherently grant data-plane access to file shares. The provided template

shows no such configuration.

1. Network ACLs:

o Microsoft Learn: "Configure Azure Storage firewalls and virtual

networks". This document states that the default action is to allow or

deny traffic when no other rules match. The template clearly shows

"defaultAction": "Allow".

§

URL: https://learn.microsoft.com/enus/azure/storage/common/storage-network-security?tabs=azure-

portal

2. Blob Access Tiers:

o Microsoft Learn: "Access tiers for blob data". This document confirms

that "General-purpose v2 (GPv2) accounts support all access tiers for

block blobs" and "You can set the tier of a blob on upload or change

the tier of an existing blob."

§

URL: https://learn.microsoft.com/enus/azure/storage/blobs/access-tiers-overview

§

Section: "Blob-level tiering"

3. Azure Files Identity-Based Authentication:

o Microsoft Learn: "Overview of Azure Files identity-based authentication

options for SMB access". This article outlines the necessary steps,

including enabling an AD source and assigning both share-level and

file/directory-level permissions. It clarifies that authentication is not

enabled by default.

§

URL: https://learn.microsoft.com/enus/azure/storage/files/storage-files-active-directory-overview

§

Section: "How it works"

In an Azure Point-to-Site (P2S) VPN configuration, when a virtual network peering is

established or modified after the VPN client package has been configured, the routes to the

newly peered virtual network (VNet2) are not automatically propagated to the P2S clients.

To resolve this, the VPN client configuration package must be downloaded again from the

Azure portal and re-installed on the client machine (Client1). This updated package contains

the necessary routes for the peered VNet's address space, which updates the client's local

routing table and enables connectivity.

A. Select Use the remote virtual network's gateway or Route Server on VNet1 to VNet2

peering. This setting would configure VNet1 to use a gateway in VNet2. The gateway

(VPNGW1) is located in VNet1, making this option incorrect.

B. Select Use the remote virtual network's gateway or Route Server on VNet2 to VNet1

peering. This setting, known as gateway transit, allows VNet2 to use VNet1's gateway.

While necessary for transit, it does not update the P2S client's local routing table.

D. Enable BGP on VPNGW1. The gateway uses static routing. While BGP is for dynamic

routing, the core issue is the client's outdated routing information, not the gateway's routing

protocol.

Microsoft Learn (Official Documentation): "Configure VPN gateway transit for virtual network

peering". Under the "Point-to-site clients" section, the documentation explicitly states: "If you

add or change the address ranges of the peered virtual network, you must download and

reinstall the point-to-site VPN client package so that your point-to-site clients can get the

routes to the peered virtual network."

URL: https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-peering-gatewaytransit-powershell#p2s

Microsoft Learn (Official Documentation): "About Point-to-Site VPN routing". This document

explains how routes are advertised to P2S clients, reinforcing that the client package

contains the routes that will be installed on the client.

URL: https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-point-to-siterouting

Statement 1 is TRUE. The Storage Account Contributor role, assigned to User1 at

the RG1 resource group scope, grants the necessary permissions

(Microsoft.Storage/storageAccounts/write) to create and manage storage accounts

directly within that resource group.

Statement 2 is FALSE. Modifying a network interface requires write permissions on

the network interface resource itself. User1 only has Reader permissions on

networkInterface1 (inherited from the subscription). The Contributor role on the

associated Network Security Group (NSG1) and the Storage Account Contributor

role on the resource group do not grant permissions to modify the network interface.

Statement 3 is TRUE. User1 has the Contributor role scoped specifically to NSG1.

This role grants full permissions to manage the NSG1 resource, which includes the

action Microsoft.Network/networkSecurityGroups/securityRules/write, allowing the

creation of new inbound security rules within that NSG.

•

Azure built-in roles Documentation: This official Microsoft documentation

details the permissions granted by each built-in role.

o Storage Account Contributor: As documented, this role permits

management of storage accounts, including creation. (See

Microsoft.Storage/storageAccounts/write permission).

o Contributor: This role grants full access to manage all resources,

which for the NSG1 scope, includes managing its security rules.

o Reader: This role only permits viewing resources, not changing them.

o Direct URL: https://docs.microsoft.com/en-us/azure/role-basedaccess-control/built-in-roles

•

Scope for Azure RBAC: This official Microsoft documentation explains how

scope functions in Azure. Permissions are inherited down, but do not apply

sideways to peer resources. A role on NSG1 does not grant permissions to

networkInterface1, even if they are in the same resource group or associated.

o Direct URL: https://docs.microsoft.com/en-us/azure/role-basedaccess-control/scope-overview (Specifically the sections on "Scope

format" and "Scope and inheritance").

To delete the resource group TestRG, you must first address any impediments to deleting

its constituent resources. VNET1 has a Delete lock, which prevents its deletion; this lock

must be removed. Vault1 is a Recovery Services vault likely protecting VM1. A Recovery

Services vault cannot be deleted if it contains backup items. Therefore, you must stop the

backup for VM1 and delete the backup data from Vault1. Option B covers both these

necessary prerequisite actions.

A: Modifying the lock type (unless to 'None' or removed) is insufficient; the lock must be

removed.

C: Turning off VM1 does not resolve the backup dependency with Vault1, which prevents

Vault1's deletion.

D: Turning off VM1 is not the primary blocker, and this option fails to address the resource

lock on VNET1.

Resource Locks: Microsoft Learn. (2023). Lock resources to prevent unexpected changes.

"Before you can delete a locked resource, you must first remove the lock."

Direct URL: https://learn.microsoft.com/en-us/azure/azure-resourcemanager/management/lock-resources?tabs=json#delete

Deleting Recovery Services Vault: Microsoft Learn. (2023). Delete an Azure Backup

Recovery Services vault. "You can't delete a Recovery Services vault if there are any

dependencies, such as backup items or recovery points... To delete a vault with

dependencies: ... In the item's dashboard, select Stop backup. In the Stop Backup page,

select Delete Backup Data from the dropdown menu."

Direct URL: https://learn.microsoft.com/en-us/azure/backup/backup-azure-deletevault?tabs=portal#delete-a-recovery-services-vault-with-dependencies

Deleting Resource Groups: Microsoft Learn. (2023). Azure Resource Manager resource

group and resource deletion. "When you delete a resource group, Resource Manager

determines the order to delete resources... It waits for dependencies to be finished before

deleting a dependent resource... If you have a lock on a resource group or a resource, you

must remove the lock before you can delete the resource group or resource."

Direct URL: https://learn.microsoft.com/en-us/azure/azure-resourcemanager/management/delete-resource-group?tabs=azure-powershell#how-resources-are-

deleted

The rule adds one instance whenever average Memory Percentage > 70 % for the 5-minute

sample period and the 5-minute cooldown has expired.

Starting with 2 instances:

5 min: memory 80 % rule satisfied (no prior cooldown)

At 5 min autoscale adds 1’ 3 instances; cooldown 5 min

10 min: rule again satisfied’ add 1’ 4; cooldown 5 min

20 min: rule again satisfied’ add 1’ 5; cooldown 5 min

By 30 minutes the upper instance limit (Maximum = 5) is reached, so the highest possible

count during the interval is 5.

A. 2 Ignores autoscale; count would not remain static while metric stays above threshold.

B. 3 Only accounts for one scale action; 30 minutes allows three actions.

C. 4 Stops one increment short; rule can fire a third time before limit is hit.

1. Microsoft Learn Autoscale best practices: Scale triggers fire each time the condition

persists and after the cooldown period; scaling never exceeds the set maximum.

https://learn.microsoft.com/azure/azure-monitor/autoscale/autoscale-best-practices#scalesettings

2. Microsoft Learn Automatically scale an App Service app: Example rule uses Memory

Percentage > 70 %, adds one instance, 5-minute cooldown.

https://learn.microsoft.com/azure/app-service/manage-scale#autoscale

3. S. Koch et al., Elastic Scaling of Cloud Applications, ACM Computing Surveys 2021, 4.2

(cool-down and repeated scale actions).

Restarting the NetLogon service on a domain controller will not initiate an immediate

synchronization of user information to Azure AD. The NetLogon service is primarily

responsible for authentication requests, service principal name (SPN) registration, and

maintaining the secure channel with other domain controllers. Directory synchronization

with Azure AD is handled by the DirSync tool (or its successor, Azure AD Connect) installed

on the DirSync server, which operates on its own schedule or can be manually triggered

through specific commands or tools associated with the synchronization service itself.

1. Azure AD Connect sync: Scheduler: While the question mentions DirSync (an older tool),

the principle of how synchronization is managed and triggered is relevant. Azure AD

Connect, the successor, uses a scheduler and can be manually triggered via PowerShell.

DirSync had similar mechanisms (e.g., DirectorySyncClientCmd.exe or the Synchronization

Service Manager) independent of domain controller services like NetLogon.

Microsoft Learn. (n.d.). Azure AD Connect sync: Scheduler. Retrieved from

https://learn.microsoft.com/en-us/azure/active-directory/hybrid/connect/how-to-connectsync-feature-scheduler (This page explains how Azure AD Connect sync is triggered,

highlighting it's a separate mechanism from DC services).

2. Net Logon service: This service is responsible for handling logon requests and secure

channel communication for a domain controller. It is not involved in directory

synchronization with Azure AD.

Microsoft Learn. (n.d.). Net Logon service. Retrieved from https://learn.microsoft.com/enus/previous-versions/windows/it-pro/windows-server-2012-r2-and-

2012/cc756950(v=ws.11)) (Describes the functions of the NetLogon service).

3. Implement directory synchronization with Azure Active Directory Connect (for context on

how synchronization is generally managed, even if DirSync is older):

Microsoft Learn. (n.d.). Tutorial: Integrate a single forest with a single Azure AD tenant.

Retrieved from https://learn.microsoft.com/en-us/azure/activedirectory/hybrid/connect/tutorial-quick-start (Provides context on the synchronization tools

and their operation).