1049 questions total · 14pages · All types, answers revealed
Page 14 of 14
Match each workload requirement to the Azure storage account kind that best fits it.
Drag a concept onto its matching description — or click a concept then click the description.
General-purpose v2
FileStorage
BlockBlobStorage
BlobStorage
Why these pairings
Each storage kind is tailored for specific workloads: GPv2 is the default, BlockBlobStorage for high throughput, FileStorage for premium files, and others for legacy or specialized needs.
A team wants an email and SMS notification whenever the average CPU on a production VM stays above 85% for 10 minutes. The same notification setup may be reused by other alerts later. Which Azure feature should you configure?
An action group is the correct choice because it is the Azure Monitor component specifically designed to hold notification recipients. It defines email addresses, SMS phone numbers, webhooks, and other actions that can be attached to any number of alert rules, allowing reuse across multiple monitoring scenarios. When a metric alert triggers, it invokes the linked action group, which delivers the email and SMS messages.
Why this answer
B is correct because an Action Group is the Azure component that defines the notification actions (email, SMS, webhook, etc.) to be triggered when an alert fires. The question specifies that the same notification setup should be reusable by other alerts later, which is exactly the purpose of an Action Group: it decouples the notification configuration from the alert rule itself. You would create a Metric Alert Rule to monitor the CPU metric, but that rule references an Action Group to send the email and SMS.
Exam trap
The trap here is that candidates confuse the alert rule (which detects the condition) with the action group (which handles the notification), often selecting Metric Alert Rule thinking it directly sends emails/SMS, when in fact it only triggers the action group.
Why the other options are wrong
A metric alert rule defines the condition (CPU > 85% for 10 minutes) but does not include notification actions like email/SMS; it requires an action group to send notifications.
Diagnostic settings collect and route metrics/logs to destinations like Log Analytics or storage, but they do not directly trigger email/SMS notifications. The alert rule and action group handle notifications.
Resource locks prevent accidental deletion or modification of Azure resources, but they do not provide any notification or alerting capabilities. The question requires email/SMS notifications based on a metric threshold, which is not a function of resource locks.
When would these options actually be correct?
If the question asked for the feature that monitors a metric and triggers an alert based on a threshold (e.g., 'which feature fires when CPU exceeds 85% for 10 minutes?'), a metric alert rule would be correct.
A diagnostic setting would be correct if the question asked for sending VM performance metrics to a Log Analytics workspace for long-term analysis or to Event Hubs for third-party integration, without requiring immediate notifications.
A resource lock would be correct if the question asked: 'You need to prevent a critical VM from being accidentally deleted by administrators. Which Azure feature should you configure?'
Why candidates pick the wrong answer
Candidates confuse the alert rule (which detects the condition) with the action group (which handles notifications), thinking the rule itself sends emails/SMS.
Candidates may confuse diagnostic settings with alerting because both involve metrics, but diagnostic settings are about data collection and routing, not notification actions.
Candidates might confuse resource locks with governance or protection features, mistakenly thinking they can be used to enforce or notify about resource state changes.
An Azure virtual machine was moved to a host that is experiencing intermittent issues. You need to move the VM to a different Azure host while keeping the existing managed disks and configuration. Which action should you perform?
Redeploy is the correct action because Azure explicitly reallocates the virtual machine to a different physical host within the same region, while preserving the VM's managed disks, network interfaces, and configuration. This operation is designed to resolve host-level failures or performance issues that a simple OS-level reboot cannot address. The portal's 'Redeploy' button triggers a backend process that first deallocates the VM and then restores it onto a healthy host, ensuring continuity of your VM's data and settings.
Why this answer
Redeploying the VM (Option C) is the correct action because it moves the VM to a new Azure host node while preserving the existing managed disks, virtual network, and configuration. The Azure platform automatically selects a healthy host, resolves transient hardware issues, and maintains the VM's identity and associated resources.
Exam trap
The trap here is that candidates confuse 'Stop' (which deallocates but may not change the host) with 'Redeploy' (which explicitly forces a host migration), or they mistakenly think 'Restart' is sufficient to fix hardware issues when it only reboots the OS on the same faulty host.
Why the other options are wrong
Stopping the VM only deallocates it; it does not force the VM to be moved to a different host. The VM may be placed back on the same problematic host when started again.
Restarting the VM does not change the underlying host; it only reboots the VM on the same host, so it would not resolve issues caused by a faulty host.
Capturing a VM creates a generalized image, which removes machine-specific configurations and managed disks, making it unsuitable for moving the VM to a different host while keeping existing managed disks and configuration.
When would these options actually be correct?
When you need to deallocate a VM to reduce costs or to change its size (resize), stopping (deallocating) is the correct action. For example, to resize a VM, you must first stop it.
If a VM is unresponsive or experiencing a temporary software glitch (e.g., memory leak, service hang), and you need to apply updates or clear the state without changing the host, Restart is the correct action.
When you need to create a reusable image from a generalized VM to deploy multiple identical VMs, or when you want to save a VM's configuration as an image for future deployments, Capture is the correct action.
Why candidates pick the wrong answer
Candidates may think that stopping and restarting the VM will cause it to be placed on a new host, similar to rebooting a local computer to resolve hardware issues.
Candidates may think restarting will force the VM to move to a different host, similar to how restarting a computer can sometimes resolve hardware-related issues, but in Azure, restart does not change the host.
Candidates may think Capture preserves the VM state and disks, but it actually generalizes the VM, losing specific settings and managed disk associations.
A project team expects frequent joiners and leavers. The same Azure permissions are needed for all members of the team, and you want to avoid editing role assignments for each person. Which two actions best meet the requirement? Select two.
Creating a security group for the project team provides a single Azure AD identity object that can be used in role assignments, policy assignments, and conditional access rules. When the team changes, you only update group membership (add/remove users) instead of modifying RBAC assignments, which avoids hitting Azure's role assignment limits and keeps access review simple.
Why this answer
Creating a security group allows you to manage permissions collectively rather than individually. By adding or removing users from the group as joiners and leavers occur, you avoid editing role assignments for each person. This aligns with Azure AD group-based licensing and RBAC best practices for dynamic teams.
Exam trap
The trap here is that candidates may think assigning roles directly to users (Option C) is simpler, but they overlook the administrative overhead of managing individual assignments for frequent joiners and leavers.
Why the other options are wrong
Assigning roles directly to each user account requires editing role assignments for every joiner and leaver, which contradicts the requirement to avoid frequent edits.
Guest accounts are for external collaboration, not for managing internal team members. They do not simplify role assignment management for frequent joiners/leavers because each guest still needs individual role assignments or group membership.
A service principal is an identity for applications or automated tools, not for human users. Assigning roles to a service principal shared by the team would not manage human joiners/leavers and could lead to security risks and lack of auditability.
When would these options actually be correct?
In a scenario where a small, static team has unique permissions per user and no group-based assignment is possible, assigning roles directly to each user account is necessary.
A question requiring granting access to external partners or vendors who need temporary, limited access to Azure resources, and you want to manage their identities in your tenant without creating full user accounts.
If the requirement were to grant permissions to an automated script or application that runs on behalf of the team, and the team members do not need individual identities, then assigning roles to a service principal would be correct. For example, a deployment pipeline that needs access to Azure resources.
Why candidates pick the wrong answer
Candidates may think direct assignment is simpler or more straightforward, not realizing the administrative overhead for frequent changes.
Candidates may think guest accounts reduce administrative overhead for temporary members, but they overlook that guest accounts still require individual role assignments or group management, and are designed for external users, not internal team churn.
Candidates may confuse service principals with security groups, thinking both can be used to group permissions. They might also believe that a shared identity simplifies management, overlooking that service principals are not designed for human user management.
During a change freeze, the operations team wants to prevent accidental deletion of a production resource group and everything in it. They still need to update VM settings, change tags, and modify network rules. Which lock should be applied?
CanNotDelete is the correct lock because it blocks deletion while still allowing normal update operations. That means the team can continue to change VM settings, update tags, and manage networking during the freeze, but they cannot accidentally delete the protected resource group or its child resources. It is the standard choice when preservation is required without freezing all management activity.
Why this answer
The CanNotDelete lock (Option B) prevents deletion of the resource group and all resources within it, while still allowing read and update operations such as modifying VM settings, changing tags, and updating network rules. This lock type is specifically designed to protect against accidental deletion during a change freeze without blocking management operations.
Exam trap
The trap here is that candidates often confuse ReadOnly locks with CanNotDelete locks, assuming that any lock will block all changes, but the key distinction is that ReadOnly locks block all write operations (including updates), whereas CanNotDelete locks only block deletion, allowing the required modifications.
Why the other options are wrong
A ReadOnly lock prevents all write operations, including updates to VM settings, tags, and network rules, which the operations team still needs to perform.
Assigning the Reader role allows read-only access but does not prevent deletion; operators could still delete resources if they have other permissions, and it blocks all write operations, which contradicts the requirement to update VM settings, change tags, and modify network rules.
Azure Policy deny assignments prevent non-compliant resource creation or modification, but they do not block deletion of existing resources. The question requires preventing deletion while allowing updates, which is achieved by a CanNotDelete lock, not a policy.
When would these options actually be correct?
If the question required preventing any changes to the resource group and its resources, such as during a security audit where no modifications are allowed, a ReadOnly lock would be correct.
This option would be correct in a scenario where the requirement is to prevent any changes (including updates and deletions) to a resource group and its resources, and users only need to view configurations for auditing or monitoring purposes.
This option would be correct if the question asked: 'The security team needs to prevent operators from creating VMs without encryption, but they should still be able to manage other resources. Which solution should you use?'
Why candidates pick the wrong answer
Candidates may think a ReadOnly lock is the safest option to prevent accidental deletion, overlooking that it also blocks necessary updates.
Candidates may think that restricting permissions via RBAC is sufficient to prevent deletion, and they might overlook that the Reader role also blocks necessary write operations, confusing it with a more granular lock.
Candidates may confuse Azure Policy's ability to enforce compliance with the operational control of resource locks, thinking a deny assignment can block deletions, but policies only affect creation and modification, not deletion.
You need to give a third-party auditor temporary read-only access to specific blobs in a container without sharing the storage account keys. Which feature should you use?
A shared access signature (SAS) is the correct choice because it provides delegated, time-limited access to specific storage resources with granular permissions, such as read-only, without exposing the storage account keys. SAS tokens can be scoped to a single container or blob, restricted to a defined IP range or protocol, and can be set to expire automatically, making them ideal for a third-party auditor's temporary read-only access. This ensures the auditor can retrieve the required data while maintaining full control over the scope and duration of access, and the token can be revoked or regenerated if necessary.
Why this answer
A shared access signature (SAS) is the correct choice because it provides delegated, time-limited, and permission-restricted access to specific Azure Storage resources—in this case, blobs—without exposing the storage account keys. You can generate a service-level SAS token scoped to individual blobs with read-only permissions and an expiration time, allowing the auditor to access only the required blobs. This meets the requirement for temporary, read-only access while maintaining security and granular control.
Exam trap
The trap here is that candidates often confuse resource locks (which prevent deletion) with access control mechanisms, or mistakenly think blob versioning provides access delegation, when in fact only SAS tokens offer granular, time-bound, and keyless access to specific blobs.
Why the other options are wrong
Sharing a storage account key grants full administrative access to the entire storage account, not temporary read-only access to specific blobs, and violates the principle of least privilege.
A resource lock prevents accidental deletion or modification of resources but does not provide any form of access control or temporary read-only access to specific blobs.
Blob versioning preserves previous versions of blobs but does not provide temporary, granular read-only access to specific blobs for a third party without using storage account keys.
When would these options actually be correct?
When the question asks for a method to provide full access to all storage account resources (e.g., for an internal admin) and key rotation is acceptable, a storage account key would be correct.
You need to prevent a critical storage container from being deleted or modified by any user, even those with Contributor or Owner permissions. A resource lock (e.g., CanNotDelete) would be the correct feature to use.
A question asks: 'You need to maintain a history of blob changes to recover from accidental overwrites or deletions. Which feature should you enable?' In that scenario, blob versioning is the correct answer.
Why candidates pick the wrong answer
Candidates may think the key is the simplest way to grant access without realizing it provides unrestricted, permanent access to the entire account, not just specific blobs.
Candidates might confuse resource locks with access control mechanisms, thinking they can restrict access to blobs, when in fact locks only protect against deletion/modification, not read access.
Candidates may confuse blob versioning with access control mechanisms, thinking it can be used to grant access to specific versions, but it does not provide authentication or authorization.
A development VM is rebuilt often and does not need its operating system disk contents to survive deallocation. The team wants the lowest practical disk latency for the OS. Which disk option should the administrator choose?
An ephemeral OS disk is hosted on the local VM storage instead of a managed disk, which eliminates the separate storage cost and dramatically reduces read/write latency. Because the disk is tied to the VM's lifecycle, every time the VM is deallocated or rebuilt the disk is reset to the original image, making it ideal for a frequently recreated development VM. This exactly matches the requirement that the VM does not need its OS disk to persist between runs.
Why this answer
Ephemeral OS disks use the local VM storage (SSD) rather than Azure managed disks, providing the lowest latency for OS read/write operations. Since the VM is rebuilt often and disk persistence is not required, the ephemeral disk is ideal because its contents are lost when the VM is deallocated, eliminating the need for a separate managed disk.
Exam trap
The trap here is that candidates often choose Standard HDD (Option A) thinking it is the cheapest option, but they overlook that 'lowest practical disk latency' explicitly requires performance, not cost, and that Ephemeral OS disks provide both low latency and zero cost for the OS disk itself (since it uses local storage).
Why the other options are wrong
Standard HDD managed disks have higher latency compared to SSDs or ephemeral disks, and the question specifically asks for the lowest practical disk latency for the OS.
A data disk formatted as the boot disk cannot be used as the OS disk in Azure; the OS disk must be a managed disk attached as the OS disk, not a data disk. This option does not provide the lowest latency or meet the requirement for an OS disk that is rebuilt often.
When would these options actually be correct?
If the question required a cost-effective solution for a VM that needs persistent OS disk data across deallocations and latency is not a primary concern, Standard HDD would be the correct choice.
This option would be correct in a scenario where the question asks for a way to migrate an existing boot disk to a different storage type or to attach an existing VHD as a data disk for data recovery, not for the OS disk of a development VM.
Why candidates pick the wrong answer
Candidates may default to Standard HDD as a familiar, low-cost option without considering that ephemeral OS disks offer even lower latency and are designed for stateless workloads.
Candidates might think that using a data disk as the boot disk could offer flexibility or cost savings, misunderstanding that Azure requires a specific OS disk type and that data disks cannot serve as the boot disk for a VM.
You deploy a Windows Server VM and need to run several PowerShell commands after deployment without signing in to the VM. Which Azure feature should you use?
The Custom Script Extension downloads and executes PowerShell scripts on the Windows VM via the Azure VM Agent. It is specifically designed for post-deployment configuration tasks such as installing roles, configuring settings, or applying updates, without requiring an interactive RDP or PowerShell session. You can deploy it through the Azure portal, CLI, PowerShell, or Azure Resource Manager templates.
Why this answer
The Custom Script Extension (CSE) is the correct Azure feature because it allows you to run PowerShell or Bash scripts on a VM after deployment without requiring interactive sign-in. It executes the script via the Azure VM Agent, which runs as a local system process, making it ideal for post-deployment configuration tasks like installing software or running commands.
Exam trap
The trap here is confusing post-deployment script execution with other VM management features like availability zones or managed identities, which serve entirely different purposes (high availability and authentication, respectively).
Why the other options are wrong
Availability zones provide high availability by protecting VMs from datacenter failures, but they do not execute PowerShell commands after deployment.
Attaching a managed identity and relying on Azure Policy does not execute PowerShell commands on the VM; it assigns permissions and enforces compliance rules, not post-deployment scripts.
Creating a snapshot before startup captures the disk state but does not execute any commands after deployment. Snapshots are for backup or recovery, not for running scripts.
When would these options actually be correct?
When the question asks for a method to protect a VM from a regional outage by placing it in a physically separate zone within an Azure region, availability zones are the correct answer.
When the question asks how to grant a VM permissions to access Azure resources (e.g., Key Vault, storage) without storing credentials, and the solution must use Azure AD authentication without manual key management.
You need to preserve the VM's disk state before applying a critical update or configuration change, so you can revert if the update fails. The question would ask: 'Which feature should you use to create a point-in-time backup of a VM's disk?'
Why candidates pick the wrong answer
Candidates may confuse availability zones with automation features, thinking that 'zones' imply some form of automated action or configuration.
Candidates may confuse Azure Policy (which can deploy extensions via DeployIfNotExists) with direct script execution, or think managed identity can trigger scripts, but neither runs custom commands automatically.
Candidates may confuse snapshots with automation features, thinking a pre-boot snapshot can somehow trigger scripts, or they may overestimate the snapshot's capabilities.
Match each image or placement term to the administrator need it supports.
Drag a concept onto its matching description — or click a concept then click the description.
Used to deploy multiple new VMs from a prepared standard build.
Used to create a new VM that keeps the source machine's existing state.
Helps protect against host or maintenance failures inside one datacenter.
Helps protect against a full datacenter outage in a region.
Why these pairings
Availability Set protects against rack failures; Availability Zone protects against datacenter failures; Proximity Placement Group reduces latency; Scale Set provides auto-scaling; VNet isolates network; Load Balancer distributes traffic.
A storage account has a private endpoint in VNet A. A VM in peered VNet B can reach the storage account by private IP, but when the VM resolves the storage account name it still gets the public IP address. What should be configured so the name resolves to the private IP from VNet B?
A private endpoint assigns the storage account a private IP address in VNet A, but name resolution from VNet B must still map the storage service FQDN to that private IP. Linking the private DNS zone to VNet B enables DNS resolution across the peered network, so clients in VNet B can resolve the storage account to its private endpoint. This is the standard approach for enabling private connectivity to a PaaS service over VNet peering.
Why this answer
When a private endpoint is created in VNet A, a private DNS zone (e.g., `privatelink.blob.core.windows.net`) is automatically linked to VNet A, enabling name resolution to the private IP within that VNet. However, VNet B is peered but not linked to that private DNS zone, so VMs in VNet B continue to resolve the storage account name via public DNS, returning the public IP. By linking the private DNS zone to VNet B, the VM will resolve the storage account name to the private IP address of the private endpoint.
Exam trap
The trap here is that candidates assume peering automatically extends DNS resolution for private endpoints, but peering only provides network connectivity—DNS zone linking is a separate, required configuration step.
Why the other options are wrong
Creating a new storage account in VNet B does not resolve the DNS issue for the existing storage account; it only provides a separate storage endpoint that would still require proper DNS configuration.
The issue is DNS resolution, not network traffic filtering. An NSG rule allowing DNS traffic from VNet B does not configure the private DNS zone to be accessible or linked to VNet B, so the storage account name still resolves to the public IP.
When would these options actually be correct?
If the question asked how to ensure a VM in VNet B can access storage with lowest latency and without traversing the public internet, creating a storage account in VNet B with a service endpoint or private endpoint would be correct.
If a VM in VNet B cannot resolve the storage account name at all (e.g., DNS query times out), and the private DNS zone is already linked to VNet B, then an inbound NSG rule allowing UDP port 53 from VNet B to the DNS server (Azure-provided or custom) would be needed to permit DNS traffic.
A question asks how to ensure traffic from a VM to a storage account stays within the Azure backbone without using a private endpoint, and the storage account does not require private IP resolution. Service endpoints would be the correct choice to route traffic privately.
Why candidates pick the wrong answer
Candidates may think that placing the storage account in the same VNet automatically resolves DNS, ignoring that private DNS zones must be linked to the peered VNet for name resolution.
Candidates may think that since the VM can reach the private IP, the problem is that DNS traffic is blocked by a firewall or NSG, so they focus on allowing DNS traffic rather than configuring DNS resolution properly.
Candidates may confuse service endpoints with private endpoints, thinking both provide private IP connectivity and DNS resolution, but service endpoints lack the DNS integration that private endpoints offer.
A contractor working from home needs temporary access to internal Azure resources. There is no on-premises network to connect, and you do not want to expose the resources publicly. Which connectivity option should you deploy?
Point-to-site VPN is the correct solution because it establishes a secure, encrypted tunnel from an individual client computer to an Azure virtual network over the public internet. It uses protocols such as IKEv2, SSTP, or OpenVPN and authenticates the user or device before granting access to private resources inside the VNet. This makes it ideal for a single remote user needing temporary access without exposing workloads publicly.
Why this answer
A Point-to-Site (P2S) VPN is the correct choice because it allows an individual client computer to establish a secure, encrypted connection to an Azure virtual network over the public internet using SSTP, IKEv2, or OpenVPN protocols. This meets the requirement of temporary remote access without exposing resources publicly, as the connection is initiated from the client and authenticated via certificates or Azure AD.
Exam trap
The trap here is that candidates often confuse Point-to-Site VPN with Site-to-Site VPN, assuming any VPN requires a physical device on-premises, or they overcomplicate the solution by choosing ExpressRoute for its perceived security, ignoring the temporary and individual nature of the access requirement.
Why the other options are wrong
Site-to-site VPN requires a VPN device on-premises to establish a connection between entire networks, but the contractor has no on-premises network to connect, making it unsuitable for individual remote access.
VNet peering connects two Azure virtual networks, not a remote client device. It does not provide remote access for an individual contractor working from home.
ExpressRoute is a dedicated private connection to Azure, requiring on-premises infrastructure and long-term contracts, making it unsuitable for temporary contractor access without an on-premises network.
When would these options actually be correct?
You need to connect an entire branch office network to an Azure virtual network securely over the internet, and the branch has a compatible VPN device. Site-to-site VPN would be the correct choice.
A question where two Azure virtual networks in different regions need to communicate privately and securely, without using the public internet or a VPN gateway. For example: 'You have two VNets in different Azure regions that must communicate with low latency. Which connectivity option should you use?'
A company needs a high-speed, low-latency, private connection between its on-premises data center and Azure for consistent, large-scale workloads, and is willing to commit to a long-term contract with a connectivity provider.
Why candidates pick the wrong answer
Candidates may assume Site-to-site VPN is the standard for any remote connectivity, not realizing it requires a fixed on-premises network and is not designed for individual client connections.
Candidates may think VNet peering can connect any remote device because the name suggests 'peering' implies general connectivity, or they confuse it with remote access solutions.
Candidates may think ExpressRoute is the most secure option and assume it can be used for any private connectivity, overlooking its complexity, cost, and requirement for on-premises infrastructure.
A virtual machine named VM-App01 hosts a critical internal application. You need to protect the VM so that it can be restored if the VM is deleted or corrupted. The solution must provide centralized backup management and retention policies. What should you use?
Azure Backup with a Recovery Services vault is the correct solution because it provides a centralized, policy-driven backup service designed specifically for VM protection. It installs the VM extension to take application-consistent snapshots, transfers them to the vault, and applies configurable retention rules for daily/weekly/monthly/yearly points. This enables granular restores (files, disks, or entire VM) with integration into Azure Monitor and RBAC, giving you a reliable, auditable backup system for disaster recovery and operational recovery.
Why this answer
Azure Backup with a Recovery Services vault is the correct choice because it provides centralized backup management, configurable retention policies, and the ability to restore a VM even if it is deleted or corrupted. Unlike snapshots, Azure Backup stores backups in a separate vault, supports application-consistent backups via the Volume Shadow Copy Service (VSS), and offers long-term retention with backup policies.
Exam trap
The trap here is that candidates often confuse Azure Backup (for backup and retention) with Azure Site Recovery (for disaster recovery), or assume that disk snapshots alone are sufficient for full VM recovery, ignoring the need for centralized management and retention policies.
Why the other options are wrong
Managed disk snapshots only provide crash-consistent backups for individual disks, but they lack centralized management, retention policies, and the ability to restore the entire VM configuration (including network and OS settings) in case of VM deletion or corruption.
Azure Site Recovery is designed for disaster recovery and business continuity by replicating VMs to a secondary region, not for centralized backup management with retention policies for restoring deleted or corrupted VMs.
Boot diagnostics only captures serial console output and screenshots for troubleshooting boot failures; it does not provide backup or restore capabilities for VM deletion or corruption.
When would these options actually be correct?
You need to create a point-in-time backup of a single managed disk (e.g., data disk) for quick restoration or to create a new VM from the snapshot, and centralized backup management or retention policies are not required.
If the question asked for a solution to replicate VMs to another Azure region for failover during a regional outage, ensuring business continuity with minimal downtime, Azure Site Recovery would be the correct answer.
When the question asks for a method to troubleshoot a VM that fails to boot or to capture boot logs for diagnostic purposes, and the solution does not need to restore the VM from backup.
Why candidates pick the wrong answer
Candidates may think snapshots are sufficient for VM protection because they can restore disks, but they overlook the need for centralized management, retention policies, and full VM restore capabilities that Azure Backup provides.
Candidates may confuse backup (Azure Backup) with disaster recovery (Azure Site Recovery), as both involve protecting VMs, but they serve different purposes: backup for point-in-time restoration, Site Recovery for replication and failover.
Candidates may confuse boot diagnostics with a recovery feature because the name implies it helps with VM issues, but it is purely diagnostic and not a backup solution.
You need to deploy 25 identical Azure virtual machines for a web application and scale the number of instances automatically based on CPU demand. Which Azure compute feature should you use?
A Virtual Machine Scale Set (VMSS) is a managed Azure service that deploys and manages a group of identically configured virtual machines, making it the ideal choice for running 25 identical web servers. VMSS integrates automatic scaling, enabling the fleet to grow or shrink based on CPU, memory, or custom metrics, and it can work with Azure Load Balancer or Application Gateway for traffic distribution. By defining a single VM image and configuration, you can effortlessly maintain a consistent environment across all instances, which is exactly what this workload requires.
Why this answer
A Virtual Machine Scale Set (VMSS) is the correct Azure compute feature because it allows you to deploy and manage a group of identical, load-balanced VMs whose number can automatically increase or decrease in response to CPU demand using autoscale rules. This directly meets the requirement for 25 identical VMs with automatic scaling based on CPU metrics.
Exam trap
The trap here is that candidates often confuse an availability set (which provides high availability) with a Virtual Machine Scale Set (which provides both identical deployment and autoscaling), leading them to select Option A because they focus on the 'identical VMs' requirement without recognizing that autoscaling is the key differentiator.
Why the other options are wrong
An availability set provides high availability by distributing VMs across fault domains and update domains, but it does not support automatic scaling based on CPU demand. It is a static grouping, not a scaling solution.
A Recovery Services vault is used for backup and disaster recovery, not for deploying or scaling virtual machines based on CPU demand.
Boot diagnostics captures serial console output and screenshots for troubleshooting VM boot failures, but it does not provide automatic scaling or deployment of multiple VMs.
When would these options actually be correct?
When the question asks for a feature that ensures VMs are placed in separate fault domains to protect against hardware failures within a datacenter, and does not mention scaling or load-based automation.
When the question asks for a service to back up Azure VMs or implement site recovery, a Recovery Services vault would be the correct answer.
You need to troubleshoot why a specific Azure VM fails to boot after a configuration change; boot diagnostics would be the correct feature to enable to capture the boot logs and screenshots.
Why candidates pick the wrong answer
Candidates may confuse availability sets with scale sets because both involve multiple VMs, and they might think availability sets also handle scaling due to the word 'set' implying grouping.
Candidates may confuse 'Recovery' with 'scaling' or think it provides some form of automatic recovery that includes scaling, but it is unrelated to compute scaling.
Candidates may confuse boot diagnostics with a feature that helps manage VM health or performance, mistakenly thinking it can be used for scaling decisions based on CPU demand.
Why is centralized logging valuable during security incident response?
Centralized logging aggregates events from firewalls, endpoints, servers, and cloud services into a single time-indexed repository, allowing analysts to reconstruct a full attack chain by correlating related activities across devices. Instead of examining isolated logs, investigators can query for indicators of compromise that span an entire network, significantly reducing the time to detect and respond to incidents.
Why this answer
Centralized logging aggregates logs from multiple sources (e.g., Azure VMs, network security groups, Azure Firewall) into a single repository like Azure Log Analytics or Azure Sentinel. This correlation enables security analysts to identify patterns across devices, such as a chain of events from an initial breach to lateral movement, which is critical for incident response. Without centralization, manually correlating timestamps and log formats from disparate systems would be impractical during an active attack.
Why the other options are wrong
This option is wrong because centralized logging does not prevent attacks; it merely helps in detecting and analyzing them after they occur. Security measures must be implemented to actually prevent attacks from succeeding.
This option is wrong because centralized logging does not replace access control mechanisms; rather, it complements them by providing visibility into access attempts and security events. Access control mechanisms are essential for determining who can access what resources, independent of logging.
Option D is incorrect because centralized logging does not dictate network architecture or enforce VLAN configurations; it focuses on aggregating log data for analysis. Centralized logging can operate across different VLANs without forcing all systems into a single VLAN.
When would these options actually be correct?
If the exam question asked about the effectiveness of security measures in preventing attacks, and specifically mentioned that a certain security architecture guarantees attack prevention, then this option could be correct. For example, a question could state that a security system is designed to block all unauthorized access, thus guaranteeing that attacks cannot succeed.
In a question that asks about the benefits of integrating security measures, such as logging and access control, one might argue that centralized logging can enhance the effectiveness of access control by providing insights into access patterns and potential breaches. This could make it a correct answer in that context.
If the exam question were to ask about network segmentation strategies that enhance security by isolating traffic, then stating that forcing all systems to use one VLAN could be seen as a correct answer in the context of simplifying network management and monitoring.
Why candidates pick the wrong answer
Candidates may find this option tempting because it suggests a strong security posture, appealing to the desire for absolute protection in cybersecurity. The idea of guaranteed prevention aligns with common misconceptions about security solutions.
Candidates may find this option tempting because they might confuse the role of logging with that of access control, believing that effective logging could inherently secure systems by replacing the need for access controls.
Candidates may find this option tempting because they might associate centralized logging with network management practices, mistakenly believing that it implies a unified network architecture or VLAN configuration for better data collection.
A company wants to enforce three controls across all current and future subscriptions under a management group: allowed Azure regions, a required cost center tag, and approved VM SKUs. Central IT wants a single assignment and consolidated compliance reporting. What should they use?
An initiative groups multiple related policies into one assignable unit. Assigning it at the management group scope ensures the controls apply to all current and future subscriptions beneath it, while keeping compliance reporting centralized and easier to manage.
Why this answer
An initiative (policy set) at the management group scope allows you to bundle multiple policy definitions (allowed regions, required tag, approved VM SKUs) into a single assignment. This ensures the controls apply to all current and future subscriptions under that management group, and Azure Policy provides consolidated compliance reporting at the management group level, meeting the requirement for a single assignment and unified view.
Exam trap
The trap here is that candidates often confuse resource locks or RBAC with policy-based governance, thinking they can enforce allowed configurations through access control or locks, but only Azure Policy (via initiatives) can evaluate and enforce resource properties like regions, tags, and SKUs.
Why the other options are wrong
Three separate policy assignments at each subscription scope would require managing multiple assignments per subscription, contradicting the requirement for a single assignment and consolidated compliance reporting across all subscriptions under the management group.
A resource lock prevents deletion or modification of resources but does not enforce compliance policies like allowed regions, tags, or VM SKUs. It cannot provide consolidated compliance reporting.
Custom RBAC roles control permissions to Azure resources, not compliance policies like allowed regions, tags, or VM SKUs. They cannot enforce or audit configuration requirements across subscriptions.
When would these options actually be correct?
If the requirement was to apply different policies to each subscription individually (e.g., different allowed regions per subscription), and there was no need for consolidated reporting, then separate assignments at each subscription scope would be appropriate.
An exam question where the requirement is to prevent accidental deletion or modification of a management group or its subscriptions, such as 'Prevent all users from deleting the management group hierarchy.'
When a company needs to delegate specific management permissions (e.g., 'Virtual Machine Contributor' with restricted scope) to a team for all subscriptions under a management group, a custom RBAC role assigned at the management group scope would be correct.
Why candidates pick the wrong answer
Candidates may think that assigning policies directly to subscriptions gives more granular control, but they overlook the management group scope's ability to apply policies consistently across all subscriptions with a single assignment.
Candidates may confuse resource locks with policy enforcement, thinking a lock can restrict resource creation or configuration, or they may believe a management group lock applies policies to child subscriptions.
Candidates may confuse RBAC with policy, thinking that restricting permissions can enforce compliance rules, or they may overestimate RBAC's ability to control resource configurations beyond access.
Which three of the following are valid ways to achieve high availability for a virtual machine workload running in Azure? (Choose three.)
Why this answer
Deploying a VM inside an Availability Set with two or more VMs ensures high availability by placing the VMs across multiple fault domains and update domains within a single Azure datacenter. This protects against hardware failures and planned maintenance events, as at least one VM remains available during an outage or update cycle.
Exam trap
The trap here is confusing high-availability mechanisms (like redundancy and automatic failover) with performance improvements (Premium SSD) or data protection (Azure Backup), leading candidates to select options that improve speed or recovery but do not ensure continuous uptime.
A storage account already has a private endpoint for Blob service in a VNet. Virtual machines in AppSubnet still resolve the account name to the public endpoint, so traffic never reaches the private IP. Which two actions should the administrator take? Select two.
A private DNS zone named privatelink.blob.core.windows.net is a mandatory component of the private endpoint deployment. When a client resolves the storage account's blob endpoint, the private DNS zone overrides the public CNAME record, returning the private IP address assigned to the private endpoint's NIC. Without this zone, DNS queries for the blob service FQDN continue to resolve to the public endpoint, so traffic never traverses the private link.
Why this answer
A private DNS zone for `privatelink.blob.core.windows.net` is required to override the default public DNS resolution for the storage account. When a private endpoint is created, the storage account's FQDN (e.g., `mystorageaccount.blob.core.windows.net`) must resolve to the private IP address of the endpoint within the VNet. Without this DNS zone, the VM in AppSubnet will continue to resolve the name to the public IP via Azure's public DNS servers, bypassing the private endpoint.
Exam trap
The trap here is that candidates often confuse service endpoints with private endpoints, assuming that enabling a service endpoint alone will redirect traffic to the private IP, when in fact DNS resolution must be explicitly configured via a private DNS zone.
Why the other options are wrong
Enabling a service endpoint for Microsoft.Storage on the subnet does not change DNS resolution; VMs would still resolve the storage account to its public IP address, not the private endpoint's IP.
When would these options actually be correct?
When the requirement is to restrict access to the storage account from a specific subnet without using a private endpoint, and the storage account firewall is configured to allow traffic from that subnet via the service endpoint.
This option would be correct in a scenario where the goal is to restrict storage account access to specific VNets/IPs without using private endpoints, and the VMs are configured to use the public endpoint but are allowed via firewall rules.
In a scenario where the storage account must be accessed via a specific public IP for firewall rules or compliance, and the private endpoint is not used, assigning a static public IP to the endpoint would be incorrect; however, if the question asked for ensuring the private endpoint uses a predictable IP for monitoring, this could be a distractor.
Why candidates pick the wrong answer
Candidates may confuse service endpoints with private endpoints, thinking both provide private IP connectivity, but service endpoints do not affect DNS resolution or provide a private IP.
Candidates may think that enabling the firewall with Selected networks forces traffic through the VNet, but without proper DNS resolution to the private IP, traffic still goes to the public endpoint and is either blocked or routed over the internet.
Candidates may think that assigning a static IP to the private endpoint will force traffic to use that IP, misunderstanding that DNS resolution must be updated separately.
A storage account should accept requests only from a specific virtual network subnet in Azure. The team does not want traffic to reach the public endpoint from the internet. What should the administrator configure?
This is the correct approach because Azure Storage network rules allow you to permit traffic only from a specific virtual network subnet or IP range, effectively blocking requests from any other network source. Alternatively, a private endpoint assigns the storage account a private IP address from your virtual network, ensuring all client traffic traverses a private, Microsoft-managed path rather than the public internet. Both options enforce a network-level boundary, which is exactly what is needed to restrict requests to a specific subnet while keeping all other sources denied.
Why this answer
Azure storage accounts can restrict access to specific virtual network subnets using service endpoints or private endpoints. A storage network rule for the subnet allows traffic only from that subnet, while a private endpoint maps the storage account to a private IP in the VNet, completely bypassing the public endpoint. This ensures no internet traffic reaches the public endpoint, meeting the requirement.
Exam trap
The trap here is that candidates often confuse network-level access controls (like service endpoints or private endpoints) with RBAC roles or storage tier changes, mistakenly thinking that assigning a role or changing a tier can restrict network traffic.
Why the other options are wrong
Enabling anonymous blob access allows public read access to blob data without authentication, but does not restrict network traffic to a specific subnet or block internet access to the public endpoint.
Assigning the Contributor role to a subnet grants management permissions but does not restrict network access to the storage account's public endpoint; it does not block internet traffic.
When would these options actually be correct?
When the requirement is to allow unauthenticated read access to blob containers (e.g., for hosting static websites or sharing public data) without needing shared access signatures or Azure AD authentication.
An administrator needs to allow a specific subnet's virtual machines to manage storage account resources (e.g., create containers) while preventing other users from doing so. Assigning the Contributor role to the subnet's managed identity would be correct.
Why candidates pick the wrong answer
Candidates may confuse 'anonymous access' with 'network restriction' because both involve controlling access, but anonymous access controls authentication, not network-level traffic filtering.
Candidates may confuse role-based access control (RBAC) with network security controls, thinking that assigning a role can restrict access to only that subnet.
A team has 20 operators who need the same Reader access to one application resource group. You want to grant access and later revoke it by changing group membership instead of editing each user's permissions. What should you use for the role assignment?
Assigning the role to an Entra ID security group is the best practice for shared access. You manage access by adding or removing users from the group, which is easier to maintain and less error-prone than changing many separate role assignments. This also supports least privilege and makes future access reviews simpler.
Why this answer
Using an Entra ID security group allows you to assign the Reader role to the group, then add or remove the 20 operators as members. This centralizes permission management: granting or revoking access is done by changing group membership rather than editing individual role assignments, which is more efficient and less error-prone.
Exam trap
The trap here is that candidates often confuse management groups (which control policy and cost across subscriptions) with security groups (which control RBAC access at a specific scope), leading them to pick Option C incorrectly.
Why the other options are wrong
Assigning Reader access to individual user accounts would require editing each user's permissions to revoke access, contradicting the requirement to manage access via group membership changes.
A management group is used to organize and manage access, policies, and compliance across multiple Azure subscriptions, not to assign roles to individual users within a single resource group. It cannot be used to grant Reader access to specific operators by changing group membership.
A resource lock prevents accidental deletion or modification of resources but does not grant access permissions. It cannot be used to assign Reader access to users.
When would these options actually be correct?
When granting access to a single user or a small number of users where group membership management is not needed, such as assigning a custom role to a specific administrator for a temporary task.
You need to apply a policy (e.g., allowed locations) or a role assignment (e.g., Contributor) to all subscriptions under an organization, and you want the assignment to be inherited by all child subscriptions. In that case, assigning the role at the management group scope would be correct.
A question asks how to prevent accidental deletion of a critical resource group while still allowing authorized users to manage resources within it. The correct answer would be to apply a resource lock (e.g., CanNotDelete) to the resource group.
Why candidates pick the wrong answer
Candidates may default to assigning roles directly to users without considering the operational overhead of managing permissions individually, especially when the number of users is manageable.
Candidates may confuse management groups with security groups, thinking both are 'groups' that can manage access, but management groups are for hierarchical governance across subscriptions, not for granular role assignments to users.
Candidates may confuse resource locks with role assignments because both involve controlling access, but locks are for preventing changes, not granting permissions.
A compliance team keeps signed contract scans in Azure Blob Storage. The files are usually read only a few times per year, but when a reviewer needs one, it must be available immediately without waiting for rehydration. Which access tier should the administrator use?
Cold is the best fit for data that is rarely read but must still be available immediately when needed. It keeps the blob online, unlike Archive, so there is no waiting for rehydration. This makes it suitable for compliance documents or records that are accessed occasionally but must open quickly during reviews.
Why this answer
The Cold access tier is designed for data that is infrequently accessed but must remain online and immediately readable without any rehydration delay. Since the compliance team needs instant access to contract scans when requested, Cold tier provides low-cost storage while keeping data online, unlike Archive which requires rehydration.
Exam trap
The trap here is that candidates often confuse 'lowest cost' (Archive) with 'immediate availability,' forgetting that Archive requires a rehydration process that can take hours, making it unsuitable for on-demand access.
Why the other options are wrong
The Hot tier is optimized for frequent access (many times per month), but the scenario specifies files are read only a few times per year, making Hot unnecessarily expensive.
Cool tier is online and immediately readable, but it is designed for data accessed more than a few times per year (e.g., monthly). The question states files are read only a few times per year, making Cold tier more cost-effective while still online.
Archive tier requires rehydration (up to 15 hours) before data can be read, contradicting the requirement for immediate availability without waiting.
When would these options actually be correct?
An administrator needs to store data that is accessed and modified frequently, such as streaming video or active transaction logs, and requires the lowest latency access with no retrieval costs.
A company stores monthly sales reports that are accessed about once a month for review. The administrator needs immediate access without rehydration and wants lower cost than Hot tier. Cool tier would be correct.
For long-term backup or compliance data that is rarely accessed and can tolerate hours of retrieval latency, such as regulatory records that must be retained for 7 years but are only accessed during audits with advance notice.
Why candidates pick the wrong answer
Candidates may assume 'Hot' is always the best for immediate retrieval, overlooking that Cold also provides instant access at lower cost for infrequent use.
Candidates may confuse 'infrequent access' with 'very infrequent access' and assume Cool is the standard tier for rarely accessed data, overlooking the existence of Cold tier for data accessed only a few times per year.
Candidates focus on the lowest cost for infrequent access, overlooking the critical constraint of immediate retrieval; they assume Archive is still readable online like Cool or Cold tiers.
This is the direct and simplest solution for private VNet connectivity in Azure.
Why this answer
VNet peering enables direct, private connectivity between two virtual networks in the same Azure region using the Microsoft backbone infrastructure. It does not require a VPN gateway, public IP addresses, or any internet transit, making it the correct choice for private communication between VNet-Hub and VNet-Spoke1.
Why the other options are wrong
A site-to-site VPN requires a VPN gateway and uses encrypted tunnels over the public internet, not the Microsoft backbone. The question specifies private communication over the Microsoft backbone without a VPN gateway, so this option does not meet the requirements.
A public load balancer distributes incoming internet traffic to backend resources and does not enable private communication between virtual networks over the Microsoft backbone.
An NSG outbound deny rule blocks traffic but does not enable private connectivity between VNets; it cannot establish communication over the Microsoft backbone.
When would these options actually be correct?
A site-to-site VPN would be correct if the question required connecting an on-premises network to Azure VNets over the internet with encrypted traffic, or connecting VNets in different Azure regions where VNet peering is not supported or when cross-region connectivity must be encrypted.
You need to distribute incoming internet traffic across multiple virtual machines in a backend pool for high availability and scalability. A public load balancer would be the correct choice.
You need to block all outbound traffic from a subnet to the internet while allowing traffic to a specific service via service tags. An NSG outbound deny rule with a higher priority deny-all rule and an allow rule for the service tag would be correct.
Why candidates pick the wrong answer
Candidates may think a VPN is the only way to connect VNets privately, not realizing that VNet peering provides private connectivity over the Microsoft backbone without a VPN gateway.
Candidates may mistakenly think a load balancer can route traffic between VNets because it handles network traffic, but it is designed for load balancing, not VNet-to-VNet connectivity.
Candidates may think that controlling outbound traffic with NSG rules is sufficient to enable private communication, misunderstanding that NSGs only filter traffic and do not create network paths.
A contractor is a member of an Entra security group that has the Contributor role on a resource group. When the contractor tries to deploy, the portal says the role is not active. The activation request requires approver approval, and the previous activation window has expired. What should the contractor do?
The assignment is eligible, not active, so the contractor must initiate an activation request in Microsoft Entra Privileged Identity Management. PIM will enforce any approval workflow configured for the role, and after approval (if required) the role becomes active for a specified duration. This is the only supported way to use an eligible role assignment.
Why this answer
The contractor has an eligible role assignment that requires activation through Privileged Identity Management (PIM). Since the previous activation window has expired, the role is no longer active, and the contractor must initiate a new activation request, which may require approver approval. Option D correctly describes this process, as PIM is the Azure service designed for just-in-time access to privileged roles.
Exam trap
The trap here is that candidates confuse 'eligible' role assignments with 'active' assignments, assuming the role is permanently available when it actually requires manual activation through PIM.
Why the other options are wrong
The contractor has an eligible role requiring activation via PIM, not a direct assignment. Role propagation delay does not apply because the role is not active; it must be activated first.
Creating a new security group and assigning Contributor directly would not resolve the issue because the contractor's role is eligible and requires activation through Privileged Identity Management (PIM), not a new group assignment.
Signing out and back in does not resolve the issue because the contractor's role is eligible, not active. The portal error indicates the role requires activation through Privileged Identity Management (PIM), not a session refresh.
When would these options actually be correct?
This would be correct if the contractor had just been assigned a direct (non-eligible) Contributor role and the deployment failed due to Azure RBAC propagation delay, typically within 5 minutes.
This option would be correct if the question stated that the contractor needs to grant Contributor access to a new user who is not part of any group, and the requirement is to use a group for role assignment to simplify management, without any PIM or eligibility constraints.
This would be correct if the contractor had an active role assignment that was not yet reflected in the portal due to propagation delay, and the question stated that the role was already active but the portal showed an error.
Why candidates pick the wrong answer
Candidates may confuse eligible role activation with direct role assignment propagation, assuming a delay is the cause when the real issue is that the role is not active.
Candidates may think that a direct role assignment to a new group bypasses the activation requirement, misunderstanding that the eligibility is tied to the user's role assignment, not the group membership.
Candidates may think a simple sign-out/sign-in refreshes cached permissions or group memberships, similar to how it can resolve some access token issues in other scenarios.
You need to allow or deny traffic to and from resources in an Azure subnet based on source IP address, destination port, and protocol. Which Azure feature should you use?
A network security group (NSG) is the Azure resource that acts as a distributed virtual firewall for inbound and outbound traffic. It contains security rules that apply a priority, source/destination address, port, and protocol to explicitly allow or deny traffic at a subnet or network interface (NIC) level. By default, NSGs include built-in rules like allowing virtual network traffic and denying all internet-inbound traffic, but you can override these with custom rules. Associating an NSG with a subnet is the standard method for controlling traffic to and from resources inside that subnet.
Why this answer
A network security group (NSG) is the correct Azure feature because it acts as a stateful, distributed firewall that filters traffic to and from Azure resources in a virtual network. NSGs contain security rules that allow or deny inbound and outbound traffic based on source/destination IP address, port, and protocol (TCP, UDP, or ICMP). This directly matches the requirement to control traffic based on source IP, destination port, and protocol.
Exam trap
The trap here is that candidates often confuse route tables (which control traffic paths) with NSGs (which control traffic permissions), especially when the question mentions 'allow or deny traffic'—route tables never deny traffic, they only redirect it.
Why the other options are wrong
Route tables control network traffic routing paths, not allow/deny rules based on source IP, destination port, or protocol. They determine where traffic goes, not whether it is permitted.
A private DNS zone is used for custom domain name resolution within a virtual network, not for filtering traffic based on source IP, port, or protocol.
Azure Advisor provides recommendations for best practices in cost, security, reliability, and performance, but it does not allow or deny traffic based on source IP, port, or protocol.
When would these options actually be correct?
You need to control the next hop for traffic leaving a subnet, such as forcing all internet-bound traffic through a network virtual appliance. A route table with custom routes would be the correct answer.
You need to resolve a custom domain name (e.g., contoso.com) to private IP addresses within your Azure virtual network, ensuring that resources in the VNet can resolve the name without exposing it to the internet.
You need to identify and implement recommendations to improve the security posture of your Azure resources, such as enabling network security groups or applying just-in-time VM access. Azure Advisor would provide the relevant security recommendations.
Why candidates pick the wrong answer
Candidates may confuse routing (path selection) with filtering (permission), assuming that controlling routes can also block traffic, but route tables do not provide access control lists.
Candidates may confuse DNS with network security, thinking that DNS zones can control access by resolving names to different IPs, but they do not filter traffic.
Candidates may confuse Azure Advisor's security recommendations with actual traffic filtering capabilities, thinking it can directly control network access.
A web app currently accesses Azure Blob Storage by using the storage account key in a connection string. Security now requires blocking any new requests that use shared key authorization, while Microsoft Entra-based access must continue to work. Which storage account setting should the administrator change?
Disabling shared key authorization blocks new requests that rely on the account key, while still allowing Microsoft Entra-based authentication paths. This is the correct control when the goal is to stop key-based access without disabling modern identity-based access.
Why this answer
Disabling shared key authorization on the storage account explicitly blocks all requests that use the storage account key (shared key) for authentication, while still allowing requests authenticated via Microsoft Entra ID (formerly Azure AD). This directly meets the security requirement to block new requests using shared key authorization without affecting Entra-based access.
Exam trap
The trap here is that candidates often confuse network-level restrictions (firewall/VNet) with authentication-level controls, mistakenly thinking that limiting network access (Option A) is equivalent to blocking shared key authorization, when in fact it only controls which IPs or VNets can reach the storage account, not how they authenticate.
Why the other options are wrong
Setting network access to selected networks only restricts access based on IP address or virtual network, not authentication method. It does not block shared key authorization; it only limits which networks can reach the storage account.
Rotating the account keys does not disable shared key authorization; it only changes the keys. The question requires blocking new requests using shared key authorization, which is achieved by disabling shared key authorization entirely, not by rotating keys.
Object replication is used to asynchronously copy blobs between storage accounts for data redundancy or compliance, not to control authentication methods. It does not block shared key authorization.
When would these options actually be correct?
This option would be correct if the question asked: 'A web app must only be accessible from a specific corporate network. Which setting should the administrator configure to restrict access to the storage account?'
This option would be correct in a scenario where the question asks for a security best practice to mitigate a potential key compromise without disrupting existing connections, or where the requirement is to periodically update keys to reduce the risk of unauthorized access while keeping shared key authorization enabled.
A question asks: 'You need to ensure that blob data is automatically copied to a secondary region for disaster recovery. Which storage account setting should you configure?'
Why candidates pick the wrong answer
Candidates may confuse network-level access control with authentication method control, thinking that restricting network access also blocks shared key authorization.
Candidates may think that rotating keys is a way to enforce security and block unauthorized access, confusing key rotation with disabling the authentication method itself.
Candidates may confuse 'replication' with 'authentication' or think that enabling replication somehow overrides or replaces shared key access, not understanding that replication is a data feature, not a security control.
A Windows VM runs an application that uploads files to a blob container every hour. Security forbids storing storage account keys or long-lived SAS tokens on the VM. The application must be able to write only to that container and nothing else. What should the administrator configure?
A managed identity avoids stored credentials, and the Storage Blob Data Contributor role grants blob read/write permissions without exposing account keys. Assigning it at the container scope keeps access limited to one container instead of the whole storage account. This is the least-privilege, Azure-native approach for an app that needs ongoing upload access.
Why this answer
It uses Azure RBAC to grant the VM's managed identity the Storage Blob Data Contributor role at the container scope. This allows the application to write only to that specific container without requiring any storage account keys or SAS tokens on the VM, satisfying the security requirement. Managed identities provide an automatically managed service principal in Azure AD, enabling secure authentication to Azure services without storing credentials.
Exam trap
The trap here is that candidates often confuse the Contributor role (which grants management-plane access) with the Storage Blob Data Contributor role (which grants data-plane access), and fail to realize that scoping the role to the container level is necessary to restrict access to only that container.
Why the other options are wrong
Storing the storage account key in an environment variable violates the security requirement that forbids storing keys on the VM. The key grants full access to the storage account, not just the container.
A service SAS with write permission on the storage account would grant write access to all containers within the account, violating the requirement to restrict writes to only that specific container. Additionally, long-lived SAS tokens are forbidden by security policy.
Contributor role at the storage account scope grants full management access to the storage account, including the ability to read and write all containers and blobs, which violates the principle of least privilege and the requirement to restrict the application to write-only access to a single container.
When would these options actually be correct?
If the question had no security restriction against storing keys and required the simplest method to grant an application access to a storage account, storing the key in an environment variable would be a valid approach.
If the requirement was to grant write access to all containers in a storage account for a limited time, and the VM could securely retrieve a short-lived SAS token from a vault or generate it at runtime, a service SAS with write permission at the account level would be appropriate.
If the question required the VM to have full management access to the storage account (e.g., to create/delete containers, manage firewall rules, or perform all data operations) and security constraints allowed broader permissions, then assigning Contributor at the storage account scope to the managed identity would be appropriate.
Why candidates pick the wrong answer
Candidates may think environment variables are a secure way to store secrets, or they may default to using keys because it's a familiar method without considering the security constraint.
Candidates may think a SAS token provides fine-grained access without needing keys, but they overlook that a service SAS at the account level grants broader permissions than needed, and the security policy prohibits long-lived tokens.
Candidates may confuse 'Contributor' with a data role, or think that assigning a role to the managed identity is the correct approach but overlook the scope and permission level, assuming Contributor provides sufficient write access without realizing it includes excessive permissions.
A team wants an Azure Storage account to be reachable only from one subnet, but they do not want to use a private endpoint. Which two configurations should they use? Select two.
A service endpoint extends the subnet's identity to the storage service without creating a private IP address.
Why this answer
Enabling a Microsoft.Storage service endpoint on the subnet extends the virtual network identity to the storage service, allowing traffic from that subnet to reach the storage account over the Azure backbone network without using a public IP. This ensures private connectivity from the subnet to the storage account while keeping the storage account's public endpoint enabled but restricted.
Exam trap
The trap here is that candidates confuse Azure RBAC roles (which control management access) with network-level access controls (firewall rules and service endpoints), leading them to incorrectly select option D.
Why the other options are wrong
The question explicitly states 'they do not want to use a private endpoint,' so creating a private endpoint contradicts the requirement. Additionally, leaving the firewall open to all networks would not restrict access to one subnet.
Azure RBAC roles like Contributor control permissions to manage resources, not network access. Assigning Contributor to a subnet does not restrict network traffic to the storage account; it only grants management rights to identities in that subnet.
Disabling the public endpoint would make the storage account unreachable from the subnet without a private endpoint or service endpoint, and relying on Internet routing does not restrict access to a single subnet.
When would these options actually be correct?
If the question required secure access from a subnet without using a service endpoint, and the subnet was in a different VNet or required private IP connectivity, then a private endpoint would be the correct choice. For example: 'You need to access a storage account from a subnet in a peered VNet without traversing the internet.'
In a scenario where the question asks how to grant a subnet's virtual machines permission to manage (e.g., read/write data in) a storage account, assigning the Contributor role to the subnet's managed identity or service principal would be correct.
If the question asked for a method to completely block all public access and allow access only through a private endpoint from a specific subnet, then disabling the public endpoint would be correct.
Why candidates pick the wrong answer
Candidates may confuse private endpoints with service endpoints, thinking both are valid for subnet restriction, or they may overlook the explicit constraint against using a private endpoint in the question.
Candidates may confuse Azure RBAC with network access controls, thinking that assigning a role to a subnet will restrict connectivity, when in fact RBAC governs control plane operations, not data plane network access.
Candidates may think that disabling the public endpoint inherently limits access to a specific subnet, not realizing that without a service endpoint or private endpoint, the subnet cannot reach the storage account at all.
Based on the exhibit, which deployment choice should the administrator use to keep the application available if one datacenter in the Azure region fails?
Availability zones place resources in physically separate datacenters within the region. If one datacenter fails, the other zone can continue serving traffic. This matches the requirement for surviving a single datacenter outage and is the preferred Azure design when zone support is available.
Why this answer
Availability zones are physically separate datacenters within an Azure region, each with independent power, cooling, and networking. Deploying VMs across separate availability zones ensures that if one datacenter fails, the application remains available in the other zone, providing resilience against datacenter-level failures.
Exam trap
The trap here is that candidates often confuse availability sets (which protect against rack failures) with availability zones (which protect against datacenter failures), leading them to incorrectly choose an availability set for datacenter-level resilience.
Why the other options are wrong
An availability set protects against rack-level failures within a single datacenter, not against a full datacenter failure. If one datacenter fails, all VMs in the same availability set (which are in that datacenter) become unavailable.
Larger VM sizes improve performance but do not provide redundancy or fault isolation; if a datacenter fails, all VMs in that datacenter are affected regardless of size.
When would these options actually be correct?
If the question required high availability for VMs within a single datacenter (e.g., to protect against hardware failure or maintenance within the same datacenter), placing VMs in the same availability set would be correct.
In a scenario where the application is experiencing performance bottlenecks due to insufficient compute resources and the question asks for a solution to improve throughput or reduce latency without changing the number of VMs.
Why candidates pick the wrong answer
Candidates often confuse availability sets with availability zones, thinking that an availability set provides redundancy across datacenters, when it only provides redundancy within a single datacenter.
Candidates may mistakenly believe that larger VMs are more resilient or that higher capacity inherently protects against failures, confusing performance scaling with availability.
An on-premises datacenter must reach private IP addresses in Azure over an encrypted site-to-site tunnel. The Azure VMs must not have public IP addresses, and the connection should use the company's existing edge device. Which Azure component should be deployed?
VPN Gateway terminates the encrypted site-to-site tunnel and enables private connectivity from on-premises to Azure VNets. It works with the on-premises edge device and allows access to Azure private IPs without assigning public IPs to the target VMs.
Why this answer
Azure VPN Gateway is the correct component because it provides an encrypted site-to-site IPsec/IKE tunnel between an on-premises network and Azure virtual networks. It supports policy-based or route-based VPNs, works with existing edge devices, and allows Azure VMs to remain without public IP addresses by routing traffic through the gateway's private IP space.
Why the other options are wrong
Azure Bastion provides secure RDP/SSH access to VMs without public IPs, but it does not create an encrypted site-to-site tunnel from on-premises to Azure private IPs.
Azure Route Server is used for dynamic routing between network virtual appliances (NVAs) and Azure virtual networks, not for creating encrypted site-to-site tunnels to on-premises datacenters.
A network security group (NSG) filters traffic but does not provide encrypted site-to-site connectivity or routing between on-premises and Azure private IPs.
When would these options actually be correct?
An exam question asking for a service that allows secure browser-based RDP/SSH connectivity to Azure VMs without public IPs, using a bastion host deployed in the same virtual network.
An organization has multiple NVAs in Azure that need to exchange routes with an on-premises network via BGP, and they want to simplify route management without configuring BGP on each NVA individually.
An NSG with inbound allow rules would be correct in a scenario where you need to control which source IPs can access Azure VMs over an existing encrypted connection (e.g., via ExpressRoute or VPN already in place), and the question focuses on security filtering rather than establishing connectivity.
Why candidates pick the wrong answer
Candidates may confuse 'secure access without public IPs' with the site-to-site VPN requirement, overlooking that Bastion is for management access, not network connectivity.
Candidates may confuse Route Server's role in routing with VPN Gateway's role in tunneling, assuming it can handle site-to-site connectivity because it deals with network routes.
Candidates may think NSGs can secure the tunnel or allow traffic, confusing network security with VPN connectivity, or they overlook that NSGs alone cannot create a site-to-site VPN.
A support engineer must restart and view the properties of virtual machines only in RG-Dev. The engineer must not gain access to other resource groups in the subscription. What should the administrator do?
Assigning the Virtual Machine Contributor role at the RG-Dev scope provides exactly the required permissions: Microsoft.Compute/virtualMachines/read to view properties and Microsoft.Compute/virtualMachines/restart to restart VMs, while limiting inheritance to that resource group. This follows least privilege because the engineer can manage VMs in RG-Dev but cannot touch VMs or other resources elsewhere in the subscription.
Why this answer
The Virtual Machine Contributor role at the RG-Dev scope grants the engineer the necessary permissions to restart and view properties of virtual machines within that resource group, while restricting access to other resource groups. This role includes actions like Microsoft.Compute/virtualMachines/start/action and Microsoft.Compute/virtualMachines/read, which cover the required tasks without granting broader management rights.
Exam trap
The trap here is that candidates often choose Option A, mistakenly thinking the Reader role at subscription scope is harmless, but it actually grants read access to all resources in the subscription, violating the explicit restriction to RG-Dev only.
Why the other options are wrong
Assigning Reader at subscription scope grants read access to all resources in the subscription, violating the requirement that the engineer must not access other resource groups.
The Contributor role includes write permissions beyond restarting and viewing properties, such as deleting resources or creating new ones, which violates the least privilege principle required by the question.
Assigning a custom role at subscription scope would grant permissions across all resource groups, violating the requirement that the engineer must not access other resource groups.
When would these options actually be correct?
If the requirement were to allow the engineer to view (but not restart) VMs in RG-Dev and also view (but not modify) resources in other resource groups, then Reader at subscription plus Virtual Machine Contributor at RG-Dev would be correct.
If the question required the engineer to have full management access to RG-Dev (e.g., deploy, delete, and modify all resources) but no access to other resource groups, the Contributor role at RG-Dev scope would be correct.
If the requirement was to grant specific permissions (e.g., restart and view properties) across multiple resource groups or the entire subscription, and no built-in role met the need, a custom role at subscription scope would be appropriate.
Why candidates pick the wrong answer
Candidates may think Reader at subscription is harmless for viewing, but it still grants read access to other resource groups, which is prohibited.
Candidates may think Contributor is the minimum role for restarting VMs, overlooking that Virtual Machine Contributor is more restrictive and sufficient for the task.
Candidates may think a custom role is needed to precisely limit permissions, but overlook that scoping it at subscription level grants access to all resource groups, not just RG-Dev.
An administrator added an NSG rule named Allow-Admin-HTTPS with priority 250 to permit inbound TCP 443 from a single public IP. The NSG also contains a Deny-All-Inbound rule with priority 200. The administrator still cannot connect to the VM over HTTPS from the allowed IP. What should be changed to resolve the issue?
NSG rules are evaluated in ascending priority order, so the lower number is processed first. Because Deny-All-Inbound at 200 is taking effect before the allow rule at 250, the connection is blocked. Moving the allow rule to a priority such as 150 ensures the specific HTTPS exception is matched before the broad deny rule.
Why this answer
The Deny-All-Inbound rule with priority 200 is evaluated before the Allow-Admin-HTTPS rule with priority 250 because NSG rules are processed in order of ascending priority (lower numbers are evaluated first). Since the deny rule matches all inbound traffic, it blocks the HTTPS connection before the allow rule can be evaluated. To resolve this, the allow rule must have a priority lower than 200 (e.g., 150) so it is evaluated first and permits the traffic from the specified public IP.
Exam trap
The trap here is that candidates often assume higher priority numbers mean higher precedence, but in Azure NSGs, lower priority numbers are evaluated first, so a deny rule with a lower number will block traffic before a higher-numbered allow rule can permit it.
Why the other options are wrong
In Azure, NSG rules are evaluated in priority order, with lower numbers evaluated first. A deny rule with priority 200 is evaluated before an allow rule with priority 250, so changing the deny rule priority to 65000 (a higher number) would cause it to be evaluated later, but the allow rule still has a higher priority number (250) than the deny rule (200), so the deny rule would still be evaluated first. The correct fix is to lower the allow rule priority below 200.
The issue is that the Deny-All-Inbound rule with priority 200 is evaluated before the Allow-Admin-HTTPS rule with priority 250, blocking the traffic. Changing the allow rule to outbound would not affect inbound HTTPS traffic, which is the problem.
Route tables control traffic routing between subnets and on-premises networks, not traffic filtering. They cannot permit or deny specific ports like HTTPS; NSGs are required for that.
When would these options actually be correct?
This option would be correct if the question stated that the deny rule was blocking traffic that should be allowed, and the goal was to ensure the deny rule is evaluated last (e.g., to allow all other traffic by default). For example, if the question said: 'An NSG has an allow rule for RDP and a deny-all rule with priority 100. The administrator wants to ensure that the deny-all rule is evaluated last.
What should be done?'
In a scenario where a VM needs to initiate HTTPS connections to an external server, and outbound traffic is being blocked by a default deny outbound rule, adding an outbound allow rule with appropriate priority would resolve the issue.
A question where a VM in a subnet cannot reach the internet or another network due to missing or incorrect routes (e.g., no default route to the internet), and the solution is to add a route table with a proper next hop.
Why candidates pick the wrong answer
Candidates may think that increasing the deny rule's priority number (making it lower priority) will allow the allow rule to take effect, but they overlook that the allow rule's priority (250) is already higher than the deny rule's (200), so the deny rule is still evaluated first. They might also confuse priority numbers with precedence, thinking higher numbers are evaluated first.
Candidates may confuse inbound and outbound traffic directions, thinking that allowing outbound HTTPS would permit the connection, or they might misremember that NSG rules are stateful and assume outbound rules affect inbound traffic.
Candidates may confuse routing (route tables) with filtering (NSGs), thinking that a route table can allow traffic by directing it, rather than understanding that NSGs are the firewall for port-based access control.
Several Azure VMs need the same Azure identity so they can access a shared resource without storing passwords. The identity should be reusable across VMs and removable centrally. Which identity type should the administrator use?
A user-assigned managed identity is a standalone Azure AD identity created as its own Azure resource, and it can be attached to multiple VMs at once. Because the identity's lifecycle is independent of any single VM, the same principal and its role assignments can be used across a fleet, and Azure automatically rotates the underlying certificates used for token acquisition. This gives the VMs a consistent, secret-less identity for authenticating to Azure services such as Key Vault or Storage.
Why this answer
A user-assigned managed identity is the correct choice because it is created as a standalone Azure resource, can be assigned to multiple VMs simultaneously, and can be centrally removed or updated without affecting the VMs themselves. This identity is reusable across VMs and eliminates the need to store passwords or secrets in code or configuration.
Exam trap
The trap here is that candidates often choose system-assigned managed identity because it is simpler to configure, but they overlook the requirement for the identity to be reusable across multiple VMs, which only user-assigned managed identities support.
Why the other options are wrong
A system-assigned managed identity is tied to a single VM and cannot be reused across multiple VMs; it is created and deleted with the VM, not centrally removable.
A service principal with a client secret requires storing and managing a secret, which contradicts the requirement to avoid storing passwords. It is also not reusable across VMs in a centralized, removable way like a managed identity.
A local administrator account is tied to a single VM, cannot be reused across multiple VMs, and requires password management, which contradicts the requirement for a centrally removable identity without storing passwords.
When would these options actually be correct?
If the question required an identity that is automatically created and tied to a single Azure resource (e.g., a VM that needs to access a resource without manual credential management), system-assigned managed identity would be correct.
When an application running outside Azure (e.g., on-premises or another cloud) needs to authenticate to Azure resources, and the identity must be managed independently of any specific VM lifecycle.
Why candidates pick the wrong answer
Candidates may confuse 'system-assigned' with 'user-assigned' or assume that any managed identity can be shared, overlooking the per-resource binding of system-assigned identities.
Candidates may confuse service principals with managed identities, thinking a service principal is the only way to grant Azure AD-based access, or they may overlook the 'no password storage' constraint.
Candidates may think a local admin account is a simple, familiar identity solution for VMs, overlooking the need for cross-VM reusability and central management.
A data disk on VM-Data01 was corrupted after a bad patch, and you already have a snapshot taken last night. The OS disk should remain unchanged. Which two actions should you take to restore only the data disk? Select two.
In Azure, a snapshot is a point-in-time read-only copy of a managed disk and cannot be attached directly to a VM. You must first create a new managed disk using the snapshot as its source (for example, with New-AzDisk specifying the snapshot ID or via the portal's 'Create disk from snapshot' action), selecting the required storage SKU, size, and zone. This produces a writable, independently managed disk that can then be attached for recovery.
Why this answer
A snapshot is a point-in-time copy of a disk that can be used to create a new managed disk. Since you have a snapshot of the corrupted data disk from last night, creating a managed disk from that snapshot restores the data to its state at the time of the snapshot, leaving the OS disk untouched.
Exam trap
The trap here is that candidates may confuse redeploying a VM (which only moves the VM to a new host) with restoring disk data, or mistakenly think a snapshot can be directly attached to a VM without first creating a managed disk.
Why the other options are wrong
Redeploying a VM does not revert the data disk to a previous state; it only migrates the VM to a new host while preserving the existing disks. The corrupted data disk would remain corrupted after redeployment.
Generalizing the VM (via Sysprep) prepares the OS for imaging, which is unnecessary and destructive for a simple data disk restore. It would reset the VM's identity and potentially break applications, while the snapshot is only for the data disk.
Replacing the snapshot with the current data disk would overwrite the snapshot, not restore the data disk. The goal is to restore the data disk from the snapshot, not replace the snapshot.
When would these options actually be correct?
This option would be correct if the question asked how to resolve a VM connectivity issue or a host-level problem (e.g., VM stuck in a failed state) without changing disk data. In that case, redeploying the VM can fix the issue by moving it to a new host.
This option would be correct in a scenario where you need to create a new VM from a snapshot of the OS disk (e.g., after a critical OS corruption) and you want to reuse the same VM name or deploy a standardized image. The question would specify 'OS disk snapshot' and 'create a new VM'.
If the question asked to update a snapshot to reflect the current state of a data disk (e.g., after applying a patch that you want to capture for future rollbacks), then replacing the snapshot with the current disk would be correct.
Why candidates pick the wrong answer
Candidates may confuse 'redeploy' with 'restore from snapshot,' assuming redeployment automatically reverts all disks to a previous state, similar to a system restore point.
Candidates may confuse the process of restoring a data disk with creating a new VM from a snapshot, or they might think generalizing is a standard step for any disk recovery, not realizing it's specific to OS disk imaging.
Candidates may confuse the direction of restoration, thinking that 'replacing' the snapshot with the disk is a way to roll back, but it actually destroys the snapshot without restoring the disk.
A finance team wants every resource created in one production resource group to carry CostCenter=PRD automatically. They do not want deployments blocked if a team forgets the tag, but they do want existing resources and future resources in that resource group to converge on the correct tag value. What should the administrator configure?
A modify policy can add or correct the tag without blocking deployment, which matches the business requirement. Assigning it at the resource-group scope limits the effect to only that production workload, and remediation updates existing resources so both old and new items converge on the same tag value.
Why this answer
Azure Policy with a 'modify' effect can automatically add or correct the CostCenter tag on resources within the specified scope. By assigning the policy at the production resource group scope and creating a remediation task, the policy will audit existing resources and, via a managed identity, apply the tag value to non-compliant resources without blocking deployment. This satisfies the requirement for automatic convergence without preventing creation if the tag is missing.
Exam trap
The trap here is confusing Azure Policy's 'modify' effect (which allows non-blocking correction) with 'deny' or 'append' effects (which block or add without remediation), or assuming that tags on management groups automatically propagate to resources, which they do not.
Why the other options are wrong
A CanNotDelete lock prevents resource deletion but does not enforce or propagate tags. It does not automatically add or correct tags on existing or new resources.
Assigning Contributor at the subscription level does not enforce automatic tagging; it only grants permissions. Teams could still forget to add the tag manually, and there is no mechanism to remediate existing resources or enforce convergence.
Tags set on a management group are not inherited by resources in child resource groups; inheritance only applies to policies and RBAC, not tags. Therefore, this option would not automatically apply the CostCenter tag to resources.
When would these options actually be correct?
An administrator needs to prevent accidental deletion of critical resources in a resource group, regardless of tag compliance. The question would specify that tag enforcement is not required, only protection against deletion.
This option would be correct if the requirement was to delegate tagging responsibility to teams with appropriate permissions, without any automatic enforcement or remediation. For example, if the question stated 'Teams must be able to assign tags themselves, but there is no requirement for automatic tagging or remediation.'
This would be correct if the question asked about applying an Azure Policy (e.g., 'inherit a tag from the resource group if missing') at the management group scope, which can enforce tag inheritance via policy, not by simply setting a tag on the management group.
Why candidates pick the wrong answer
Candidates may confuse locks with governance controls, thinking a lock can enforce tag values, or they may misread the requirement as preventing deletion of untagged resources.
Candidates may think that granting Contributor role allows administrators to enforce tagging through permissions, but they overlook that Contributor does not automatically apply tags or remediate non-compliant resources.
Candidates may mistakenly believe that tags set at higher scopes (management group) automatically propagate to lower scopes (resource groups and resources), similar to how RBAC or policy assignments inherit.
Which two statements about network security group processing are correct? Select two.
Azure Network Security Group rules are evaluated in ascending priority-number order, so the rule with the smallest numeric value (for example, 100) is processed before rules numbered 200 or 1000. The first rule whose source, destination, port, and protocol match the traffic is applied, and no later rules are evaluated. This numeric priority design ensures deterministic, predictable filtering regardless of rule order in the portal or ARM template.
Why this answer
NSG rules are processed in order of increasing priority number, meaning the rule with the lowest priority number (e.g., 100) is evaluated first. This ensures that more specific or critical rules can be applied before broader rules with higher priority numbers.
Exam trap
The trap here is that candidates often confuse NSG rule processing order with alphabetical or sequential naming, or mistakenly believe NSGs cannot be applied to NICs, leading them to select options B or E instead of the correct priority-based evaluation logic.
Why the other options are wrong
An NSG can be linked to both a subnet and a network interface card (NIC), not just a subnet. This is a fundamental capability of NSGs in Azure.
Azure does not ignore NSG rules when a route table is attached. NSGs and route tables operate independently: NSGs filter traffic, while route tables control traffic routing. Both can be applied to the same subnet without conflict.
NSG rules are processed in priority order (lowest number first), not alphabetically by name. Rule names are for identification only and have no effect on evaluation order.
When would these options actually be correct?
If the question stated 'An NSG can be linked only to a subnet, not to a virtual network' or 'An NSG can be linked only to a subnet, not to a virtual machine directly' (without mentioning NIC), then this option could be correct because NSGs are associated at subnet or NIC level, not directly to a VM or VNet.
This option would be correct if the question stated: 'Which statement about Azure network security is true?' and the scenario involved a forced tunneling configuration where a route table directs all traffic to a network virtual appliance, effectively bypassing NSG inspection for certain traffic flows. However, even then, NSG rules are not ignored; they are still evaluated.
This would be correct in a question about Azure Policy or role-based access control (RBAC) where policy rules or role assignments are evaluated alphabetically by name when priorities are equal.
Why candidates pick the wrong answer
Candidates may confuse NSG association with other Azure resources that are subnet-only, or they may incorrectly recall that NSGs are only for subnets, overlooking the NIC-level association.
Candidates may confuse the functions of NSGs and route tables, thinking that a route table overrides NSG rules because both can be associated with subnets. They might also recall that user-defined routes can influence traffic flow, leading to the incorrect assumption that NSGs are bypassed.
Candidates may assume that since many IT systems process rules alphabetically (e.g., firewall rule lists), Azure NSGs follow the same pattern, overlooking the explicit priority number system.
Your application stores regulatory records in Azure Blob Storage. The records must remain in a write-once-read-many state for four years and must not be altered or deleted during that time. What should you configure?
Immutable blob storage with a time-based retention policy provides WORM (Write Once, Read Many) protection at the container level, explicitly preventing any modification or deletion of blobs for the configured retention period. This satisfies regulatory requirements for records retention (e.g., SEC 17a-4) because even the storage account owner cannot overwrite or purge the data. The policy is enforced by Azure Storage itself, independent of client permissions, making it a true compliance-grade control.
Why this answer
Immutable blob storage with a time-based retention policy enforces a write-once-read-many (WORM) state, ensuring that blobs cannot be modified or deleted for a specified duration. This directly meets the regulatory requirement of four-year retention without alteration or deletion, as the policy locks the data at the container level and prevents any changes until the retention period expires.
Exam trap
The trap here is that candidates often confuse soft delete (which only protects against deletion) with immutable storage (which prevents both modification and deletion), leading them to choose blob soft delete when the question explicitly requires a write-once-read-many state.
Why the other options are wrong
Blob soft delete protects against accidental deletion but does not prevent overwrites or enforce a write-once-read-many (WORM) state, so it cannot ensure records remain unaltered for four years.
Lifecycle management moves data to Archive tier based on age, but does not prevent deletion or modification. The question requires a write-once-read-many (WORM) state with deletion protection, which lifecycle management cannot enforce.
A shared access signature (SAS) provides delegated access to storage resources but does not enforce write-once-read-many (WORM) compliance or prevent deletion or modification of blobs.
When would these options actually be correct?
A question requiring protection against accidental deletion of blobs for a specific retention period, without needing to prevent overwrites or modifications, would make blob soft delete correct.
A question asks: 'You need to automatically move blobs older than 90 days to cool storage to reduce costs. What should you configure?' In that scenario, lifecycle management is the correct answer.
A question requiring time-limited, secure access to a specific blob or container for a third-party application, without exposing the storage account key, would make a SAS the correct answer.
Why candidates pick the wrong answer
Candidates may confuse soft delete with immutable storage because both offer data protection, but soft delete only handles deletion, not modification, leading to a false sense of compliance.
Candidates may confuse cost optimization (archiving old data) with data protection requirements, assuming that moving data to Archive also prevents modification, which it does not.
Candidates may confuse access control mechanisms with data protection policies, thinking that restricting access via SAS can prevent unauthorized modifications or deletions.
A build pipeline needs to run a Linux container for about 15 minutes whenever a request arrives. The job never needs inbound traffic, clustering, or persistent node management. A second workload is a public web app that needs built-in TLS, deployment slots, and autoscale. Which two Azure compute services should the administrator choose? Select two.
This is a serverless container host that fits short-lived, on-demand container jobs.
Why this answer
Azure Container Instances (ACI) is the correct choice for the first workload because it allows you to run a Linux container on demand without managing any underlying infrastructure, and it supports a 15-minute execution time perfectly with its per-second billing and no requirement for persistent nodes or inbound traffic. Azure App Service is correct for the second workload because it natively provides built-in TLS/SSL termination, deployment slots for staging and swapping, and autoscale capabilities out of the box, making it ideal for a public web app.
Exam trap
The trap here is that candidates often choose Azure Kubernetes Service for any container workload, overlooking that ACI is simpler and cheaper for ephemeral, single-container tasks, and they may also pick Azure Functions for the web app without realizing it lacks native deployment slots and built-in TLS management compared to App Service.
Why the other options are wrong
Azure Kubernetes Service (AKS) is overkill for a simple Linux container that runs for 15 minutes on demand without clustering or persistent node management. For the public web app, AKS does not provide built-in TLS, deployment slots, or autoscale out of the box; these require additional configuration.
Azure Virtual Machines require persistent node management, inbound traffic handling, and clustering, which are unnecessary for the short-lived Linux container job. For the public web app, VMs lack built-in TLS, deployment slots, and autoscale without additional configuration.
Azure Functions is event-driven and designed for short-lived executions (typically under 10 minutes), not for a 15-minute container run on demand. It also lacks native container support for arbitrary images.
When would these options actually be correct?
A question requiring orchestration of multiple containers with complex networking, persistent storage, or rolling updates would make AKS correct. For example: 'A company needs to deploy a microservices application with 10 containers that require service discovery, load balancing, and automated rollouts. Which service should they choose?'
A question requiring a custom OS configuration, full control over the operating system, or legacy application support that cannot be containerized. For example: 'A company needs to migrate an on-premises monolithic application that requires a specific Windows Server version and third-party software installed on the OS.'
A workload requires running a short-lived, event-driven function (e.g., processing a queue message or HTTP trigger) that completes in under 10 minutes, with no need for custom container images or persistent state.
Why candidates pick the wrong answer
Candidates may think AKS is the only option for running containers in Azure, or they may overestimate the complexity of the workloads, assuming container orchestration is always needed.
Candidates may default to VMs as a familiar, general-purpose compute option, overlooking that the question specifies no need for persistent management and requires built-in features like TLS and deployment slots that App Service provides out-of-the-box.
Candidates may confuse Azure Functions with container-based compute because both can run code on demand, overlooking the execution time limit and lack of container hosting for arbitrary images.
A contractor needs temporary access to upload files into one Azure Blob container for six hours. The administrator does not want to share the storage account key. What should the administrator create?
A SAS can grant limited, time-bound access to a specific resource such as one container, without exposing the storage account key.
Why this answer
A shared access signature (SAS) scoped to the container provides time-limited, delegated access to specific operations (e.g., upload) without exposing the storage account key. By setting an expiration time of six hours, the administrator ensures the contractor can upload files only during that window, after which the token becomes invalid. This meets the requirement for temporary, secure access.
Exam trap
The trap here is that candidates may confuse a SAS with a storage account key, thinking any shared credential is unsafe, or mistakenly choose a private endpoint as a security solution for access control rather than network isolation.
Why the other options are wrong
Sharing the storage account access key grants full access to all storage services and containers, which violates the requirement to limit access to a single container for a specific time period.
A management group assignment manages access and policies across multiple subscriptions, not temporary access to a single blob container. It does not provide time-limited, container-specific access.
A private endpoint restricts network access to the storage account but does not provide temporary, scoped access to a specific container without sharing the account key.
When would these options actually be correct?
If the question required granting full administrative access to a storage account for a trusted internal team member with no time restriction, sharing the access key would be appropriate.
An administrator needs to apply the same Azure Policy, such as requiring tags on all resources, to multiple subscriptions under a management group. Creating a management group assignment would enforce the policy across those subscriptions.
An administrator needs to ensure that only traffic from a specific virtual network can access a storage account, while blocking all public internet access. In that case, creating a private endpoint would be correct.
Why candidates pick the wrong answer
Candidates may think that any access key provides limited access, but they overlook that storage account keys grant unrestricted access to all data in the account.
Candidates may confuse management groups with role assignments or think they can be used to grant granular access, but management groups are for organizing subscriptions and applying governance, not for direct data access.
Candidates may think a private endpoint provides secure, temporary access by isolating the storage account, but it does not grant time-limited permissions to a specific container.
Based on the exhibit, which Network Watcher tool should you use to determine whether an NSG allows or denies TCP 1433 traffic and which rule is responsible?
IP flow verify is the correct choice because it evaluates a specific 5-tuple (source IP, destination IP, protocol, and source/destination ports) against the effective NSG rules applied to a virtual machine's NIC or subnet. It returns an explicit allow/deny result along with the rule ID that permitted or blocked the traffic, making it purpose-built for answering 'does this NSG allow this TCP flow?' Unlike broader connectivity tests, it isolates NSG rule evaluation as the sole decision factor, so you know exactly which rule is responsible.
Why this answer
IP flow verify tests a specific source/destination IP, port, and protocol (TCP 1433) against the effective NSG rules to report whether traffic is allowed or denied, and it identifies the exact NSG rule (name and priority) responsible for that decision. This makes it the correct tool for determining NSG rule impact on a specific traffic flow.
Exam trap
The trap here is that candidates confuse 'Connection troubleshoot' (which tests end-to-end connectivity) with 'IP flow verify' (which specifically tests NSG rule evaluation), leading them to pick B because they think connectivity checks include rule analysis.
Why the other options are wrong
Connection troubleshoot tests connectivity from a source VM to a destination, but it does not identify which specific NSG rule is allowing or denying traffic; it only reports overall reachability.
Packet capture captures network traffic for analysis but does not evaluate NSG rules against a specific traffic flow to determine if traffic is allowed or denied and which rule is responsible.
Next hop is used to determine the next hop type and IP address for a specific destination, not to check if NSG rules allow or deny traffic. It does not evaluate NSG rules.
When would these options actually be correct?
Connection troubleshoot would be correct if the question asked to verify end-to-end TCP connectivity from a specific VM to a destination IP/port, including checks for NSG, route, and other issues, without needing to identify the exact rule.
Packet capture is correct when the question asks to capture and inspect network packets to diagnose issues like packet loss, latency, or protocol anomalies, such as 'Which tool should you use to capture inbound and outbound packets from a VM to analyze a connectivity issue?'
When you need to find out the next hop type (e.g., Internet, VirtualNetwork, VirtualAppliance) and IP address for traffic from a VM to a specific destination IP, such as troubleshooting asymmetric routing or verifying traffic path through a network virtual appliance.
Why candidates pick the wrong answer
Candidates may confuse 'troubleshoot connectivity' with 'verify NSG rules,' assuming that a connectivity test will also reveal the specific rule, but it only provides a pass/fail result.
Candidates may think packet capture can show whether traffic is blocked, but it does not directly map traffic to NSG rules; it only shows the traffic that actually flows.
Candidates may confuse 'next hop' with 'IP flow verify' because both involve network paths; they might think next hop also checks NSG rules, but it only shows routing decisions.
A shared resource group contains a VPN gateway and several virtual machines used by the finance department. Administrators must still be able to resize the VMs and update NSG rules, but no one should be able to delete the resource group or anything in it during the quarter-end freeze. Which lock should be applied?
A CanNotDelete lock on the resource group is the correct control because it prevents deletions of the resource group itself and any resources inside it—including the VPN gateway—while still allowing read and update operations. This means administrators can resize the gateway, adjust NSG rules, and apply configuration changes, but no one can accidentally remove the entire shared boundary. It provides a targeted safeguard at the exact scope where the shared resources live.
Why this answer
The CanNotDelete lock (option B) prevents deletion of the resource group and all resources within it, while still allowing read and update operations such as resizing VMs and modifying NSG rules. This meets the requirement to block deletions during the quarter-end freeze without hindering administrative changes. ReadOnly locks would block all write operations, including resizing and NSG rule updates, which is not desired.
Exam trap
The trap here is that candidates often confuse ReadOnly locks with CanNotDelete locks, assuming that blocking all writes is necessary to prevent deletions, but ReadOnly locks also block updates like VM resizing and NSG rule changes, which are explicitly allowed in the requirement.
Why the other options are wrong
A ReadOnly lock prevents all write operations, including resizing VMs and updating NSG rules, which administrators must still be able to perform.
A management group lock on the subscription would apply to all resource groups under that management group, which is too broad for a freeze limited to a single resource group. The question specifies a shared resource group, not the entire subscription or management group.
Azure Policy deny effect can block actions based on conditions, but it is not a lock; it requires a policy definition and assignment, and it does not prevent deletion of the resource group itself unless explicitly configured. The question asks for a lock, and CanNotDelete lock directly prevents deletion.
When would these options actually be correct?
A ReadOnly lock would be correct if the requirement was to prevent any changes to resources, such as during a security audit where configuration must remain static, but read access is still needed.
If the question required preventing deletion of all resources across multiple subscriptions (e.g., during a company-wide freeze) and the lock needed to be applied at a high scope to cover all child resources, a management group lock on the subscription would be correct.
An Azure Policy deny effect would be correct if the requirement is to enforce specific rules (e.g., block all resources without encryption) across multiple subscriptions, not just prevent deletion during a freeze.
Why candidates pick the wrong answer
Candidates may think a ReadOnly lock is sufficient to prevent deletion, but it also blocks modifications, which is overly restrictive for this scenario.
Candidates might think a management group lock provides broader protection and is easier to apply, but they overlook that the question's scope is limited to a single resource group, making a resource group lock more appropriate.
Candidates may confuse Azure Policy with resource locks because both can restrict operations, but locks are simpler and directly prevent deletion or modification, while policies are for compliance and governance.
A storage account must be reachable only from resources in a specific Azure subnet, and connections must not use the public endpoint. Which option should the administrator configure?
A private endpoint assigns the storage service a private IP address inside the selected virtual network subnet. Traffic then stays on private addressing instead of using the public endpoint, which is exactly what the requirement asks for. This also allows the administrator to restrict access to approved network locations while improving the security posture of the storage account.
Why this answer
A private endpoint assigns the storage account a private IP address from the subnet, effectively bringing the service into the virtual network. This ensures all traffic to the storage account stays within the Microsoft Azure backbone and never traverses the public internet, meeting the requirement that connections must not use the public endpoint.
Exam trap
The trap here is that candidates confuse service endpoints with private endpoints, assuming both provide the same level of isolation, but service endpoints still expose the public endpoint and do not give a private IP address.
Why the other options are wrong
A service endpoint does not prevent public endpoint access; it only ensures traffic from the subnet to the storage account stays on the Azure backbone, but the storage account still has a public endpoint that could be accessed from elsewhere.
A NAT gateway enables outbound internet connectivity for private subnets but does not restrict inbound access to the storage account from a specific subnet, nor does it eliminate the public endpoint.
A storage firewall rule allowing all Azure services permits connections from any Azure service, not just from the specific subnet, and still uses the public endpoint, failing to meet the requirement of no public endpoint access.
When would these options actually be correct?
A service endpoint would be correct if the requirement was to restrict access to the storage account from a specific subnet while still allowing public endpoint access from other sources, and the goal was to optimize routing and keep traffic on the Azure backbone.
When the question asks how to provide outbound internet access to resources in a private subnet while hiding their private IPs behind a single public IP, a NAT gateway is the correct answer.
This option would be correct if the question required allowing trusted Azure services (e.g., Azure Backup, Azure Logic Apps) to access the storage account while blocking all other public traffic, and the storage account's public endpoint is still used but restricted by firewall rules.
Why candidates pick the wrong answer
Candidates may confuse service endpoints with private endpoints, thinking both eliminate public exposure, but service endpoints only provide a direct route without removing the public endpoint.
Candidates may confuse NAT gateway with network isolation features, thinking it can replace private endpoints for securing inbound traffic to Azure services.
Candidates may think that allowing all Azure services is a simple way to restrict access to Azure resources, overlooking that it does not limit traffic to a specific subnet and still uses the public endpoint.
A platform team wants to investigate incidents involving Azure VM performance, storage failures, and subscription-level changes in one place. They want to minimize Log Analytics ingestion cost. Which telemetry approach should they use?
This approach captures the specific platform diagnostic logs and Activity Log entries that contain the resource-level and control-plane operations needed for incident investigation, while avoiding the cost of ingesting unrelated telemetry. Centralizing these logs in a single Log Analytics workspace enables cross-resource correlation using KQL, and metric alerts provide a lightweight, threshold-based monitoring layer that requires no log storage, striking the right balance between investigative depth and operational cost.
Why this answer
It balances the need for centralized incident investigation with cost control. By sending only required platform diagnostic logs (e.g., from Azure Storage and VM metrics) and Activity logs to a single Log Analytics workspace, the team avoids unnecessary ingestion of verbose guest-level logs. Metric alerts provide threshold-based signals without log ingestion costs, enabling efficient monitoring of performance and failures.
Exam trap
The trap here is that candidates may think full logging (Option A) is necessary for comprehensive investigation, overlooking the cost implications of ingesting verbose guest-level logs, or assume metrics alone (Option B) can replace logs for incident root cause analysis.
Why the other options are wrong
Enabling full guest-level logging on every VM and sending all storage logs and all activity logs from every subscription generates excessive data, significantly increasing Log Analytics ingestion costs, which contradicts the goal of minimizing cost.
Metric alerts alone cannot provide the detailed logs needed to investigate VM performance, storage failures, and subscription-level changes; they only trigger on thresholds and lack the diagnostic data required for root cause analysis.
Exporting all telemetry to a storage account and querying it manually is inefficient for real-time incident investigation, incurs high storage costs, and lacks the centralized querying and alerting capabilities of Log Analytics, contradicting the requirement to minimize cost and investigate in one place.
When would these options actually be correct?
This option would be correct if the question required comprehensive, centralized monitoring with no cost constraints, such as 'A security team needs to capture all possible telemetry for forensic analysis after a breach, regardless of cost.'
A question that asks for the most cost-effective way to monitor resource health and trigger notifications without needing detailed log investigation, such as 'Which approach minimizes cost while alerting on high CPU usage across VMs?'
In a scenario where compliance mandates long-term archival of raw telemetry data for auditing purposes, and cost optimization is achieved by using lifecycle management policies (e.g., moving to cool/archive tiers) rather than real-time querying, exporting to a storage account would be appropriate.
Why candidates pick the wrong answer
Candidates may think that collecting all logs ensures complete visibility, not realizing the cost implications and that selective logging can still cover the required incident types.
Candidates may believe metrics are always cheaper and sufficient for all monitoring needs, overlooking that incident investigation requires logs for detailed analysis.
Candidates may think storing raw data in a storage account is cheaper than Log Analytics ingestion, and that manual querying is acceptable for occasional investigations, overlooking the operational overhead and lack of integrated analysis tools.
An NSG associated directly with the target VM's network interface (NIC) applies its rules only to that NIC, so adding an inbound allow rule for TCP 22 from your admin IP explicitly permits SSH for that single VM while leaving every other NIC in the subnet unaffected. Because Azure's default rules deny all other inbound internet traffic, this NIC-level NSG creates the narrowest possible exposure: only the specified source IP can reach only the specified port on only the target VM. This is the proper least-privilege approach when you need to administer one specific Linux VM within a shared subnet.
Why this answer
Network Security Groups (NSGs) can be associated at the subnet or NIC level. By associating an NSG directly with the target VM's NIC and adding an inbound allow rule for TCP port 22 from your admin IP address, you restrict SSH access exclusively to that VM while leaving the other VMs in the subnet unaffected by the rule. This provides granular, host-level security without impacting the broader subnet traffic.
Exam trap
The trap here is that candidates often assume subnet-level NSG rules are sufficient for granular control, but they fail to recognize that a subnet NSG applies to all VMs in that subnet, whereas a NIC-level NSG provides per-VM isolation.
Why the other options are wrong
Applying the rule at the subnet NSG level would allow SSH access to all VMs in the subnet, not just the target VM, violating the requirement that other VMs remain inaccessible from the internet.
A public load balancer distributes traffic across multiple VMs, not restrict access to a single VM. It would expose all VMs behind it to SSH traffic if configured, and it adds unnecessary complexity and cost for a simple access control requirement.
When would these options actually be correct?
If the requirement were to allow SSH access to all VMs in the subnet from your admin IP, then adding an inbound allow rule on the subnet NSG for TCP 22 would be correct.
When you need to distribute SSH traffic across multiple VMs for load balancing or high availability, and you want to hide the VMs' public IPs behind a single endpoint. For example, managing a fleet of jump servers where any available server can handle the connection.
If the question required restricting access from a specific Azure service (e.g., Azure Storage) to only a particular subnet or VM, enabling a service endpoint on the subnet would be correct.
Why candidates pick the wrong answer
Candidates may think that subnet-level NSG rules are sufficient and simpler, overlooking the need to restrict access to a single VM when others must remain inaccessible.
Candidates may think a load balancer provides granular access control or security, but its primary purpose is distribution and availability, not fine-grained per-VM access restriction.
Candidates may confuse 'service endpoint' with 'network security group' or think it can limit traffic to a specific VM, misunderstanding its purpose of securing Azure service traffic.
Azure VPN gateways require a dedicated GatewaySubnet, which must be created within the virtual network with a name exactly 'GatewaySubnet', and at least one public IP address for the VPN gateway that serves as the endpoint for on-premises VPN devices. This public IP is assigned to the gateway and provides the external IP that the on-premises VPN device connects to. Without these, the gateway cannot be deployed or establish site-to-site tunnels. Also note that the public IP should be in the Basic or Standard SKU depending on gateway SKU, and it must be a dynamic allocation for Basic gateways.
Why this answer
A VPN gateway in Azure requires a dedicated subnet named 'GatewaySubnet' to host the gateway instances, and a public IP address resource must be allocated to the gateway to establish the site-to-site VPN tunnel over the internet. Without these two prerequisites, the deployment will fail because the gateway cannot be provisioned or addressed externally.
Exam trap
The trap here is that candidates often confuse the required subnet name 'GatewaySubnet' with other special subnets like 'AzureBastionSubnet' or 'AzureFirewallSubnet', leading them to select an incorrect option that seems plausible but serves a different purpose.
Why the other options are wrong
AzureBastionSubnet is required for Azure Bastion, not for a VPN gateway. A VPN gateway requires a subnet named GatewaySubnet and a public IP address, not a static private IP.
A network security group (NSG) cannot be attached directly to a virtual network gateway; NSGs are associated with subnets or network interfaces, not the gateway resource itself. The gateway requires a dedicated GatewaySubnet, not an NSG.
A load balancer is not required for a site-to-site VPN gateway; the gateway uses a public IP address for termination, not a load balancer. The missing resources are a dedicated GatewaySubnet and a public IP address.
When would these options actually be correct?
When deploying Azure Bastion for secure RDP/SSH access to VMs, you must create a subnet named AzureBastinSubnet with a /27 or larger address range. The Bastion service uses a public IP, but the subnet itself does not require a static private IP.
In a scenario where you need to restrict inbound traffic to a subnet containing a virtual network gateway (e.g., to limit management access from specific IPs), you would associate an NSG with the GatewaySubnet. The question would ask: 'How can you secure the gateway subnet?'
For a highly available site-to-site VPN deployment using active-active mode with multiple on-premises devices, you might deploy a load balancer in front of the VPN gateways to distribute traffic, but this is not a standard requirement for a basic gateway creation.
Why candidates pick the wrong answer
Candidates may confuse the subnet naming requirements for different Azure services, or think that a static private IP is necessary for gateway stability, not realizing that the VPN gateway uses a public IP and dynamic private IP assignment.
Candidates may think that since NSGs provide network security, attaching one directly to the gateway would secure the VPN connection, misunderstanding that NSGs apply at the subnet or NIC level, not to the gateway object itself.
Candidates may confuse the need for high availability or load balancing with the basic gateway setup, or assume that a public-facing service like VPN requires a load balancer for termination.
IP flow verify is designed to test a specific source, destination, protocol, and port combination against NSG rules. It returns whether the flow is allowed or denied and identifies the rule that matched, which makes it the right tool when you need to prove whether TCP 1433 is blocked and why.
Why this answer
IP flow verify is the correct tool because it evaluates the 5-tuple (source IP, destination IP, source port, destination port, and protocol) against the effective Network Security Group (NSG) rules for a given virtual machine network interface. It explicitly reports whether the traffic is allowed or denied and, if denied, identifies the exact NSG rule (name and priority) that caused the denial. This directly meets the administrator's requirement to test the exact flow and identify the blocking rule.
Exam trap
The trap here is that candidates often confuse 'Connection troubleshoot' (which tests end-to-end connectivity and can indicate a block) with 'IP flow verify' (which explicitly identifies the exact NSG rule name that caused the denial), leading them to choose the less precise tool.
Why the other options are wrong
Effective routes show the effective route table for a VM, not NSG rules. They cannot identify the specific NSG rule that allows or denies traffic based on a 5-tuple.
Packet capture does not automatically identify which NSG rule denied traffic; it only captures raw network packets, requiring manual analysis to infer blocking.
When would these options actually be correct?
When the question asks to verify the next hop or the route taken by traffic from a VM to a destination, such as checking if traffic goes through a virtual appliance or is routed to the internet.
When the question asks to capture and analyze the actual network packets between two VMs to diagnose a connectivity issue, such as verifying if packets are being dropped or inspecting application-level data.
Why candidates pick the wrong answer
Candidates may confuse 'effective routes' with 'effective security rules' or think that route tables include NSG information, leading them to believe it can show NSG rule names.
Candidates may think packet capture provides direct insight into NSG decisions because it captures all traffic, but it lacks the rule-level evaluation that IP flow verify offers.
A VM in VNet B can reach a blob storage account through a private endpoint that was created in peered VNet A. The storage FQDN still resolves to the public IP when queried from VNet B, so the VM does not use the private path. What should the administrator change?
Private endpoint connectivity depends on DNS resolution returning the private IP address. In a peered virtual network, the DNS zone for the private endpoint must be linked so clients in VNet B resolve the storage name to the private address instead of the public one. Once that DNS path is corrected, traffic follows the private endpoint.
Why this answer
The private endpoint in VNet A creates a private IP for the storage account, but DNS resolution in VNet B still returns the public IP because the private DNS zone (privatelink.blob.core.windows.net) is not linked to VNet B. By linking the private DNS zone to VNet B, the VM will resolve the storage FQDN to the private IP, ensuring traffic uses the private endpoint path through the VNet peering.
Exam trap
The trap here is that candidates assume VNet peering automatically extends DNS resolution for private endpoints, but in reality, private DNS zones must be explicitly linked to each peered VNet to enable private IP resolution.
Why the other options are wrong
A service endpoint for Microsoft.Storage would route traffic to the public IP of the storage account, not to the private endpoint. The VM in VNet B already needs to resolve the storage FQDN to the private IP, which requires DNS resolution through the private DNS zone linked to VNet B.
Disabling the storage account firewall would not change DNS resolution; the VM in VNet B would still resolve the FQDN to the public IP because the private DNS zone is not linked to VNet B.
Moving the storage account into VNet B does not resolve the DNS resolution issue; the private endpoint's DNS zone must be linked to VNet B for the FQDN to resolve to the private IP.
When would these options actually be correct?
A service endpoint would be correct if the question asked for a way to ensure that traffic from VNet B to the storage account stays within the Azure backbone without using a private endpoint, and the storage account firewall is configured to allow access from that VNet.
Why candidates pick the wrong answer
Candidates may confuse service endpoints with private endpoints, thinking both provide private connectivity, but service endpoints do not provide a private IP address or DNS resolution to a private IP.
Based on the exhibit, where should the administrator go next to review the failed backup job details?
The Jobs blade in a Recovery Services vault is the operational log for Azure Backup. It lists every backup, restore, and protection-change operation with a status such as Completed, Failed, or In Progress, and for failed jobs it surfaces the specific error code and a detailed message. Selecting the failed job from the exhibit opens its full error context, including the impacted data source and timestamps, which is exactly what you need to diagnose the failure.
Why this answer
The Jobs blade in Azure Backup is the central location for reviewing the status, progress, and detailed error messages of all backup jobs, including failed ones. It provides a filtered view of backup, restore, and other operations, allowing the administrator to drill into specific job failures to see error codes and recommended actions.
Exam trap
The trap here is that candidates confuse the location of configuration data (policies, properties) with operational data (job status), leading them to select Backup policy or Properties instead of Jobs.
Why the other options are wrong
The question asks where to review failed backup job details, not configuration. Backup policy shows retention and schedule, not job execution status or errors.
The question asks where to review failed backup job details, which are found under 'Jobs', not 'Backup items'. 'Backup items' lists protected resources and recovery points but does not show job status or error details.
The Properties blade shows general vault settings (e.g., name, subscription, encryption), not backup job details or error logs. To review failed backup job details, the administrator must navigate to the Jobs blade, which lists job status and error messages.
When would these options actually be correct?
If the question were 'Where should an administrator go to modify the retention duration for backups?' then Backup policy would be correct as it contains retention and schedule settings.
This option would be correct if the question were: 'Where should an administrator go to view the list of protected resources and their latest recovery points?' or 'Where can an administrator verify which items are currently protected by the backup vault?'
This option would be correct if the question asked: 'Where should the administrator go to verify the encryption settings or change the storage replication type for the Recovery Services vault?'
Why candidates pick the wrong answer
Candidates may confuse policy configuration with job execution details, assuming that reviewing backup failures is part of policy management.
Candidates may confuse 'Backup items' with job details because items show recovery points, which are related to backup jobs, but they do not display job status or error information.
Candidates may confuse 'Properties' with a catch-all for any vault-related information, not realizing that job-specific details are in a separate blade.
A department has 10 subscriptions and wants the same two governance rules applied to all current and future subscriptions. One rule audits missing tags, and the other denies unapproved locations. Which two actions should the administrator take? Select two.
An Azure Policy initiative (policySetDefinition) bundles multiple individual policy definitions into a single assignable unit, allowing the department to enforce both tag-auditing and allowed-location rules together. This reduces assignment overhead because one initiative assignment generates a combined compliance state for all 10 subscriptions. It also makes future policy updates easier because you only need to edit the initiative definition rather than modifying separate assignments.
Why this answer
Azure Policy Initiative allows grouping multiple policy definitions (like audit for missing tags and deny for unapproved locations) into a single set for coordinated enforcement. Assigning the initiative at the management group scope ensures it applies to all current and future subscriptions under that management group, meeting the requirement for consistent governance across all 10 subscriptions and any new ones added later.
Exam trap
The trap here is that candidates often confuse Azure Policy with Azure RBAC or resource locks, thinking they can enforce governance rules through permissions or protection mechanisms, when Policy is the only service that audits and denies resource configurations based on rules.
Why the other options are wrong
Assigning each policy only to one resource group would not apply the governance rules to all 10 subscriptions or future subscriptions, as required. The question specifies that the rules must apply to all current and future subscriptions, which requires assignment at a management group scope.
Azure RBAC controls who can access resources (authorization), not what configurations or locations are allowed. The requirements are about auditing tags and denying unapproved locations, which are governance rules enforced by Azure Policy, not RBAC.
Read-only locks prevent modifications to resources but do not enforce governance rules like tag auditing or location restrictions. The question requires policy enforcement, not resource locking.
When would these options actually be correct?
This option would be correct if the question asked to apply different policies to specific resource groups within a single subscription, and the requirement was to target only those resource groups, not all subscriptions.
A question asks: 'You need to ensure that only users in the IT department can create virtual machines in a subscription. Which solution should you use?' In that scenario, Azure RBAC (e.g., a custom role) would be correct because it controls permissions to create resources.
A question asks: 'You need to prevent accidental deletion of critical resources in a subscription. What should you do?' In that scenario, applying a read-only lock on the subscription would be correct.
Why candidates pick the wrong answer
Candidates may think that assigning policies to resource groups is sufficient for governance, but they overlook the need for broad, consistent application across multiple subscriptions and future resources.
Candidates may confuse governance (Policy) with access control (RBAC), thinking that restricting locations or enforcing tags is about permissions rather than compliance rules.
Candidates may confuse locks with policy enforcement, thinking that preventing changes can also enforce compliance rules, but locks only block modifications, not audit or deny specific configurations.
A central audit team needs Reader access on every current and future subscription under the company hierarchy. Which scope should you use for the role assignment?
Management groups are hierarchical containers that aggregate Azure subscriptions. Assigning the Reader role at a management group scope applies that permission to every subscription within that management group, including any subscriptions added in the future. This makes it the only option here that provides centralized, inheritance-based read access across the entire environment without requiring per-subscription or per-resource assignments. It also supports governance by enabling the audit team's access to be managed in a single place.
Why this answer
A management group scope allows role assignments to be inherited by all subscriptions and resource groups within that management group hierarchy. By assigning the Reader role at the management group level, the central audit team automatically gains read access to every current subscription and any future subscription added under that management group, ensuring consistent governance without manual updates.
Exam trap
The trap here is that candidates often default to subscription scope because they think of subscriptions as the primary boundary for access control, overlooking that management groups provide a broader, hierarchical inheritance that automatically covers future subscriptions.
Why the other options are wrong
Subscription scope only grants Reader access to the selected subscription, not to future subscriptions or other subscriptions under the management group hierarchy.
Resource group scope limits access to a single resource group, not all current and future subscriptions under the company hierarchy.
Resource scope applies to a single resource, not to all current and future subscriptions, so it cannot provide Reader access across multiple subscriptions.
When would these options actually be correct?
If the requirement is to grant Reader access to a single subscription (e.g., for a project-specific auditor) without covering future subscriptions or other subscriptions in the hierarchy, subscription scope would be correct.
A question requiring Reader access only to a specific resource group and its resources, with no need for cross-subscription or future subscription access.
When the question specifies granting Reader access to a specific resource (e.g., a virtual machine or storage account) for a user or group, resource scope is correct.
Why candidates pick the wrong answer
Candidates may think that assigning at the subscription level covers all current subscriptions under the tenant, but they overlook the need to include future subscriptions and the broader management group hierarchy.
Candidates may confuse resource group scope as a way to cover multiple resources within a group, but it does not scale to multiple subscriptions or future subscriptions.
Candidates may think resource scope is sufficient because it's the most granular level, overlooking the requirement for coverage across all subscriptions.
A company uses Azure Blob Storage for legal documents. The documents must not be modified or deleted for seven years after upload, even by administrators. What should you configure?
Immutable blob storage with a time-based retention policy enforces write-once-read-many (WORM) behavior: blobs cannot be modified or deleted until the retention period expires. For legal documents needing seven-year preservation, this policy provides a strict, compliance-ready guarantee because the retention clock starts when the policy is applied and continues regardless of user permissions. This is the only option that actually enforces immutability for the full required duration.
Why this answer
Immutable blob storage with a time-based retention policy (WORM – Write Once, Read Many) ensures that blobs cannot be modified or deleted for a specified retention period, even by administrators. This is the only Azure storage feature that provides legal hold or regulatory compliance for fixed records, such as legal documents that must remain unaltered for seven years.
Exam trap
The trap here is that candidates often confuse soft delete or versioning with immutable storage, not realizing that only a time-based retention policy (WORM) provides the strict, administrator-proof immutability required for regulatory compliance.
Why the other options are wrong
Blob soft delete protects against accidental deletion but does not prevent modifications, and administrators can still delete blobs within the retention period if they have sufficient permissions.
Lifecycle management moves blobs to different tiers or deletes them based on age, but it does not prevent modification or deletion by administrators. It cannot enforce a write-once, read-many (WORM) state required for legal hold or regulatory compliance.
Blob versioning preserves previous versions of blobs but does not prevent deletion or modification of the current version by administrators. It cannot enforce a legal hold or retention period that blocks all modifications and deletions.
When would these options actually be correct?
A company wants to recover blobs that are accidentally deleted or overwritten within a specified retention period, but does not require strict legal hold or administrator-proof immutability.
A company wants to reduce storage costs by automatically moving blobs that have not been accessed for 30 days to the Cool tier, and blobs older than 90 days to the Archive tier. Lifecycle management would be the correct solution for this cost-optimization scenario.
An organization needs to recover from accidental deletion or overwrite of blobs, and wants to maintain a history of changes for auditing or rollback purposes, without requiring strict immutability. For example, a development team using Azure Blob Storage for application logs that may need to restore earlier versions.
Why candidates pick the wrong answer
Candidates may confuse soft delete with immutable storage, thinking it provides long-term protection against deletion, but they overlook that soft delete does not prevent modifications or administrator actions.
Candidates may confuse lifecycle management with retention policies, thinking that moving blobs to Archive makes them immutable or that the policy itself prevents deletion, but Archive blobs can still be deleted by administrators.
Candidates may confuse versioning with immutability, thinking that preserving all versions inherently protects data from modification or deletion, not realizing that administrators can still delete the current version or entire storage account.
A healthcare application stores files that must be protected against a single datacenter outage in the region. The team does not need a secondary region for read access, and they want the simplest resilient option. Which storage redundancy should they choose?
Zone-redundant storage (ZRS) synchronously replicates your data across three Azure availability zones in the same region, so if one zone's datacenter fails, the storage account remains available and no data is lost. This directly meets the scenario's requirement to protect files against a datacenter-level outage while staying within a single region. The replication is automatic and transparent, and you keep using the same endpoint without any manual failover, making ZRS the appropriate and cost-effective choice here.
Why this answer
Zone-redundant storage (ZRS) replicates data synchronously across three Azure availability zones within a single region, protecting against a complete datacenter outage without requiring a secondary region. This meets the requirement for the simplest resilient option that guards against a single datacenter failure while avoiding the complexity and cost of geo-replication.
Exam trap
The trap here is that candidates often confuse 'protecting against a single datacenter outage' with needing geo-redundancy, but ZRS within a region is sufficient and simpler when no secondary region read access is required.
Why the other options are wrong
LRS replicates data within a single datacenter, so it does not protect against a single datacenter outage in the region. The question requires resilience to a datacenter failure, which LRS cannot provide.
RA-GRS provides read access to a secondary region, but the question explicitly states that a secondary region is not needed and only requires protection against a single datacenter outage within the region. RA-GRS is overkill and adds complexity.
When would these options actually be correct?
If the question stated that the application only needs protection against local hardware failures (e.g., disk or server failures) within a single datacenter, and cost is the primary concern, LRS would be the simplest and cheapest option.
A question where the application requires read access to data in a secondary region for disaster recovery or high availability, and the primary region is unavailable. For example: 'An app needs read-only access to storage during a regional outage. Which redundancy option provides this?'
Why candidates pick the wrong answer
Candidates may choose LRS because it is the simplest and cheapest redundancy option, and they overlook the requirement for datacenter outage protection, mistakenly thinking LRS provides sufficient resilience.
Candidates may confuse 'geo-redundant' with 'zone-redundant' and think that any geo option provides better resilience, or they may assume that read-access is always beneficial without considering the specific requirement of not needing a secondary region.
A blob was moved to the Archive tier last month. A user now needs to open the file within a few hours. What should the administrator do first?
The correct action is to set the blob’s access tier to Hot or Cool by issuing a Set Blob Tier operation. Once the tier-change request is submitted, the service automatically rehydrates the blob from Archive, which can take up to 15 hours depending on the rehydration priority you specify; the blob is not readable until the process completes. After rehydration, the blob becomes accessible for normal read/update operations, although you may also choose to copy the blob out to a new online-tier blob to keep the original archived.
Why this answer
Blobs in the Archive tier are offline and cannot be read directly. To access the data, you must first change the blob's access tier to Hot or Cool, which initiates a rehydration process that makes the blob available for reading. Since the user needs the file within a few hours, rehydration typically completes within that timeframe (up to 15 hours for Archive to Cool/Hot).
Exam trap
The trap here is that candidates assume the Archive tier is readable like Cool or Hot, or that snapshots or versioning bypass the rehydration requirement, but Azure explicitly blocks direct access to archived blobs until they are rehydrated.
Why the other options are wrong
Blobs in the Archive tier are offline and cannot be downloaded directly; they must first be rehydrated to an online tier (Hot or Cool) before access.
Creating a snapshot does not rehydrate the blob from Archive tier; snapshots are read-only copies of the blob at the time of creation and remain in the same tier, so the user still cannot access the data without rehydration.
Enabling versioning does not rehydrate a blob from the Archive tier; it only creates new versions on writes. The user needs to rehydrate the blob to a hot or cool tier before accessing it.
When would these options actually be correct?
If the blob is already in the Hot or Cool tier (not Archive), or if the question specifies that the blob is in the Cool tier and the user needs immediate access, then downloading directly would be correct.
This option would be correct if the question asked: 'A user needs to preserve the current state of a blob before modifying it. What should the administrator do first?' In that case, creating a snapshot captures the blob's state at that moment.
An administrator needs to protect against accidental deletion or overwrites of blobs. The correct action is to enable versioning on the storage account so that previous versions are preserved and can be restored.
Why candidates pick the wrong answer
Candidates may assume that all blobs are immediately accessible regardless of tier, or they may overlook the fact that Archive tier blobs require rehydration before download.
Candidates may think a snapshot provides an immediate accessible copy, misunderstanding that snapshots inherit the source blob's tier and do not bypass rehydration requirements for archived blobs.
Candidates may confuse versioning with a method to access archived blobs, thinking that creating a new version might allow reading the data without rehydration.
A backup job from an Azure service must write to a storage account that has the network firewall set to deny all public traffic. The team does not want to create a private endpoint for this workload. What should the administrator enable?
Allowing trusted Microsoft services is the correct choice when a supported Azure platform service needs to reach the storage account without opening the firewall broadly. It permits specific Microsoft-managed services to bypass the network restriction while keeping public traffic denied. This is appropriate when the workload is an Azure service rather than a customer VM or subnet.
Why this answer
Azure Storage firewalls include a special exception for 'Allow trusted Microsoft services to access this storage account'. When enabled, this exception permits Azure platform services—such as Azure Backup—to bypass the public network deny rule and write to the storage account without requiring a private endpoint. This works because the backup service runs on Microsoft-owned infrastructure that is authenticated and authorized at the control plane level, not via a public IP.
Exam trap
The trap here is that candidates often confuse 'Allow trusted Microsoft services' with a generic security bypass, not realizing it is a specific, documented exception designed for Azure platform services like Backup, Log Analytics, and Azure Site Recovery.
Why the other options are wrong
The backup job is an Azure service (e.g., Azure Backup) that does not have a public IP address to add; it runs on Azure infrastructure. Adding a public IP would not work because the traffic originates from Azure's internal network, not a specific public IP.
Service endpoints allow access from a specific subnet to a storage account, but the backup job runs as an Azure service (e.g., Azure Backup) and not from a specific subnet. The question explicitly states the team does not want to use a private endpoint, and service endpoints still require the storage firewall to allow traffic from the subnet, which does not resolve the need to bypass the firewall for the Azure service itself.
Disabling the firewall temporarily creates a security gap where the storage account is exposed to all public traffic during the backup window, violating the requirement to deny all public traffic.
When would these options actually be correct?
This option would be correct if the backup server is an on-premises or non-Azure VM with a known static public IP address, and the storage account firewall is configured to allow access only from that IP.
This option would be correct if the backup job runs on a virtual machine in a specific subnet, and the requirement is to allow that subnet to access the storage account without using a private endpoint. For example, a question where a VM in a VNet needs to back up to a storage account with a firewall, and the solution is to enable a service endpoint on the VM's subnet.
If the question stated that the backup job fails intermittently due to firewall rules and the team needs a quick workaround while troubleshooting, temporarily disabling the firewall during the backup window could be a temporary fix, though not a best practice.
Why candidates pick the wrong answer
Candidates may think that allowing a specific IP is a straightforward way to bypass the firewall, not realizing that Azure services do not have a fixed public IP and that the 'Allow trusted Microsoft services' setting is designed for this scenario.
Candidates may confuse service endpoints with managed identity or think that enabling a service endpoint on the subnet hosting the backup job will automatically grant access to the Azure Backup service, not realizing that the backup job is not tied to a specific subnet.
Candidates may think that temporarily disabling the firewall is a simple way to allow the backup job to succeed without understanding the security implications or the existence of the 'Allow trusted Microsoft services' option.
A legal department stores project video assets in Azure Blob Storage. The files are reviewed only during quarterly audits, but when someone needs a file it must open immediately without waiting for rehydration. Which access tier should the administrator use for the blobs?
The Cool access tier is designed for data that is infrequently accessed (typically fewer than a few times a year) but must remain immediately accessible. Because Cool keeps blobs online, users can open files in real time during quarterly audits without incurring rehydration latency or additional Archive retrieval charges. It balances lower storage costs relative to Hot with a modest retrieval fee, making it the most cost-effective tier for this legal department's infrequent, but time-sensitive, access pattern.
Why this answer
The Cool access tier is designed for data that is infrequently accessed but must remain immediately available (online) without any rehydration delay. Since the legal department needs instant access during quarterly audits, Cool meets the requirement of low retrieval cost while keeping blobs online, unlike Archive which requires hours-long rehydration.
Exam trap
The trap here is that candidates often choose Archive thinking it is the cheapest for rarely used data, forgetting that Archive blobs are offline and require significant rehydration time, which contradicts the 'immediately available' requirement in the question.
Why the other options are wrong
The Hot tier is optimized for frequent access and has higher storage costs, but the scenario requires infrequent access (quarterly audits) with immediate availability. The Hot tier would be unnecessarily expensive for data accessed only a few times per year.
Archive tier requires rehydration (which can take hours) to make blobs readable, contradicting the requirement that files must open immediately without waiting.
Premium tier is designed for high-performance, low-latency access with Azure Premium SSD storage, not for long-term archival or cost-effective infrequent access. It is significantly more expensive and not intended for rarely accessed data like quarterly audit files.
When would these options actually be correct?
An administrator needs to store data that is accessed and modified frequently (e.g., daily active project files) and requires low-latency access. The Hot tier would be correct because it offers the lowest access costs for frequent operations and keeps blobs online.
When the question states that data is rarely accessed and a retrieval delay of several hours is acceptable, such as for long-term backup or compliance archives where instant access is not needed.
An administrator needs to store data for a high-traffic web application that requires consistently low latency (e.g., sub-10 ms) and high throughput, such as a real-time analytics dashboard or an e-commerce product catalog. Premium tier would be correct for such performance-sensitive workloads.
Why candidates pick the wrong answer
Candidates may assume 'Hot' is always the best for immediate access, overlooking that Cool also provides instant access at lower storage cost for infrequent use. They might not differentiate between access cost and storage cost.
Candidates see 'rarely used' and 'cheapest' and assume Archive is best, overlooking the critical requirement for immediate access without rehydration delay.
Candidates may confuse 'premium' with 'best overall' or assume it offers the best long-term economics, not realizing it is optimized for performance, not cost savings on infrequently accessed data.
An administrator wants to let a help desk group start, stop, and restart virtual machines in one resource group, but the group must not be able to delete the VMs or any other resource in the group. Which two actions should the administrator take? Select two.
A custom role is required because the built-in roles are broader than the help desk's task. Limiting the actions keeps the permission set aligned with the actual operational need.
Why this answer
Creating a custom RBAC role with only VM start, stop, restart, and read actions ensures the help desk group can perform only those specific operations without any delete permissions. This role must be assigned at the resource group scope (Option B) to limit its effect to that resource group, preventing the group from modifying or deleting resources in other scopes. Together, these two actions fulfill the requirement precisely.
Exam trap
The trap here is that candidates often choose Virtual Machine Contributor (Option C) thinking it provides only VM management, but it actually includes delete permissions and broader resource control, or they incorrectly combine a CanNotDelete lock (Option D) with an existing role, not realizing the lock does not grant the required start/stop/restart actions.
An operations team archived monthly log exports six weeks ago. An auditor now needs one specific blob restored within a day, and the file will likely be opened several times during the audit. Which action should the administrator take first?
The blob must be rehydrated before it can be opened, and Hot is a sensible target when repeated reads are expected during an active audit. Choosing Hot avoids repeated retrieval penalties and keeps the file immediately online for the rest of the audit window. That makes the workflow simpler for the auditor.
Why this answer
The blob is currently in the Archive tier, which is offline and cannot be read directly. To access the data, the blob must first be rehydrated to an online tier (Hot or Cool) by changing its tier or copying it to a new blob. Rehydrating to the Hot tier ensures the blob is available for multiple reads within the audit timeframe, as the rehydration process typically takes up to 15 hours for Archive tier blobs.
Exam trap
The trap here is that candidates may think snapshots can be taken of any blob regardless of tier, but Azure requires the source blob to be in an online tier (Hot, Cool, or Cold) to create a snapshot.
Why the other options are wrong
The blob is already in the Archive tier and needs to be accessed within a day. Setting it directly to the Archive tier again does not change its state; it remains archived and inaccessible for reading. The blob must first be rehydrated to a hot or cool tier to be readable.
Archived blobs are offline and cannot be directly snapshotted; you must first rehydrate the blob to an online tier (Hot or Cool) before creating a snapshot. Snapshotting an archived blob without rehydration will fail.
Increasing account redundancy to RA-GRS does not directly address the need to access an archived blob; it provides geo-redundant storage but does not rehydrate the blob from the Archive tier, which is required before any read operations.
When would these options actually be correct?
This option would be correct if the blob had been accidentally moved from Archive to a lower tier (e.g., Cool) and the goal was to minimize cost by moving it back to Archive immediately, with no need for access.
If the blob is already in an online tier (Hot or Cool) and you need a point-in-time copy for auditing without modifying the original, creating a snapshot is the correct action. For example, 'An auditor needs a read-only copy of a current log file for review; which action should you take?'
This option would be correct if the question asked for a long-term data durability or disaster recovery requirement, such as 'An organization needs to ensure data is protected against a regional outage with minimal downtime' — then changing to RA-GRS would be appropriate.
Why candidates pick the wrong answer
Candidates may think that setting the tier again will somehow 'refresh' the blob or trigger rehydration, not realizing that Archive blobs are offline and must be explicitly rehydrated before they can be read.
Candidates may think snapshots provide immediate access to archived data without rehydration, not realizing that archived blobs are offline and require rehydration before any read or snapshot operation.
Candidates may think that increasing redundancy improves availability or access speed, but for archived blobs, the primary bottleneck is the rehydration process, not redundancy.
You want to group subscriptions for Finance, HR, and Engineering so you can apply governance consistently at a higher level. What should you create?
Management groups are the correct construct because they sit above subscriptions in the Azure hierarchy, enabling you to organize multiple subscriptions (finance, HR, engineering) into logical containers. Through management groups, you can enforce governance consistently across those subscriptions by applying Azure Policy, Azure RBAC roles, and cost-management settings that inherit down to all contained subscriptions. Unlike resource groups or tags, management groups create a true parent-child structure for subscriptions, not just a grouping of resources or metadata.
Why this answer
Management groups are the correct choice because they allow you to organize Azure subscriptions into a hierarchy for applying governance policies, role-based access control (RBAC), and cost management consistently across multiple subscriptions. By creating a management group hierarchy (e.g., Finance, HR, Engineering), you can assign Azure Policy initiatives or RBAC roles at the management group level, which are inherited by all subscriptions within that group. This provides a scalable and centralized governance model without needing to configure each subscription individually.
Exam trap
The trap here is that candidates often confuse resource groups (which group resources within a subscription) with management groups (which group subscriptions themselves), leading them to select resource groups as the answer for cross-subscription governance.
Why the other options are wrong
Resource groups are containers for resources within a single subscription, not for grouping multiple subscriptions. They cannot apply governance across subscriptions.
Tags are metadata applied to Azure resources for categorization, not a grouping mechanism for subscriptions. They cannot enforce governance policies across multiple subscriptions.
Resource locks prevent accidental deletion or modification of resources but do not group subscriptions for governance. Management groups are the correct construct for hierarchical subscription grouping and policy application.
When would these options actually be correct?
You need to organize resources within a single subscription by lifecycle or team, and apply role-based access control or policies at that level. For example, grouping all virtual machines for a project into one resource group for easier management.
You need to categorize resources by cost center or environment (e.g., 'Finance', 'Production') and apply cost tracking or filtering based on that categorization. Tags would be the correct answer.
You need to prevent critical resources (e.g., a production database) from being deleted or modified by users. Creating a resource lock (e.g., CanNotDelete) on the resource or resource group would be the correct answer.
Why candidates pick the wrong answer
Candidates confuse resource groups with management groups because both are hierarchical containers, but resource groups operate only within a subscription, not across subscriptions.
Candidates may confuse tags with management groups because both can organize resources, but tags lack the hierarchical policy enforcement capability needed for subscription-level governance.
Candidates may confuse resource locks with governance controls, thinking they can enforce policies across subscriptions, but locks only protect individual resources, not group or govern multiple subscriptions.
Two app VMs must stay available during planned host maintenance in the same region. Datacenter-level redundancy is not required, but the VMs should be spread across update domains. What should you configure?
An availability set logically groups VMs so Azure distributes them across fault domains (isolated power/network) and update domains (host groups rebooted sequentially). During planned host maintenance, Azure updates one update domain at a time, so at least one VM in the set remains online. This is the targeted placement control that directly matches the scenario's requirement.
Why this answer
An availability set logically groups VMs to protect against planned maintenance events by distributing them across up to 3 fault domains and 20 update domains. This ensures that during host maintenance, only one update domain is taken offline at a time, keeping the other VMs available. Since datacenter-level redundancy is not required, an availability set is the correct choice.
Exam trap
The trap here is that candidates often confuse availability zones (which provide datacenter-level redundancy) with availability sets (which provide intra-datacenter fault and update domain distribution), leading them to select availability zones even when the question explicitly states datacenter-level redundancy is not required.
Why the other options are wrong
Availability zones provide datacenter-level redundancy across physically separate zones, which is not required here. The question specifies that datacenter-level redundancy is not needed, and only spreading across update domains within the same region is required, which is a feature of availability sets.
Azure Backup is a data protection service for backing up VMs, not a high-availability feature. It does not distribute VMs across update domains or provide availability during planned host maintenance.
Managed disks provide storage redundancy and durability, but they do not distribute VMs across update domains to ensure availability during planned host maintenance.
When would these options actually be correct?
This option would be correct if the question required high availability across datacenter-level failures within a region, such as 'VMs must survive a datacenter outage in the same region' or 'protect against zone-level failures'.
A question asks: 'You need to ensure VM data is recoverable in case of accidental deletion or corruption. What should you configure?' In that scenario, Azure Backup would be the correct answer.
A question asking for a storage solution that provides high availability and fault tolerance for VM disks, such as ensuring data redundancy within a region without requiring VM-level distribution across update domains.
Why candidates pick the wrong answer
Candidates may confuse availability zones with availability sets, thinking both provide similar fault tolerance, or they may over-engineer the solution by choosing a more redundant option without reading the constraints carefully.
Candidates may confuse backup with high availability, thinking that backing up VMs ensures they stay available during maintenance, or they may misinterpret 'stay available' as 'data is preserved'.
Candidates may confuse managed disks' built-in replication (e.g., LRS) with the VM-level availability features needed to survive host maintenance events.
A records team wants blobs to be replicated to a secondary region, and the secondary copy must be readable if the primary region becomes unavailable. Which redundancy option should you choose?
RA-GRS replicates data to a secondary region and allows reads from that secondary copy, which fits the requirement exactly.
Why this answer
RA-GRS (Read-access geo-redundant storage) is correct because it provides geo-redundant replication (GRS) to a secondary region, plus read access to the secondary copy even if the primary region is unavailable. This ensures the blob data is replicated asynchronously to a paired secondary region, and the secondary endpoint can be read immediately during a primary outage, meeting the team's requirement for readable secondary copies.
Exam trap
The trap here is that candidates often confuse GRS with RA-GRS, assuming that geo-redundant replication automatically provides readable secondary copies, but GRS does not allow read access to the secondary region until a failover occurs, whereas RA-GRS explicitly enables read access at all times.
Why the other options are wrong
LRS replicates data only within a single datacenter in the primary region, so it does not provide a readable secondary copy if the primary region becomes unavailable.
When would these options actually be correct?
If the question specifies that cost is the primary concern and the data does not need to be available in case of a regional disaster, LRS would be the correct choice.
Why candidates pick the wrong answer
Candidates may choose LRS because it is the cheapest option and they overlook the requirement for readable secondary copy during a regional outage.
A Windows VM fails shortly after startup when a custom extension runs, and the administrator cannot use RDP to inspect the machine. The goal is to see what happened during boot and confirm whether the failure occurred before the guest OS finished loading. Which two features should be used first? Select two.
Boot diagnostics captures the VM's serial console output and screenshots during the boot process, storing them in an Azure storage account for later review. For a VM that fails shortly after startup when a custom extension runs, these artifacts can reveal kernel panics, missing drivers, or a stuck boot sequence that prevents the extension from executing. By viewing the serial log, you can pinpoint the exact stage of boot failure, making it the first-line diagnostic tool for such scenarios.
Why this answer
Boot diagnostics captures serial console output and screenshots of the VM during the boot process, allowing you to see if the OS failed to load before the guest OS finished. Azure Serial Console provides text-based, keyboard-focused access to the VM even when RDP is unavailable, enabling you to inspect boot logs and interact with the OS during startup. Together, they let you determine whether the custom extension failure occurred before or after the OS fully loaded.
Exam trap
The trap here is that candidates often choose managed disk snapshots or availability sets, thinking they can restore or inspect the VM state, but these do not provide the real-time, pre-OS boot logs needed to diagnose a startup failure before the guest OS finishes loading.
Why the other options are wrong
An availability set provides high availability for VMs by distributing them across fault domains, but it does not help diagnose boot failures or inspect boot logs. The question requires features to see what happened during boot, which availability set cannot provide.
Managed disk snapshots are used for backup or creating new disks, not for real-time boot troubleshooting. They cannot show boot logs or allow interactive access to diagnose a VM that fails before the OS loads.
Azure Monitor autoscale is used to automatically scale resources (like VMSS) based on demand, not to diagnose boot failures or inspect OS-level issues. It cannot help see what happened during boot or confirm failure timing.
When would these options actually be correct?
A question asks: 'You need to ensure that two VMs hosting a critical application remain available during planned maintenance. Which feature should you use?' In that scenario, an availability set is the correct answer to guarantee uptime by placing VMs in separate update and fault domains.
A managed disk snapshot would be correct if the question asked for a point-in-time backup of a VM's OS disk before applying a critical update, or to create a new VM from a known good state for recovery purposes.
A web application experiences intermittent performance degradation during peak hours. You need to automatically increase the number of VM instances when CPU usage exceeds 80% and decrease when it drops below 30% to maintain performance and optimize cost. Azure Monitor autoscale would be the correct feature to configure.
Why candidates pick the wrong answer
Candidates may confuse high availability features with diagnostic tools, thinking that an availability set can help recover or inspect a failed VM, but it only ensures redundancy, not troubleshooting capability.
Candidates may think snapshots can be used to analyze the disk contents offline to find boot errors, but this is inefficient and not the intended first step; boot diagnostics and serial console are designed for this exact scenario.
Candidates may think 'Azure Monitor' implies monitoring and diagnostics, and assume autoscale can help with boot issues, confusing scaling with troubleshooting.
Your company has an on-premises office network that needs encrypted connectivity to an Azure virtual network. In addition, traveling users need secure access from their laptops when they are away from the office. Which Azure design best meets both requirements?
A VPN gateway supports both site-to-site tunnels for the office network and point-to-site access for individual users. This single design meets the hybrid branch requirement and the remote-user requirement without exposing the VNet directly to the internet. It is the standard Azure networking choice when you need encrypted connectivity from both networks and individual clients.
Why this answer
A VPN gateway supports both site-to-site (S2S) connections for the on-premises office network and point-to-site (P2S) connections for individual traveling users. The S2S connection uses IPsec/IKE to establish encrypted tunnels between the on-premises VPN device and the Azure VPN gateway, while the P2S connection uses SSTP, OpenVPN, or IKEv2 to allow remote laptops to connect securely from anywhere. This single gateway resource can handle both connection types simultaneously, meeting both requirements efficiently.
Why the other options are wrong
VNet peering connects two Azure virtual networks, not an on-premises network to Azure. It does not provide encrypted site-to-site or point-to-site connectivity, so it fails to meet both requirements.
When would these options actually be correct?
A question asks: 'You need to connect two Azure virtual networks in different regions with low-latency, private IP communication. Which solution should you use?' In that case, VNet peering is the correct answer.
A question requiring secure access from an on-premises network to Azure PaaS services (e.g., Azure Storage or SQL Database) without traversing the public internet, while also needing private access for laptops. For example: 'Your company needs to connect its on-premises network to Azure Storage and also allow remote employees to access the storage privately. Which solution should you use?'
A question requiring outbound internet access for Azure resources with source network address translation (SNAT) to a single public IP, while minimizing the number of public IPs used. For example: 'You need to enable outbound internet connectivity for multiple VMs in a subnet using a single public IP address.'
Why candidates pick the wrong answer
Candidates may confuse VNet peering with VPN connectivity, thinking it can extend on-premises networks, or they might believe that once a connection is established, it can be shared with remote users without additional configuration.
Candidates may confuse service endpoints with VPN connectivity, thinking they provide general private access to the virtual network, or they may assume 'private access for laptops' means using a service endpoint, not understanding that service endpoints apply only to Azure services.
A reporting server will run an in-memory analytics application that needs 8 vCPUs and 64 GiB of RAM. The administrator wants a VM family that is a good fit for memory-heavy workloads. Which VM family should be chosen?
Memory-optimized sizes are designed for workloads that need a higher memory-to-vCPU ratio than general-purpose sizes. They are a practical fit for analytics engines, large caches, and in-memory databases where RAM is the main constraint. Choosing this family helps the team meet the workload requirement without paying for unnecessary specialized features that do not address the sizing need.
Why this answer
Memory-optimized VM families (e.g., Azure E-series) are designed for workloads that require a high memory-to-vCPU ratio, such as in-memory analytics applications. The requirement of 64 GiB of RAM for 8 vCPUs (8:1 ratio) aligns with the memory-optimized profile, which offers up to 8 GiB per vCPU or more, ensuring the application's data fits entirely in RAM for low-latency processing.
Exam trap
The trap here is that candidates may confuse 'memory-heavy' with 'compute-heavy' and choose compute-optimized VMs, overlooking the specific memory-to-vCPU ratio required for in-memory analytics.
Why the other options are wrong
The question specifies a memory-heavy workload requiring 64 GiB of RAM, and burstable VM families are designed for workloads with variable CPU usage, not consistent high memory demands.
The question specifies a memory-heavy workload with 64 GiB of RAM, and compute-optimized VMs prioritize high CPU performance over memory capacity, making them unsuitable for this requirement.
Storage-optimized VM families are designed for high disk throughput and I/O, not for large memory requirements. The question specifies a memory-heavy workload needing 64 GiB of RAM, which is not a storage concern.
When would these options actually be correct?
A correct scenario would be: 'A small web server that experiences sporadic traffic spikes and needs cost-effective compute for low-utilization periods.'
A question asks for a VM family for a CPU-intensive application, such as a high-frequency trading platform or batch processing, that requires high vCPU performance but not large memory.
A question asks: 'An application requires high disk throughput and low latency for large data sets, with moderate CPU and memory needs. Which VM family should be chosen?' In that case, storage-optimized would be correct.
Why candidates pick the wrong answer
Candidates may confuse 'burstable' with 'scalable' or think it implies flexibility for any resource, including memory, without understanding its CPU-centric design.
Candidates may confuse 'in-memory analytics' with needing high compute power, overlooking that the primary bottleneck is memory capacity, not CPU speed.
Candidates may confuse 'in-memory analytics' with 'storage' because analytics often involves large data sets, leading them to think storage optimization is key, rather than recognizing the primary constraint is memory capacity.
An application on an Azure VM needs more CPU and memory. The administrator wants to keep the same OS disk and installed apps, without redeploying the server. What should be done?
Resizing the VM changes the allocated compute resources while keeping the same operating system disk and data disks. This is the usual way to give an existing VM more CPU and memory without rebuilding the server. In many cases, you only need to stop the VM briefly, choose a larger size, and start it again.
Why this answer
Resizing the VM (Option A) allows you to change the VM size to a SKU with more CPU and memory while preserving the OS disk, installed applications, and all data. This operation can be performed on a stopped (deallocated) VM and does not require redeployment or reimaging, making it the correct choice for scaling up resources without disruption to the existing configuration.
Exam trap
The trap here is that candidates may confuse 'resizing' with 'reimaging' or think that changing availability zones or storage accounts can affect compute resources, when in fact only changing the VM size directly modifies CPU and memory allocation.
Why the other options are wrong
Reimaging the VM would reset the OS disk to its original state, removing installed applications and custom configurations, which contradicts the requirement to keep the same OS disk and installed apps.
Moving a VM to a different availability zone does not change its CPU or memory resources; it only changes the physical location for high availability.
Creating a new storage account does not change the VM's CPU or memory resources; it only provides additional storage, which does not address the need for more compute capacity.
When would these options actually be correct?
When a VM is corrupted or compromised and needs to be restored to a clean baseline state, and the question specifies that reinstalling applications is acceptable or the OS disk is not required to be preserved.
When the question asks to improve application resilience by distributing VMs across physically separate datacenters within a region, moving to a different availability zone would be correct.
This option would be correct if the question asked: 'An application on an Azure VM is experiencing storage performance issues due to throttling. The administrator wants to increase throughput limits without changing the VM size. What should be done?'
Why candidates pick the wrong answer
Candidates may confuse reimaging with resizing, thinking it can upgrade resources while preserving data, or they may believe reimaging is a standard method to change VM performance characteristics.
Candidates may confuse availability zones with scaling resources, thinking that moving to a different zone provides access to different hardware capabilities.
Candidates may think that a new storage account can provide better performance or resources, confusing storage scalability with compute scalability.
VNet peering is the native Azure connectivity mechanism that links two virtual networks through the Microsoft backbone infrastructure, providing low-latency, private, and high-bandwidth communication without traversing the public internet. Because both VNets reside in the same region and subscription, you can simply enable peering between them, and the existing routing automatically allows resources in vnet spoke1 to reach resources in vnet hub with no additional gateway or encryption overhead.
Why this answer
VNet peering enables direct connectivity between two virtual networks in the same region and subscription over the Microsoft backbone, without requiring a VPN gateway or public internet. This is the correct solution because it provides low-latency, private communication using the Azure infrastructure, and it supports resources in both VNets to communicate as if they were on the same network.
Exam trap
The trap here is that candidates often confuse VNet peering with VPN gateways or service endpoints, mistakenly thinking a VPN gateway is required for cross-VNet communication or that service endpoints can connect VNets, when in fact VNet peering is the native, gateway-free solution for direct VNet-to-VNet connectivity within the same region.
Why the other options are wrong
A site-to-site VPN gateway requires traffic to traverse the public internet or a VPN tunnel, not the Microsoft backbone, and incurs additional cost and complexity. The question explicitly requires communication over the Microsoft backbone without a VPN gateway.
A private endpoint enables secure access to a specific Azure service (e.g., Azure SQL) from a VNet via a private IP, but it does not connect two VNets together. The question requires inter-VNet communication, which private endpoints cannot provide.
Service endpoints allow access to Azure PaaS services from a VNet over the Microsoft backbone, but they do not enable communication between two VNets. VNet peering is required for direct VNet-to-VNet connectivity.
When would these options actually be correct?
A site-to-site VPN gateway would be correct if the VNets are in different regions or different tenants, or if you need encrypted traffic over the public internet, or if VNet peering is not supported (e.g., overlapping address spaces).
A question asking: 'You need to securely connect an Azure SQL database to a VNet so that traffic never traverses the public internet. What should you configure?' — here, a private endpoint would be the correct answer.
A question asking how to securely access an Azure Storage account from a VNet without using a public IP address would make service endpoints correct, as they provide direct connectivity to PaaS services over the Microsoft backbone.
Why candidates pick the wrong answer
Candidates may think VPN gateways are the standard way to connect VNets, especially when security is a concern, and may overlook that VNet peering uses the Microsoft backbone and is simpler for same-region connections.
An administrator enabled Azure VM backup yesterday and now wants to confirm whether the most recent backup job succeeded. Which two places can they check? Select two.
The Recovery Services vault's 'Backup Jobs' blade displays the complete history of backup and restore operations for Azure VMs protected by that vault, including their status (completed, failed, in progress) and detailed error messages if a job failed. When an administrator needs a definitive, per-vault list of job success or failure for a specific backup policy, this is the canonical location to check. It also allows filtering by time range, operation type, and status to isolate yesterday's job.
Why this answer
The Recovery Services vault backup jobs (Option C) is correct because it provides a dedicated view of all backup jobs associated with the vault, including status, start time, and duration. Backup Center (Option D) is correct because it offers a centralized, cross-vault, cross-region dashboard to monitor backup jobs and alerts, making it ideal for confirming the success of the most recent backup.
Exam trap
The trap here is that candidates often confuse the Activity log (which shows who enabled backup) with the actual backup job status, or they mistakenly think Azure Advisor provides operational monitoring, when in fact it only offers proactive recommendations.
Why the other options are wrong
The Activity log records administrative operations like starting/stopping backup jobs, but does not show the success/failure status of individual backup jobs. It lacks the granularity to confirm a specific backup job's outcome.
Azure Advisor provides recommendations for optimizing Azure resources, not real-time backup job status. It does not show the success or failure of individual backup jobs.
Resource Graph is a query service for exploring Azure resources, not for monitoring backup job status. It does not provide direct access to backup job success/failure details.
When would these options actually be correct?
An administrator needs to review all recent management operations on a VM, such as who triggered a backup or when a backup policy was modified. The Activity log would be correct for auditing control plane actions.
In a question asking 'Which tool provides recommendations to improve backup compliance and reliability?', Azure Advisor would be correct as it analyzes backup configurations and suggests best practices.
In a scenario where an administrator needs to query all resources across subscriptions to identify which VMs have backup configured or to list backup policies, Resource Graph would be the correct tool to use.
Why candidates pick the wrong answer
Candidates may think the Activity log tracks all events including backup job results, confusing it with the backup job monitoring capabilities found in Recovery Services vault or Backup center.
Candidates may confuse Azure Advisor's monitoring and recommendation capabilities with operational status checking, assuming it can report on backup job outcomes.
Candidates may think Resource Graph can be used to query backup job status because it can query metadata about Azure resources, but it does not expose operational backup job results.
A team is troubleshooting inbound access to Azure VMs. Match each NSG concept on the left with the most accurate behavior or troubleshooting implication on the right.
Drag a concept onto its matching description — or click a concept then click the description.
The priority 100 rule is evaluated first, so it wins if both rules match the same traffic.
It controls traffic entering the subnet or NIC from another network location.
It filters traffic for a single VM and can be used in addition to a subnet NSG.
It matches any ephemeral source port and does not limit the sender's port selection.
It allows only HTTPS traffic that uses TCP and the specified destination port.
You have an Azure load balancer in front of two virtual machines. The load balancer reports both instances as unavailable even though the VMs are running. What is the most likely cause?
The health probe is failing. Azure Load Balancer continuously sends HTTP, TCP, or HTTPS probes to the configured backend pool endpoints. If the probe does not receive the expected response within the timeout interval, the load balancer marks that backend instance as unhealthy and stops routing new traffic to it, directly causing the symptom of unavailable virtual machines.
Why this answer
The health probe is the mechanism by which the Azure Load Balancer determines the availability of backend instances. If the probe is misconfigured (e.g., wrong port, protocol, path, or interval) or the backend VMs are not responding to the probe requests (e.g., firewall blocking the probe traffic or the application not listening on the specified port), the load balancer marks both instances as 'Unavailable' even though the VMs are running. This is the most common cause of backend pool unavailability.
Exam trap
The trap here is that candidates often assume 'VM is running' means it is automatically available to the load balancer, overlooking the critical role of the health probe configuration and the need for the probe traffic to be allowed by network security rules.
Why the other options are wrong
An availability set ensures high availability by distributing VMs across fault domains, but it does not affect load balancer health probe status. The load balancer reports instances unavailable due to health probe failures, not availability set membership.
The storage account tier (Cool vs. Hot) affects access cost and latency for blob storage, not the health of VMs behind a load balancer. The load balancer's health probe failure is unrelated to storage account configuration.
A budget alert does not affect load balancer health probe status; it only triggers cost-related notifications. The load balancer reports VMs as unavailable due to health probe failures, not subscription billing settings.
When would these options actually be correct?
In a question asking 'What is the purpose of placing VMs in an availability set?', the correct answer would be 'To protect against datacenter-level failures by distributing VMs across fault domains and update domains.'
In a question about why data retrieval costs are high for infrequently accessed data stored in Azure Blob Storage, the Cool tier would be the correct answer because it has lower storage costs but higher access costs compared to the Hot tier.
In a scenario where a subscription budget alert is configured to automatically disable resources (e.g., via an Azure Policy or automation runbook) when a cost threshold is exceeded, the load balancer might show VMs as unavailable if the VMs are stopped or deallocated as a result.
Why candidates pick the wrong answer
Candidates may confuse availability sets with load balancing health, thinking that being in an availability set automatically makes VMs healthy, or they may overthink the role of availability sets in load balancer configuration.
Candidates might confuse storage tier issues with general Azure resource health, or incorrectly assume that a misconfigured storage account could impact VM availability through dependencies like boot diagnostics or custom script extensions.
Candidates may confuse budget alerts with operational alerts that affect resource availability, or mistakenly think that budget constraints can directly impact load balancer health monitoring.
A VM suddenly stops responding, and the operations team needs to determine whether the issue is caused by a Microsoft platform problem or is isolated to that specific VM. Which two Azure portal features should be reviewed? Select two.
Service Health is the correct first stop because it monitors the status of all Azure services across regions and subscriptions in one dashboard. When a VM stops responding, checking Service Health immediately reveals whether an active incident, advisory, or planned maintenance is affecting the VM's region, which separates a large-scale platform outage from a localized VM problem.
Why this answer
Service Health (A) provides a global view of Azure platform-wide issues, such as regional outages or service degradation, that could affect multiple resources. Resource Health (B) reports the health of a specific VM instance, indicating whether the VM is available, degraded, or unavailable, and whether the issue is due to a platform event or a user-initiated action. Together, these two features allow the operations team to differentiate between a Microsoft platform problem and an isolated VM issue.
Exam trap
The trap here is that candidates often confuse 'Service Health' with 'Resource Health' or think Azure Advisor can diagnose real-time outages, but the exam expects you to know that Service Health covers platform-wide issues while Resource Health is per-resource, and neither Diagnostic settings nor Action groups provide health status.
Why the other options are wrong
Azure Advisor provides recommendations for best practices in cost, security, reliability, and performance, but it does not offer real-time health status or incident information for a specific VM or platform issues.
Diagnostic settings are used to configure streaming of platform logs and metrics to destinations like Storage, Event Hubs, or Log Analytics; they do not provide real-time health status of a VM or platform services, so they cannot determine if the issue is platform-wide or VM-specific.
Action groups are used to define notification and remediation actions for alerts, not to diagnose whether a VM issue is caused by a platform problem or isolated to the VM.
When would these options actually be correct?
When asked which Azure service provides personalized recommendations to optimize Azure resources for high availability, security, performance, and cost, Azure Advisor would be the correct answer.
When the question asks: 'Which feature should be configured to send VM metrics and logs to a Log Analytics workspace for analysis?' or 'Which feature enables collection of guest OS performance counters and event logs for a VM?'
When a question asks how to configure email or SMS notifications when a VM becomes unhealthy, or how to trigger an automated runbook in response to a resource health alert, Action groups would be the correct answer.
Why candidates pick the wrong answer
Candidates may confuse Advisor's proactive recommendations with the reactive health monitoring needed for troubleshooting a current outage, assuming it can diagnose ongoing issues.
Candidates may confuse diagnostic settings with health monitoring tools, thinking that enabling diagnostics will show health status, or they may assume that reviewing diagnostic data can help identify the root cause of the outage.
Candidates may confuse the purpose of Action groups, thinking they help in diagnosing issues because they are associated with alerts, but they only define responses to alerts, not diagnostic information.
You have a storage account named stlogs01. An application running on VM-App01 in Azure must access blobs in the account without storing account keys in code or configuration files. What should you use?
For the correct approach, configure a system-assigned managed identity on VM-App01 so the application acquires an Azure AD token automatically at runtime, then grant that identity the Storage Blob Data Contributor (or a minimally scoped custom) RBAC role at the storage account or container level. This completely removes secret management because the managed identity is the security principal, tokens are issued by Azure AD, and credentials are rotated automatically. Unlike keys or SAS, there is no embedded secret to leak, and access can be surgically revoked by removing the role assignment—making this the only option that satisfies a strict identity-based, no-secrets security requirement.
Why this answer
Using a managed identity for VM-App01 allows the application to authenticate to Azure Storage without storing any credentials in code or configuration files. The managed identity is automatically managed by Azure AD, and you grant it access to the blob container using Azure RBAC (e.g., the Storage Blob Data Contributor role). This eliminates the need for account keys or shared access signatures.
Exam trap
The trap here is that candidates may think a SAS token stored in a file is acceptable because it is not an account key, but the question explicitly prohibits storing any secrets in code or configuration files, and a SAS token is still a secret that must be protected.
Why the other options are wrong
Storing a shared access signature in a text file on the VM still exposes credentials in a file, which violates the requirement to avoid storing account keys in code or configuration files. It also does not leverage Azure RBAC or managed identities for secure access.
Hard-coding the storage account access key in the application violates the requirement to avoid storing keys in code or configuration files, and it poses a security risk if the code is exposed.
Anonymous public access allows anyone on the internet to read blobs without authentication, which violates the requirement to restrict access to the application without storing keys.
When would these options actually be correct?
If the question required granting time-limited, delegated access to specific blobs without using Azure AD authentication, and the application could securely retrieve the SAS from a file (e.g., via Azure Key Vault or a secure configuration management system), then a shared access signature stored in a text file could be correct.
In a scenario where the application runs in a trusted environment, the storage account access key is managed securely (e.g., via Azure Key Vault), and the question does not prohibit storing keys in code, using the access key directly might be acceptable for simplicity.
If the question asked for a method to allow public read access to blobs in a container for a website or public dataset, and security or authentication is not a concern, then enabling anonymous public access on the container would be correct.
Why candidates pick the wrong answer
Candidates may think a SAS is a secure way to grant access without exposing the account key, but they overlook that storing it in a file on the VM still constitutes a credential stored in a configuration file, which the question explicitly prohibits.
Candidates may think that using the access key is straightforward and secure enough, not realizing that managed identities provide a more secure, keyless authentication method recommended by Azure.
Candidates may think anonymous access is a simple way to avoid storing keys, but they overlook the security implications and the requirement that only the application should access the blobs.
Two backend VMs must remain available if an Azure host is patched or fails. A full datacenter outage is not part of the requirement, and the team wants the VMs to stay in the same region with predictable east-west latency. Which placement option should the administrator choose?
An availability set spreads the two backend VMs across multiple fault domains (distinct racks with separate power and network switches) and update domains (hosts rebooted one at a time during patching). By placing each VM in a different fault domain, Azure guarantees that at least one VM stays running when a single physical host fails or undergoes maintenance, so this directly meets the resilience requirement with minimal configuration.
Why this answer
An availability set distributes VMs across multiple fault domains (separate physical racks with independent power, cooling, and network) within a single Azure datacenter. This protects against host patching and hardware failures while keeping VMs in the same datacenter, ensuring predictable east-west latency. The requirement explicitly excludes a full datacenter outage, so availability zones (which span separate datacenters) are unnecessary.
Exam trap
The trap here is that candidates confuse availability zones (which protect against datacenter failures) with availability sets (which protect against host failures within a single datacenter), leading them to choose zones even when the requirement explicitly excludes a full datacenter outage.
Why the other options are wrong
Availability zones place VMs in physically separate datacenters within a region, which protects against a single host failure but also introduces cross-zone latency. The requirement specifies predictable east-west latency and staying within the same region without needing full datacenter redundancy, making availability sets a better fit.
A proximity placement group reduces network latency between VMs but does not protect against host patching or failure; it can place VMs on the same host, increasing failure risk.
A single VM scale set instance does not provide high availability; it is just one VM. The requirement for two backend VMs to remain available during host patching or failure necessitates redundancy, which a single instance cannot offer.
When would these options actually be correct?
If the requirement were to protect against a full datacenter outage (e.g., due to fire or flooding) while still staying within the same region, availability zones would be correct. For example: 'Two backend VMs must remain available if an entire Azure datacenter fails, but must stay in the same region for low latency.'
An administrator needs to minimize east-west latency between VMs for a high-performance computing workload, and availability is not a primary concern—only low latency matters.
When the requirement is to automatically scale out multiple identical VMs based on load, and high availability is achieved by using multiple instances in the scale set across availability zones or an availability set. For example, 'Deploy a scalable web application that can handle variable traffic with at least two VMs.'
Why candidates pick the wrong answer
Candidates may think availability zones are always the best for high availability, not realizing they introduce cross-zone latency and are overkill when only host-level redundancy is needed.
Candidates may confuse low latency with high availability, assuming that grouping VMs closely together also provides redundancy.
Candidates may think a VM scale set inherently provides high availability because it can manage multiple VMs, but a single instance scale set offers no redundancy, confusing scalability with availability.
A reporting application will run on a single Azure VM and needs 8 vCPUs, 64 GiB of RAM, and a temporary local disk for cache. The team wants a size that satisfies the requirement without oversizing memory or paying for an unnecessarily large specialty series. Which two VM sizes meet the requirement best? Select two.
This size provides 8 vCPUs and 64 GiB of memory, matching the workload requirement closely.
Why this answer
The E8as_v5 is correct because it provides 8 vCPUs and 64 GiB of RAM, matching the requirement exactly, and includes a temporary local disk (SSD) for cache. It belongs to the memory-optimized Esv5 series, which is designed for memory-intensive workloads without oversizing, and the 'as' variant includes local temporary storage.
Exam trap
The trap here is that candidates often overlook the local temporary disk requirement and select a VM size that meets vCPU and RAM but lacks local storage (e.g., D8as_v5 without 's' or F-series), or they choose an M-series VM that grossly oversizes memory, mistaking 'memory-optimized' as always appropriate for any memory need.
Why the other options are wrong
The D8as_v5 has only 32 GiB of RAM, which is half the required 64 GiB, and it lacks a local temporary disk for cache, failing the storage requirement.
The F8s_v2 has only 8 vCPUs and 16 GiB of RAM, which is far below the required 64 GiB of RAM for the reporting application.
The M8ms is a memory-optimized VM from the M-series, which is designed for large in-memory workloads like SAP HANA. It provides 8 vCPUs and 64 GiB of RAM, but it is a specialty series that is significantly more expensive than the E-series, and the question specifies avoiding unnecessarily large specialty series. Additionally, the M8ms does not include a temporary local disk for cache, which is required by the application.
When would these options actually be correct?
This size would be correct for a general-purpose workload needing 8 vCPUs and 32 GiB of RAM without a local temporary disk, such as a web server or small database that relies on remote storage.
This size would be correct for a compute-intensive batch processing job that needs high CPU performance but minimal memory, such as a video encoding task requiring 8 vCPUs and less than 16 GiB of RAM.
This option would be correct in a scenario where the application requires very high memory-to-core ratio (e.g., 8 GiB per vCPU or more) and is a large in-memory database or analytics workload that benefits from the M-series' memory bandwidth and large cache. The question would specify that cost is not a primary concern and that the VM must be from the M-series for compatibility or performance guarantees.
Why candidates pick the wrong answer
Candidates may see 'D' series as cost-effective and assume the 'as' variant includes local storage, but D-series 'as' variants do not have local temp disks, unlike E-series 'ds' variants.
Candidates may focus only on the vCPU count (8 vCPUs) and overlook the memory requirement, or they might assume the F-series is suitable for any general-purpose workload without checking memory specifications.
Candidates may see that M8ms exactly matches the vCPU and RAM requirements (8 vCPUs, 64 GiB RAM) and assume it is a good fit, without realizing that the M-series is a premium specialty series that is overkill for a reporting application needing only a temporary local disk cache. They may overlook the cost and series constraints mentioned in the question.
Based on the exhibit, what should the administrator use to temporarily allow the legacy storage account to remain noncompliant without changing the policy for everyone?
A policy exemption is designed for approved exceptions to an existing assignment. It lets the legacy storage account remain temporarily outside the deny effect while preserving the policy for everything else. This keeps governance intact and documents the exception clearly.
Why this answer
A policy exemption allows the administrator to exclude a specific resource (the legacy storage account) or its resource group from the Azure Policy evaluation without modifying the underlying policy definition. This is the correct approach because it temporarily grants noncompliance for that resource while the policy remains enforced for all other resources, aligning with the requirement to avoid changing the policy for everyone.
Exam trap
The trap here is that candidates often confuse policy exemptions with resource locks or policy definition modifications, mistakenly thinking a ReadOnly lock or moving the resource will bypass policy evaluation, when in fact only an exemption explicitly excludes a resource from policy compliance checks.
Why the other options are wrong
Modifying the policy definition to allow public network access for all storage accounts would affect everyone, not just the legacy account. The requirement is to temporarily allow only the legacy account to be noncompliant without changing the policy for others.
Applying a ReadOnly lock prevents any changes to the storage account, but it does not exempt the account from policy compliance. The policy would still evaluate the account as noncompliant because public network access remains enabled.
Moving the storage account to another subscription would remove it from the policy's scope, but the question asks for a temporary solution without changing the policy for everyone. This approach is not temporary and could cause other compliance or management issues.
When would these options actually be correct?
If the question asked for a permanent solution to allow public network access for all storage accounts, or if the policy was too restrictive and needed to be relaxed globally, then modifying the policy definition would be correct.
A ReadOnly lock would be correct if the question asked how to prevent accidental modifications or deletions of a critical storage account while still allowing read access, without any policy compliance requirement.
If an organization wants to permanently exclude a resource from a policy without affecting other resources, and the policy is scoped to a specific subscription, moving the resource to a different subscription that does not have the policy assigned would be a valid solution.
Why candidates pick the wrong answer
Candidates may think that changing the policy is the most direct way to resolve noncompliance, overlooking the need to isolate the exemption to a single resource.
Candidates may confuse locks with policy exemptions, thinking that locking the resource prevents policy evaluation or enforcement, or they may believe that a lock can override policy effects.
Candidates may think that moving the resource to another subscription is a quick way to bypass the policy, overlooking that it's not temporary and may introduce other complications like network connectivity or management overhead.
An application uses two Azure VMs in the same datacenter and must continue through planned maintenance and a single hardware host failure. The administrator does not need separate datacenter protection. Which option should be used?
An availability set is designed to spread VMs across update and fault domains within a datacenter. That reduces the chance that maintenance or a host failure takes down all instances at once. Because the scenario only requires protection from host-level and planned maintenance events, an availability set is the appropriate and cost-effective choice.
Why this answer
An availability set distributes VMs across multiple fault domains (hardware hosts) and update domains within a single Azure datacenter. This ensures that during planned maintenance (update domains) or a single hardware host failure (fault domains), at least one VM remains available. Since the requirement does not include separate datacenter protection, an availability set is the correct choice.
Exam trap
The trap here is that candidates often confuse availability zones (which offer datacenter-level redundancy) with availability sets (which offer host-level redundancy within a single datacenter), leading them to choose zones even when the requirement explicitly states no separate datacenter protection is needed.
Why the other options are wrong
Availability zones provide datacenter-level redundancy across multiple physical locations within a region, but the question explicitly states no separate datacenter protection is needed. The requirement is only for protection against planned maintenance and a single hardware host failure, which an availability set handles within a single datacenter.
Proximity placement groups reduce network latency between VMs but do not provide high availability against planned maintenance or hardware failures. They lack fault domain and update domain isolation.
A virtual machine scale set provides auto-scaling and load balancing across multiple VMs, but it does not guarantee protection against planned maintenance or a single hardware host failure unless combined with an availability set or zones. The question specifies only two VMs and no need for scaling, making an availability set the simpler and correct choice.
When would these options actually be correct?
A question requiring high availability and disaster recovery across datacenters within a region, such as: 'An application must remain available if an entire Azure datacenter fails. Which option should be used?'
A question requiring the lowest latency between VMs in the same region, such as for tightly coupled workloads like HPC or real-time data processing, where availability against failures is not the primary concern.
A question requiring automatic scaling of VMs based on demand, such as a web application that experiences variable traffic and needs to add or remove instances automatically, would make a virtual machine scale set the correct answer.
Why candidates pick the wrong answer
Candidates may confuse availability zones with availability sets, thinking both offer similar high availability, but zones provide broader fault isolation at the datacenter level, which is unnecessary here.
Candidates may confuse proximity placement groups with availability sets because both involve grouping VMs, but proximity groups focus on performance, not fault tolerance.
Candidates may confuse scale sets with high availability because scale sets can distribute VMs across fault domains, but they are primarily for scaling, not for ensuring availability of a fixed number of VMs through planned maintenance.
A team can already deploy virtual machines, but they want to prevent users from creating VMs unless the deployment includes an approved tag. They also want to see which existing resources do not meet the rule. What should the administrator use?
Azure Policy is the correct control because the requirement is about resource compliance, not user authorization. A policy can deny deployments that do not include the approved tag and can also audit existing resources to show which ones are noncompliant. That separates governance enforcement from RBAC, which only decides who is allowed to perform actions in Azure.
Why this answer
Azure Policy with a 'deny' effect prevents creation of VMs that lack the required tag, while the 'audit' effect identifies non-compliant existing resources without blocking them. This directly addresses both requirements: enforcing the tag on new deployments and discovering which existing resources violate the rule.
Exam trap
The trap here is confusing Azure Policy (which enforces rules on resource properties like tags) with RBAC (which controls who can perform actions), leading candidates to mistakenly choose a custom role instead of the policy-based solution.
Why the other options are wrong
A custom RBAC role that removes the create action for VMs would prevent all VM creation, not enforce a tag requirement. It cannot audit existing resources for compliance, only block future actions.
A resource lock prevents deletion or modification of resources but does not enforce tagging requirements during deployment or audit existing resources for compliance.
Entra ID dynamic groups manage user membership based on attributes, not resource compliance. They cannot enforce tagging rules on VM deployments or audit existing resources for missing tags.
When would these options actually be correct?
This would be correct if the goal was to completely prevent a specific user or group from creating any VMs, regardless of tags, such as enforcing a separation of duties where only a dedicated team can provision VMs.
An administrator needs to prevent accidental deletion of a critical resource group containing production VMs. A resource lock (e.g., CanNotDelete) would be the correct solution.
An administrator needs to automatically grant or revoke access to Azure resources based on user attributes (e.g., department or location). In that case, an Entra ID dynamic group would be used to assign RBAC roles dynamically.
Why candidates pick the wrong answer
Candidates may confuse RBAC with Azure Policy, thinking that restricting the create action can enforce tagging, but RBAC controls permissions, not resource configuration compliance.
Candidates may confuse resource locks with policy enforcement, thinking a lock can block creation of VMs without tags, but locks only protect existing resources from changes or deletion.
Candidates may confuse identity-based governance (Entra ID groups) with resource governance (Azure Policy), thinking that controlling who can create VMs is equivalent to enforcing tagging rules.
Based on the exhibit, a security team wants to search Key Vault audit events in Log Analytics for 30 days and create alerts when secrets are accessed unexpectedly. The current diagnostic configuration is not sending the right data. What should the administrator enable?
To make Key Vault activity searchable, you must enable the AuditEvent diagnostic category and route it to a Log Analytics workspace. That workspace stores the event data in a structured format that supports KQL queries, time-range filtering, and Azure Monitor log alerts, which are all required for the security team's investigation. Sending audit events to a storage account would only archive them, making real-time search and alerting impractical.
Why this answer
The Key Vault diagnostic setting must include the AuditEvent category to capture all audit logs, including secret operations. Sending these logs to a Log Analytics workspace enables the security team to query them for 30 days and create alerts on unexpected secret access. Without AuditEvent enabled, no audit data is available for analysis.
Exam trap
The trap here is that candidates often confuse AllMetrics (which provides performance data) with AuditEvent (which provides security logs), or mistakenly think that network controls like private endpoints or resource locks can substitute for proper diagnostic logging configuration.
Why the other options are wrong
AllMetrics captures performance metrics, not audit events. The question requires searching audit events for secret access, which only AuditEvent provides. Sending to a storage account also prevents real-time alerting in Log Analytics.
Creating a private endpoint for Key Vault restricts network access but does not enable audit logging or send audit events to Log Analytics, which is required to search logs and create alerts.
When would these options actually be correct?
If the question asked to monitor Key Vault performance (e.g., request latency, availability) and retain data in a storage account for compliance, enabling AllMetrics and sending to storage would be correct.
A question where the requirement is to ensure that Key Vault is accessed only over a private network and not exposed to the public internet, such as 'You need to secure Key Vault access to only resources within a virtual network.'
Why candidates pick the wrong answer
Candidates may confuse metrics with logs, assuming 'AllMetrics' includes all data, or think storage accounts are sufficient for log analysis without understanding Log Analytics is needed for querying and alerting.
Candidates may confuse network security controls (private endpoints) with logging and monitoring capabilities, thinking that restricting access also provides auditing.
Page 14 of 14
Practice AZ-104 by domain
Target a specific domain to shore up weak areas.