NSG

Learn Network Security Groups for subnet and NIC-level traffic filtering, least-privilege network access, and Azure troubleshooting.

Last reviewed: June 2026

·Microsoft AzureAzure PortalAzure CLIARM and Bicep
✅
Quick Understanding: NSG matters in Azure because it affects landing-zone decisions, production operations, security ownership, and how teams deploy or troubleshoot cloud workloads at enterprise scale.

🔍 What Is It?

A Network Security Group filters inbound and outbound traffic using prioritized allow or deny rules. NSGs are often attached to subnets or network interfaces to enforce network-level least privilege.

🎯 Why Do We Need It?

NSGs matter because many Azure incidents involve overexposed services, blocked dependencies, or unclear traffic paths. Engineers are expected to reason about NSG rules during architecture and support conversations.

Why teams ask about this in interviews:

  • →Azure engineers are expected to explain the service boundary, not just the definition
  • →Interviewers want to hear how the service behaves during deployment, failure, cost review, and access control
  • →Senior candidates must connect the topic to platform governance, production support, and architecture trade-offs

🏗️ What Happens in Real Projects?

In production, NSGs are used to restrict application tiers, allow only approved admin access paths, protect data services, and stop lateral movement between subnets that should not freely communicate.

⚙️ How It Works

Traffic is evaluated against NSG rules in priority order. Engineers usually combine NSGs with subnet design, load balancers, private endpoints, or firewall routing instead of treating them as a complete security model by themselves.

💻 Example

Application subnet NSG example — A practical Azure-oriented example for nsg.

text
Allow 443 from Application Gateway subnet
Allow 22 only from Bastion / admin subnet
Allow outbound to database private endpoint
Deny unexpected inbound from public internet

🤔 Common Confusions

❓ Is NSG only a portal concept?

No. NSG must be understood through automation, RBAC, operational ownership, and how it behaves in live Azure environments rather than only through the portal UI.

❓ What makes a weak answer for NSG?

A weak answer defines NSG without explaining security boundaries, production trade-offs, observability, failure handling, and how teams actually use it in subscriptions and environments.

❓ How should senior engineers discuss NSG?

Senior engineers should connect NSG to enterprise standards, delivery workflows, troubleshooting evidence, and the Azure services or controls it influences around it.

🚨 Common Production Issues

Rules are too broad, leaving internal or public attack surfaces larger than intended.

Teams focus on inbound rules only and miss egress controls or downstream dependency behavior.

Troubleshooting gets messy because NSG intent was never documented and many overlapping rules exist.

✅ Best Practices

Use NSGs to enforce least-privilege network paths, not broad convenience access.

Review both ingress and egress behavior for production services.

Keep rule ownership and purpose visible in naming and documentation.

Validate NSG behavior during deployment and incident simulations.

🏛️ Architect's Note

Senior Architect's Perspective

In Azure, NSG should be governed as part of the wider platform model. The architect-level conversation is about ownership, blast radius, policy, cost, security, and how this decision stays repeatable across environments.

💬 Frequently Asked Questions

Interview: how do you explain NSG in a real Azure project?

Explain NSG through the workload it supports, the Azure boundary it lives in, the operational controls around it, and what can go wrong in production if it is configured poorly.

Interview: what production concern usually comes up with NSG?

The common production concern is misalignment between service configuration and the wider Azure platform design: identity, network access, deployment automation, monitoring, or cost ownership.

🎯 Key Takeaways

1NSG is not just a definition question. It is a production-behavior question.
2Strong Azure answers connect the service to identity, network, automation, and monitoring.
3Enterprise Azure teams expect repeatable configuration through IaC and policy.
4Production readiness means thinking about failure, cost, and ownership before release.

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these Azure references to verify the concept in official docs and continue into the most relevant SplashRide pages.