Practice Test #2

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.

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.

No. Ping uses ICMP, and NSG rules only allow traffic that matches an explicit allow (or the default “AllowVNetInBound” if no higher-priority deny/limit exists). In typical ASG-based designs for a web tier, a custom inbound rule on VM4 (or its subnet) allows TCP/80 (and possibly TCP/443) from a specific source ASG (for example, VM1/VM2 in an “App” ASG) to the destination ASG containing VM4 (“Web”). If the inbound rules are restricted to TCP 80/443, ICMP is not included, so VM1 cannot successfully ping VM4. Also, if there is any higher-priority deny rule for intra-VNet traffic except web ports, that deny will override the default AllowVNetInBound. Therefore, even though VM1 may be permitted to reach the web service, ICMP echo requests will be blocked and ping will fail.

No. The same reasoning as sub-question 0 applies: ICMP is not TCP/UDP and is commonly not permitted when NSG rules are written to allow only web traffic to the web server ASG. Even if VM2 is in the same subnet/VNet as VM4, a custom inbound rule set that only allows TCP 80 (and/or 443) to VM4’s ASG will not match ICMP, so the traffic will fall through to a deny (either an explicit deny rule or the default DenyAllInBound after the allow rules are evaluated). Exam tip: don’t assume “same VNet means ping works”; NSGs can block ICMP, and ASG-based segmentation often intentionally blocks non-required protocols to reduce lateral movement risk.

Yes. Connecting to the web server on VM4 implies TCP port 80 (HTTP) is allowed from VM1 to VM4. With ASGs, this is typically implemented as an inbound NSG rule on VM4’s NIC/subnet that allows Source = ASG containing VM1 (for example, “AppServers” or “Mgmt”) and Destination = ASG containing VM4 (“WebServers”), Service = TCP/80, Action = Allow, with a priority higher than any deny rules. Because NSG processing requires both outbound from VM1 and inbound to VM4 to allow the flow, and outbound is usually permitted by default (AllowVNetOutBound) unless explicitly denied, the decisive control is the inbound allow to VM4 on TCP/80. Therefore VM1 can establish an HTTP connection even though ping (ICMP) is blocked.