Microsoft AZ-500: Compute, Container and Endpoint Security — Study Guide

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Part of the Microsoft Azure Security Engineer Associate AZ-500 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

This section provides an operational reference for securing Azure compute, containers, and endpoints across IaaS and PaaS. It focuses on how to configure protections, why they matter, and how to enforce them consistently with Azure-native controls.

Compute and Endpoint Security

Azure VM platform protections and encryption options are foundational.

• Secure Boot, vTPM, and Trusted Launch: Trusted launch hardens Gen2 VMs by enabling UEFI Secure Boot and a virtual TPM (vTPM). Secure Boot prevents unsigned bootloaders/rootkits. The vTPM provides a tamper-resistant store for keys (for example BitLocker) and supports measured boot so the platform can attest to the OS boot chain. Operationally, enable trusted launch at deployment and enforce it with policy to ensure all new VMs gain hardware-rooted integrity checks without administrators needing to handle static BIOS/UEFI settings.

• Confidential VMs: Use AMD SEV-SNP or Intel TDX-backed confidential VM series (for example DCasv5/DCadsv5) to encrypt VM memory and provide attestation. This protects workloads from a malicious host/hypervisor and side-channel attacks. Operationally, select confidential SKUs for highly sensitive data-in-use scenarios, integrate attestation in your deployment pipeline, and prefer ephemeral OS disks when you need rapid redeployments without data persistence.

• Disk Encryption options:

  • Azure Disk Encryption (ADE): Inside-guest BitLocker (Windows) or DM-Crypt (Linux), keys in Key Vault (BEK/KEK). Useful when you need guest-based crypto domains, inside-OS compliance checks, or to leverage vTPM-bound BitLocker. Requires agent and lifecycle operations for extension health.
  • Server-Side Encryption (SSE) with Customer-Managed Keys (CMK): Storage-level encryption for managed disks using keys in Key Vault or Managed HSM. No guest agents, full platform coverage (disks, snapshots, images), minimal ops overhead. Recommended default for most use cases; pair with Trusted Launch or Confidential VMs for stronger defense-in-depth.

• Microsoft Defender for Servers:

  • Plan 1: Microsoft Defender for Endpoint (MDE) for EDR/endpoint protection on servers. Choose this when you already have mature vulnerability and configuration management tooling and primarily need EDR.
  • Plan 2: Adds agent-based/agentless vulnerability assessment, just-in-time (JIT) VM access, adaptive application controls, adaptive network hardening, and file integrity monitoring (FIM). Choose when you want platform-driven exposure reduction and governance-in-action without stitching multiple tools.
  • Endpoint protection: Deploy MDE via VM extensions or Arc for non-Azure servers to standardize telemetry, tamper protection, and response playbooks across hybrid footprints.
  • Vulnerability assessment: Use the MDE Threat & Vulnerability Management signal or the integrated scanner (e.g., Qualys) to inventory CVEs, prioritize by exploitability, and orchestrate patching. Operationally, baseline critical internet-facing servers first; tie remediation to change windows.
  • File Integrity Monitoring: Track changes to sensitive files/registry keys to detect suspicious tampering and meet compliance requirements. Configure scoped watch paths to avoid noise and forward alerts to your SIEM.

• Exposure reduction with Defender for Cloud:

  • Just-in-Time VM Access: Closes inbound RDP/SSH. Administrators request time-bound access; Defender opens the NSG or Azure Firewall rule and logs activity. The result is a drastically reduced attack surface with auditable exceptions.
  • Adaptive Application Controls: Learns normal processes and creates allowlists (AppLocker on Windows, audit rules for Linux). This blocks unapproved binaries and scripts—particularly effective against fileless or LOLBin attacks.
  • Adaptive Network Hardening: Uses traffic analytics and threat intelligence to propose NSG rule tightening. Adopt a review-and-apply cadence to iteratively restrict exposure while avoiding outages.
  • Guest Configuration: Azure Policy for in-guest audit/remediation (Windows and Linux) via an agent or Azure Arc. Use it to enforce OS baselines, password policies, and CIS-aligned settings when you need provable configuration state, not just platform posture.

PaaS Compute: App Service and Functions

Secure-by-default patterns reduce PaaS attack surface.

• Azure App Service:

  • Authentication/Authorization: Enable App Service Authentication to offload auth to Microsoft Entra ID or other providers. Use Easy Auth for standard OIDC/OAuth2 flows, then enforce login on all routes to remove unauthenticated exposure.
  • Access Restrictions: Allow or deny traffic by IP/CIDR, service tags, or virtual network traffic via private endpoints. Maintain separate rules for the scm endpoint and app endpoint to protect your deployment plane independently.
  • Private Endpoints: Expose the app over a private IP in your VNet and optionally disable public access. Use private DNS zones and restrict outbound dependencies with VNet Integration and a central egress firewall.
  • Managed Identities: Prefer system-assigned or user-assigned identities to access Key Vault, Storage, and other services. This eliminates embedded secrets and enables centralized role assignment and key rotation.

• Azure Functions:

  • Key Management: Functions use function keys, host keys, and the master key. Rotate keys regularly and store externally-consumed keys in Key Vault, or replace keys with proper OAuth flows if feasible.
  • Network Integration: Use private endpoints for inbound access to the Function app and regional VNet Integration for outbound controls. Restrict the Storage account used by Functions to selected networks only and add the Function’s private endpoint to allowed networks.
  • Identities: Use managed identities for service-to-service auth instead of keys or connection strings. Drive least privilege with narrow-scoped RBAC assignments.
  • Deployment Controls: Enforce FTPS-only, disable basic auth for the scm site, restrict scm IPs, and use Run From Package to ensure immutable deployments. Integrate CI/CD with workload identity federation to eliminate long-lived secrets.

Kubernetes and Container Security

Harden clusters and supply chains end-to-end.

• AKS identity and authorization:

  • Microsoft Entra integration: Enable managed AAD for AKS to authenticate kubectl using Entra tokens and groups. This centralizes user lifecycle and MFA/Conditional Access.
  • Kubernetes RBAC: Map Entra users/groups to Kubernetes roles and role bindings for namespace-scoped least privilege.
  • Azure RBAC for Kubernetes: Use built-in roles (e.g., Azure Kubernetes Service RBAC Viewer/Admin) when you want Azure RBAC to authorize Kubernetes API actions directly. This unifies authorization and audit with the Azure control plane.

• AKS networking and privacy:

  • Network policies: Enforce pod-to-pod and pod-to-service traffic with Azure NPM or Calico. Deny by default and explicitly allow required egress; policy-as-code prevents lateral movement.
  • Private clusters: Make the API server private, accessible only via private endpoints. Pair with Azure Bastion/Private Link and a firewall egress strategy (NAT Gateway + UDRs) to keep management plane off the internet.

• Container Registry (ACR) security:

  • RBAC: Assign AcrPull to workloads that only need to pull images and AcrPush to build pipelines; avoid over-privileged Owner. AcrPull and AcrPush align with least privilege.
  • Content trust and signing: Sign images with cosign and enforce verification with admission control (Gatekeeper + Ratify) before pods start. This defends against tampered images.
  • Image scanning: Enable Microsoft Defender for Cloud to scan ACR on push/import and on a schedule. Block deployment of images with critical unpatched CVEs using admission policies.
  • Quarantine pattern: Route new images to a quarantined repo or tag, run scanning and policy checks, then promote by retagging after approval.
  • Private access: Disable public network access and use private endpoints and registry firewall rules. Attach AKS to ACR using a resource-level role assignment rather than a directory role.

Short example to attach ACR to AKS using the cluster’s managed identity:

az aks update -g rg-aks -n myAKS --attach-acr myAcrName

• Microsoft Defender for Containers: Deploys a data plane sensor to AKS, monitors Kubernetes audit logs and runtime signals, and correlates with image scan results. It detects suspicious execs into pods, crypto-mining, exposed dashboards, and risky control-plane operations. Enable auto-provisioning and connect alerts to your SIEM/SOAR for triage.

Governance, Policy, and Enforcement

Consistent control requires policy at deploy and at runtime.

• Azure Policy for compute and disks:
  • Deny creation of VMs without trusted launch or without SSE with CMK.
  • Enforce VM extensions for endpoint protection using DeployIfNotExists to auto-install required agents.
  • Audit guest configuration compliance; remediate drift on a schedule.

Short policy snippet to deploy a required VM extension if missing:

"policyRule": {
  "if": { "field": "type", "equals": "Microsoft.Compute/virtualMachines" },
  "then": {
    "effect": "DeployIfNotExists",
    "details": {
      "type": "Microsoft.Compute/virtualMachines/extensions",
      "name": "MDE.Windows"
    }
  }
}

• Kubernetes admission controls:
  • Azure Policy add-on for AKS uses Gatekeeper (OPA) to evaluate pod specs at admission. Enforce rules such as “only pull from ACR,” “no privileged containers,” and “require image signatures.”
  • Maintain separate initiatives for baseline (must-have) and reinforced (sensitive namespaces) to allow progressive hardening.

Short Gatekeeper constraint to restrict registries:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-acr-only
spec:
  parameters:
    repos:
    - myacr.azurecr.io/

• Operational cadence:
  • Detect: Use Defender for Cloud recommendations and workload alerts as your drift and threat signals.
  • Decide: Triage by business impact and exploitability; assign owners via tags.
  • Enforce: Convert successful pilots to deny policies/admission constraints; measure blocked attempts to detect shadow IT.

Practical Problem Scenario

Adobe Inc. is migrating a payments microservice to Azure. Security requirements mandate zero public exposure, signed images only, and time-bound admin access to legacy VMs during cutover.

1. Make the AKS control plane private and lock down egress.

• Rationale: A private AKS API server removes the management plane from the internet. A NAT Gateway plus Azure Firewall with explicit outbound rules ensures workloads only reach approved endpoints (ACR, Key Vault, Microsoft package repos).

2. Enforce signed images and restrict registries.

• Rationale: Configure Gatekeeper with constraints that only allow images from myacr.azurecr.io and require cosign signatures validated by Ratify. This prevents tampered or untrusted images from running, closing a major supply chain risk.

3. Secure ACR with private endpoints and least-privilege roles.

• Rationale: Disable public network access and expose ACR via a private endpoint in the AKS VNet. Grant the AKS managed identity AcrPull only; grant the build pipeline AcrPush. This follows least privilege and eliminates internet dependency.

4. Enable Defender for Containers and ACR image scanning.

• Rationale: Continuous image scanning on push and runtime threat detection provide layered coverage. Alerts unify misconfigurations, known vulnerabilities, and suspicious behaviors for rapid response.

5. Protect App Service-based admin tools with authentication and private access.

• Rationale: Use App Service Authentication with Microsoft Entra ID to require MFA and Conditional Access. Create a private endpoint for the admin app and restrict scm access separately. Managed identities remove secrets for Key Vault access.

6. Use Just-in-Time VM access for legacy hosts during cutover.

• Rationale: JIT closes RDP/SSH by default and opens only on approved requests for limited durations. This strictly bounds exposure windows while preserving emergency access.

7. Standardize encryption choices: SSE with CMK for disks; Trusted Launch for VMs.

• Rationale: SSE with CMK minimizes operational load and centralizes key lifecycle in Key Vault, while Trusted Launch/vTPM adds boot integrity and key protection. ADE is reserved only where guest-based crypto domain evidence is contractually required.

8. Apply Azure Policy and admission control as guardrails.

• Rationale: Azure Policy initiatives enforce trusted launch, required VM extensions, and deny public ACR/Function access. Gatekeeper constraints implement runtime admission checks for AKS. Together they ensure configurations remain compliant as teams iterate.

9. Validate and operate with continuous governance.

• Rationale: Wire Defender for Cloud and MDE alerts into Adobe’s SIEM, measure policy effect (deny vs. audit), and review exceptions monthly. This transforms one-time controls into an enduring security operating model.

← Network Security Architecture · All domains · Data →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Microsoft →