Practice Test #1

Yes. VM1 can be reached from the Internet over HTTP because it has an Internet-facing entry point and an effective inbound allow path for TCP/80. In Azure, that typically means VM1 either has a public IP assigned to its NIC (or is behind a public Load Balancer/App Gateway) and the applicable NSG (NIC-level and/or subnet-level) includes an inbound rule permitting TCP port 80 from Internet (or from Any) to the VM. This explicit allow is required because the default NSG rules do not allow inbound from Internet; without a custom allow rule, inbound HTTP would be denied. Since the question asks specifically about connecting to the web server using HTTP, the key is that TCP/80 is permitted end-to-end. Any other rules (for example, allowing only HTTPS/443) would not satisfy HTTP access.

No. VM2 cannot be reached from the Internet over HTTP because it does not have an effective Internet-to-VM inbound path for TCP/80. The most common reasons (and the ones typically tested in AZ-500) are: VM2 has no public IP and is not published through a public Load Balancer/Application Gateway, and/or the NSG effective rules do not include an inbound allow for TCP/80 from Internet. Even if VM2 runs a web server internally, without a public endpoint and an NSG rule allowing inbound HTTP, Internet clients cannot initiate a connection. Also note that default NSG rules only allow inbound from within the virtual network and from the Azure Load Balancer, not from Internet. Therefore, absent an explicit allow and a public entry point, HTTP from the Internet will fail.

No. VM3 cannot be reached from the Internet over HTTP because it is not exposed for inbound TCP/80 from Internet based on the effective connectivity controls. As with VM2, Internet reachability requires both (1) an Internet-facing IP (directly on the VM NIC or indirectly via a public load-balancing/publishing service) and (2) an NSG rule that allows inbound TCP/80 from Internet at a higher priority than any deny. If VM3 is only on a private subnet, has no public IP, or is protected by an NSG that lacks an allow rule for port 80 (or includes a deny that takes precedence), then HTTP connections from the Internet cannot be established. This aligns with secure networking best practices: keep backend VMs private and publish only through controlled ingress (WAF/App Gateway/Front Door) when needed.

Yes. User1 is assigned the Contributor role at the Tenant Root Group scope. RBAC assignments at the tenant root management group inherit to all child management groups, subscriptions, resource groups, and resources in the tenant. RG1 is under Subscription1, which is under ManagementGroup1, which is under the Tenant Root Group; therefore User1 has Contributor permissions on RG1. Contributor includes Microsoft.Compute/virtualMachines/write and related permissions needed to deploy (create) virtual machines in RG1. There is no indication of any deny assignment or policy that would block VM creation, so from an RBAC perspective User1 can deploy VMs to RG1.

Yes. User2 is assigned the Virtual Machine Contributor role at the Subscription2 scope. VM2 is in RG2, and RG2 is within Subscription2, so the role assignment applies to VM2 via inheritance. Virtual Machine Contributor allows managing virtual machines, including deleting them (it includes actions such as Microsoft.Compute/virtualMachines/delete). While this role does not grant full control over related resources like VNets or storage accounts, deleting an existing VM resource itself is within scope of the role. Therefore, User2 can delete VM2 (assuming no resource locks or deny assignments are present, which are not mentioned).

No. User3 is assigned Virtual Machine Administrator Login at the RG2 scope. This role is intended for OS-level access: it allows the user to log in to the VM as an administrator using Azure AD-based login (when the VM is configured for AAD login and the OS supports it). It is not a management-plane role for changing Azure resource configuration. Resetting the password of the built-in local Administrator account is typically done via management-plane operations (for example, using the VMAccess extension/Reset password feature), which requires permissions like Microsoft.Compute/virtualMachines/extensions/write and related compute actions. Virtual Machine Administrator Login does not include those management permissions, so User3 cannot reset the built-in Administrator password through Azure.

Yes. In the inbound rules exhibit for NSG1, the custom rule named Allow_RDP is configured to allow Remote Desktop traffic on port 3389. That means its action is Allow and its destination port is 3389. This is distinct from the default inbound rules, which do not open RDP from the internet by themselves.

Yes. The inbound rules shown for NSG1 include Rule1 with source set to ASG1 and action set to Allow. NSG rules can use Application Security Groups as source or destination objects, so this is a valid configuration. Therefore the statement matches the exhibit and should be marked Yes.

Yes. The exhibit includes Rule2 as a custom inbound NSG rule, and it uses ASG2 as the source with an Allow action. This means traffic originating from VMs in ASG2 is explicitly permitted by that rule, subject to the other rule fields such as destination and port. Since the statement matches the rule definition, the correct answer is Yes.

No. Based on the inbound rules exhibit, Rule3 is not defined as having source ASG4 with action Allow. The custom rules shown identify specific ASG-based sources, and this statement does not match the actual Rule3 configuration. Therefore the statement should be marked No.

Yes. The inbound rules exhibit includes Rule4 and its action is Deny. Custom deny rules in an NSG take precedence over lower-priority default rules and can block traffic even when a broader default allow might otherwise apply. Because the statement matches the rule definition, the correct answer is Yes.

Yes. AllowVnetInBound is a default inbound NSG rule with Source set to VirtualNetwork, Destination set to VirtualNetwork, and Action set to Allow. The question asks about the rule definition itself, and that definition is standard for every NSG. Other inbound rules with higher priority can override its effect for specific traffic, but they do not change the default rule's configured properties.

Yes. Another default inbound NSG rule is AllowAzureLoadBalancerInBound. It allows traffic where Source = AzureLoadBalancer and Action = Allow (destination is typically Any within the scope). This default rule supports Azure Load Balancer health probes and related platform traffic. It is present by default in every NSG unless replaced by custom rules with higher priority (lower number). The exhibit doesn’t show inbound rules, but the question is asking whether the default rule has that source and action, which is correct.

Yes. The default inbound NSG rule DenyAllInBound has Action = Deny. This rule is evaluated after AllowVNetInBound and AllowAzureLoadBalancerInBound, and it blocks all other inbound traffic (including from Internet) unless a higher-priority custom allow rule exists. This is the key reason why simply having a public IP on a VM does not automatically make management ports reachable: you must explicitly allow them in the NSG (and also ensure the OS firewall allows it). Therefore, the statement about DenyAllInBound being a deny rule is true.

Yes. VM1 and VM3 are in peered virtual networks, so there is network reachability between Subnet1 and Subnet3. The VM firewalls allow ICMP, and the inbound NSG rules shown permit the relevant traffic path rather than blocking it. Therefore VM1 can successfully ping VM3; this is not determined solely by the default rules because custom inbound rules must also be considered.

No. VM2 is in Subnet2 of VNET2. VM4 is in Subnet4 of VNET4. VNET4 has no peering configured (Peered network = None). Without VNet peering, VPN gateway, ExpressRoute, or other routing connectivity, there is no network path between VNET2 and VNET4. NSG rules cannot create connectivity; they only allow/deny traffic that already has a route. Even though VM4 has a public IP, VM2 cannot reach VM4’s private IP due to lack of routing, and reaching VM4’s public IP would be “Internet” traffic and would require VM4 to respond appropriately; additionally, inbound to VM4 from Internet is denied by default (DenyAllInBound). Thus, VM2 cannot ping VM4 successfully.

No. VM3 has a public IP address, but inbound access from the internet is blocked by default by the NSG inbound rule DenyAllInBound unless there is an explicit inbound allow rule for TCP/3389 (RDP) from Internet (or a specific source IP range). The exhibit only shows outbound rules, and there is no shown inbound rule such as Allow_RDP. Therefore, RDP from the internet to VM3 will be denied at the NSG. This aligns with security best practices (Azure Well-Architected Framework): avoid exposing RDP/SSH directly; use Azure Bastion, Just-In-Time VM access (Defender for Cloud), or restrict to known admin IPs via NSG.