NSG practice questions

Create a route table that sends RDP traffic to the management subnet.

Why wrong: Route tables do not implement port-based access control.

Deploy a private endpoint for each application server.

Why wrong: Private endpoints are for Azure PaaS services, not exposing VM RDP selectively.

Enable service endpoints on the application subnet.

Why wrong: Service endpoints are unrelated to RDP access control.

Azure Backup vault names

Why wrong: Vault names are configuration details, not a log type that can be queried.

Virtual network address spaces

Why wrong: Address spaces describe networking, but they are not log records for analysis.

Managed disk size settings

Why wrong: Disk size is a resource property, not a log stream for Log Analytics.

Add a subnet-to-subnet peering connection between the web and app subnets.

Why wrong: Peering provides connectivity between VNets, but it does not restrict traffic to only the desired tier or replace NSG rules.

Create a load balancer backend pool rule for TCP 8080.

Why wrong: Load balancer backend pools distribute traffic, but they are not a security control for limiting east-west access between application tiers.

Use a user-defined route that sends TCP 8080 traffic to the app tier.

Why wrong: Routes select next hops and do not provide an allow-list based on source and destination roles like an NSG rule does.

Packet capture

Why wrong: Packet capture records traffic for analysis, but it is not the fastest way to determine which NSG rule allows or denies a specific flow.

Connection troubleshoot

Why wrong: Connection troubleshoot is useful for end-to-end connectivity checks, but IP flow verify is the better tool when the specific goal is to see NSG rule impact.

Effective routes

Why wrong: Effective routes help inspect routing decisions, not NSG filtering. They do not tell you which security rule is blocking the TCP session.

Delete the deny rule so the allow rule can be evaluated.

Why wrong: Removing the deny rule is unnecessary if the allow rule is given a higher priority.

Change the destination from ASG-Api to the entire subnet address range.

Why wrong: The destination address form is not the issue; the deny rule still wins because of priority.

Change the protocol from TCP to Any so the rule matches more traffic.

Why wrong: The rule already matches TCP 443 traffic; protocol widening does not resolve a higher-priority deny.

Replace the source IP range with an application security group in the allow rule.

Why wrong: Source grouping helps manageability, but it does not fix a higher-priority deny rule.

Change the protocol from TCP to Any in the allow rule.

Why wrong: The rule already matches RDP traffic; protocol broadening does not change priority order.

Add a user-defined route to the subnet so RDP traffic bypasses the NSG.

Why wrong: Routing changes do not bypass NSG filtering, because NSGs still evaluate the packet.

Delete the Deny-All-Inbound rule.

Why wrong: Removing the deny rule would open more traffic than intended and is not the least disruptive fix. The real problem is priority order, not the existence of a deny rule.

Change Allow-HTTPS-Admin protocol from TCP to Any.

Why wrong: The traffic is already TCP 443, so changing the protocol to Any does not address the fact that the deny rule is evaluated first. Priority, not protocol, is the issue.

Move the allow rule to outbound traffic.

Why wrong: The connection attempt is inbound to the VM, so moving the rule to outbound would not allow the HTTPS session. The direction must match the traffic flow being filtered.

It guarantees that attacks cannot succeed.

Why wrong: This is wrong because logging helps with detection and analysis, not guaranteed prevention.

It replaces access control mechanisms.

Why wrong: This is wrong because logging does not replace prevention controls.

It forces all systems to use one VLAN.

Why wrong: This is wrong because centralized logging is unrelated to VLAN assignment.

Service tag

Why wrong: Service tags represent Microsoft-managed address ranges for Azure services, not your own backend VMs. They are not the right way to group private application servers.

Route table

Why wrong: A route table controls traffic forwarding, not NSG rule targeting. It cannot replace the need for a security grouping object in the rule.

Private endpoint

Why wrong: Private endpoints are for private access to supported PaaS services, not for grouping compute instances into a security target in NSG rules.

An inbound rule that uses the current web VM's private IP as the source and the current app VM's private IP as the destination.

Why wrong: IP-based rules work for one VM, but they do not scale cleanly when the tiers grow or change.

A route table that sends TCP 8443 traffic from the web subnet to the app subnet.

Why wrong: Route tables decide where traffic goes, but they do not allow or deny TCP ports between workloads.

An Azure Firewall application rule collection that permits all traffic between the two subnets.

Why wrong: Azure Firewall could filter traffic, but this option is broader than requested and does not describe the most direct NSG-based tier control.

A route table

Why wrong: A route table controls where traffic is sent, not whether it is allowed or denied.

A private DNS zone

Why wrong: A private DNS zone handles name resolution, not filtering.

Azure Advisor

Why wrong: Azure Advisor provides recommendations and does not enforce traffic rules.

The VM uses managed disks

Why wrong: Managed disks do not block inbound HTTPS access.

Azure Backup is not enabled

Why wrong: Backup configuration does not affect HTTPS connectivity.

The storage account uses the Cool tier

Why wrong: Storage access tier is unrelated to web traffic to the VM.

Packet capture

Why wrong: False because packet capture records traffic for later inspection, but it does not directly answer allow or deny decisions.

Effective routes

Why wrong: False because effective routes shows routing paths, not whether a specific security flow is allowed or denied.

Network topology

Why wrong: False because that is not the specific Network Watcher tool used for end-to-end connectivity testing.

Azure Policy

Why wrong: Azure Policy enforces standards and evaluates compliance but does not primarily provide optimization guidance.

Azure Backup

Why wrong: Azure Backup protects data and workloads rather than generating optimization recommendations.

Virtual network peering

Why wrong: VNet peering provides connectivity and is unrelated to broad optimization recommendations.

Azure Policy

Why wrong: Azure Policy evaluates compliance and enforces standards but is not the main recommendation service.

Azure Backup

Why wrong: Azure Backup provides protection and restore capabilities.

Virtual network peering

Why wrong: VNet peering provides connectivity and does not analyze resource optimization.

Use the individual private IP addresses of each backend VM as the source.

Why wrong: This works only while the VM IPs stay the same and does not simplify rule maintenance when addresses change.

Use the VirtualNetwork service tag for both source and destination.

Why wrong: This is too broad because it can allow traffic from many resources inside the virtual network, not just the frontend tier.

Create a route table entry that sends TCP 8443 traffic to the backend subnet.

Why wrong: Route tables control next-hop selection, not security filtering. They cannot allow or deny traffic on a port.

ReadOnly lock on the resource group

Why wrong: This would block writes such as resizing VMs and changing NSG rules, which are still required.

Management group lock on the subscription

Why wrong: This is broader than necessary and does not target the specific change-control boundary described.

Azure Policy deny effect on the resource group

Why wrong: Policy can block deployments, but a lock is the appropriate control for preventing deletion.

A service endpoint on the backend subnet.

Why wrong: Service endpoints are for securing access to supported PaaS services, not for grouping VMs in NSG rules.

A route table with a next hop of Virtual network gateway.

Why wrong: Route tables control forwarding, but they do not simplify security rules for changing VM IP addresses.

A private endpoint for each backend VM.

Why wrong: Private endpoints are used for private access to supported services, not for direct VM-to-VM tier grouping.

Change the allow rule protocol from TCP to Any.

Why wrong: The failure is caused by rule priority, not protocol selection. Changing the protocol alone will not override an earlier deny rule.

Move the VM to a different subnet so the rule can apply.

Why wrong: Subnet placement does not change NSG evaluation. The same priority behavior applies in any subnet where the NSG is attached.

Add a route table entry for TCP 8443 to bypass the NSG.

Why wrong: Route tables control next-hop selection, not packet filtering. They cannot override an NSG deny decision.