Configuring security baselines for workloads in an Azure Landing Zone (ALZ) relies on policy-driven governance. Rather than manually configuring individual resources, you enforce security controls at the Management Group level using Azure Policy, Microsoft Defender for Cloud, and Infrastructure as Code (IaC) modules.

1. Implement Policy-Driven Guardrails

In an Enterprise-Scale Landing Zone, security baselines inherit automatically based on where a subscription sits in the Management Group hierarchy (Corp, Online, or Platform).

Key Policy Definitions to Assign

Assign built-in policy initiatives (like the Microsoft cloud security benchmark (MCSB)) to the Intermediate Root Management Group:

• Enforce Encryption in Transit: Block storage accounts or web apps that allow HTTP or TLS versions below 1.2 (Deny).
• Disable Public Access: Prevent PaaS resources (SQL Server, Key Vault, Storage) from exposing public IP endpoints (Deny or Modify).
• Auto-Provision Diagnostics: Stream all resource activity, audit, and diagnostic logs to the central Log Analytics workspace in the Management subscription using DeployIfNotExists (DINE) policies.

2. Deploy Automated Security via IaC (Bicep / Terraform)

When provisioning workload landing zones, use ALZ Bicep or Terraform modules to apply security baselines dynamically upon subscription creation.

Example: Bicep Policy Assignment for Security Baseline

Code snippet

targetScope = 'managementGroup'
param managementGroupId string = 'alz-landing-zones'
// Assign Microsoft Cloud Security Benchmark Initiative
resource mcsbAssignment 'Microsoft.Authorization/policyAssignments@2022-06-01' = {
  name: 'mcsb-baseline-assignment'
  scope: managementGroup(managementGroupId)
  properties: {
    displayName: 'Enforce Microsoft Cloud Security Benchmark'
    description: 'Applies baseline security controls across all landing zone subscriptions.'
    policyDefinitionId: '/providers/Microsoft.Authorization/policySetDefinitions/1f3afdf9-d0c9-4c3d-847f-89da613e70a8'
    enforcementMode: 'Default'
  }
}

3. Configure Microsoft Defender for Cloud at Scale

To ensure all workload subscriptions automatically inherit Defender plans:

1. Enable Defender Plan Auto-Provisioning: Configure continuous policy assignments at the Management Group level so any new subscription placed in Corp or Online automatically enables plans for Servers, Containers, Databases, and Storage.
2. Auto-Deploy Endpoint Protection: Enable auto-provisioning for Microsoft Defender for Endpoint extensions on all Linux and Windows VMs.
3. Agentless Vulnerability Scanning: Activate agentless scanning for VMs and container registries across all subscriptions.

4. Operational Checklist for Workload Onboarding

1.Subscription Placement:Placement.

Move the workload subscription under the appropriate Management Group archetype (Corp for internal hybrid workloads, Online for internet-facing apps).

Verification: Verify that inherited policy assignments appear under Subscription > Policies.

2.Enforce Perimeter Isolation:Network.

Provision Private Endpoints for all PaaS services and attach a Network Security Group (NSG) to every subnet. Route outbound traffic through the Central Azure Firewall.

Verification: Ensure public network access is disabled on the resource overview blade in the portal.

3.Configure Managed Identities:Identity.

Configure System-Assigned or User-Assigned Managed Identities for app-to-service authentication, eliminating hardcoded keys or credentials.

Verification: Check Entra ID enterprise applications to confirm Managed Identity registration.

Securing cloud workloads (IaaS virtual machines, PaaS services, container clusters, and serverless functions) requires enforcing defense-in-depth across identity, network perimeter, data protection, and continuous threat monitoring.

Core Security Configurations by Layer

1. Identity & Access Management (IAM)

• Least Privilege Access: Assign granular Role-Based Access Control (RBAC) roles at the resource group or specific resource scope. Avoid global Owner or Contributor assignments.
• Workload Identities: Use managed identities (Azure Managed Identities, AWS IAM Roles for Service Accounts) for app-to-service authentication instead of embedding service principal credentials or hardcoded API keys.
• Privileged Identity Management (PIM): Enforce Just-In-Time (JIT) access and multi-factor authentication (MFA) for administrative operations.

2. Network & Perimeter Controls

• Private Connectivity: Disable public IP addresses on databases, key vaults, and internal backend services using Private Endpoints / Private Link.
• Traffic Inspection: Route outbound internet-bound traffic through a central firewall (e.g., Azure Firewall, AWS Network Firewall) to enforce FQDN/URL filtering.
• Micro-segmentation: Enforce stateful packet filtering using Network Security Groups (NSGs) or Kubernetes NetworkPolicies to restrict East-West traffic between subnets and pods.

3. Data Protection & Secrets Management

• Encryption at Rest: Enforce Customer-Managed Keys (CMK) via key vaults for storage accounts, database disks, and backups.
• Encryption in Transit: Mandate TLS 1.2 or TLS 1.3 across all endpoints and disable plain HTTP/unencrypted database connections.
• Centralized Secrets Storage: Store connection strings, certificates, and tokens in dedicated secret vaults (e.g., Azure Key Vault, AWS Secrets Manager) with auto-rotation policies.

4. Vulnerability & Threat Protection

• Continuous Scanning: Enable Cloud Workload Protection Platforms (CWPP)—such as Microsoft Defender for Cloud or Wiz—for real-time threat detection and vulnerability scanning.
• Container Image Security: Integrate image scanning into CI/CD pipelines and container registries to block images with known CVEs from being deployed.
• Automated Audit Logging: Stream control-plane Activity Logs and resource diagnostic logs to a central Log Analytics workspace or SIEM (e.g., Microsoft Sentinel).

Workload Baseline Configurations

Here are top Azure Network Security Policy interview questions spanning core components—including Network Security Groups (NSGs), Application Security Groups (ASGs), Azure Firewall, and Web Application Firewall (WAF)—structured by role level with key architectural takeaways.

1. Foundational & Core Security Policy Questions

Q1: What is the difference between an NSG, an ASG, and an Azure Firewall?

• Network Security Group (NSG): A basic Layer 3/4 stateful packet-filtering firewall applied at the Subnet or Network Interface (NIC) level. It evaluates rules based on source/destination IP, port, and protocol.
• Application Security Group (ASG): A logical grouping of VMs based on workload type or application role (e.g., ASG-Web, ASG-DB). ASGs are used within NSGs as source/destination abstractions so you don’t need to maintain individual static IP addresses in security rules.
• Azure Firewall: A fully managed, stateful, cloud-native Layer 3–7 firewall service. It supports threat intelligence, FQDN/URL filtering, IDPS (Intrusion Detection and Prevention System), TLS inspection, and central routing across multiple VNets.

Q2: How are NSG rules evaluated when both Subnet-level and NIC-level NSGs are applied?

• Inbound Traffic: The Subnet NSG evaluates traffic first. If allowed, the packet moves to the NIC NSG. Traffic is blocked if either NSG denies it.
• Outbound Traffic: The NIC NSG evaluates traffic first. If allowed, the packet moves to the Subnet NSG.
• Key Takeaway: Both NSGs must explicitly allow the traffic for communication to succeed.

Q3: Explain NSG Rule Priority and Default Rules.

• Priority Range: Rules are processed in order of priority from 100 to 4096 (lower numbers take higher precedence).
• Evaluation: Once a packet matches a rule’s criteria, rule processing stops (first match wins).
• Default Rules (Priority 65000+): Cannot be deleted, but can be overridden by adding higher-priority rules (e.g., < 65000):
  • AllowVNetInBound (65000)
  • AllowAzureLoadBalancerInBound (65001)
  • DenyAllInBound (65500)

2. Advanced Architecture & Deep-Dives

Q4: How does Azure Firewall Manager manage security policies across enterprise landing zones?

• Answer: Azure Firewall Manager centralizes security policy and route management across multiple Azure Firewalls and Virtual WAN Hubs.
• Firewall Policies: Hierarchical objects containing Rule Collection Groups (DNAT, Network, and Application rule collections).
• Inheritance Model: Allows a central SecOps team to enforce a Parent Policy (e.g., global threat-intel blocking and core logging) while allowing application teams to append region-specific or app-specific rules via Child Policies.

Q5: Compare Azure Firewall vs. Web Application Firewall (WAF) on Azure Front Door / Application Gateway.

• Azure Firewall: Broad L3–L7 network/application firewall designed for non-HTTP/HTTPS traffic, outbound egress filtering, and cross-subnet/cross-VNet inspection.
• Azure WAF: Specialized L7 reverse-proxy firewall designed exclusively for HTTP/HTTPS web applications. Protects against OWASP Top 10 risks (SQLi, XSS), bot attacks, and rate limiting using managed rule sets (CRS).

Q6: How do NSG Service Tags and Application Security Groups simplify rule management?

• Service Tags: System-managed aliases representing IP address prefixes for specific Azure services (e.g., Storage, Sql, AzureKeyVault). They automatically update when Microsoft adjusts backend IP ranges, removing the need to manage dynamic public IPs manually.
• ASGs: Decouple security configurations from network topology. Rather than writing rules targeting explicit static IP addresses (10.0.1.4), you write rules using ASGs (Allow ASG-Web to ASG-DB on port 1433).

3. Scenario-Based Architectural Questions

Q7: Scenario: Traffic between two subnets in the same VNet is failing, but the NSG allows port 443. How do you troubleshoot?

1. Rule Evaluation Check: Check for a higher-priority NSG rule (e.g., Priority 200 Deny vs. Priority 300 Allow) overriding the rule.
2. Effective Security Rules: Use Azure Portal or CLI (az network nic show-effective-security-rules) to inspect the combined Subnet + NIC rule evaluation on the target VM.
3. IP Flow Verify: Run Network Watcher IP Flow Verify with the specific 5-tuple payload to see which precise NSG and rule name is dropping packets.
4. Local OS Firewall: Check if the internal OS firewall (Windows Firewall / iptables / ufw) on the VM itself is blocking inbound requests on port 443.

Q8: How do you enforce asymmetric routing prevention when implementing Azure Firewall in a Hub-and-Spoke topology?

• Cause: Asymmetric routing occurs when request traffic reaches a spoke via an external route (e.g., direct public IP or Gateway), but return traffic is redirected to Azure Firewall via a 0.0.0.0/0 User Defined Route (UDR), causing the stateful firewall to drop the connection.
• Fix: Enforce SNAT (Source Network Address Translation) on Azure Firewall for internal ranges, or adjust User Defined Routes (UDRs) and Gateway Subnet routing tables so both inbound and outbound legs traverse the same firewall instance.

4. Hands-On Configuration Example: Creating an NSG with Bicep

Below is an enterprise Bicep template demonstrating an NSG configuration with rule priorities, Service Tags, and Subnet association:

param location string = resourceGroup().location
// Define Application Security Group
resource webAsg 'Microsoft.Network/applicationSecurityGroups@2023-09-01' = {
  name: 'asg-web-prod'
  location: location
}
// Define Network Security Group with Custom Rules
resource webNsg 'Microsoft.Network/networkSecurityGroups@2023-09-01' = {
  name: 'nsg-web-prod'
  location: location
  properties: {
    securityRules: [
      {
        name: 'Allow-HTTP-Inbound-ASG'
        properties: {
          priority: 100
          direction: 'Inbound'
          access: 'Allow'
          protocol: 'Tcp'
          sourceAddressPrefix: 'Internet'
          sourcePortRange: '*'
          destinationApplicationSecurityGroups: [
            {
              id: webAsg.id
            }
          ]
          destinationPortRange: '443'
        }
      }
      {
        name: 'Deny-All-Inbound-Custom'
        properties: {
          priority: 4000
          direction: 'Inbound'
          access: 'Deny'
          protocol: '*'
          sourceAddressPrefix: '*'
          sourcePortRange: '*'
          destinationAddressPrefix: '*'
          destinationPortRange: '*'
        }
      }
    ]
  }
}

Azure network security configurations rely on a defense-in-depth model operating across multiple layers (L3/L4 transport filtering, L7 application inspection, and platform-level perimeter defense).

Below is an overview of the primary Azure network security constructs, how they differ, and standard deployment patterns.

1. Network Access Control Controls

Network Security Groups (NSGs)

• Scope:L3/L4 stateful packet inspection. Attached to Subnets or Network Interfaces (NICs).
• Rule Syntax:Evaluates 5-tuple hash (Source IP, Source Port, Destination IP, Destination Port, Protocol) based on rule Priority (100–4096). Lower numbers take precedence.
• Service Tags: Simplifies rule management by representing groups of IP address prefixes (e.g., VirtualNetwork, AzureCloud, Storage).
• Application Security Groups (ASGs): Allows grouping virtual machines into logical application tiers (e.g., Web-Tier, DB-Tier) to write rules based on workload identity rather than explicit static IPs.

Azure Firewall

• Scope:Fully managed, cloud-native L4/L7 stateful firewall deployed in a dedicated AzureFirewallSubnet.
• Rule Engine:
  • DNAT Rules: Inbound port forwarding/translation.
  • Network Rules: L3/L4 filtering based on IP addresses, ports, and protocols.
  • Application Rules: Fully Qualified Domain Name (FQDN) filtering (e.g., allow *.github.com via HTTP/HTTPS).
• SKU Tiers:
  • Basic:SMB workloads (< 250 Mbps).
  • Standard:L3–L7 filtering, threat intelligence-based filtering, DNS Proxy.
  • Premium:Signature-based Intrusion Detection & Prevention System (IDPS), TLS Inspection, and URL filtering.

2. Web & Perimeter Protection

3. Secure PaaS & Private Connectivity

To prevent Azure PaaS services (e.g., Storage Accounts, SQL Databases) from exposing public IP addresses:

• Private Endpoints (Azure Private Link): Assigns a private IP address from your Virtual Network to an individual Azure PaaS instance. Eliminates public internet access and prevents data exfiltration risks.
• Service Endpoints: Secures direct connection to PaaS endpoints by extending your VNet private address space over the Azure backbone, while keeping the public IP destination of the PaaS service.

4. Routing & Traffic Inspection Enforcers

By default, system routes in Azure allow VNet-to-VNet and outbound Internet communications directly. To force traffic through a centralized inspection point (like Azure Firewall or a Network Virtual Appliance):

1. User Defined Routes (UDRs): Custom route tables attached to subnets.
2. Next Hop Overrides: Route 0.0.0.0/0 (Internet) or internal VNet CIDRs to the private IP address of the Azure Firewall as the VirtualAppliance next hop.

Recommended Architecture Pattern: Hub-and-Spoke Topology

                  ┌─────────────────────────────────────────┐
                  │              Public Internet            │
                  └────────────────────┬────────────────────┘
                                       │
                               ┌───────▼───────┐
                               │  Azure WAF /  │ (Public Edge Inbound)
                               │  Front Door   │
                               └───────┬───────┘
                                       │
    ┌──────────────────────────────────▼──────────────────────────────────┐
    │ HUB VNet                                                            │
    │                                                                     │
    │  ┌───────────────────────────────────────────────────────────────┐  │
    │  │ AzureFirewallSubnet                                           │  │
    │  │ ┌───────────────────────────────────────────────────────────┐ │  │
    │  │ │                      Azure Firewall                       │ │  │
    │  │ └───────────────────────────────────────────────────────────┘ │  │
    │  └───────────────────────────────▲───────────────────────────────┘  │
    └──────────────────────────────────┼──────────────────────────────────┘
                                       │ (VNet Peering + UDR)
            ┌──────────────────────────┴──────────────────────────┐
            │                                                     │
    ┌───────▼─────────────────────────────┐       ┌───────────────▼─────────────────────┐
    │ SPOKE 1: Web App VNet               │       │ SPOKE 2: Backend VNet               │
    │                                     │       │                                     │
    │ ┌─────────────────────────────────┐ │       │ ┌─────────────────────────────────┐ │
    │ │ Subnet: Web Tier                │ │       │ │ Subnet: Database Tier           │ │
    │ │  • NSG: Allow inbound 443 from  │ │       │ │  • NSG: Allow 1433 from Web     │ │
    │ │    Firewall Subnet              │ │       │ │    subnet only                  │ │
    │ │  • UDR: Default route to FW     │ │       │ │  • Private Endpoint (SQL DB)    │ │
    │ └─────────────────────────────────┘ │       │ └─────────────────────────────────┘ │
    └─────────────────────────────────────┘       └─────────────────────────────────────┘

1. Centralized Inspection: All spoke traffic routes through the central Hub VNet where the Azure Firewall resides.
2. Micro-Segmentation: Spoke subnets use localized NSGs to limit lateral movement between subnets (e.g., blocking direct access to the database layer from non-web tiers).
3. Private Access: Backend resources communicate externally or with PaaS using Private Endpoints.

To filter and convert specific Microsoft Defender for Cloud (MDC) alerts into tailored Microsoft Sentinel Incidents, you write custom Kusto Query Language (KQL) rules using the SecurityAlert table.

1. Understand How MDC Alerts Are Stored

When Defender for Cloud streams alerts into Sentinel, they populate the SecurityAlert table. The key fields used for filtering are:

• ProviderName: For MDC alerts, this is typically ProtectionCenter, MDFC, or specific engines like Azure Security Center.
• AlertName: The title of the alert (e.g., “Unfamiliar ASP.NET app execution”, “Potential SQL Injection”).
• AlertSeverity: Severity level (High, Medium, Low, Informational).
• Entities: JSON array containing detailed entity metadata (IPs, Hosts, Accounts, Azure Resources).
• ExtendedProperties: JSON dictionary containing alert-specific context (e.g., process command line, query text).

2. Crafting Custom KQL Alert Queries

Example 1: High-Severity Storage & Database Alerts

Filter only for High severity MDC alerts targeting Storage Accounts or SQL Databases:

Code snippet

SecurityAlert
| where TimeGenerated >= ago(1h)
| where ProviderName in ("ProtectionCenter", "MDFC", "Azure Security Center")
| where AlertSeverity == "High"
// Filter by specific alert types or resource categories
| where AlertName has_any ("SQL", "Storage", "Blob", "Key Vault")
| extend CompromisedResource = Properties
| project TimeGenerated, SystemAlertId, AlertName, AlertSeverity, Description, CompromisedResource, Entities

Example 2: Suspicious Process Execution on VMs (Excluding Approved Dev Machines)

Filter for server alerts related to suspicious processes while suppressing noise from non-production resource groups:

Code snippet

SecurityAlert
| where TimeGenerated >= ago(1h)
| where ProviderName in ("ProtectionCenter", "MDFC")
| where AlertName has_any ("Suspicious Process", "Malware", "Execution")
// Parse entities to extract the targeted computer name or Azure resource
| extend ExtractedHost = tostring(parse_json(Entities)[0].HostName)
| extend ResourceGroup = tostring(parse_json(ExtendedProperties)["Resource Group"])
// Suppress noise from non-prod/test resource groups
| where ResourceGroup !has "rg-dev-" and ResourceGroup !has "rg-test-"
| project TimeGenerated, SystemAlertId, AlertName, AlertSeverity, ExtractedHost, ResourceGroup, Entities

3. Step-by-Step: Creating the Analytics Rule in Sentinel

1.Open Analytics Rules:Sentinel Navigation.

1. In the Azure Portal, open Microsoft Sentinel.
2. Under Configuration on the left menu, select Analytics.
3. Click + Create at the top and select NRT query rule (for real-time evaluation) or Scheduled query rule.

2.Set General Properties:Rule Details.

1. Name: Give your rule a descriptive title (e.g., MDC: High-Severity SQL Injection Attempts).
2. Description: State the purpose of the custom filter.
3. Tactics and Techniques: Map to MITRE ATT&CK categories (e.g., Initial Access, Execution).
4. Severity: Set the severity level for the generated incident.

3.Set Query, Mapping, and Scheduling:Rule Logic.

1. Set rule logic: Paste your refined KQL query into the Set rule logic field.
2. Entity Mapping: Map query fields to Sentinel entities so incident analysts see structured context:
   • Host$\rightarrow$ExtractedHost
   • IP$\rightarrow$IPAddress
   • Azure Resource$\rightarrow$ResourceGroup
3. Query scheduling: Set Run query every (e.g., 1 hour) and Lookup data from the last (e.g., 1 hour).

4.Configure Grouping and Alert Suppression:Incident Settings.

1. Incident creation: Ensure Create incidents from alerts triggered by this analytics rule is Enabled.
2. Alert grouping: Choose whether to group multiple matching alerts into a single incident (e.g., group alerts triggered within 5 hours for the same resource).

5.Validate and Save:Review.

1. Click Review + create and select Save.
2. The custom rule will now periodically run against incoming Defender for Cloud alerts and automatically create high-fidelity Sentinel incidents.

Best Practice Tip: Suppress Duplicate Incidents

Because the native Microsoft Defender for Cloud data connector can create default Sentinel incidents, turn off the default incident creation setting on the connector page OR disable specific rules if you are replacing them with custom KQL rules. This prevents duplicate incidents from cluttering your SOC queue.