Examkin

All practice questions

1252 questions

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

Zenix Solutions has an Azure subscription named sub-zenix-prod. You deploy an Azure Storage account named sazenixprod and an Azure Key Vault named kv-zenix-secure.

The Key Vault is configured as follows:
- Permission model: Azure role-based access control (Azure RBAC)
- Soft-delete: Enabled
- Purge protection: Enabled

You create a user-assigned managed identity named uami-zenix-storage. You plan to configure customer-managed keys (CMK) for encryption on sazenixprod using uami-zenix-storage to access the keys in kv-zenix-secure.

Which two actions should you perform to configure customer-managed key encryption? Select two.

Select all that apply

Show answer & explanation

Answer: Associate the user-assigned managed identity uami-zenix-storage with the storage account sazenixprod.; Assign the Key Vault Crypto Service Encryption User role on kv-zenix-secure to uami-zenix-storage.

Answer

Associate the user-assigned managed identity with the storage account, and assign the Key Vault Crypto Service Encryption User role on the Key Vault to the user-assigned managed identity.
To successfully configure customer-managed keys for an Azure Storage account using a user-assigned managed identity and a Key Vault that uses Azure RBAC, you must first associate the user-assigned managed identity with the storage account. Second, you must grant the identity data-plane access to the Key Vault. The Key Vault Crypto Service Encryption User role is the specific role designed for storage account encryption operations as it permits wrapping and unwrapping key actions.

Step-by-Step Solution

1
Associate the identity
The user-assigned managed identity uami-zenix-storage is linked to the storage account sazenixprod.
This allows the storage account to use the user-assigned managed identity's credentials when requesting operations from Azure Key Vault.
2
Grant RBAC permissions on the Key Vault
The managed identity is assigned the Key Vault Crypto Service Encryption User role on kv-zenix-secure.
Because the Key Vault uses Azure RBAC, the identity must have explicit data-plane permissions (specifically wrap/unwrap key actions) to perform the cryptographic operations required for storage encryption.

Key Concept

Configuring Customer-Managed Keys (CMK) for Azure Storage using a user-assigned managed identity and an Azure RBAC-enabled Azure Key Vault.
Question 722Question →

An administrator is deploying a new version of a web application to an Azure App Service web app. The application is currently running in a staging deployment slot and needs to be swapped into the production slot. You need to configure a swap operation that allows you to test the new code under production configuration settings (such as connection strings and application settings) before any client traffic is routed to the new version.

Which sequence of actions should you perform to complete this process?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of actions is: Navigate to the Deployment slots page and select Swap; configure the swap settings for a Swap with preview from staging to production; start the swap to apply target settings to the source slot; browse the staging slot URL to verify application functionality; and finally, complete the swap to route production traffic.
Starting a swap with preview applies the configuration of the target slot to the source slot, allowing validation before the final code swap occurs. Testing must be performed on the source slot while in this preview state before finalizing (completing) the swap or cancelling it.

Step-by-Step Solution

1
Navigate to the App Service page, select Deployment slots, and click Swap.
The Swap configuration dialog opens.
This initiates the configuration wizard for swapping slots.
2
Set the swap type to Swap with preview, select staging as the source, and production as the target.
The configuration is set to deploy the source slot code under target slot settings without executing a full cutover.
This specifies that we want to validate the target slot settings on our staging code before going live.
3
Click Start Swap.
The staging slot restarts with production configuration settings applied.
This applies the target slot configurations (such as connection strings and app settings) to the staging slot so it behaves as if it were in production.
4
Browse to the staging slot's URL and test the application.
The application's behavior is verified using the production configuration settings.
This ensures the application is running correctly under production settings before changing DNS/routing settings.
5
Go back to the Swap dialog and select Complete Swap.
The swap operation completes, routing production traffic to the staging slot code (which is now in the production slot).
This completes the swap, making the new deployment live.

Key Concept

Azure App Service Deployment Slots Swap with Preview workflow
Estimated Time:2m 0s
Question 723Question →

An Azure administrator configures a hub-and-spoke network topology. The hub virtual network is named VNet-Hub (10.10.0.0/1610.10.0.0/16) and contains an active VPN gateway. Two spoke virtual networks, named VNet-Spoke1 (10.20.0.0/1610.20.0.0/16) and VNet-Spoke2 (10.30.0.0/1610.30.0.0/16), have virtual machines deployed in their respective subnets. The administrator configures bidirectional virtual network peering between VNet-Spoke1 and VNet-Hub, enabling 'Allow gateway transit' on the VNet-Hub side and 'Use remote gateways' on the VNet-Spoke1 side. Similarly, bidirectional virtual network peering is configured between VNet-Spoke2 and VNet-Hub, enabling 'Allow gateway transit' on the VNet-Hub side and 'Use remote gateways' on the VNet-Spoke2 side. There is no direct peering between VNet-Spoke1 and VNet-Spoke2, and no network virtual appliances (NVAs) are deployed.

Statement: Under this configuration, a virtual machine in VNet-Spoke1 can communicate directly with a virtual machine in VNet-Spoke2 by routing traffic through the VNet-Hub gateway.

Show answer & explanation

Answer: False

Answer

The statement is false. Virtual network peering in Azure is non-transitive, and configuring gateway transit does not enable routing of traffic between two peered spoke networks through the hub gateway.
The statement is false because Azure virtual network peering is strictly non-transitive. Configuring 'Allow gateway transit' and 'Use remote gateways' allows the spokes to share the hub's VPN gateway to communicate with on-premises networks, but it does not route traffic between spokes. Spoke-to-spoke communication requires direct peering between the spokes or a custom routing solution using a Network Virtual Appliance (NVA) and User-Defined Routes (UDRs).

Step-by-Step Solution

1
Analyze the network topology and peering connections.
VNet-Spoke1 is peered to VNet-Hub, and VNet-Spoke2 is peered to VNet-Hub. There is no direct peering between VNet-Spoke1 and VNet-Spoke2.
To determine the available physical or logical network paths.
2
Evaluate the transit behavior of Azure Virtual Network Peering.
Peering is non-transitive. Traffic from VNet-Spoke1 cannot transit through VNet-Hub to reach VNet-Spoke2 unless an NVA or Azure Firewall is deployed in VNet-Hub to route the traffic.
To determine if hub-and-spoke peering enables automatic spoke-to-spoke connectivity.
3
Determine the function of the 'Allow gateway transit' and 'Use remote gateways' settings.
These settings only permit peered virtual networks to share a VPN or ExpressRoute gateway in VNet-Hub to reach on-premises networks; they do not facilitate routing between spokes.
To assess if the gateway configuration overrides the non-transitive nature of peering for inter-spoke traffic.

Key Concept

Azure Virtual Network Peering non-transitivity and gateway transit configuration.
Question 724Question →

An administrator creates a resource group named rg-db-migration and applies a tag named CostCenter: Migrations and a CanNotDelete resource lock to it. Within rg-db-migration, the administrator deploys an Azure SQL Database named sqldb-prod. An Azure Policy is assigned to the subscription that audits any resource lacking the CostCenter tag. In this scenario, the sqldb-prod database will be flagged as non-compliant by Azure Policy, and authorized users are prevented from deleting sqldb-prod unless the resource lock on rg-db-migration is removed.

Show answer & explanation

Answer: True

Answer

The statement is true.
The correct evaluation shows that tags are not inherited, causing the database to be non-compliant with the auditing policy, while locks are inherited, preventing deletion of the database.

Step-by-Step Solution

1
Evaluate the tag inheritance behavior for the Azure SQL Database resource inside the resource group.
The sqldb-prod database does not inherit the CostCenter: Migrations tag from the rg-db-migration resource group.
Azure resource tags applied at the resource group level do not automatically inherit to individual child resources.
2
Determine the compliance status of the database against the assigned Azure Policy.
The sqldb-prod database is flagged as non-compliant.
The policy audits resources lacking the CostCenter tag. Since the database did not inherit the tag and does not have it explicitly applied, it lacks the required tag.
3
Evaluate the resource lock inheritance behavior for the database.
The sqldb-prod database inherits the CanNotDelete lock from the rg-db-migration resource group.
Resource locks applied at the resource group level are inherited by all child resources within that group.

Key Concept

Resource lock and tag inheritance rules in Azure governance
Question 725Question →

An administrator manages an Azure subscription containing a virtual network named `VNet1`. `VNet1` contains two subnets: `Subnet-Web` (10.0.1.0/2410.0.1.0/24) and `Subnet-App` (10.0.2.0/2410.0.2.0/24).

A virtual machine named `VM-Web` is deployed in `Subnet-Web` and has a network interface named `NIC-Web`. A Network Security Group (NSG) named `NSG-Subnet` is associated with `Subnet-Web`. A second NSG named `NSG-NIC` is associated with `NIC-Web`.

`NSG-Subnet` contains the following inbound security rule:
* Priority: 110110, Source: 10.0.2.0/2410.0.2.0/24, Port: 8080, Protocol: TCP, Action: Allow

`NSG-NIC` contains the following inbound security rules:
* Priority: 120120, Source: Any, Port: 8080, Protocol: TCP, Action: Deny
* Priority: 130130, Source: 10.0.2.410.0.2.4, Port: 8080, Protocol: TCP, Action: Allow

A virtual machine named `VM-App` is deployed in `Subnet-App` with the IP address 10.0.2.410.0.2.4.

If `VM-App` attempts to establish an HTTP connection to `VM-Web` on TCP port 8080, what is the outcome of this connection attempt?

Show answer & explanation

Answer: The connection is blocked by `NSG-NIC` because the Deny rule with priority 120120 takes precedence over the Allow rule with priority 130130.

Answer

The connection is blocked by `NSG-NIC` because the Deny rule with priority 120120 takes precedence over the Allow rule with priority 130130.
For inbound traffic, Azure processes the subnet-level NSG first, followed by the NIC-level NSG. The traffic successfully passes the subnet NSG because of the rule at priority 110110. However, when the traffic reaches the NIC NSG, it is matched against the rule with priority 120120 (Deny) before the rule with priority 130130 (Allow) because lower priority numbers have higher precedence. As a result, the connection is blocked at the network interface level.

Step-by-Step Solution

1
Determine the evaluation order for inbound traffic to the destination virtual machine.
Inbound traffic is evaluated first by the Network Security Group associated with the subnet (`NSG-Subnet`), and then by the Network Security Group associated with the network interface (`NSG-NIC`).
Azure processes security rules sequentially from the subnet boundary to the network interface boundary for inbound flows.
2
Evaluate the traffic against the rules in `NSG-Subnet`.
The rule with priority 110110 allows TCP traffic on port 8080 from the source range 10.0.2.0/2410.0.2.0/24. Since `VM-App` has the IP address 10.0.2.410.0.2.4, the traffic matches this rule and is allowed past the subnet layer.
The source IP falls within the CIDR block defined in the rule.
3
Evaluate the traffic against the rules in `NSG-NIC` by priority order.
The rule with priority 120120 (Deny, Source: Any, Port: 8080) is evaluated before the rule with priority 130130 (Allow, Source: 10.0.2.410.0.2.4, Port: 8080). The priority 120120 rule matches the traffic and applies the Deny action, blocking the connection.
Within a single NSG, rules are evaluated in order of ascending priority numbers (lower numbers represent higher precedence). Once a matching rule is found, subsequent rules are not processed.

Key Concept

Azure Network Security Group (NSG) inbound traffic evaluation order (subnet-level before NIC-level) and internal rule precedence based on priority numbers.
Question 726Question →

An administrator is configuring network security for an Azure subscription containing a virtual network named `VNet1`. `VNet1` contains two subnets: `Subnet-Web` (10.0.1.0/2410.0.1.0/24) and `Subnet-DB` (10.0.2.0/2410.0.2.0/24).

* `VM-Web1` is deployed in `Subnet-Web`, and its network interface is associated with an Application Security Group (ASG) named `ASG-Web`.
* `VM-DB1` is deployed in `Subnet-DB`, and its network interface is associated with an ASG named `ASG-DB`.
* A Network Security Group (NSG) named `NSG-Subnet` is associated with both `Subnet-Web` and `Subnet-DB`. `NSG-Subnet` contains a custom inbound rule named `Deny-CrossSubnet` with a priority of 200200 that denies all traffic between the two subnets.
* An NSG named `NSG-NIC` is associated only with the network interface of `VM-DB1`. `NSG-NIC` contains a custom inbound rule named `Deny-SQL` with a priority of 300300 that denies inbound TCP traffic on port 14331433 from any source.

You need to allow `VM-Web1` to establish a database connection to `VM-DB1` on TCP port 14331433. The solution must follow the principle of least privilege.

Which two security rules should you add to achieve this goal? (Select TWO)

Select all that apply

Show answer & explanation

Answer: In `NSG-Subnet`, add an inbound rule with a priority of 150150 that allows TCP traffic on port 14331433 from `ASG-Web` to `ASG-DB`.; In `NSG-NIC`, add an inbound rule with a priority of 250250 that allows TCP traffic on port 14331433 from `ASG-Web` to `ASG-DB`.

Answer

To allow the connection under the principle of least privilege, you must add an inbound rule to `NSG-Subnet` with a priority of 150150 allowing TCP port 14331433 from `ASG-Web` to `ASG-DB`, and an inbound rule to `NSG-NIC` with a priority of 250250 allowing TCP port 14331433 from `ASG-Web` to `ASG-DB`.
For inbound traffic to reach a virtual machine associated with both a subnet NSG and a NIC NSG, the traffic must be allowed by both security boundaries. Since custom rules in both the subnet-level NSG (priority 200) and the NIC-level NSG (priority 300) currently deny this traffic, we must add an allow rule in each NSG. To override the existing deny rules, the new rules must have higher precedence (lower priority numbers, such as 150 for NSG-Subnet and 250 for NSG-NIC) and target the correct traffic flow from the web server's ASG to the database server's ASG on TCP port 1433.

Step-by-Step Solution

1
Analyze the outbound traffic path from VM-Web1.
Outbound traffic from VM-Web1 is evaluated by the outbound rules of NSG-Subnet (since VM-Web1 has no NIC-level NSG). There are no custom outbound deny rules, so the default AllowVNetOutBound rule allows the outbound traffic.
Azure processes security rules sequentially starting with the subnet-level NSG for outbound traffic, then the NIC-level NSG.
2
Evaluate the inbound traffic path at the subnet level for VM-DB1.
The traffic is blocked by the Deny-CrossSubnet rule (priority 200) in NSG-Subnet.
An inbound security rule with a lower priority number (higher precedence) than 200 must be added to NSG-Subnet to explicitly allow the traffic.
3
Evaluate the inbound traffic path at the NIC level for VM-DB1.
The traffic is blocked by the Deny-SQL rule (priority 300) in NSG-NIC.
An inbound security rule with a lower priority number (higher precedence) than 300 must be added to NSG-NIC to explicitly allow the traffic.

Key Concept

Azure Network Security Group (NSG) rule processing hierarchy (subnet-level then NIC-level for inbound traffic), rule priority evaluation (lower numbers take precedence), and the use of Application Security Groups (ASGs) to define granular source/destination filters.
Estimated Time:2m 30s
Question 727Question →

A company's Azure environment contains two subnets named Subnet1 and Subnet2.
Subnet1 is associated with a Network Security Group (NSG) named NSG1.
Subnet1 contains two virtual machines named VM1 and VM2. The network interface of VM1 is associated with an Application Security Group (ASG) named ASG-Web. The network interface of VM2 is associated with an ASG named ASG-App.

NSG1 has the following inbound security rules:
- Rule1: Priority 120120, Source: Any, Destination: ASG-Web, Port: 8080, Action: Deny
- Rule2: Priority 180180, Source: Any, Destination: ASG-Web, Port: 8080, Action: Allow

You need to allow inbound HTTP traffic on port 8080 from the internet to VM1, while ensuring that security configurations for VM2 are not altered.

Which configuration change should you perform?

Show answer & explanation

Answer: Change the priority of Rule2 to 110110.

Answer

Change the priority of Rule2 to 110110.
In Azure Network Security Groups, rules are evaluated sequentially based on their priority values, with lower numerical values receiving higher precedence. Currently, the Deny rule (Rule1) has a priority of 120, which is lower than the Allow rule (Rule2) with a priority of 180. As a result, the Deny rule is processed first and blocks the traffic. By changing the priority of the Allow rule (Rule2) to 110, it is evaluated before the Deny rule, allowing the inbound HTTP traffic to reach the destination interface associated with the target application security group.

Step-by-Step Solution

1
Analyze how Azure Network Security Group (NSG) rules are evaluated.
NSG rules are processed in priority order, where lower numbers have higher precedence.
To determine which rule currently applies to the incoming traffic on port 80.
2
Evaluate the current rule precedence for traffic targeting VM1 (associated with ASG-Web) on port 80.
Rule1 (Deny, priority 120) takes precedence over Rule2 (Allow, priority 180) because 120 is less than 180. Thus, traffic is blocked.
To identify why the inbound HTTP traffic is currently failing to reach the virtual machine.
3
Identify the change required to make the Allow rule take precedence over the Deny rule.
The Allow rule must be assigned a priority number lower than 120. Changing Rule2's priority to 110 meets this requirement.
Assigning a lower priority number ensures the Allow rule is processed before the Deny rule.

Key Concept

Azure NSG rule processing order is determined by rule priority numbers, where smaller numbers represent higher precedence.
Estimated Time:45s
Question 728Question →

An administrator is configuring an Azure Virtual Machine Scale Set (VMSS) named vmss-retail that uses Uniform orchestration to run a web application. The administrator needs to configure the VMSS to roll out application updates automatically when the VMSS model is updated. The configuration must meet the following requirements:
- Updates must be applied to instances gradually in batches.
- A subset of instances must remain available to serve traffic during the update.
- The update process must automatically pause if the new instances are unhealthy.
- No manual intervention should be required to promote the update across batches.
Which two options should the administrator configure to meet these requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: Set the VMSS upgrade policy mode to Rolling.; Associate an Application Health Extension or a Load Balancer health probe with the VMSS.

Answer

The administrator should set the upgrade policy mode to Rolling and associate an Application Health Extension or a Load Balancer health probe with the Virtual Machine Scale Set.
To meet the requirements, the VMSS upgrade policy mode must be set to Rolling. The Rolling upgrade policy applies updates to instances in batches. To monitor the health of these instances during the update and determine when to proceed to the next batch or pause, a health probe (either via Application Health Extension or a Load Balancer health probe) must be associated with the VMSS. This combination allows for zero-downtime, automated, health-aware deployments.

Step-by-Step Solution

1
Analyze the requirement for automatic, gradual, batch-based updates that pause upon health check failure.
Identify that the Rolling upgrade policy is designed specifically for this purpose, unlike Automatic or Manual upgrade modes.
Selecting the correct upgrade policy mode is the foundational configuration step.
2
Analyze the health monitoring requirement for the rolling update.
Determine that the Rolling upgrade policy requires a health mechanism, such as an Application Health Extension or a Load Balancer health probe, to evaluate instance health.
Without a configured health probe, the scale set cannot verify the health of the upgraded batch to safely proceed or pause the rollout.

Key Concept

Configuring Virtual Machine Scale Set upgrade policies and health probe dependencies for rolling upgrades.
Question 729Question →

An administrator is setting up a high-availability database server on an Azure virtual machine named VM-DBServer. The virtual machine has a single network interface named nic-db. Currently, VM-DBServer is in the backend pool of a Standard Load Balancer named LB-Database. To configure multiple database instances that require individual public-facing endpoints, the administrator needs to add a secondary IP configuration named ipconfig2 to nic-db and associate it with a public IP address named pip-db-sec. Which configuration must the administrator choose for pip-db-sec?

Show answer & explanation

Answer: Standard SKU and Static allocation

Answer

Standard SKU and Static allocation
The correct configuration requires a Standard SKU public IP address with a Static allocation method. Since the virtual machine is in the backend pool of a Standard Load Balancer, all public IP addresses associated with the virtual machine's network interfaces must use the Standard SKU. Furthermore, Standard SKU public IP addresses only support Static allocation; Dynamic allocation is not an option for Standard SKU public IPs.

Step-by-Step Solution

1
Identify that the virtual machine VM-DBServer is in the backend pool of a Standard Load Balancer (LB-Database).
Determine that all public IP addresses associated with VM-DBServer must use the Standard SKU to align with the Standard Load Balancer.
Azure enforces SKU alignment between a load balancer and any public IP addresses associated with resources in its backend pool.
2
Verify the allocation method requirement for Standard SKU public IP addresses.
Determine that the allocation method must be Static.
Standard SKU public IP addresses only support the Static allocation method in Azure; Dynamic allocation is unsupported.

Key Concept

SKU alignment and allocation rules for public IP addresses on virtual machines associated with a Standard Load Balancer
Question 730Question →

Your organization is designing an Azure governance strategy to enforce resource compliance. You need to map the operational requirements to the appropriate Azure Policy effects. Match each operational requirement on the left to its corresponding Azure Policy effect on the right.

Click a left item, then click its matching right item

Items

Automatically deploy a dependency resource, such as diagnostic settings, when a resource is created or updated.
Prevent resource creation or update requests that violate configuration standards.
Add or update specific properties or tags on a resource during creation or update.
Log a non-compliance warning event in the activity log without blocking resource deployment.

Matches

Show answer & explanation

Answer

DeployIfNotExists matches deploying diagnostic settings; Deny matches blocking resource creation; Modify matches adding or updating tags; Audit matches logging compliance warnings without blocking.
Each requirement is mapped to its correct Azure Policy effect based on their evaluation behavior: DeployIfNotExists handles nested deployment templates; Deny blocks the resource creation; Modify alters resource tags or properties during creation/update; Audit logs compliance warnings without altering the deployment flow.

Step-by-Step Solution

1
Analyze the operational requirement to deploy a dependency resource like diagnostic settings.
Identify that DeployIfNotExists is the policy effect designed to run a template deployment to create sub-resources or dependencies if they do not exist.
This matches the requirement for automatic remediation of sub-resources.
2
Analyze the requirement to prevent creation or update of resources that violate policies.
Identify that the Deny effect intercepts the resource provider request and fails the deployment immediately.
This satisfies the requirement to block non-compliant resource creation.
3
Analyze the requirement to add or update specific properties or tags during creation/update.
Identify that Modify is the modern policy effect used to alter tags or properties during the evaluation phase.
This allows updating or inserting tags on resources dynamically.
4
Analyze the requirement to log warning events without blocking.
Identify that the Audit effect evaluates the resource compliance and generates a warning event in the activity log without stopping the deployment.
This provides non-intrusive auditing.

Key Concept

Azure Policy effects define the behavior of resource compliance evaluation and enforcement.
Question 731Question →

An organization is setting up a private name resolution system in Azure. A Private DNS zone named corp.internal has been created. The IT team wants virtual machines in a virtual network named VNet-Core to automatically register their hostname and private IP addresses in this DNS zone.

Which setting must be configured to achieve this?

Show answer & explanation

Answer: A virtual network link from the corp.internal zone to VNet-Core with the auto-registration option enabled

Answer

A virtual network link from the corp.internal zone to VNet-Core with the auto-registration option enabled must be created.
To achieve both name resolution and automatic registration of virtual machines, a virtual network link must be created between the Private DNS zone and the virtual network with the auto-registration setting enabled. This configuration automatically creates A records for the virtual machines in the private zone when they are deployed.

Step-by-Step Solution

1
Identify the requirement for automatic hostname registration in the Private DNS zone.
Realize that Azure Private DNS requires a virtual network link with the auto-registration option active to perform this action.
Without a virtual network link, the virtual network has no association with the Private DNS zone.
2
Differentiate between name resolution and auto-registration.
Conclude that enabling auto-registration is specifically required to dynamically register VM hostnames, whereas a basic link only provides resolution.
Ensures that new VM deployments are dynamically updated in the zone without manual record creation.

Key Concept

Azure Private DNS Zone virtual network links and auto-registration
Estimated Time:1m 0s
Question 732Question →

An administrator is configuring customer-managed keys (CMK) for an Azure Storage account named saapexdata. The storage account has a system-assigned managed identity enabled. The key is stored in an Azure Key Vault named kv-apex-keys, which is configured to use the Azure role-based access control (Azure RBAC) permission model. Soft-delete and purge protection are already enabled on the Key Vault. Which role must be assigned to the storage account's managed identity over kv-apex-keys to allow encryption to function?

Show answer & explanation

Answer: Key Vault Crypto Service Encryption User

Answer

Key Vault Crypto Service Encryption User
The correct role is Key Vault Crypto Service Encryption User. Under the Azure RBAC authorization model, this role grants the required cryptographic data-plane operations (wrap key and unwrap key) to the managed identity of the storage account, enabling Azure Storage Service Encryption to encrypt and decrypt data using the customer-managed key.

Step-by-Step Solution

1
Identify the authorization model used by the Key Vault.
The Key Vault uses the Azure RBAC permission model instead of Vault Access Policies.
This determines how permissions to read and use the cryptographic keys must be granted.
2
Determine the cryptographic operations required by Azure Storage Service Encryption.
The storage account identity must be able to wrap and unwrap keys to perform envelope encryption.
Azure Storage uses envelope encryption where it encrypts data with a symmetric key and wraps that key using the customer-managed key.
3
Select the built-in role that offers the minimum required permissions for key usage.
The 'Key Vault Crypto Service Encryption User' role is identified as granting wrap and unwrap permissions.
Using built-in, least-privileged roles is a security best practice.

Key Concept

Assigning appropriate Azure RBAC roles to a storage account's managed identity for Key Vault access when configuring customer-managed keys (CMK).
Estimated Time:2m 0s
Question 733Question →

You are planning the deployment and configuration of several Azure virtual machines. Each virtual machine has specific performance, boot, or administration requirements. Match each virtual machine configuration requirement to its corresponding Azure virtual machine feature.

Click a left item, then click its matching right item

Items

Store the virtual machine operating system on the local host cache to achieve high-speed read/write access and eliminate remote storage costs, with the understanding that data is lost upon virtual machine deallocation.
Execute an administrative script on a running virtual machine using the VM Agent without provisioning any virtual machine extensions.
Enable support for Unified Extensible Firmware Interface (UEFI) boot architecture and provision virtual machine OS disks larger than 2 TB2\text{ TB}.
Capture serial console logs and virtual machine screenshots during the boot process to troubleshoot operating system startup failures.

Matches

Show answer & explanation

Answer

The correct matches pair the Ephemeral OS Disk with host-cache storage, Run Command with VM Agent script execution, Generation 2 Virtual Machine with UEFI and large OS disk support, and Boot Diagnostics with boot troubleshooting screenshots.
The correct pairings align the appropriate Azure VM configuration features to their respective operational goals: Ephemeral OS Disk for low-latency host-cache storage, Run Command for agent-based scripting, Generation 2 VMs for UEFI and large OS volumes, and Boot Diagnostics for visual boot troubleshooting.

Step-by-Step Solution

1
Identify the storage configuration that utilizes the physical host's local cache for the OS disk, which is the Ephemeral OS Disk feature.
Matched requirement 1 to Ephemeral OS Disk.
Ephemeral OS disks run on local host caching rather than remote Azure Storage.
2
Select the option that allows execution of scripts inside a running VM without using extensions, which is the Run Command feature.
Matched requirement 2 to Run Command.
Run Command leverages the pre-installed VM Agent directly.
3
Recognize that UEFI boot support and OS disks exceeding 2 TB2\text{ TB} are capabilities introduced in Generation 2 Virtual Machines.
Matched requirement 3 to Generation 2 Virtual Machine.
Generation 1 VMs are constrained to MBR boot disks, limiting them to 2 TB2\text{ TB}.
4
Correlate the troubleshooting of startup failures via screenshots and console logs to Boot Diagnostics.
Matched requirement 4 to Boot Diagnostics.
Boot Diagnostics captures system screenshots and serial log streams at startup.

Key Concept

Azure Virtual Machine configuration features, placement options, extensions, and disk performance characteristics.
Estimated Time:1m 30s
Question 734Question →

Your company is deploying a new public-facing application in Azure. You plan to distribute traffic to the application's virtual machines using a Standard Load Balancer. Which two configurations are compatible and supported for this Standard Load Balancer deployment?

Select all that apply

Show answer & explanation

Answer: A frontend IP configuration that uses a Standard SKU public IP address; Backend pool virtual machines located in different virtual networks within the same region

Answer

The Standard Load Balancer must use a Standard SKU public IP address for its frontend configuration, and its backend pool can contain virtual machines from any virtual network within the same region.
A Standard Load Balancer requires Standard SKU public IP addresses for its frontend and any instance-level public IPs on the backend VMs. It also supports virtual machines from any virtual network in the same region as backend pool members.

Step-by-Step Solution

1
Identify the Load Balancer SKU.
The scenario specifies a Standard Load Balancer.
SKU limits dictate the compatible options for frontends and backend pools.
2
Determine the frontend IP configuration requirements.
The public IP address used for the frontend must be a Standard SKU public IP address.
Standard Load Balancers require Standard SKU public IPs; Basic SKU public IPs are incompatible.
3
Determine the backend pool membership requirements.
The backend pool can include virtual machines from any virtual network in the same region, and any instance-level public IPs on these VMs must also be Standard SKU.
Standard Load Balancers support cross-VNet backend pools, but require all IP resources to share the same SKU.

Key Concept

SKU compatibility and backend pool features of Azure Standard Load Balancer
Question 735Question →

You have two peered Azure virtual networks named VNet1 (address space: 10.1.0.0/1610.1.0.0/16) and VNet2 (address space: 10.2.0.0/1610.2.0.0/16) in the same region. VNet1 contains a subnet named Subnet1 (10.1.1.0/2410.1.1.0/24) and a virtual machine named VM1. The network interface of VM1 is associated with an Application Security Group (ASG) named ASG-Web. An NSG named NSG-Subnet1 is associated with Subnet1. VNet2 contains a subnet named Subnet2 (10.2.1.0/2410.2.1.0/24) and a virtual machine named VM2. The network interface of VM2 is associated with an NSG named NSG-NIC2. You need to allow inbound HTTPS traffic (TCP port 443443) to VM2 from VM1. You configure the following security rules:

* In NSG-Subnet1, you add an outbound rule with a priority of 150150 that allows TCP port 443443 outbound from ASG-Web to the private IP address of VM2.
* In NSG-NIC2, you add an inbound rule with a priority of 120120 that allows TCP port 443443 inbound from ASG-Web to the private IP address of VM2.

When you attempt to save the configuration for NSG-NIC2, the deployment fails. What is the cause of this configuration failure?

Show answer & explanation

Answer: Application Security Groups can only be referenced in Network Security Group rules where both the Network Security Group and the Application Security Group reside in the same virtual network.

Answer

Application Security Groups can only be referenced in Network Security Group rules where both the Network Security Group and the Application Security Group reside in the same virtual network.
The rule configuration fails because Application Security Groups (ASGs) can only be referenced in Network Security Group (NSG) rules if the NSG and the ASG reside within the same virtual network. Since ASG-Web is in VNet1 and NSG-NIC2 is in VNet2, referencing ASG-Web in NSG-NIC2 is an invalid configuration and fails Azure Resource Manager validation.

Step-by-Step Solution

1
Identify the virtual network membership of the resources.
VM1 and ASG-Web reside in VNet1. VM2 and NSG-NIC2 reside in VNet2.
This establishes the logical boundaries for network security rule references.
2
Evaluate the configuration of the security rules in both virtual networks.
The outbound rule in NSG-Subnet1 (VNet1) references ASG-Web (VNet1), which is valid. The inbound rule in NSG-NIC2 (VNet2) attempts to reference ASG-Web (VNet1), which spans across the virtual network boundary.
This isolates the specific rule that is causing the validation failure.
3
Apply Azure Application Security Group constraints.
Determine that an Application Security Group can only be referenced by a Network Security Group that is in the same virtual network. Because NSG-NIC2 is in VNet2 and ASG-Web is in VNet1, the deployment fails.
This identifies the root cause of the deployment failure.

Key Concept

Application Security Group boundaries and Network Security Group cross-VNet constraints.
Estimated Time:3m 0s
Question 736Question →

An enterprise administrator manages access controls for a corporate Tenant Root Group. Under this root group, a production subscription named `Sub-Prod` is created, which houses two resource groups: `RG-App-Prod` and `RG-Data-Prod`.

To implement the security baseline, the administrator must grant access to three administrative teams (Team A, Team B, and Team C) using the principle of least privilege.

Match each team's requirement to the correct role and scope configuration.

Click a left item, then click its matching right item

Items

Team A requires the ability to grant and revoke access permissions for users across all resources in the Sub-Prod subscription, but must not be able to create or manage resources directly.
Team B requires the ability to create, delete, and modify virtual machines, storage accounts, and networks inside the RG-App-Prod resource group, but must not have access to manage permissions.
Team C requires the ability to inspect the configuration settings of all resources under Sub-Prod without the capability to write changes or view secret keys.

Matches

Show answer & explanation

Answer

Team A matches with User Access Administrator role assigned at the Sub-Prod subscription scope; Team B matches with Contributor role assigned at the RG-App-Prod resource group scope; Team C matches with Reader role assigned at the Sub-Prod subscription scope.
The correct pairings map Team A to User Access Administrator at the subscription scope, Team B to Contributor at the resource group scope, and Team C to Reader at the subscription scope. This configuration perfectly satisfies the administrative needs while enforcing the narrowest scope and correct role separation.

Step-by-Step Solution

1
Analyze Team A's requirements.
The requirement demands delegation of access management (RBAC role assignments) without resource management capabilities. The built-in User Access Administrator role is designed exactly for this. Since it must apply to all resources in Sub-Prod, the scope must be the Sub-Prod subscription.
Least privilege requires choosing a role that only allows identity management without resource manipulation.
2
Analyze Team B's requirements.
The requirement demands full resource management (VMs, storage, networks) within a single resource group, RG-App-Prod, without access delegation capability. The Contributor role allows resource management but prevents role assignment. Setting the scope specifically to RG-App-Prod limits access to only that resource group.
Restricting the scope to the specific resource group and choosing Contributor instead of Owner prevents access delegation and limits resource management to the target scope.
3
Analyze Team C's requirements.
The requirement demands read-only access to all resource configurations in the subscription (including both resource groups) without write actions or secret exposure. The Reader role provides read-only access. Assigning it at the subscription scope leverages inheritance so that it automatically applies to all resources under Sub-Prod.
Reader is the standard role for read-only visibility without write or data-plane secret access.

Key Concept

Azure Role-Based Access Control (RBAC) relies on three components: security principal (identity), role definition (permissions), and scope (resource boundaries). Least privilege is achieved by assigning the minimum required role at the narrowest scope necessary.
Question 737Question →

You are configuring outbound internet connectivity for a subnet named Subnet1 in a virtual network named VNet1. You deploy Azure Firewall to VNet1.

To route all outbound internet traffic from Subnet1 through the Azure Firewall using a User-Defined Route (UDR), which two options must you configure in the route table associated with Subnet1? Select two.

Select all that apply

Show answer & explanation

Answer: A route with the destination IP address range set to 0.0.0.0/0 and the next hop type set to Virtual appliance; The private IP address of the Azure Firewall as the next hop IP address

Answer

To route outbound internet traffic through Azure Firewall, you must configure a route with a destination of 0.0.0.0/0 and the next hop type set to Virtual appliance, and specify the private IP address of the Azure Firewall as the next hop IP address.
To route all outbound traffic to Azure Firewall, you need a route table associated with Subnet1. The route must target all internet traffic by using the destination IP address range 0.0.0.0/0. Additionally, because Azure Firewall is a firewall service, it acts as a virtual appliance, meaning the next hop type must be set to 'Virtual appliance' and the private IP address of the firewall must be supplied as the next hop address.

Step-by-Step Solution

1
Create a route in the subnet's route table with a prefix representing all internet destinations.
A destination IP address range of 0.0.0.0/0 is specified.
This routes all traffic not covered by more specific routes to the firewall.
2
Select the correct next hop type for a firewall resource.
The next hop type is set to Virtual appliance.
Azure Firewall functions as a virtual appliance, not a virtual network gateway.
3
Identify and configure the next hop destination address.
The next hop IP address is set to the private IP address of the Azure Firewall.
Traffic must be directed to the firewall's internal private IP to be filtered and processed.

Key Concept

Configuring custom routing (User-Defined Routes) to forward traffic to Azure Firewall.
Question 738Question →

You are planning the deployment of a new virtual network named `vnet-corporate` in an Azure subscription. The virtual network is configured with the address space 172.16.0.0/22172.16.0.0/22. You must create subnets within the virtual network to meet the following requirements:
- Deploy Azure Bastion to allow secure administrative access to virtual machines.
- Create a subnet named `snet-web` that supports at least 6060 usable host IP addresses.
- Create a subnet named `snet-db` that supports at least 2828 usable host IP addresses.

You need to configure the subnet names and IP address prefixes to satisfy these requirements while minimizing address waste. Which subnet configuration should you use?

Show answer & explanation

Answer: AzureBastionSubnet: 172.16.0.0/26172.16.0.0/26; snet-web: 172.16.0.128/25172.16.0.128/25; snet-db: 172.16.1.0/26172.16.1.0/26

Answer

The configuration allocating AzureBastionSubnet as 172.16.0.0/26172.16.0.0/26, snet-web as 172.16.0.128/25172.16.0.128/25, and snet-db as 172.16.1.0/26172.16.1.0/26 is correct because it satisfies the name and size requirements for Azure Bastion, accounts for the 55 reserved IP addresses in Azure subnets, and avoids subnet overlaps.
The correct configuration uses the exact name `AzureBastionSubnet` with a /26/26 prefix, satisfying Azure Bastion requirements. It allocates a /25/25 prefix for `snet-web` (providing 123123 usable IPs, which is the smallest prefix satisfying the 6060 host requirement) and a /26/26 prefix for `snet-db` (providing 5959 usable IPs, which is the smallest prefix satisfying the 2828 host requirement) without overlapping any address ranges.

Step-by-Step Solution

1
Determine Azure Bastion subnet constraints.
The subnet must be named exactly `AzureBastionSubnet` and have a prefix of /26/26 or larger (minimum 6464 IP addresses).
Azure enforces strict naming and sizing constraints on the Bastion subnet for deployment validation.
2
Calculate the prefix size for `snet-web` to support at least 6060 usable host IPs.
A /25/25 prefix is required.
Azure reserves 55 IP addresses per subnet (the first 44 and the last 11). A /26/26 prefix provides 6464 total addresses, which leaves 64−5=5964 - 5 = 59 usable host IPs (insufficient). A /25/25 prefix provides 128128 total addresses, leaving 128−5=123128 - 5 = 123 usable host IPs, which meets the 6060 hosts requirement.
3
Calculate the prefix size for `snet-db` to support at least 2828 usable host IPs.
A /26/26 prefix is required.
A /27/27 prefix provides 3232 total addresses, which leaves 32−5=2732 - 5 = 27 usable host IPs (insufficient). A /26/26 prefix provides 6464 total addresses, leaving 64−5=5964 - 5 = 59 usable host IPs, which meets the 2828 hosts requirement.
4
Select and lay out non-overlapping ranges within 172.16.0.0/22172.16.0.0/22.
AzureBastionSubnet at 172.16.0.0/26172.16.0.0/26, snet-web at 172.16.0.128/25172.16.0.128/25, and snet-db at 172.16.1.0/26172.16.1.0/26.
This layout fits cleanly within the virtual network's address space without overlaps (AzureBastionSubnet spans 172.16.0.0172.16.0.0 to 172.16.0.63172.16.0.63; snet-web spans 172.16.0.128172.16.0.128 to 172.16.0.255172.16.0.255; snet-db spans 172.16.1.0172.16.1.0 to 172.16.1.63172.16.1.63).

Key Concept

Azure virtual network subnets require specific planning for reserved addresses (first four and last one) and service-specific subnets (such as Azure Bastion requiring exactly AzureBastionSubnet with a minimum size of /26).
Estimated Time:1m 30s
Question 739Question →

An organization has an Azure management group named MG-Finance. A child subscription named Sub-Analytics is under MG-Finance. Within Sub-Analytics, there is a resource group named RG-Reporting.

An administrator configures the following Azure Policy settings:
1. A policy definition that requires a cost-center tag on resources is assigned to MG-Finance with the effect set to Deny. An exclusion is configured on this assignment for RG-Reporting.
2. A policy definition that audits missing cost-center tags on resources is assigned to Sub-Analytics with the effect set to Audit. There are no exclusions configured for this assignment.

An administrator attempts to deploy an Azure SQL database without a cost-center tag into RG-Reporting.

Which of the following describes the outcome of this deployment?

Show answer & explanation

Answer: The deployment succeeds, and the Azure SQL database is flagged as non-compliant in Azure Policy compliance reporting.

Answer

The deployment succeeds, and the Azure SQL database is flagged as non-compliant in Azure Policy compliance reporting.
The correct answer states that the deployment succeeds, and the Azure SQL database is flagged as non-compliant in Azure Policy compliance reporting. This is because the Deny policy assigned at the management group level includes an exclusion for the target resource group, preventing it from blocking the database creation. However, the Audit policy assigned at the subscription level inherits downward without exclusions, which permits resource deployment while correctly identifying it as non-compliant in compliance dashboards.

Step-by-Step Solution

1
Evaluate the management group-level policy assignment.
The policy has a Deny effect but explicitly excludes the destination resource group (RG-Reporting). Therefore, the Deny action is bypassed.
Exclusions at lower scopes override policy assignments made at higher scopes.
2
Evaluate the subscription-level policy assignment.
The Audit policy assigned to Sub-Analytics has no exclusions and applies to the child resource group (RG-Reporting).
Policies assigned to subscriptions are inherited by all child resource groups unless explicitly excluded.
3
Determine the resource creation behavior under the Audit policy effect.
The resource deployment is allowed to proceed to completion, and Azure Policy updates the compliance status of the resource to non-compliant.
The Audit effect logs compliance evaluation results without blocking resource creation or modification.

Key Concept

Understanding policy assignment scopes, inheritance, exclusions, and the behavioral difference between Deny and Audit effects.

Alternative Method

Instead of checking compliance status via the Azure Portal UI, administrators can use Azure Resource Graph queries to fetch compliance states programmatically by querying the 'AdvisorResources' or 'PolicyStates' tables.
Estimated Time:1m 30s
Question 740Question →

An administrator is designing a new Azure Kubernetes Service (AKS) cluster in a spoke virtual network (VNet) with the address space 10.80.0.0/2210.80.0.0/22. The cluster must scale up to 150150 nodes, with each node hosting up to 4040 pods simultaneously. The network security team mandates the use of Azure Network Policies for pod traffic enforcement. You need to select the network configurations that will support this scale and meet the security requirements while preventing IP address exhaustion in the VNet. Which two configurations should you implement? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the cluster network plugin to use Azure CNI Overlay.; Define a pod CIDR block, such as 192.168.0.0/16192.168.0.0/16, that does not overlap with the virtual network or any peered networks.

Answer

Configure the cluster network plugin to use Azure CNI Overlay, and define a pod CIDR block, such as 192.168.0.0/16192.168.0.0/16, that does not overlap with the virtual network or any peered networks.
The correct configurations involve using the Azure CNI Overlay network plugin and defining a non-overlapping pod CIDR block. Azure CNI Overlay resolves VNet IP exhaustion by only assigning VNet IP addresses to the nodes, while pods are assigned IPs from a private overlay network. This allows a small virtual network range like 10.80.0.0/2210.80.0.0/22 to easily support 150150 nodes and their pods. Additionally, Azure CNI Overlay natively supports Azure Network Policies, satisfying the security mandate. A distinct, non-overlapping pod CIDR block (like 192.168.0.0/16192.168.0.0/16) must be defined to prevent routing conflicts between the overlay network and the underlying VNet.

Step-by-Step Solution

1
Analyze the IP addressing capacity requirements of the cluster.
The requirement is 150150 nodes hosting up to 4040 pods each, totaling up to 60006000 pods. The spoke virtual network is limited to a 10.80.0.0/2210.80.0.0/22 range, providing only 10241024 IP addresses.
Determining the total IP requirement shows that standard Azure CNI (which assigns VNet IPs to pods) will cause IP address exhaustion since 6150>10246150 > 1024.
2
Evaluate networking models that conserve VNet IP addresses.
Both Kubenet and Azure CNI Overlay conserve VNet IPs by using private internal pod ranges. However, Kubenet does not support Azure Network Policies, whereas Azure CNI Overlay supports them.
Selecting a model that supports Azure Network Policies is necessary to meet the security mandate while conserving VNet IPs.
3
Determine the necessary configuration parameters for Azure CNI Overlay.
Azure CNI Overlay requires enabling the overlay plugin and specifying a non-overlapping private pod CIDR (like 192.168.0.0/16192.168.0.0/16) for routing within the overlay network.
Specifying these configurations ensures correct cluster deployment and avoids IP conflicts with the underlying VNet or peered networks.

Key Concept

Azure CNI Overlay allows AKS pods to be deployed on a private CIDR range to conserve virtual network IP addresses, while still supporting Azure Network Policies and high-performance routing.
PreviousPage 37 / 63Next
All practice questions — Microsoft Azure Administrator (AZ-104) | Examkin