Microsoft AZ-500

Yes. A policy assignment scoped to RG1 that specifies a Not allowed resource types list including Microsoft.Compute/virtualMachines (often shown as “virtualMachines”) will deny create operations for that resource type within RG1. Azure Policy with a Deny effect is evaluated by Azure Resource Manager when a request is made to create or update a resource. Because the scope is RG1, the restriction applies to resources in RG1 only. This does not retroactively delete or disable existing VMs; it prevents future create/update requests that would violate the policy. Also, it does not automatically block runtime actions unless those actions are implemented as ARM writes and are explicitly denied by policy conditions (most “not allowed resource types” policies focus on resource creation). Therefore, the statement that virtualMachines are not allowed at scope RG1 is true.

Yes. A policy assignment scoped to RG2 that specifies Allowed resource types including Microsoft.Compute/virtualMachines means only the listed types are permitted for create/update operations in RG2. If virtualMachines is in the allowed list, then creating a VM is permitted by that policy (assuming no other policy assignments deny it). In Azure Policy, “Allowed resource types” is typically implemented with a Deny effect for any resource type not in the list. So the presence of virtualMachines in the allowed list explicitly permits that type at that scope. This is a common governance control to restrict what can be deployed in a resource group. Therefore, the statement that virtualMachines are allowed at scope RG2 is true.

Yes. The statement is about the lock configuration: Lock1 is Read-only and created on VM1. A Read-only lock applied directly to a VM resource means the VM resource cannot be modified through ARM operations. This includes operations that change state or configuration (for example, start/stop/restart, resizing, updating extensions), because these are executed via ARM and treated as write operations. In exam questions, when a lock is described as being created “on VM1,” it means the lock scope is the VM resource itself (not inherited from the resource group). That scope is narrower than an RG-level lock, but it is still sufficient to block modifications to VM1. Therefore, the statement describing Lock1 is true.

Yes. The statement is about the lock configuration: Lock2 is Read-only and created on RG2. A Read-only lock at the resource group scope applies to the resource group and all resources within it (inheritance). That means any resource in RG2 becomes effectively read-only from an ARM perspective: you can’t create, delete, or modify resources in that RG while the lock is in place. This is a strong protection mechanism used to prevent accidental changes to critical environments. In the context of the question, it also means that even if Azure Policy would allow a VM type in RG2, the Read-only lock would still block creation or modification operations. Therefore, the statement that Lock2 is Read-only and created on RG2 is true.

No. You cannot start VM1 because Lock1 is a Read-only lock applied to VM1. Starting a VM is an ARM control-plane action (Microsoft.Compute/virtualMachines/start/action) and is treated as a write/modify operation against the VM resource. Read-only locks block write operations, so the start request will be denied by Azure Resource Manager. Even though VM1 is currently Stopped (Deallocated), the deallocated state does not bypass locks. Locks are evaluated at the time of the management operation. Also, Azure Policy about “not allowed resource types” in RG1 primarily affects creation of new resources; it is the Read-only lock that directly prevents the start operation. Therefore, the statement “You can start VM1” is false.

No. You cannot start VM2 because Lock2 is a Read-only lock applied at the RG2 scope. Resource group locks are inherited by all resources in the group, including VM2. As with VM1, starting a VM is a management operation executed via ARM and is considered a modification of the VM resource state. A Read-only lock at the resource group level blocks any write operations on resources in that group, including start/stop/restart and configuration changes. Azure Policy in RG2 allowing virtualMachines does not override the lock; locks are enforced independently by ARM and will still deny the operation. Therefore, the statement “You can start VM2” is false.

No. Even though the Azure Policy in RG2 allows the virtualMachines resource type, the Read-only lock (Lock2) on RG2 prevents creating any new resources in that resource group. Creating a VM is an ARM create operation (a write) and is blocked by a Read-only lock at the resource group scope. This is a key exam point: Azure Policy determines whether a request is compliant and can be accepted, but a lock can still block the operation even if it is compliant. In other words, “allowed by policy” does not mean “possible” when a Read-only lock exists. To create a VM in RG2, you would need to remove or change the lock (for example, remove Read-only or use a different protection strategy). Therefore, the statement “You can create a virtual machine in RG2” is false.

User1 is in the Enabled state for per-user MFA. Enabled means the user is enabled for MFA registration, but MFA is not yet strictly enforced for sign-ins in the same way as the Enforced state. Although 134.18.14.10 is not in a trusted IP range and only phone-based methods are available, the statement says User1 must be authenticated by using a phone, which is not guaranteed for a user in Enabled state. Therefore, the correct answer is No.

User2 is Enforced for per-user MFA, meaning MFA is required at sign-in unless a trusted IP bypass applies. The sign-in is from the Seattle office. However, Seattle users egress through the public NAT segment 190.15.1.0/24. The trusted IP list includes 10.10.0.0/16 (Seattle internal space) but does not include 190.15.1.0/24. Azure AD evaluates the public source IP it receives, so the Seattle sign-in will not match the trusted IP configuration and MFA will still be required. The statement claims User2 must use the Microsoft Authenticator app. That is incorrect because the verification options do not allow app-based methods (both “Notification through mobile app” and “Verification code from mobile app or hardware token” are unchecked). With only phone call/SMS enabled, User2 cannot be required to use the Authenticator app. Therefore, the statement is false.

User2 is Enforced, so normally MFA would be required. But the sign-in is from the New York office, which uses public NAT segment 194.25.2.0/24. That exact public range is included in the trusted IPs list. Because Azure AD will see the source IP as 194.25.2.x, the request matches a trusted IP range and MFA is skipped for that sign-in. Since MFA is bypassed, User2 does not need to complete a phone call or SMS challenge (or any MFA method) for this sign-in. Therefore, the statement “User2 must be authenticated by using a phone” is not true in this scenario. Note that the presence of 172.16.0.0/16 (New York internal space) is irrelevant to Azure AD’s evaluation because it is not the public egress IP seen by Azure AD.

Create 1 NSG. Since all VMs are in the same subnet, you can associate a single NSG to the subnet and control traffic to all NICs/VMs in that subnet. This minimizes NSG count and is a common exam pattern: use one subnet-level NSG unless you need different policies per subnet or you must apply different NSGs to different NICs. Here, the requirements can be expressed with ASG-based rules inside one NSG (target AppGroup12 for Internet access and AppGroup4 for VM4 restrictions). Creating 2–4 NSGs would not reduce the number of rules needed and would increase management overhead, violating the “minimize the number of NSGs” requirement.

Create 3 security rules (inbound) in the single NSG. 1) Allow Internet -> AppGroup12 (VM1 and VM2) on required ports (ports aren’t specified, so conceptually “traffic”). This satisfies “Allow traffic from the Internet to VM1 and VM2 only” because other VMs remain blocked by default DenyAllInBound. 2) Allow AppGroup3 (VM3) -> AppGroup4 (VM4). This permits VM3 to reach VM4. 3) Deny VirtualNetwork -> AppGroup4. This is required because the default AllowVnetInBound would otherwise allow VM1/VM2 (and any other VNet source) to reach VM4. Place rule (2) at a higher priority (lower number) than rule (3) so VM3 remains allowed while all other VNet sources are denied. With only 2 rules, you cannot both allow VM3 and block all other VNet sources due to the default allow.

Group1’s evaluated membership results in exactly two users: User2 and User4. This outcome is consistent with either (a) an Assigned group where only User2 and User4 are explicitly added, or (b) a Dynamic user group where only User2 and User4 match the rule shown in the prompt image (for example, a specific department, job title, or user type). The other options don’t fit: - A (No members) would require that no users are assigned and/or no users match the dynamic rule. - B (Only User2) would require User4 to be absent from the assigned list or fail the dynamic rule. - D (User1, User2, User3, and User4) would require all users to be explicitly assigned or all to match the dynamic rule, which is not the case based on the scenario’s membership evaluation.

Group2’s evaluated membership includes User1 and User3 only. This is typical of a Dynamic user group where the rule matches exactly those two users’ attributes (for example, user.department -eq "HR" matching User1 and User3, while User2 and User4 are in other departments), or an Assigned group where only those two are explicitly added. The incorrect options are eliminated as follows: - A (No members) contradicts the evaluated membership shown. - B (Only User3) would require User1 not to be assigned and/or not to satisfy the dynamic rule. - D (User1, User2, User3, and User4) would require all users to be assigned or to match the rule, which is not supported by the scenario’s membership outcome. For AZ-500, remember dynamic membership is calculated automatically and is driven strictly by the rule; it’s commonly used to enforce least privilege at scale.

Pass. The correct sequence is: 1) Create an access review program. 2) Create an access review control. 3) Set Reviewers to Group owners. Why: The requirement says the review will be assigned to a new collection of reviews—this is an Access Review Program, which must exist before you can assign the review to it. Next you create/configure the actual access review (the “control”), which defines what is being reviewed and its schedule/settings. Finally, because the review must be reviewed by resource owners, you set the reviewers to the owners of the resource. In the provided options, “Set Reviewers to Group owners” best matches “resource owners” for group-based access reviews. Why others are wrong: “Selected users” and “Members” don’t satisfy “resource owners.” “Create an access review audit” is not a setup step; auditing is inherent via logs and reporting rather than a created object.

Azure Disk Encryption for Windows requires a supported Windows Server version, and Windows Server 2008 R2 is not supported for ADE. Therefore, VM1 must be changed to a supported operating system version before disk encryption can be enabled. The tier is not the determining issue here, and the VM size/type itself is not the blocker as long as the VM runs a supported OS and can use the required extension.

Azure Disk Encryption on Linux supports specific endorsed distributions and images, and Ubuntu 16.04-DAILY-LTS is not a supported production image for ADE. To enable encryption, VM2 must be changed to a supported operating system version/image, such as an officially supported Ubuntu LTS marketplace image. The tier is already Standard, so that is not the issue, and the L4s VM type is not the blocker for ADE in this scenario.

The correct effect is DeployIfNotExists because the requirement is to ensure every VM has a specific antimalware VM extension installed. DeployIfNotExists evaluates compliance and, when the required related resource/configuration is missing (the VM extension), it can automatically deploy it via an embedded ARM template. This is the standard pattern for enforcing VM extensions, diagnostic settings, and other “should be configured” requirements. Why not Deny? Deny would only prevent creation or update operations that don’t meet the condition; it does not remediate existing VMs that are already deployed without the extension, and it can also disrupt legitimate VM operations if not carefully scoped. Why not Append? Append (and its modern replacement Modify) is used to add or alter properties on the resource being created/updated, but it cannot reliably create a separate child resource like Microsoft.Compute/virtualMachines/extensions. Therefore, DeployIfNotExists is the only option that both detects absence and installs the extension to reach compliance.

In a DeployIfNotExists policy, the policy rule's details section includes an existenceCondition to determine whether the related resource already exists and is compliant. For a VM extension scenario, this condition checks whether the required antimalware extension is present on the virtual machine. Template is used later inside the deployment definition to describe what to deploy for remediation, and resources is only a section within an ARM template, not the policy field being asked for here.