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.

Streaming Microsoft Defender for Cloud (MDC) alerts to Microsoft Sentinel or a third-party SIEM (like Splunk, QRadar, or Elastic) involves two distinct approaches.

Option 1: Stream to Microsoft Sentinel (Native Integration)

Using the built-in Microsoft Sentinel Data Connector allows automatic alert streaming and bi-directional status synchronization.

Prerequisites

• Microsoft Sentinel Workspace deployed.
• Permissions:Contributor or Security Admin role on the relevant Azure Subscriptions, and Read/Write access to the Sentinel Workspace.

1.Install Solution from Content Hub:Prerequisite.

1. Go to Microsoft Sentinel in the Azure or Defender Portal.
2. Under Content Management, select Content Hub.
3. Search for Microsoft Defender for Cloud.
4. Select the solution and click Install.

2.Configure the Data Connector:Enable Subscription Stream.

1. In Sentinel, navigate to Configuration > Data connectors.
2. Search for and select Microsoft Defender for Cloud.
3. Click Open connector page.
4. In the configuration list, locate your target Azure Subscriptions.
5. Toggle the status to Connected for each subscription.

3.Enable Bi-Directional Synchronization:Recommended.

1. On the connector page, locate the Bi-directional sync column.
2. Set the status to Enabled.

Result: Closing or updating an incident status in Microsoft Sentinel automatically updates the corresponding alert status inside Defender for Cloud, and vice versa.

4.Enable Incident Generation:Automatic Alert Creation.

1. Under the Create incidents section on the connector page, select Enabled.
2. This turns on the default analytics rule that automatically converts incoming MDC security alerts into actionable Sentinel incidents.

Option 2: Stream to Third-Party SIEMs (Splunk, QRadar, Elastic, Datadog)

To export Defender for Cloud alerts to non-Microsoft SIEMs, stream alerts using Azure Event Hubs.

┌───────────────────────────┐      ┌─────────────────────────┐      ┌─────────────────────┐
│  Defender for Cloud       │─────►│  Continuous Export      │─────►│  Azure Event Hubs   │
│  (Alerts & Security Data) │      │  (System Feature)       │      │  (Streaming Pipeline)│
└───────────────────────────┘      └─────────────────────────┘      └──────────┬──────────┘
                                                                               │
                                                                               ▼
                                                                    ┌─────────────────────┐
                                                                    │ Third-Party SIEM    │
                                                                    │ (Splunk/QRadar/etc) │
                                                                    └─────────────────────┘

1.Create an Azure Event Hub Namespace:

1. Search for Event Hubs in the Azure Portal.
2. Create an Event Hubs Namespace (standard tier or higher).
3. Under the namespace, create an Event Hub instance (e.g., named mdc-alerts).

2.Configure Continuous Export in Defender for Cloud:

1. In Microsoft Defender for Cloud, select Environment settings under Management.
2. Select your top-level Management Group or specific Azure Subscription.
3. Select Continuous export from the menu.
4. Choose the Event Hub tab.
5. Check Security alerts (and optionally Recommendations or Secure score).
6. Select your Event Hub Namespace, Event Hub name, and select an Event Hub policy with Send permissions.
7. Click Save at the top.

3.Configure Your SIEM Integration:

1. In your target SIEM (e.g., Splunk Add-on for Microsoft Cloud Services or QRadar Azure DSM), configure the input plugin.
2. Provide the Event Hub Connection String (from Event Hubs Namespace > Shared access policies > RootManageSharedAccessKey).
3. Verify that JSON-formatted security alert payloads start streaming into your SIEM indexer.

Verification & Testing

To confirm that the stream is operational:

• In Sentinel: Navigate to Logs in Sentinel and run the following KQL query to see ingested alerts:
  Code snippetSecurityAlert | where ProviderName == "ProtectionCenter" or ProviderName == "MDFC" | order by TimeGenerated desc
• In Event Hubs: Check the Throughput graph under your Event Hub Namespace to verify outgoing message activity.

Setting up Microsoft Defender for Cloud requires configuring global subscription settings, enabling paid workload protection plans, configuring agent provisioning, and establishing continuous security governance.

Prerequisites

Before starting, ensure your user account has one of the following Role-Based Access Control (RBAC) permissions:

• Security Admin or Owner (Required to turn on Defender plans and change security policies).
• Contributor (Can edit resource configurations and view security states).

1.Enable Foundational CSPM:Prerequisite Step.

1. Log in to the Azure Portal.
2. Search for and select Microsoft Defender for Cloud.
3. Navigate to Getting Started on the left menu.
4. Select the target Azure Subscription and click Upgrade or Enable on all subscriptions.

Note: Enabling Defender for Cloud automatically turns on Foundational CSPM (Cloud Security Posture Management) across your subscription at no cost.

2.Configure Environment Settings and Enable Defender Plans:Paid Workload Plans.

1. On the left navigation pane under Management, select Environment settings.
2. Expand your management group and click on your target Subscription.
3. Under the Defender plans blade, toggle On the specific workload protection plans required for your environment (e.g., Servers, Containers, Databases, Storage, Key Vault).
4. Click Save at the top left.

3.Configure Auto-Provisioning and Monitoring Agents:Agent Deployment.

1. While inside the subscription’s Environment settings, select Settings & Monitoring from the left sub-menu.
2. Turn On relevant extensions based on your active plans:
   • Log Analytics Agent / Azure Monitor Agent (AMA): Auto-provisions logs and vulnerability monitoring agents to VMs.
   • Agentless scanning for VMs: Enables agentless disk scanning for malware and vulnerabilities without installing software.
   • Defender for Containers components: Automatically installs the Defender profile/DaemonSet on Azure Kubernetes Service (AKS) clusters.
3. Click Continue and Save.

4.Set Up Email Notifications and Alerting:Operational Readiness.

1. In the subscription’s Environment settings, select Email notifications.
2. Add the email addresses of your Security Operations Center (SOC) team or administrators.
3. Under Notification settings, set the minimum severity level for email alerts (recommended: High or Medium).
4. Check Also send email notifications to subscription owners if executive alerting is required.
5. Click Save.

5.Assign Security Baselines & Compliance Standards:Governance & Compliance.

1. On the main Defender for Cloud menu, click Regulatory compliance.
2. Click Manage compliance policies.
3. Select your subscription and click Add more standards (e.g., PCI-DSS, ISO 27001, NIST SP 800-53).
4. Assign the standard to automatically evaluate your Azure environment against these benchmarks.

Verification & Post-Setup Checklist

To verify that your configuration was successful:

• Verify Secure Score Calculation: Go to Overview in Defender for Cloud. Within 24 hours, your Secure Score will populate along with populated recommendations under the Recommendations blade.
• Verify Agent Deployment: For VM workloads, navigate to Inventory, select a Virtual Machine, and confirm that the Azure Monitor Agent or Defender Endpoint extension shows as Succeeded.
• Test Security Alerts: Use the Azure CLI or PowerShell to simulate a sample alert (Microsoft provides standard test commands) and verify that an alert appears under Security alerts.

Microsoft Defender for Cloud is Microsoft’s Cloud-Native Application Protection Platform (CNAPP).It combines security posture management, developer security, and real-time threat protection across Azure, hybrid environments, and multicloud platforms (AWS, GCP).

Core Pillars of Defender for Cloud

                            ┌─────────────────────────────────────────┐
                            │      Microsoft Defender for Cloud       │
                            └────────────────────┬────────────────────┘
                                                 │
      ┌────────────────────────┬─────────────────┴───────────────┬────────────────────────┐
      ▼                        ▼                                 ▼                        ▼
┌───────────┐         ┌─────────────────┐             ┌─────────────────────┐   ┌─────────────────┐
│  DevOps   │         │ Security Posture│             │   Workload Plans    │   │ Data & AI Risk  │
│ Security  │         │   Management    │             │ (Threat Protection) │   │   Protection    │
│ (DevSecOps)         │   (CSPM / CIEM) │             │       (CWPP)        │   │    (DSPM / AI)  │
└───────────┘         └─────────────────┘             └─────────────────────┘   └─────────────────┘

1. Cloud Security Posture Management (CSPM)

Continuously assesses configurations against security baselines and compliance standards.

• Secure Score: Provides a single metric reflecting overall security posture with prioritized remediation steps.
• Foundational CSPM (Free):Includes basic risk assessment, resource inventory, and compliance tracking.
• Defender CSPM (Paid):Unlocks agentless scanning, attack path analysis, Cloud Infrastructure Entitlement Management (CIEM) to fix over-permissioned identities, and custom security frameworks.

2. Cloud Workload Protection Plans (CWPP)

Delivers specialized, real-time threat protection and vulnerability detection across individual cloud services:

• Defender for Servers:Integrates with Microsoft Defender for Endpoint for agentless/agent-based malware scanning, vulnerability assessments, and Just-In-Time (JIT) VM access.
• Defender for Containers:Protects AKS, Amazon EKS, and GCP clusters, providing runtime threat detection and container image vulnerability scanning.
• Defender for Databases:Scans SQL, Cosmos DB, and open-source relational databases for anomalous access, SQL injection, and vulnerabilities.
• Defender for Storage & Key Vault:Scans uploads for malware, detects unauthorized SAS token usage, and alerts on unusual secret access.
• Defender for APIs & App Service: Identifies exposed endpoints, OWASP Top 10 vulnerabilities, and runtime exploits targeting web applications.

3. DevOps Security (DevSecOps)

Protects code and infrastructure-as-code (IaC) templates before deployment.

• Integrates directly into GitHub Actions, Azure DevOps, and GitLab pipelines.
• Scans for hardcoded secrets, code vulnerabilities, and misconfigurations in IaC scripts (Bicep, Terraform, ARM) to fix security issues at the source.

4. Data & AI Security

• Data Security Posture Management (DSPM): Discovers sensitive data stores across your cloud estate and maps access permissions.
• AI Security:Provides visibility into generative AI workloads (LLM deployments, OpenAI endpoints), identifying prompt injection risks, data leaks, and component supply-chain vulnerabilities.

Key Capabilities & Workflows

Licensing Options

• Free Tier:Automatically active on all Azure subscriptions. Includes Foundational CSPM, Secure Score, basic inventory, and core security recommendations.
• Defender Plans (Paid per-resource): Enabled on a per-plan basis (e.g., Servers, Storage, Containers) charged per resource/hour or per gigabyte scanned.

Enterprise Azure Policy as Code (EPAC) is an open-source framework managed by Microsoft and the community to design, deploy, and manage Azure Policy resources at enterprise scale.Built on PowerShell and Infrastructure-as-Code (IaC) principles, EPAC turns cloud governance into a version-controlled, automated, and repeatable software engineering pipeline.

Core Capabilities & Architecture

EPAC brings standard DevOps practices to Azure Policy lifecycle management:

• Desired State Configuration (Declarative):EPAC operates as a true desired-state engine.It maintains ownership over policies defined within a specified scope (deploymentRootScope), creating, updating, or deleting policies based on what is in source control.
• Simplified Schema (JSON + CSV):Beyond raw Azure JSON definitions, EPAC allows defining complex policy assignments and bulk parameters using CSV files, lowering the entry barrier for non-developer operational teams.
• Azure Landing Zones Integration:EPAC natively aligns with Microsoft’s Cloud Adoption Framework (CAF) and Azure Landing Zones, providing pre-built archetypes and reference policies.
• Multi-Tenant & Multi-Scope Support: EPAC manages multi-subscription and multi-tenant architectures from a single operational repository using environment mapping.

The Deployment Lifecycle (3-Stage Plan & Apply)

Rather than applying changes directly, EPAC breaks operations into a predictable 3-step workflow:

                     ┌───────────────────────────┐
                     │ 1. Build-DeploymentPlans  │
                     └─────────────┬─────────────┘
                                   │
                           Outputs Plan Files
                         (policy-plan, roles-plan)
                                   │
              ┌────────────────────┴────────────────────┐
              ▼                                         ▼
┌───────────────────────────┐             ┌───────────────────────────┐
│  2. Deploy-PolicyPlan     │             │    3. Deploy-RolesPlan    │
├───────────────────────────┤             ├───────────────────────────┤
│ Deploys Policy Definitions│             │ Assigns Managed Identity  │
│ Sets, Assignments,        │             │ Roles for Remediation     │
│ & Exemptions              │             │ (DeployIfNotExists/Modify)│
└───────────────────────────┘             └───────────────────────────┘

1. Build-DeploymentPlans (Planning): Analyzes the current target state in Azure against your local repository files to calculate diffs. Generates explicit plan files without altering Azure resources.
2. Deploy-PolicyPlan (Policy Deployment): Executes the policy plan by creating, updating, or removing Policy Definitions, Initiatives (Policy Sets), Assignments, and Exemptions.
3. Deploy-RolesPlan (Role Assignment): Automatically provisions the required Azure Role-Based Access Control (RBAC) permissions for Managed Identities attached to DeployIfNotExists and Modify policies.

Directory Structure

An EPAC project follows a structured repository layout:

Recommended Practices

• Isolate epac-dev Scopes:Always establish a dedicated development Management Group hierarchy (epac-dev) completely separate from tenant production scopes.Because EPAC deletes unmanaged policies in its target scope, testing inside active landing zones can inadvertently wipe existing policies.
• Avoid the Tenant Root Management Group:Target deployment scopes to intermediate Management Groups rather than Tenant Root Group to prevent locking out tenant-wide administrative access or conflicting with default Azure policies.
• Use CI/CD Pipelines:Implement EPAC using pipeline modules (GitHub Actions, Azure DevOps, or GitLab).Use Pull Request (PR) triggers to run Build-DeploymentPlans for peer review, followed by post-merge execution for automated deployment.