Examkin

All practice questions

1252 questions

All types1,252Multiple choice644Multiple select429True / False47Matching52Ordering80
Question 641Question →

An administrator is configuring autoscaling for an Azure Virtual Machine Scale Set (VMSS) named `vmss-app`. The workload for the application follows a predictable schedule:

* During business hours (Monday through Friday, 08:00 to 18:00), the VMSS must have a minimum of 5 instances and a maximum of 10 instances, scaling dynamically based on CPU utilization.
* Outside of business hours and during weekends, the VMSS must scale down to a minimum of 2 instances and a maximum of 4 instances to optimize costs.

Which of the following configuration methods should the administrator implement to meet these requirements with the least administrative effort?

Show answer & explanation

Answer: Configure two autoscale profiles: one default profile with capacity limits of 2 to 4, and one recurring profile configured for weekdays between 08:00 and 18:00 with capacity limits of 5 to 10.

Answer

Configure two autoscale profiles: one default profile with capacity limits of 2 to 4, and one recurring profile configured for weekdays between 08:00 and 18:00 with capacity limits of 5 to 10.
Azure Monitor Autoscale allows you to define multiple profiles. A default profile applies when no other profiles are active (handling weekends and off-hours). A recurring profile can be configured for specific schedules (weekdays during business hours) and will take precedence when its recurrence conditions are met, allowing different capacity limits and scale rules to apply automatically. This is the native, least administrative effort method.

Step-by-Step Solution

1
Analyze the workload requirements to identify the scheduling patterns and capacity limits.
Identified two distinct operational windows: weekday business hours (5 to 10 instances) and off-hours/weekends (2 to 4 instances).
Understanding the schedule is necessary to determine if a single static profile or multiple profiles are required.
2
Evaluate the capabilities of Azure Monitor Autoscale settings for Virtual Machine Scale Sets.
Determined that Azure Monitor Autoscale natively supports configuring multiple profiles (default and recurring/scheduled).
This confirms that native capabilities can satisfy the scheduling requirement without external automation.
3
Configure the default profile and the recurring profile within the autoscale settings.
Created a default profile with limits 2-4, and a recurring profile for weekdays 08:00-18:00 with limits 5-10.
The recurring profile automatically overrides the default profile during its active window, meeting the requirements with the least administrative effort.

Key Concept

Azure Monitor Autoscale supports multiple scale profiles (default and recurring/scheduled) to dynamically adapt VMSS capacity limits and rules to predictable workload patterns.
Question 642Question →

Your company has an Azure subscription containing a virtual network named `VNet1`. `VNet1` contains two subnets named `Subnet-Web` and `Subnet-App`.

You have the following resource configuration:
- A virtual machine named `VM-Web1` in `Subnet-Web`. The network interface of `VM-Web1` is associated with an Application Security Group (ASG) named `ASG-Web`.
- A virtual machine named `VM-App1` in `Subnet-App`. The network interface of `VM-App1` is associated with an ASG named `ASG-App` and a Network Security Group (NSG) named `NSG-NIC-App1`.
- An NSG named `NSG-Subnet-App` is associated with `Subnet-App`.

`NSG-Subnet-App` contains the following inbound security rule:
- `Rule1`: Priority 200200, Source `ASG-Web`, Destination `ASG-App`, Port 8080, Protocol `TCP`, Action `Allow`

`NSG-NIC-App1` contains the following inbound security rules:
- `Rule2`: Priority 150150, Source `ASG-Web`, Destination `ASG-App`, Port 8080, Protocol `TCP`, Action `Deny`
- `Rule3`: Priority 250250, Source `ASG-Web`, Destination `ASG-App`, Port 8080, Protocol `TCP`, Action `Allow`

You need to allow HTTP traffic on port 8080 from `VM-Web1` to `VM-App1` using the ASGs. The solution must use the principle of least privilege.

Which two of the following actions can you perform to achieve the goal? (Select two.)

Select all that apply

Show answer & explanation

Answer: Delete Rule2 from NSG-NIC-App1.; Change the priority of Rule3 in NSG-NIC-App1 to 120120.

Answer

To allow the HTTP traffic, you must ensure that both the subnet-level and NIC-level NSGs allow the traffic. Since the subnet NSG already allows it, you must resolve the block at the NIC level by either deleting the Deny rule (Rule2) or changing the priority of the Allow rule (Rule3) to a value lower than the Deny rule (such as 120).
Deleting Rule2 from the NIC-level NSG leaves Rule3 as the active rule allowing port 80 traffic. Alternatively, changing the priority of Rule3 to 120 makes it process before Rule2 (priority 150), allowing the HTTP traffic to be accepted at the NIC level. Inbound traffic must be allowed by both the subnet-level and NIC-level NSGs, and since the subnet NSG already permits it, resolving the NIC-level block is sufficient.

Step-by-Step Solution

1
Analyze the inbound traffic flow path in Azure virtual networks.
Inbound traffic is evaluated first by the subnet-level NSG (NSG-Subnet-App) and second by the NIC-level NSG (NSG-NIC-App1).
Both NSGs must allow the traffic for the connection to succeed.
2
Evaluate the subnet-level NSG rules.
NSG-Subnet-App has Rule1 with priority 200 that allows port 80 traffic from ASG-Web to ASG-App.
This confirms that the subnet-level configuration is already correct.
3
Evaluate the NIC-level NSG rules and identify the blocking rule.
NSG-NIC-App1 has Rule2 (Deny, priority 150) and Rule3 (Allow, priority 250). Since lower priority numbers have higher precedence, Rule2 is processed first and blocks the traffic.
To allow the traffic, the blocking rule must be bypassed or removed.
4
Determine the valid administrative actions to allow the traffic.
Deleting Rule2 allows the lower precedence Rule3 (Allow) to be applied. Alternatively, changing the priority of Rule3 to a value lower than 150 (such as 120) makes the Allow rule process before the Deny rule.
These actions modify the NSG evaluation order or ruleset to permit the connection.

Key Concept

NSG inbound rules are processed in priority order (lower numbers first), and inbound traffic is evaluated at the subnet level NSG before the network interface (NIC) level NSG.
Question 643Question →

You need to host an event-processing worker in Azure Container Instances (ACI). The worker continuously monitors an external queue. The workload must meet the following configuration requirements:
- The container must run continuously under normal operation.
- If the container process terminates with a non-zero exit code due to an unhandled error, it must be restarted automatically.
- If a maintenance script gracefully terminates the container process (exit code 0), the container must remain terminated.

Which restart policy configuration should you apply to the container group?

Show answer & explanation

Answer: Configure the container group restart policy to OnFailure.

Answer

Configure the container group restart policy to OnFailure.
The correct configuration is to set the container group's restart policy to OnFailure. Under this policy, Azure Container Instances (ACI) will automatically restart the container if the containerized process terminates with a non-zero exit code (indicating a failure). If the process terminates with exit code 0 (indicating success or a graceful shutdown), the container group transitions to a Succeeded state and is not restarted. This matches all specified requirements.

Step-by-Step Solution

1
Analyze the container exit behaviors and restart requirements.
Identified that the container must restart when the process exits with a non-zero code, but must not restart when the process exits with code 0.
This maps to the specific behavior of ACI restart policies, which evaluate exit codes to determine whether to restart a container.
2
Evaluate the available ACI restart policies (Always, Never, and OnFailure).
Always restarts on any exit code. Never does not restart at all. OnFailure restarts only on non-zero exit codes.
To ensure that graceful exits (code 0) do not trigger a restart, but exceptions (non-zero) do, the OnFailure policy must be selected.
3
Determine the configuration scope for restart policies in ACI.
Confirmed that the restart policy must be configured at the container group level.
ACI does not support setting restart policies on individual containers; it is applied group-wide.

Key Concept

Azure Container Instances restart policies are configured at the container group level and evaluate exit codes to determine restart behavior.
Question 644Question →

You have an Azure virtual machine named VM-Legacy deployed in the East US region. The virtual machine has a network interface named nic-legacy, which is associated with a public IP address named pip-legacy. The public IP address uses the Basic SKU and Dynamic allocation. You plan to deploy a Standard Load Balancer named LB-Prod in the East US region and associate nic-legacy with the load balancer's backend pool. You need to upgrade pip-legacy to the Standard SKU to support the new configuration. Which sequence of actions should you perform?

Show answer & explanation

Answer: Disassociate pip-legacy from nic-legacy, change the allocation method of pip-legacy to Static, and then upgrade the SKU to Standard.

Answer

Disassociate pip-legacy from nic-legacy, change the allocation method of pip-legacy to Static, and then upgrade the SKU to Standard.
The correct sequence requires disassociating the public IP address from the network interface first because Azure does not allow SKU modifications on associated public IPs. Additionally, because Standard SKU public IP addresses only support Static allocation, the allocation method must be set to Static before performing the SKU upgrade.

Step-by-Step Solution

1
Disassociate the public IP address pip-legacy from the network interface nic-legacy.
The public IP address is no longer bound to any resource, which is a prerequisite for changing its SKU.
Azure does not permit changing the SKU of a public IP address while it is associated with a network interface or other resource.
2
Change the allocation method of pip-legacy from Dynamic to Static.
The allocation method is updated to Static, and the current dynamic IP address is locked/reserved for this resource.
Standard SKU public IP addresses do not support Dynamic allocation. The IP must be set to Static allocation before upgrading the SKU.
3
Upgrade the SKU of pip-legacy from Basic to Standard.
The public IP address is successfully upgraded to the Standard SKU.
Standard SKU is required for compatibility with Standard Load Balancers and to support features like availability zones.

Key Concept

Upgrading a Basic SKU public IP to a Standard SKU public IP requires disassociating the resource and ensuring the allocation method is Static, as Standard SKU public IPs do not support Dynamic allocation.
Question 645Question →

An administrator manages an Azure subscription containing a virtual network named `VNet1` with a subnet named `Subnet1`.

`Subnet1` is associated with a Network Security Group (NSG) named `NSG-Subnet`. `NSG-Subnet` has the following inbound security rule:
- Priority: 150150
- Source: `ASG-Source`
- Destination: `ASG-Dest`
- Port: 84438443
- Protocol: TCP
- Action: Deny

`Subnet1` contains two virtual machines:
- `VM1` has a network interface associated with the Application Security Group (ASG) named `ASG-Source`.
- `VM2` has a network interface associated with the ASG named `ASG-Dest` and a Network Security Group (NSG) named `NSG-NIC`.

`NSG-NIC` has the following inbound security rule:
- Priority: 110110
- Source: *
- Destination: *
- Port: 84438443
- Protocol: TCP
- Action: Allow

All other custom NSG rules are deleted, and only default rules remain.

A user attempts to establish a TCP connection on port 84438443 from `VM1` to `VM2`.

What is the outcome of the connection attempt?

Show answer & explanation

Answer: The connection is blocked because the subnet-level Network Security Group (NSG) is evaluated first and denies the traffic, and a network interface-level Allow rule cannot override a subnet-level Deny rule.

Answer

The connection is blocked because the subnet-level Network Security Group (NSG) is evaluated first and denies the traffic, and a network interface-level Allow rule cannot override a subnet-level Deny rule.
For inbound network traffic to an Azure virtual machine, the subnet-level Network Security Group (NSG) is evaluated first. If a rule in the subnet-level NSG denies the traffic, the traffic is dropped immediately, and the network interface-level NSG is not evaluated to override this decision. Both NSGs must allow the traffic for the connection to succeed.

Step-by-Step Solution

1
Identify the traffic direction and the NSGs involved in the path.
The traffic is inbound from `VM1` to `VM2` on TCP port 84438443. The traffic traverses both the subnet-level NSG (`NSG-Subnet`) and the network interface-level NSG (`NSG-NIC`).
Inbound VM traffic must pass through the subnet-level NSG first and then the network interface-level NSG.
2
Evaluate the rules in the subnet-level NSG (`NSG-Subnet`).
The rule with priority 150150 explicitly denies TCP traffic on port 84438443 from `ASG-Source` (`VM1`) to `ASG-Dest` (`VM2`). This rule matches the traffic, resulting in a Deny decision.
Subnet-level rules are evaluated first. If a match occurs that denies traffic, evaluation stops at this level, and the traffic is blocked.
3
Determine if the network interface-level NSG (`NSG-NIC`) can permit the blocked traffic.
No. The Allow rule with priority 110110 on `NSG-NIC` is not evaluated because the traffic has already been blocked at the subnet level. NSG rule priorities are local to each NSG and cannot override decisions made in other NSGs.
For traffic to be permitted, both the subnet-level NSG and the network interface-level NSG must allow the connection.

Key Concept

Inbound Network Security Group (NSG) evaluation flow and priority scopes
Question 646Question →

You manage a Microsoft Entra ID tenant. You are configuring Self-Service Password Reset (SSPR) for a pilot group of users. You create a security group named SSPR-Pilot and select it under the Selected SSPR enablement setting. To organize the pilot users, you perform the following actions:

* You add 20 cloud-only users directly as members of SSPR-Pilot.
* You create a second security group named SSPR-SubGroup, add 30 hybrid users to SSPR-SubGroup, and make SSPR-SubGroup a member of SSPR-Pilot.
* You create an Administrative Unit named SSPR-AU, add SSPR-Pilot to SSPR-AU, and assign the Helpdesk Administrator role to a user named Admin1 for the scope of SSPR-AU.

Which users will be able to perform self-service password resets?

Show answer & explanation

Answer: Only the 20 cloud-only users added directly to SSPR-Pilot.

Answer

Only the 20 cloud-only users added directly to SSPR-Pilot will be able to perform self-service password resets.
Only direct members of the targeted group are enabled when SSPR is configured for a selected group. Because Microsoft Entra ID SSPR does not support nested groups, the users in the nested subgroup are excluded. Additionally, SSPR is configured at the tenant level and does not require subscription RBAC roles or Administrative Unit configuration to function.

Step-by-Step Solution

1
Identify the SSPR group scoping configuration.
SSPR is enabled for the group SSPR-Pilot.
SSPR enablement determines which users are targeted by the policy based on group membership.
2
Evaluate the membership of the SSPR-Pilot group.
Only the 20 cloud-only users are direct members. The 30 hybrid users are members of SSPR-SubGroup, which is nested inside SSPR-Pilot.
Microsoft Entra ID SSPR does not support nested groups; only direct members are evaluated.
3
Verify if Administrative Unit or Azure RBAC roles impact SSPR user enablement.
Administrative Units and Azure subscription RBAC roles do not change user-level SSPR scope or authentication method configurations.
SSPR is a directory-wide service configured globally in Microsoft Entra ID.

Key Concept

Microsoft Entra ID SSPR does not support nested groups for policy scoping, and SSPR settings are managed globally rather than via subscription-level RBAC or Administrative Unit scope.
Question 647Question →

Your organization uses the following Azure resource hierarchy:
* A root management group named Tenant-Root-MG
* A management group named Platform-MG under Tenant-Root-MG
* A management group named Workloads-MG under Tenant-Root-MG
* An Azure subscription named Sub-SharedServices under Platform-MG
* An Azure subscription named Sub-Production under Workloads-MG
* Two resource groups named RG-Network and RG-Security under Sub-SharedServices

You assign an Azure Policy definition named "Require CostCenter tag on resources" to the Platform-MG scope. The policy uses the Deny effect. You add the RG-Security resource group to the exclusions (notScopes) list of the policy assignment.

An administrator attempts to perform the following operations:
* Operation 1: Create a virtual network in RG-Network without the CostCenter tag.
* Operation 2: Create a key vault in RG-Security without the CostCenter tag.
* Operation 3: Create a virtual machine in Sub-Production without the CostCenter tag.

Which operations will complete successfully?

Show answer & explanation

Answer: Only Operation 2 and Operation 3

Answer

Only Operation 2 and Operation 3 will complete successfully.
The operations that complete successfully are Operation 2 and Operation 3. Operation 2 is successful because RG-Security is excluded from the assignment's scope via the notScopes property. Operation 3 is successful because Sub-Production is part of the Workloads-MG hierarchy, which is completely separate from the Platform-MG scope where the policy is assigned.

Step-by-Step Solution

1
Determine the scope of the policy assignment.
The policy is assigned at Platform-MG. This scope covers the child subscription Sub-SharedServices and both of its resource groups (RG-Network and RG-Security). It does not cover Workloads-MG or its child subscription Sub-Production.
Azure Policy assignments apply to the assigned scope and inherit down the hierarchy unless excluded.
2
Identify any exclusions (notScopes) configured for the assignment.
The resource group RG-Security is explicitly excluded from the Platform-MG policy assignment scope.
Exclusions prevent the policy from being evaluated or enforced on resources within the excluded scope.
3
Evaluate compliance and enforcement for each operation.
Operation 1 (RG-Network) is within the policy scope and not excluded; thus, the Deny policy blocks it. Operation 2 (RG-Security) is within the excluded scope, so the policy is not applied and the operation succeeds. Operation 3 (Sub-Production) is outside the Platform-MG scope, so the policy is not applied and the operation succeeds.
To determine which resource creation tasks are blocked by a Deny policy based on their location.

Key Concept

Azure Policy assignment scopes, inheritance, and exclusions
Question 648Question →

An administrator is configuring a virtual network named `vnet-prod-core` in an Azure subscription. The virtual network is configured with two address spaces:

* 10.240.0.0/1610.240.0.0/16
* 10.250.8.0/2410.250.8.0/24

The virtual network currently contains no subnets.

The administrator needs to deploy a new subnet named `subnet-compute` that will host virtual machines. The subnet must support at least 400400 virtual machines.

The administrator proposes to configure `subnet-compute` with the CIDR block 10.250.8.0/2310.250.8.0/23.

Does the proposed configuration meet the requirements and successfully deploy?

Show answer & explanation

Answer: False

Answer

The proposed configuration does not meet the requirements and will fail to deploy because the subnet range is not fully contained within any of the virtual network's defined address spaces.
The correct answer is False because the proposed CIDR block 10.250.8.0/2310.250.8.0/23 requires the IP range 10.250.8.010.250.8.0 to 10.250.9.25510.250.9.255. This range is not fully contained within either of the virtual network's defined address spaces (10.240.0.0/1610.240.0.0/16 and 10.250.8.0/2410.250.8.0/24). Consequently, Azure Resource Manager will fail to deploy the subnet.

Step-by-Step Solution

1
Calculate the host capacity of the proposed subnet 10.250.8.0/2310.250.8.0/23.
A /23/23 subnet contains 512512 total IP addresses. Azure reserves 55 IP addresses in every subnet, leaving 512−5=507512 - 5 = 507 usable IP addresses. This meets the requirement of supporting at least 400400 virtual machines.
Determine if the proposed subnet size is mathematically sufficient to host the requested number of virtual machines after accounting for Azure's reserved addresses.
2
Evaluate the address space containment constraint for the proposed subnet.
The range of 10.250.8.0/2310.250.8.0/23 spans from 10.250.8.010.250.8.0 to 10.250.9.25510.250.9.255. The virtual network's defined address spaces are 10.240.0.0/1610.240.0.0/16 and 10.250.8.0/2410.250.8.0/24 (covering 10.250.8.010.250.8.0 to 10.250.8.25510.250.8.255). The proposed subnet range exceeds the second address space boundary (specifically, the range 10.250.9.010.250.9.0 to 10.250.9.25510.250.9.255 is not defined in the virtual network) and does not belong to the first address space.
Verify if the proposed subnet CIDR block falls entirely within one of the parent virtual network's defined address spaces.
3
Determine configuration validity and deployment outcome.
Since the proposed subnet range is not fully contained within a single defined address space of the virtual network, Azure will block the creation of the subnet, resulting in a deployment failure.
Apply Azure architectural rules to conclude whether the deployment succeeds or fails.

Key Concept

Every subnet created in an Azure virtual network must have an address range that is a subset of, and fully contained within, a single address space defined on the parent virtual network.
Question 649Question →

You configure routing for an Azure subnet named `Subnet1`. You deploy a third-party firewall virtual machine to act as a Network Virtual Appliance (NVA) in a subnet named `Subnet-DMZ` within the same virtual network. You need to route all outbound internet traffic from `Subnet1` through the NVA. You create a custom route table and associate it with `Subnet1`. Which route configuration must you add to the route table?

Show answer & explanation

Answer: Destination prefix of 0.0.0.0/00.0.0.0/0 and next hop type of Virtual appliance

Answer

A route with a destination prefix of 0.0.0.0/00.0.0.0/0 and next hop type of Virtual appliance.
To route all outbound internet traffic through a Network Virtual Appliance (NVA), you must define a default route with the destination prefix 0.0.0.0/00.0.0.0/0 and set the next hop type to Virtual appliance, specifying the NVA's private IP address as the next hop IP address.

Step-by-Step Solution

1
Identify the destination prefix required to capture all outbound internet traffic.
The destination prefix must be 0.0.0.0/00.0.0.0/0.
In Azure routing, the 0.0.0.0/00.0.0.0/0 address prefix represents the default route containing all IP addresses not matched by other routes.
2
Determine the correct next hop type to route traffic through a custom firewall virtual machine.
The next hop type must be set to Virtual appliance.
A Virtual appliance next hop type specifies that traffic should be forwarded to a private IP address of a user-defined virtual machine acting as a firewall or router.

Key Concept

The configuration of user-defined routes to direct outbound internet traffic (0.0.0.0/00.0.0.0/0) to a Network Virtual Appliance (NVA) using the 'Virtual appliance' next hop type.
Question 650Question →

An administrator needs to rotate the access keys for an Azure Storage account named logisticsdata2026. The storage account is accessed by a web application that must remain online. The web application is currently configured to use key1.

Which two actions should the administrator perform to rotate the access keys without interrupting the web application's access to the storage account? (Select two.)

Select all that apply

Show answer & explanation

Answer: Update the web application configuration to use key2.; Regenerate key1 after the web application has transitioned to key2.

Answer

Update the web application configuration to use key2, and regenerate key1 after the web application has transitioned to key2.
To rotate storage account access keys without downtime, the application must be updated to use the secondary key before the primary key is regenerated. This ensures that the application's connection remains valid during the regeneration process. Once the application is successfully using the secondary key, the primary key can be regenerated safely.

Step-by-Step Solution

1
Transition the application authentication to the secondary key.
The web application continues to function normally using key2 while key1 becomes inactive from the application's perspective.
This prevents application downtime when key1 is regenerated.
2
Regenerate the primary key (key1) in the Azure Storage account.
A new value is generated for key1 while the application continues running on key2.
This completes the rotation of the primary key without impacting active application connections.

Key Concept

Manual rotation of Azure Storage account access keys without downtime
Question 651Question →

A medical clinic plans to deploy two web applications to Azure App Services: a patient portal named ClinicPortal and an API named TelemetryAPI. You need to configure a separate App Service plan for each application.

The applications have the following requirements:
* ClinicPortal requires support for a custom domain with SSL, three deployment slots, and daily automated backups.
* TelemetryAPI must be integrated with a regional Azure Virtual Network (VNet) and must be able to scale out to 25 instances during peak load.

Which of the following App Service plan pricing tiers are the most cost-effective options that satisfy the requirements for each application? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Standard (S1) for ClinicPortal; Premium V3 (P1v3) for TelemetryAPI

Answer

Standard (S1) for ClinicPortal and Premium V3 (P1v3) for TelemetryAPI are the most cost-effective tiers that meet all requirements.
The correct options are the tiers that meet all requirements for each application at the lowest price. For ClinicPortal, the Standard (S1) tier is the cheapest tier that offers both deployment slots (up to 5) and daily backups. For TelemetryAPI, even though the Standard tier supports VNet integration, it is limited to 10 instances. Therefore, the Premium V3 (P1v3) tier is required to scale up to 25 instances.

Step-by-Step Solution

1
Analyze the requirements for ClinicPortal.
ClinicPortal requires custom domain with SSL, 3 deployment slots, and daily automated backups. The minimum tier supporting slots and backups is the Standard tier.
Free, Shared, and Basic tiers do not support deployment slots or backups. The Standard tier supports up to 5 slots and 10 daily backups.
2
Analyze the requirements for TelemetryAPI.
TelemetryAPI requires regional VNet integration and a scale-out limit of 25 instances.
Although VNet integration is supported starting in the Standard tier, the Standard tier has a maximum scale-out limit of 10 instances. To scale out to 25 instances, the Premium V3 tier (which supports up to 30 instances) is required.
3
Select the most cost-effective pricing tiers that meet all requirements.
Standard (S1) is chosen for ClinicPortal, and Premium V3 (P1v3) is chosen for TelemetryAPI.
These represent the lowest-priced tiers that satisfy all specified requirements for each workload.

Key Concept

Selecting the appropriate App Service Plan pricing tier based on feature requirements (backups, slots, VNet integration) and scaling limits.
Question 652Question →

You are planning the deployment and configuration of several Azure virtual machines. Each virtual machine has specific performance, latency, or bootstrapping requirements.

Which Azure virtual machine configuration feature matches each deployment requirement?

Click a left item, then click its matching right item

Items

Ephemeral OS disk
Proximity Placement Group
Ultra Disk
Custom Script Extension

Matches

Show answer & explanation

Answer

Ephemeral OS disk matches local storage caching to eliminate cost. Proximity Placement Group matches physically grouping VMs to reduce latency. Ultra Disk matches dynamic performance adjustments. Custom Script Extension matches running scripts during provisioning.
Each feature matches its corresponding configuration requirement. Ephemeral OS disks eliminate storage costs by using local temp/cache storage. Proximity placement groups reduce latency by grouping VMs physically close. Ultra Disks support dynamic IOPS and throughput scaling. Custom Script Extensions automate VM provisioning tasks.

Step-by-Step Solution

1
Identify the storage characteristics of Ephemeral OS disks.
They reside on local node storage, eliminating remote storage costs.
To match Ephemeral OS disk with its description.
2
Identify the latency optimization characteristics of Proximity Placement Groups.
They physically place VMs close together in the same datacenter to minimize latency.
To match Proximity Placement Group with its network latency description.
3
Identify the unique capabilities of Ultra Disks.
They allow modifying IOPS and throughput dynamically without deallocating the VM.
To match Ultra Disk with its dynamic performance adjustment description.
4
Identify the configuration purpose of the Custom Script Extension.
It executes custom scripts on VMs during the provisioning phase.
To match Custom Script Extension with its script execution description.

Key Concept

Azure Virtual Machine creation and configuration options, including storage types, latency optimization, and extensions.
Estimated Time:2m 0s
Question 653Question →

You have an on-premises Windows Server named FS-Sync01 and an Azure subscription that contains a Storage Sync Service named SyncService1 and an Azure storage account. You need to synchronize files in a local folder path D:\SharedData on FS-Sync01 to an Azure file share named cloudshare1 in the storage account. Which of the following represents the correct sequence of steps to configure Azure File Sync and establish synchronization?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Install the Azure File Sync agent on the server, register the server with the Storage Sync Service, create a sync group, add the Azure file share as a cloud endpoint, and then add the local path as a server endpoint.
Establishing Azure File Sync requires a sequential configuration path. The agent must first be installed on the local Windows Server to enable communication and registration tools. Once installed, the server is registered to the Storage Sync Service. Within the Storage Sync Service, a sync group must be created to define the topology. The Azure file share is then added as the cloud endpoint. Finally, the local directory on the registered server is added as a server endpoint to begin synchronization.

Step-by-Step Solution

1
Install the Azure File Sync agent on FS-Sync01.
The Server Registration Utility is installed and ready for execution.
The local server cannot communicate with the Storage Sync Service or run registration utilities until the agent package is installed.
2
Register the Windows Server (FS-Sync01) with the Storage Sync Service (SyncService1).
FS-Sync01 is listed as a registered server in the Azure Portal under SyncService1.
Server registration establishes a trust relationship between the on-premises server and Azure.
3
Create a sync group inside SyncService1.
A sync group is created to manage sync topology.
Endpoints must belong to a sync group, which coordinates the sync relationship between the Azure file share and local folders.
4
Add the Azure file share (cloudshare1) as a cloud endpoint in the sync group.
The cloud endpoint is linked to the sync group.
Azure File Sync enforces that a cloud endpoint must be added to the sync group before any server endpoints can be added.
5
Add D:\SharedData as a server endpoint in the sync group.
The folder path is registered as a server endpoint and data sync initiates.
The server endpoint links a specific folder on a registered server to the sync group, completing the configuration.

Key Concept

Azure File Sync Deployment Sequence
Estimated Time:2m 0s
Question 654Question →

An enterprise deploys a virtual network named `VNet-Prod` containing two subnets: `Subnet-App` (172.16.1.0/24172.16.1.0/24) and `Subnet-Data` (172.16.2.0/24172.16.2.0/24). A virtual machine named `VM-Web` resides in `Subnet-App`, and its network interface `NIC-Web` is associated with an Application Security Group named `ASG-Web` and a Network Security Group named `NSG-NIC-Web`. Another virtual machine named `VM-DB` resides in `Subnet-Data`, and its network interface `NIC-DB` is associated with an Application Security Group named `ASG-DB`. `Subnet-App` is associated with a Network Security Group named `NSG-Subnet-App`.

The inbound security rules for `NSG-Subnet-App` are configured as follows:
- Priority: 130130 | Source: 172.16.2.0/24172.16.2.0/24 | Port: 443443 | Destination: `ASG-Web` | Action: Allow

The inbound security rules for `NSG-NIC-Web` are configured as follows:
- Priority: 110110 | Source: `ASG-DB` | Port: 443443 | Destination: * | Action: Deny
- Priority: 210210 | Source: 172.16.2.10172.16.2.10 (the static IP of `VM-DB`) | Port: 443443 | Destination: * | Action: Allow

What is the result when `VM-DB` attempts to establish an HTTPS connection (TCP port 443443) to `VM-Web`?

Show answer & explanation

Answer: The connection is blocked by NSG-NIC-Web because the deny rule at priority 110110 evaluates before the allow rule at priority 210210.

Answer

The connection is blocked by NSG-NIC-Web because the deny rule at priority 110110 evaluates before the allow rule at priority 210210.
In Azure, inbound traffic is first evaluated by the subnet-level NSG and then by the network interface-level (NIC) NSG. The traffic must be allowed by both levels to succeed. At the subnet level, the rule at priority 130130 allows traffic from 172.16.2.0/24172.16.2.0/24 to the ASG-Web. At the NIC level, rules are processed in priority order (lower numbers first). The deny rule at priority 110110 matches VM-DB (which is associated with ASG-DB) and immediately blocks the traffic, preventing the allow rule at priority 210210 from being evaluated.

Step-by-Step Solution

1
Evaluate the subnet-level NSG (NSG-Subnet-App) for inbound traffic.
The traffic is allowed at the subnet level because VM-DB's IP address (172.16.2.10172.16.2.10) belongs to the 172.16.2.0/24172.16.2.0/24 subnet range defined in the rule with priority 130130, and VM-Web's NIC is associated with ASG-Web.
Azure evaluates subnet-level NSG inbound rules before network interface-level rules.
2
Evaluate the network interface-level NSG (NSG-NIC-Web) for inbound traffic.
The traffic matches both the rule at priority 110110 (source ASG-DB, which contains VM-DB's NIC-DB) and the rule at priority 210210 (source 172.16.2.10172.16.2.10).
After passing the subnet-level NSG, the traffic is processed by the network interface-level NSG rules.
3
Determine the winning rule based on priority in NSG-NIC-Web.
The rule with priority 110110 (Deny) is applied because it has a lower priority number (higher precedence) than the rule with priority 210210 (Allow).
Azure processes security rules sequentially from lowest priority number to highest, and stops processing once a match is found.

Key Concept

Inbound NSG rules are evaluated first at the subnet level, then at the network interface (NIC) level, and rules within each NSG are processed in ascending order of their priority numbers.
Question 655Question →

An administrator is configuring autoscaling for an Azure Virtual Machine Scale Set (VMSS) named `vmss-commerce`. The web application hosted on the scale set experiences rapid traffic fluctuations. To prevent rapid, continuous scaling actions (thrashing), which of the following settings should you configure? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Set a cool-down period of 10 minutes or more to allow the system to stabilize before subsequent scale actions.; Maintain a wide margin between the scale-out (80%) and scale-in (30%) CPU thresholds.

Answer

To prevent thrashing in a Virtual Machine Scale Set, you should configure an adequate cool-down period and maintain a wide margin between the scale-out and scale-in thresholds.
Configuring a cool-down period ensures the system waits for the metrics to stabilize after a scale event before taking another action. Additionally, keeping a wide margin between scale-out (80%) and scale-in (30%) thresholds prevents the addition of a new instance from immediately lowering the average CPU level enough to trigger a scale-in operation.

Step-by-Step Solution

1
Analyze the scaling thresholds to ensure the scale-out and scale-in values are not too close, avoiding situations where adding an instance reduces the load per instance enough to immediately trigger a scale-in.
You identify that a wide margin (such as 80% for scale-out and 30% for scale-in) prevents immediate reverse actions.
This establishes a stable operating range for the scale set.
2
Configure the cool-down period setting on both the scale-out and scale-in rules.
The scale set waits for the specified duration (e.g., 10 minutes) after any scaling event before evaluating the metrics again.
This allows new instances time to start up and begin processing load, ensuring the metrics reflect the new state of the scale set before further scaling occurs.

Key Concept

Instance thrashing in Virtual Machine Scale Sets occurs when scale-out and scale-in actions trigger continuously in a loop. To mitigate this, administrators must configure appropriate cool-down durations and maintain a sufficient gap between scale-out and scale-in metric thresholds.
Estimated Time:1m 30s
Question 656Question →

An organization is configuring governance controls across their Azure subscriptions. Match each Azure Policy effect to the correct operational behavior that occurs during resource creation or update.

Click a left item, then click its matching right item

Items

Deny
Audit
Modify
DeployIfNotExists

Matches

Show answer & explanation

Answer

Deny matches blocking resource deployment requests; Audit matches allowing resource deployment but generating a non-compliance event; Modify matches applying defined tag or property updates before processing; DeployIfNotExists matches executing a nested Resource Manager template for remediation after successful deployment.
The correct pairings align each policy effect with its exact evaluation phase and system behavior: Deny blocks the request; Audit creates a compliance log without blocking; Modify alters properties before creation; and DeployIfNotExists deploys a template to remediate after creation.

Step-by-Step Solution

1
Determine the evaluation timing of each policy effect relative to the resource provider processing phase.
Deny, Audit, and Modify are evaluated and run before the resource provider processes the deployment. DeployIfNotExists is evaluated and runs after a successful resource creation or update.
This splits the effects into pre-deployment and post-deployment categories.
2
Distinguish between the outcomes of pre-deployment effects.
Deny blocks the deployment. Audit allows the deployment but creates a warning log. Modify alters tags/properties before the resource is deployed.
This maps the specific actions of Deny, Audit, and Modify to their descriptions.
3
Identify the remediation capability of DeployIfNotExists.
DeployIfNotExists runs a nested ARM template to install components or configure settings after the resource is created.
This matches the post-deployment effect to its template-based remediation behavior.

Key Concept

Azure Policy effects define the actions taken when resource properties match the rule conditions of a policy definition.
Question 657Question →

Your company has an Azure subscription containing three virtual networks named VNetA, VNetB, and VNetC. VNetA is peered with VNetB, and VNetB is peered with VNetC. There is no direct peering between VNetA and VNetC. You create two Azure Private DNS zones named corp.contoso.com and dev.local. Virtual machines are deployed in all three virtual networks. You need to implement a DNS configuration that meets the following requirements:
- Virtual machines in VNetA must automatically register their DNS records in corp.contoso.com.
- Virtual machines in VNetB must automatically register their DNS records in dev.local.
- Virtual machines in VNetB and VNetC must be able to resolve DNS names in corp.contoso.com.
- Virtual machines in VNetC must be able to resolve DNS names in dev.local.

Which two virtual network link configurations should you perform to meet these requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure a virtual network link from corp.contoso.com to VNetA with auto-registration enabled, and configure virtual network links from corp.contoso.com to VNetB and VNetC with auto-registration disabled.; Configure a virtual network link from dev.local to VNetB with auto-registration enabled, and configure a virtual network link from dev.local to VNetC with auto-registration disabled.

Answer

Configure a virtual network link from corp.contoso.com to VNetA with auto-registration enabled, and configure virtual network links from corp.contoso.com to VNetB and VNetC with auto-registration disabled. Also, configure a virtual network link from dev.local to VNetB with auto-registration enabled, and configure a virtual network link from dev.local to VNetC with auto-registration disabled.
To satisfy the requirements, the virtual networks must be linked directly to the private DNS zones. Because VNetA must auto-register in corp.contoso.com, its link to that zone must have auto-registration enabled. Since VNetB must auto-register in dev.local, its link to dev.local must have auto-registration enabled. The remaining resolution requirements (VNetB and VNetC resolving corp.contoso.com, and VNetC resolving dev.local) must be met using links with auto-registration disabled, as a virtual network cannot have auto-registration enabled for more than one zone. Since DNS resolution is not transitive over virtual network peering, direct links with auto-registration disabled are required for VNetC to resolve both zones, and for VNetB to resolve corp.contoso.com.

Step-by-Step Solution

1
Determine the auto-registration requirements for each virtual network.
Identify that VNetA must register in corp.contoso.com, and VNetB must register in dev.local.
Azure Private DNS allows a virtual network to be linked to only one private DNS zone with auto-registration enabled.
2
Determine the DNS resolution requirements for each virtual network.
Identify that VNetB and VNetC require name resolution for corp.contoso.com, and VNetC requires name resolution for dev.local.
DNS resolution is not transitive across peered virtual networks. Each VNet that requires name resolution must have an explicit virtual network link to the Private DNS zone.
3
Define the link types (registration vs. resolution-only) for each zone and VNet.
Create registration links for corp.contoso.com to VNetA, and dev.local to VNetB. Create resolution-only links (auto-registration disabled) for corp.contoso.com to VNetB and VNetC, and for dev.local to VNetC.
This satisfies all auto-registration and resolution requirements while adhering to the one-registration-link limit per VNet and ensuring all networks can resolve target zones.

Key Concept

Azure Private DNS Virtual Network Links and Auto-registration Constraints
Estimated Time:3m 0s
Question 658Question →

An administrator is planning the deployment of a new virtual network named `vnet-prod` to support a web application and secure administrative access. The virtual network is assigned the address space 10.200.0.0/2210.200.0.0/22.

The administrator must configure three subnets within `vnet-prod` to meet the following requirements:
- A subnet for the web application servers that must support up to 5858 concurrent virtual machines.
- A subnet for Azure Bastion to allow secure administration.
- A subnet for a database tier that must support up to 44 virtual machines.

The administrator wants to minimize IP address space waste and allocate the smallest possible CIDR blocks that satisfy these requirements.

Which of the following subnet configurations should the administrator use?

Show answer & explanation

Answer: AzureBastionSubnet: 10.200.0.0/2610.200.0.0/26; Subnet-Web: 10.200.0.64/2610.200.0.64/26; Subnet-DB: 10.200.0.128/2810.200.0.128/28

Answer

AzureBastionSubnet: 10.200.0.0/26; Subnet-Web: 10.200.0.64/26; Subnet-DB: 10.200.0.128/28
The configuration specifying AzureBastionSubnet at 10.200.0.0/2610.200.0.0/26, Subnet-Web at 10.200.0.64/2610.200.0.64/26, and Subnet-DB at 10.200.0.128/2810.200.0.128/28 is correct because it satisfies all naming, sizing, and usability constraints: first, the Azure Bastion subnet is named exactly `AzureBastionSubnet` and is sized at `/26` (the minimum supported size); second, the web subnet is sized at `/26` (providing 64−5=5964 - 5 = 59 usable IPs), which is the smallest CIDR block that can accommodate 5858 virtual machines; third, the database subnet is sized at `/28` (providing 16−5=1116 - 5 = 11 usable IPs), which is the smallest CIDR block that can accommodate 44 virtual machines since a `/29` would only provide 33 usable IPs.

Step-by-Step Solution

1
Determine the naming and size requirements for the Azure Bastion subnet.
The subnet must be named exactly `AzureBastionSubnet` and have a prefix size of `/26` or larger.
Azure requires this specific configuration to deploy and scale the Azure Bastion resource.
2
Calculate the minimum subnet size for the web application servers.
A `/26` subnet is required.
The web tier requires 5858 VM IPs plus 55 Azure-reserved IPs, totaling 6363 IP addresses. A `/26` subnet provides 6464 IP addresses (5959 usable), whereas a `/27` subnet only provides 3232 IP addresses (2727 usable).
3
Calculate the minimum subnet size for the database tier.
A `/28` subnet is required.
The database tier requires 44 VM IPs plus 55 Azure-reserved IPs, totaling 99 IP addresses. A `/28` subnet provides 1616 IP addresses (1111 usable), whereas a `/29` subnet only provides 88 IP addresses (33 usable).

Key Concept

Azure Virtual Network subnets reserve 5 IP addresses (the first four and the last one). Therefore, the capacity calculation must always be: Usable IPs = Total IPs - 5. Furthermore, specialized subnets like Azure Bastion have strict minimum sizes (/26) and naming requirements.
Question 659Question →

You are planning the deployment of three separate enterprise workloads using Azure Container Instances (ACI). You need to configure the appropriate restart policy for each workload to ensure optimal behavior and cost efficiency. Match each workload requirement to the correct Container Instance restart policy configuration.

Click a left item, then click its matching right item

Items

A front-end dashboard application designed to display real-time telemetry metrics that must be highly available to administrators.
A nightly extract-transform-load (ETL) pipeline that processes a queue of log files and should only retry if it terminates with an error code.
A custom diagnostic utility that runs a network discovery scan and must be prevented from executing again, even if it fails due to network timeouts, to avoid duplicate firewall alerts.

Matches

Show answer & explanation

Answer

The telemetry dashboard matches the Always restart policy. The nightly ETL pipeline matches the OnFailure restart policy. The network discovery scan matches the Never restart policy.
The telemetry dashboard is a continuous application requiring Always to ensure high availability. The nightly ETL pipeline is a batch task that needs to run to completion and retry only on failure, matching OnFailure. The network discovery scan must run only once and never retry, matching Never.

Step-by-Step Solution

1
Analyze the uptime and operational requirements of the telemetry dashboard workload.
Identify that the dashboard is a continuous, user-facing application that must be kept running indefinitely.
For continuous services, Azure Container Instances (ACI) requires a restart policy that restarts the container if it stops for any reason, which corresponds to the Always policy.
2
Determine the execution lifecycle and failure-handling requirements of the nightly ETL pipeline.
Identify that the ETL pipeline is a batch workload that runs until completion and must only retry in the event of an execution failure.
The OnFailure restart policy ensures that ACI does not restart the container group upon successful completion (exit code 0) but will automatically restart it if it exits with an error (non-zero exit code).
3
Evaluate the execution constraints of the network discovery scan utility.
Determine that the scan must execute a maximum of one time and must not attempt automatic retries, regardless of whether the execution succeeded or failed.
The Never restart policy guarantees that the container group is never restarted by Azure once it exits, preventing duplicate executions.

Key Concept

Selecting and configuring the appropriate restart policy (Always, Never, or OnFailure) in Azure Container Instances based on workload execution characteristics.
Estimated Time:2m 0s
Question 660Question →

An enterprise Azure environment is configured with a virtual network named `VNet1` (10.0.0.0/1610.0.0.0/16) that contains the following subnets:
- `Subnet-Web` (10.0.1.0/2410.0.1.0/24)
- `Subnet-App` (10.0.2.0/2410.0.2.0/24)
- `Subnet-DB` (10.0.3.0/2410.0.3.0/24)
- `Subnet-Sec` (10.0.10.0/2410.0.10.0/24)

A Network Virtual Appliance (NVA) named `Sec-NVA` is deployed in `Subnet-Sec` with the private IP address 10.0.10.410.0.10.4.

You need to configure routing for `Subnet-Web` to meet the following requirements:
1. All traffic sent to `Subnet-App` must be routed through the NVA.
2. All traffic sent to the specific IP range 10.0.2.128/2610.0.2.128/26 within `Subnet-App` must bypass the NVA and route directly.
3. All other traffic to `VNet1` subnets must route directly via default routing.
4. All outbound traffic to the Internet must route through the NVA.

Which combination of route entries and network interface configurations on `Sec-NVA` will meet these requirements?

Show answer & explanation

Answer: Configure three routes in the route table associated with `Subnet-Web`:
- Destination: 0.0.0.0/00.0.0.0/0, Next hop type: Virtual appliance, Next hop IP: 10.0.10.410.0.10.4
- Destination: 10.0.2.0/2410.0.2.0/24, Next hop type: Virtual appliance, Next hop IP: 10.0.10.410.0.10.4
- Destination: 10.0.2.128/2610.0.2.128/26, Next hop type: Virtual network
And enable IP forwarding on the network interface of `Sec-NVA`.

Answer

The configuration that sets 0.0.0.0/00.0.0.0/0 and 10.0.2.0/2410.0.2.0/24 to route to the Virtual appliance at 10.0.10.410.0.10.4, sets 10.0.2.128/2610.0.2.128/26 to route to the Virtual network, and enables IP forwarding on the network interface of the NVA.
The correct option sets the route for 10.0.2.0/2410.0.2.0/24 to the Virtual appliance (10.0.10.410.0.10.4), overrides it for the specific sub-range 10.0.2.128/2610.0.2.128/26 by setting the next hop to Virtual network (exploiting the Longest Prefix Match rule), routes the Internet traffic (0.0.0.0/00.0.0.0/0) to the NVA, and enables IP forwarding on the NVA's network interface to authorize transit routing.

Step-by-Step Solution

1
Determine how to route the general subnet traffic and the bypass subnet range.
Create a route for 10.0.2.0/2410.0.2.0/24 with the next hop set to the NVA's IP (10.0.10.410.0.10.4). To allow the subset range 10.0.2.128/2610.0.2.128/26 to bypass the NVA, define a more specific route pointing to 'Virtual network' as the next hop.
Azure routing uses the Longest Prefix Match (LPM) rule. A route with a /26 prefix is more specific than a /24 prefix. Therefore, traffic for 10.0.2.128/2610.0.2.128/26 will match the /26 route and bypass the NVA, while all other traffic in 10.0.2.0/2410.0.2.0/24 matches the /24 route and goes to the NVA.
2
Identify the correct next hop type for routing traffic through the firewall appliance.
Select 'Virtual appliance' as the next hop type and specify the NVA private IP address (10.0.10.410.0.10.4).
Azure requires the 'Virtual appliance' next hop type when routing traffic to custom firewalls or routing NVAs.
3
Ensure the NVA can forward traffic not destined for its own IP address.
Enable IP forwarding on the network interface (NIC) associated with `Sec-NVA` in Azure.
By default, Azure VMs drop network traffic that does not originate from or terminate at their own private IP address. Enabling IP forwarding allows the NVA to act as a transit router.

Key Concept

Azure User-Defined Routes (UDR) prioritize custom routes over system routes. When multiple routes match a destination, the Longest Prefix Match (LPM) rule dictates the path. Network Virtual Appliances require IP forwarding enabled on their network interface to forward transit traffic.
PreviousPage 33 / 63Next
All practice questions — Microsoft Azure Administrator (AZ-104) | Examkin