Microsoft AZ-500: Application Security and DevSecOps — 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

Application Security and DevSecOps in Azure focus on preventing identity misuse, protecting ingress and APIs, shifting security left in pipelines, securing secrets at rest and in transit, and enforcing robust release governance. Effective designs eliminate long‑lived secrets, use least privilege, validate every caller, and institutionalize continuous detection and remediation across code, dependencies, infrastructure, and runtime.

Secure Application Identity, Ingress, and API Protection

Secure application identity in Microsoft Entra ID (Azure AD) starts with a well‑scoped app registration and the correct OAuth 2.0 flow:

• Delegated permissions apply when a user is signed in and consent can be restricted to verified publisher apps or admin‑approved scopes only. Application permissions (app‑only) always require admin consent because they authorize background daemons or services that act without a user.
• Enforce least privilege by granting only the minimal scopes or application roles needed and requiring admin review of consent requests. Disable end‑user consent or allow only for low‑risk, verified publishers to reduce consent phishing.
• Prefer certificate credentials or federated identities over client secrets. Certificates support stronger assurance and predictable rotation. Configure short lifetimes and automate rotation. Block public client flows unless needed.
• For Azure services, use managed identities instead of app secrets. Assign data‑plane roles such as Key Vault Secrets User or Storage Blob Data Reader, and restrict network access using Private Endpoints where applicable.

Application Gateway WAF v2 and Azure Front Door WAF protect public ingress against OWASP Top 10 threats:

• Enable the latest Microsoft‑managed OWASP Core Rule Set and run in Prevention mode after tuning. Use anomaly scoring initially to reduce false positives during learning.
• Configure custom rules for geofencing, IP reputation blocks, header enforcement, and request size limits. For Front Door, add rate‑limit rules per client IP to blunt credential stuffing and basic L7 DoS.
• Terminate TLS with strong cipher suites and policies; use end‑to‑end TLS to the origin. For scenarios requiring mTLS, configure client certificate validation on Application Gateway listeners.
• Attach WAF policies to listeners/routes precisely; use rule exclusions only when you fully understand the false positive. Stream WAF logs to Log Analytics for detection engineering and incident response.

API Management (APIM) enforces a multilayer security posture:

• Validate OAuth tokens at the gateway with strict issuer, audience, and scope checks. Require HTTPS everywhere and enforce mTLS when the client trust boundary requires it.
• Combine subscription keys with OAuth for defense‑in‑depth and for throttling identity. Use product‑level subscription keys to partition consumers and rotate keys without breaking others.
• Apply rate limiting and quotas with per‑consumer, per‑scope, or per‑subscription granularity. Use IP filtering to allowlist partner networks when appropriate.
• Protect backend services using mutual TLS or managed identities. Store secrets as Named Values backed by Key Vault references to avoid in‑config plaintext.

Example APIM policy for JWT scope enforcement and throttling:

<policies>
  <inbound>
    <base />
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401" require-scheme="Bearer">
      <openid-config url="https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration" />
      <audiences>
        <audience>api://your-api-app-id</audience>
      </audiences>
      <required-claims>
        <claim name="scp">
          <value>read.items</value>
        </claim>
      </required-claims>
    </validate-jwt>
    <rate-limit-by-key calls="100" renewal-period="60" counter-key="@(context.Subscription?.Key ?? context.Request.IpAddress)" />
  </inbound>
  <backend><base /></backend>
  <outbound><base /></outbound>
  <on-error><base /></on-error>
</policies>

DevSecOps Pipeline Hardening and Defender for DevOps

Azure DevOps and GitHub Actions must authenticate to Azure without long‑lived secrets:

• Use workload identity federation (OIDC) for service connections. Create an app registration/service principal in Entra ID, then add a federated credential that binds the repo, branch, and workflow/environment to the identity. This yields short‑lived tokens with no stored secrets and supports least privilege scoping via Azure RBAC.
• Lock down pipeline permissions: require approvals to use service connections, restrict pipeline to protected branches, and disable “Allow scripts to access OAuth token” unless needed. Use variable groups and secrets with masking; disallow secret echo via logging commands. In GitHub, prefer environment and organization secrets over repo secrets for centralized control and use “prevent secrets in logs” settings in hosted runners where applicable.
• Apply environment protection rules: required reviewers, checks (e.g., change management tickets, test pass), and time‑based approvals.

Create a federated credential with Azure CLI (GitHub OIDC example):

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"github-oidc-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:org/repo:ref:refs/heads/main",
    "audiences":["api://AzureADTokenExchange"]
  }'

Microsoft Defender for DevOps integrates with Azure Repos and GitHub to surface:

• Code security findings (SAST) in common languages; pull request annotations highlight new issues to prevent regressions.
• Dependency risk (SCA) using vulnerability intelligence for OSS libraries with remediation guidance and fixed versions.
• Secret exposure detection and recommended rotations for leaked tokens/keys.
• Infrastructure‑as‑Code misconfigurations across ARM/Bicep/Terraform (e.g., public storage, permissive NSGs) with policy‑driven governance and drift tracking. Findings roll up into Defender for Cloud with repository and pipeline context for prioritization. Gate releases based on severity thresholds to stop unsafe deployments.

Secrets Management and Platform Integration

Key Vault provides centralized secret, key, and certificate management with comprehensive controls:

• Enforce purge protection and soft delete to prevent destructive loss. Prefer RBAC over access policies for unified authorization; enable Private Endpoints and disable public network access where feasible; enable logging to a secure workspace.
• App Service and Functions use Key Vault references in app settings with managed identities; rotate secrets transparently without redeployment.
• AKS retrieves secrets at runtime via Secrets Store CSI Driver with the Azure Key Vault provider, authenticated by Azure AD Workload Identity (recommended). Avoid placing plaintext secrets in Kubernetes Secret objects.

App Service Key Vault reference example:

Name: DbConn
Value: @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnString/23a1...)

AKS SecretProviderClass (abridged):

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: kv-secrets
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "false"
    useWorkloadIdentity: "true"
    keyvaultName: kv-prod
    tenantId: <tenant-id>
    objects: |
      array:
        - | 
          objectName: api-key
          objectType: secret

Pipelines should fetch secrets at job runtime:

• Azure DevOps: Key Vault task with managed identity‑backed service connection; restrict secret download to the least number of stages.
• GitHub Actions: azure/login for OIDC and azure/keyvault to pull only required names.

Secure SDLC, Containers, Logging, and Releases

Secure SDLC practices reduce risk before deployment:

• Threat modeling early with STRIDE or equivalent ensures authentication, authorization, and data flows are explicitly validated. Update models as architecture evolves.
• SAST runs on every PR; break builds on high‑severity issues with clear ownership. DAST executes post‑deploy into a staging slot/environment with safe test data.
• SCA continuously monitors packages; mandates fixed versions and license compliance.
• Rigorous code review with branch policies: required reviewers, linked work items, build validation, and signed commits.

Container image security is foundational to supply chain integrity:

• Generate and store SBOMs (SPDX or CycloneDX) during builds, publish alongside images as OCI artifacts for traceability.
• Scan images pre‑push and at‑rest in registries using Defender for Cloud’s container scanning; gate promotion on critical findings.
• Sign images and attestations using Notary v2/OCI artifacts with cosign. Enforce signature verification at admission (e.g., Gatekeeper/OPA or AKS Policy for Kubernetes).
• Registry controls in Azure Container Registry (ACR): disable the admin user, restrict network via Private Endpoints, enable customer‑managed keys, use repository‑scoped tokens for fine‑grained access, and apply retention and quarantine patterns. Grant only AcrPull to runtimes and AcrPush to CI. For AKS, attach ACR with the supported command to create the correct assignment rather than manual role configuration.
• If containers must use VNet service endpoints from a VM host, install a supported CNI plugin so per‑container traffic is sourced from the subnet.

Application logging must not leak secrets or PII:

• Configure Application Insights to redact or drop sensitive fields with Telemetry Processors; avoid logging raw headers, tokens, or payloads that contain secrets or PII. Limit data fields to business need and enable sampling to reduce exposure.
• Route diagnostics to a dedicated Log Analytics workspace with strict RBAC (Log Analytics Reader at least privilege) and immutable storage when exporting to Storage (time‑based retention locks).
• Protect telemetry ingestion and query endpoints with Private Link where available. Store instrumentation connection strings in Key Vault and rotate regularly.

Secure release practices enforce controlled promotion:

• Approval gates in Azure DevOps Environments or GitHub Environments require designated reviewers, passing quality checks, and change tickets. Automate hold‑back windows for high‑risk deployments.
• Apply least privilege to service connections and agents; scope to resource groups or subscriptions per environment. Use managed identities with narrowly scoped roles.
• Environment segregation across Dev, Test, and Prod with separate subscriptions, VNets, Key Vaults, and ACRs; disallow cross‑environment lateral movement and use different secrets/keys in each environment.

Practical Problem Scenario

Fabrikam, Inc. is publishing a multi‑tenant SaaS API to the internet. Requirements: block OWASP Top 10 attacks, validate OAuth scopes per operation, prevent secrets in repos, throttle abusive clients, and ensure only signed container images run in production.

1. Fronting and WAF

• Deploy Azure Front Door Standard with a WAF policy using the latest OWASP managed rule set in Prevention mode, plus custom rate‑limit rules and geo blocking. Rationale: centralized global edge enforcement reduces attack surface and absorbs L7 attacks before they reach the origin.

2. API Gateway Policy

• Place Azure API Management behind Front Door; implement validate-jwt with issuer/audience/scope checks per operation and product‑level subscription keys with quotas. Rationale: APIM provides identity‑aware enforcement and tenant isolation; keys plus OAuth offer layered defense and precise throttling.

3. Identity and Consent

• Register the SPA and daemon apps in Entra ID with delegated scopes for user flows and application roles for the daemon; restrict user consent to verified publishers and require admin consent for app permissions. Use certificate credentials for the daemon. Rationale: eliminates weak secrets, enforces least privilege, and reduces consent phishing exposure.

4. DevSecOps with OIDC

• Configure GitHub Actions to use OIDC federation to an Azure service principal scoped to a non‑production subscription for build and to a production‑scoped principal for release, each with minimal roles (AcrPush for build, Contributor limited to a prod RG for release). Rationale: no stored secrets; blast radius minimized per environment.

5. Container Supply Chain

• Build images via ACR Tasks, generate SBOMs (CycloneDX) and sign images with cosign; store attestations as OCI artifacts. Configure AKS admission with policy to require valid signatures. Rationale: provenance and integrity are verifiable at deploy time, blocking tampered images.

6. Registry and Runtime Controls

• Disable ACR admin user, enable Private Endpoint, assign AcrPull to the AKS kubelet identity via the supported attach‑acr flow, and enable Defender for Cloud image scanning. Rationale: network and identity hardening remove default backdoors; scanning catches known CVEs before runtime.

7. Secrets and Configuration

• Use Key Vault with Private Endpoint and RBAC; App Service and Functions consume Key Vault references, and AKS uses Secret Store CSI with Workload Identity. Rationale: secrets never reside in repos or app configs; rotation is centralized and auditable.

8. Release Governance

• Protect GitHub main branch with required reviews and checks; require environment approvals and passing security gates (no critical SAST/SCA/IaC findings) before production deploy. Rationale: ensures only validated, secure builds progress; human oversight remains for high‑risk changes.

9. Observability Hygiene

• Configure Application Insights to redact PII with custom Telemetry Processors and route WAF/APIM diagnostics to a secured Log Analytics workspace with least‑privileged Reader access. Rationale: preserves forensic value without exposing sensitive data; access is auditable and constrained.

← Microsoft Sentinel and Security Operations · All domains · Hybrid and Multi-Cloud Security →

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

Browse Microsoft →