Playbook - AZ-500 Microsoft Azure Security Engineer Associate

Provide just-in-time (JIT) access to privileged Azure AD roles, requiring approval and justification.

Configure Microsoft Entra Privileged Identity Management (PIM) for the role. Set "Require approval to activate", specify approvers, enable "Require justification on activation", and set a maximum activation duration.

Why: PIM is the native Azure service for JIT role elevation. Simply making a user eligible is not enough; the policy settings enforce the approval and justification workflow.

Reference

Enforce MFA and a compliant device for all users accessing sensitive apps, but exempt a specific help desk group from the device compliance rule.

Create two Conditional Access (CA) policies. Policy 1 targets "All Users" excluding the help desk group, requiring MFA and a compliant device. Policy 2 targets only the help desk group, requiring only MFA.

Why: A single policy with an exclusion would remove all requirements for the excluded group. Two targeted policies ensure each group gets the correct, distinct set of controls.

Reference

Automatically respond to detected identity risks: block high-risk sign-ins and force password resets for high-risk users.

Configure two Microsoft Entra ID Protection policies. Set the "Sign-in risk policy" to Block access at a High risk level. Set the "User risk policy" to Require password change at a High risk level.

Why: Sign-in risk is about a single authentication attempt (real-time), while User risk is a cumulative score about the identity itself (compromised credentials). They require different remediation actions.

Allow users in a hybrid identity environment to reset their cloud password and have it sync back to on-premises Active Directory.

In Microsoft Entra Connect, enable the "Password writeback" feature. In Azure AD, enable and configure Self-Service Password Reset (SSPR) for the targeted users.

Why: SSPR provides the cloud-side user interface for password reset, while Password Writeback is the component in Entra Connect that syncs the new password hash back to the on-premises AD.

Periodically review all guest user access and automatically remove guests who are no longer approved or are inactive.

Create an Access Review in Microsoft Entra ID Governance. Target guest users in all groups, set a recurring schedule (e.g., quarterly), and enable "Auto apply results to resource". Optionally, review inactive users.

Why: Access Reviews are the dedicated governance tool for periodic recertification of access. The "Auto apply results" feature is critical for closing the loop and automating removal.

Provide external partners with a self-service way to request a bundle of access (groups, apps, SharePoint sites) that expires automatically after 90 days.

Use Microsoft Entra Entitlement Management. Create a Connected Organization for the partner. Create an Access Package containing the resources. Define a policy for the package that allows users from the connected org to request it, with a 90-day expiration.

Why: Entitlement Management is designed for governing access at scale, especially for external users. It bundles resources and automates the entire access lifecycle from request and approval to expiration and removal.

A high-security application requires users to authenticate with a method that is resistant to phishing and man-in-the-middle attacks.

Enforce authentication methods like FIDO2 security keys or Windows Hello for Business. These methods use public-key cryptography and are bound to the device, preventing credential theft.

Why: Methods like SMS, voice calls, or simple push notifications are phishable. FIDO2 and WHfB use cryptographic challenges that are tied to the origin of the request, making them resistant to phishing.

A background service running on a VM needs to read all user profiles from Microsoft Graph without any user interaction.

Register the application in Microsoft Entra ID. Under API permissions, grant it Microsoft Graph "Application" permissions (not "Delegated") for `User.Read.All`. An administrator must grant admin consent.

Why: Application permissions allow the app to act as itself, using its own identity (client ID/secret or certificate). Delegated permissions require a signed-in user context, which is not available in a non-interactive daemon app.

Allow a pod in an AKS cluster to securely access Azure Key Vault without using stored credentials like client secrets or certificates.

Use Azure AD Workload Identity. Create a user-assigned managed identity, establish a federated identity credential between the K8s service account and the managed identity, and grant the managed identity access to Key Vault.

Why: Workload Identity uses OIDC federation to exchange a Kubernetes token for an Azure AD token, completely eliminating the need to store, manage, or rotate secrets in the cluster.

Reference

Secure an Azure Key Vault to only allow access from specific VNets, log all operations, and protect against accidental deletion of critical keys.

Configure the Key Vault firewall to allow access from "Private endpoint and selected networks". Enable diagnostic logging to a Log Analytics workspace. Enable both Soft Delete and Purge Protection.

Why: Soft Delete allows recovery from accidental deletion, but Purge Protection prevents even a privileged user from permanently deleting the vault or its contents during the retention period. This combination is critical for protecting TDE keys.

An Azure App Service needs to authenticate to Azure SQL Database to retrieve data, without storing connection string passwords in configuration.

Enable a system-assigned managed identity on the App Service. In Azure SQL, create a contained user mapped to the App Service's managed identity name and grant it the necessary database roles (e.g., db_datareader).

Why: Managed Identity provides an identity for the Azure resource itself in Azure AD. Azure handles credential creation and rotation automatically, eliminating stored secrets, which is a major security best practice.

Encrypt Azure VM managed disks at rest using a key that your organization controls in Azure Key Vault.

Create a Disk Encryption Set resource. Configure it to use a customer-managed key (CMK) from your Azure Key Vault. Assign the Disk Encryption Set to the VM's managed disks.

Why: This is Server-Side Encryption (SSE) with CMK, which encrypts data in the storage infrastructure. It is simpler than Azure Disk Encryption (ADE), which uses BitLocker/dm-crypt to encrypt data inside the guest OS and is generally used for OS and data disks together.

Ensure container images stored in Azure Container Registry (ACR) are scanned for vulnerabilities before they are deployed.

Enable Microsoft Defender for Containers. This will automatically scan images in ACR when they are pushed, when they are pulled, and on an ongoing basis for newly discovered vulnerabilities.

Why: This "shift-left" security practice identifies vulnerabilities early in the CI/CD pipeline. Defender for Containers provides this scanning capability natively within the Azure ecosystem.

Detect and receive alerts for potential SQL injection attacks and anomalous access patterns on an Azure SQL Database.

Enable Microsoft Defender for SQL on the logical SQL server. This provides advanced threat protection and vulnerability assessment.

Why: Defender for SQL is the dedicated workload protection plan that uses behavioral analytics and machine learning to detect threats like SQL injection, brute force attacks, and unusual data access, which are not visible to network-level tools.

Restrict a storage account to a specific VNet, but still allow trusted Microsoft services like Azure Backup to access it.

In the storage account networking settings, select "Enabled from selected virtual networks and IP addresses". Add the required VNet/subnet. Then, check the box for "Allow trusted Microsoft services to access this storage account".

Why: The trusted services exception creates a secure path for specific Microsoft services to bypass the VNet firewall rules. Without it, services that operate on behalf of the user (like Backup or Portal) would be blocked.

Protect specific sensitive data columns (e.g., credit card numbers) in an Azure SQL database, even from privileged database administrators (DBAs).

Use Always Encrypted. The client application driver transparently encrypts the data before sending it to the database, and the encryption keys are never revealed to the database engine.

Why: Transparent Data Encryption (TDE) encrypts the entire database at rest (on disk), but a DBA with access can still see the data. Always Encrypted provides client-side encryption, separating those who manage the data (DBAs) from those who can see it.

Process highly sensitive data on an Azure VM, ensuring it remains encrypted and protected even in memory from the hypervisor and cloud operators.

Deploy an Azure Confidential VM. These VMs use hardware-based Trusted Execution Environments (TEEs) like AMD SEV-SNP to create an isolated, encrypted memory space.

Why: Standard VM encryption (like ADE or SSE) protects data at rest. Confidential Computing is the only technology that protects data *while in use* in memory, providing the highest level of data privacy and isolation in the cloud.

An App Service needs to use a secret from Key Vault as an application setting, without changing application code to use the Key Vault SDK.

Enable managed identity on the App Service and grant it "Get" permissions on secrets in Key Vault. In the App Service configuration, create an application setting with the value formatted as a Key Vault reference: `@Microsoft.KeyVault(SecretUri=...)`.

Why: This feature allows the App Service platform to resolve the secret value at runtime using the managed identity. The application code simply reads a standard environment variable, abstracting away the Key Vault interaction.

Store compliance-related data in Azure Blob Storage in a WORM (Write-Once, Read-Many) state for a 7-year retention period.

On the storage container, configure an immutability policy. Use a time-based retention policy set to 7 years and lock the policy. Once locked, the data cannot be modified or deleted by anyone until the retention period expires.

Why: This feature is specifically designed to meet regulatory compliance requirements (e.g., SEC 17a-4). Locking the policy is the critical step that makes it truly immutable.

In a multi-tenant application using a single Azure SQL database, ensure that users from one tenant can only see data belonging to their own tenant.

Implement Row-Level Security (RLS). Create a security policy with a predicate function that filters rows based on the user's tenant ID, which is stored in the session context or a user lookup table.

Why: RLS enforces access logic directly within the database engine. This is more secure and reliable than implementing filtering in the application layer, as it cannot be bypassed and is transparent to the application code.

Protect Generation 2 VMs against boot kits and rootkits by ensuring the integrity of the entire boot chain from UEFI to the OS kernel.

Provision the VM with Trusted Launch enabled. This activates Secure Boot, which validates the signature of all boot components, and a virtual Trusted Platform Module (vTPM) for measured boot and attestation.

Why: Trusted Launch addresses sophisticated, low-level malware that can subvert traditional OS-level security controls. It establishes a hardware root of trust for the VM.

Isolate traffic between application tiers (web, app, data) hosted in separate subnets.

Create a dedicated Network Security Group (NSG) for each subnet. In each NSG, create inbound rules that only allow traffic from the source IP range of the preceding tier on the required port. (e.g., App-tier NSG allows TCP/8080 from Web-tier subnet).

Why: Applying a unique, least-privilege NSG to each subnet provides defense-in-depth and granular control over east-west traffic flows, which is more secure than a single, complex NSG for the VNet.

In a hub-spoke topology, force all traffic between spoke VNets to be inspected by an NVA or Azure Firewall in the hub.

On each spoke subnet, create a User Defined Route (UDR) for the other spokes' address spaces with the next hop type set to "VirtualAppliance" and the IP of the NVA/Firewall. Enable IP Forwarding on the NVA's NIC.

Why: By default, VNet peering allows spokes to communicate directly. UDRs override this default routing behavior, forcing traffic to the central inspection point.

Provide a PaaS service (e.g., Azure SQL, Storage) with a private IP address inside your VNet, ensuring traffic never traverses the public internet.

Create a Private Endpoint for the PaaS service in your VNet. Critically, in the PaaS service's networking settings, disable public network access to block the public endpoint.

Why: A Private Endpoint brings the service *into* your VNet with a private IP. A Service Endpoint just optimizes the route over the Azure backbone to a public IP. Disabling public access is required to enforce private-only communication.

Allow outbound traffic from VMs to a dynamic set of Microsoft service endpoints, like Windows Update, without manually maintaining IP lists.

In Azure Firewall, create an Application Rule collection. Add a rule with the target FQDN type set to "FQDN Tag" and select the "WindowsUpdate" tag.

Why: FQDN Tags are curated collections of FQDNs that Microsoft manages. This is the correct way to allow access to PaaS services whose underlying IPs change frequently. Service Tags are for IP-based rules.

A Web Application Firewall (WAF) is blocking legitimate traffic to your application due to a false positive in a managed rule (e.g., SQL injection).

In the WAF policy, keep the WAF in Prevention mode. Find the managed rule that is blocking traffic and configure an exclusion for the specific request header, cookie, or body parameter that is causing the false positive.

Why: Exclusions are the most precise way to handle false positives. They allow you to maintain the protection of the rule for all other traffic while making a specific exception, which is more secure than disabling the entire rule.

Provide secure RDP/SSH access to Azure VMs without exposing management ports to the internet or requiring public IPs on the VMs.

Deploy Azure Bastion (Standard SKU for advanced features) into a dedicated subnet in the VNet. Access VMs via the Azure portal, which connects through the Bastion service.

Why: Bastion acts as a secure jump box, brokering the RDP/SSH connection. The only public IP is on the Bastion service itself, which is hardened and managed by Microsoft, dramatically reducing the attack surface of your VMs.

Provide developers with time-limited, audited access to management ports (RDP/SSH) on development VMs.

Enable Microsoft Defender for Cloud and configure Just-in-Time (JIT) VM access for the VMs. Users will request access through Defender for Cloud, which dynamically modifies NSG rules to allow access for a limited time from a specific IP.

Why: JIT is a core feature of Defender for Cloud that hardens the network posture of VMs by keeping management ports closed by default, opening them only on-demand.

Enforce security best practices, such as disallowing privileged containers, on an Azure Kubernetes Service (AKS) cluster at deployment time.

Enable the Azure Policy add-on for AKS. Assign the built-in policy initiative named "Kubernetes cluster pod security restricted standards for Linux-based workloads".

Why: This leverages Azure Policy as a centralized, at-scale admission controller for Kubernetes, enforcing security and compliance guardrails before workloads are even created in the cluster.

Route all internet-bound traffic from an Azure VNet back to an on-premises security appliance for inspection before it reaches the internet.

Configure a site-to-site VPN or ExpressRoute. Create a User Defined Route (UDR) for the address prefix 0.0.0.0/0, and set the next hop to be the Virtual Network Gateway.

Why: This pattern, known as forced tunneling, overrides Azure's default route to the internet and forces all outbound traffic through the gateway to the on-premises network, ensuring no VM can bypass corporate security controls.

Inspect outbound TLS-encrypted traffic from VMs for threats using Azure Firewall.

Deploy Azure Firewall Premium. Enable TLS Inspection and Intrusion Detection (IDPS). Configure a subordinate CA certificate on the Firewall and deploy its public key to the client VMs as a trusted root CA.

Why: To inspect encrypted traffic, the firewall must perform a man-in-the-middle operation. This requires the Premium SKU, IDPS for threat detection, and a proper certificate infrastructure to avoid TLS errors on client machines.

Protect all public-facing applications across multiple VNets and subscriptions from volumetric DDoS attacks in a cost-effective way.

Create a single Azure DDoS Protection Plan. Associate this one plan with all the virtual networks that contain public IP addresses that need protection.

Why: A single DDoS Protection Plan can cover up to 100 VNets, and you pay a flat monthly fee for the plan, not per VNet or per IP. This centralized model is much more cost-effective than deploying multiple plans or using the per-IP protection SKU.

When a high-severity incident is created in Microsoft Sentinel, automatically disable the involved user account in Azure AD and notify the security team in Teams.

Create an Automation Rule that triggers on high-severity incident creation. The rule should call a Playbook (Logic App). The playbook uses the Azure AD connector to disable the user and the Teams connector to post a message.

Why: This demonstrates the SOAR (Security Orchestration, Automation, and Response) pattern. The Automation Rule is the trigger/condition engine, and the Playbook is the action/workflow engine.

Reference

Apply a consistent set of security policies and enable Defender for Cloud plans across a large number of Azure subscriptions.

Organize all subscriptions under a Management Group. Assign the Azure Security Benchmark policy initiative and enable the required Defender for Cloud plans at the management group level.

Why: Management Groups are the primary tool for enterprise-scale governance. Policies and settings applied at this level are inherited by all child subscriptions, ensuring consistency and reducing administrative overhead.

Create a custom detection in Sentinel for a user signing in from a new country for the first time.

Create a Scheduled query analytics rule. Use a KQL query that joins recent `SigninLogs` with a summarized history of past `SigninLogs` to identify UserPrincipalName/Country combinations not seen before.

Why: Scheduled query rules with KQL are the foundation of custom threat detection in Sentinel, allowing for complex, stateful logic that goes beyond simple event matching.

Retain security logs in Sentinel for 2 years for compliance, but only keep the most recent 90 days available for fast, interactive queries to manage costs.

In the Log Analytics workspace, set the "Interactive Retention" to 90 days. Set the "Total retention" (Archive) to 730 days (2 years). Configure retention policies per-table if needed.

Why: This tiered approach balances cost and capability. The interactive tier is expensive but fast. The archive tier is very low-cost for long-term storage. Archived data can still be queried via asynchronous Search Jobs or temporarily restored.

During an incident investigation, you need to quickly visualize the relationships between a compromised user, the IP they signed in from, and the resources they accessed.

From the incident page in Microsoft Sentinel, open the Investigation Graph. Use the graph to visually explore entities and their connections across different alerts and log sources.

Why: The Investigation Graph is a powerful visualization tool that maps out the attack story, making it much easier to understand the scope and timeline of an incident than by manually correlating events in log queries.

Detect an attacker who has compromised a user account and is now attempting to access unusual resources or hosts within the network.

Ensure User and Entity Behavior Analytics (UEBA) is enabled in Microsoft Sentinel and that relevant data sources (Azure AD logs, Defender for Endpoint/Security Events) are connected. Monitor UEBA for anomaly detections related to lateral movement.

Why: UEBA builds a baseline of normal behavior for each user and entity. It excels at detecting deviations that indicate lateral movement, such as a user accessing a server for the first time or using unusual protocols, which are difficult to spot with static rules.

Reduce Microsoft Sentinel ingestion costs for high-volume, verbose logs that are needed for compliance but not for real-time analytics.

Configure the table plan for these logs to "Basic Logs". Additionally, use Data Collection Rules (DCRs) with XPath queries or other transformations to filter out noisy, low-value events before ingestion.

Why: Basic Logs offer a significantly lower ingestion cost in exchange for limited query capabilities and shorter retention. Filtering at the source with DCRs is the most effective way to reduce volume by preventing unwanted data from ever reaching the workspace.

Automatically enforce a security setting, like enabling "Secure transfer required" on all existing and new Azure Storage accounts.

Assign an Azure Policy with the `DeployIfNotExists` or `Modify` effect. For existing non-compliant resources, create a remediation task from the policy compliance blade to apply the change.

Why: Audit and Deny policies only report or block non-compliance. `DeployIfNotExists` and `Modify` with remediation tasks actively correct misconfigurations, making policy a powerful tool for automated governance and security hardening.

Detect runtime threats in an AKS cluster, such as suspicious process execution or a container connecting to a known malicious IP.

Enable Microsoft Defender for Containers. This deploys a DaemonSet (Defender agent) to each node in the cluster, which collects security signals from the host and containers to provide real-time threat detection.

Why: While ACR scanning provides "shift-left" security, runtime protection is crucial for detecting threats that occur post-deployment. Defender for Containers provides this visibility at the host and workload level within the cluster.