What is Azure API Management (APIM), and why do we use it?

Azure API Management (APIM)

Azure API Management is a managed service that sits in front of your APIs as a gateway. Clients call APIM, and APIM applies policies (authentication, rate limiting, transformation, caching) before forwarding requests to your backends. The backends can be App Service, Functions, AKS, Container Apps, on-premises systems, or even other clouds.

The three components

• Gateway: the runtime proxy that receives API calls, enforces policies, and routes to backends. This is the data plane.
• Management plane: the Azure portal, CLI, Bicep, or REST API, where you define APIs, products, policies, and users.
• Developer portal: an auto-generated, customizable website where API consumers browse docs, try calls, and get subscription keys.

Self-hosted gateway: you can also run the gateway in containers on-premises or in other clouds, managed from the same APIM instance (Developer and Premium tiers).

Core concepts

• API: a set of operations (e.g., GET /orders/{id}), imported from OpenAPI, WSDL, an App Service, a Function App, or created manually.
• Product: a bundle of APIs with its own terms, quotas, and visibility (e.g., "Free" vs. "Premium" plans).
• Subscription: a key a consumer uses to access a product or API (sent in the Ocp-Apim-Subscription-Key header by default).
• Policy: XML statements that run on the request or response pipeline at global, product, API, or operation scope.
• Named values: configuration and secrets used inside policies (can be backed by Key Vault).
• Backend: a reusable definition of a downstream service, with URL, credentials, and circuit breaker settings.

Why use it

1. Security at the edge

• Validate JWTs from Entra ID before requests reach your backend
• Enforce subscription keys, client certificates, and IP filtering
• Authenticate to backends with managed identity, so backends never expose public credentials
• Centralize security policies instead of re-implementing them in every service

2. Traffic control

• Rate limiting and quotas per client, per key, or per IP
• Protection against abusive callers and backend overload
• Response caching to reduce backend load and latency
• Retry and circuit breaker behavior for flaky backends

3. A single, consistent front door

• One public URL and domain across many backend services
• Backends can move or be replaced without breaking consumers
• Consistent URL structure, headers, and error formats

4. Versioning and lifecycle

• Run multiple versions (/v1, /v2) side by side
• Revisions let you make non-breaking changes and test them before making them current

5. Transformation and mediation

• Rewrite URLs, add or strip headers, convert XML to JSON, mask fields in responses
• Expose a clean API over a messy legacy backend without changing it

6. Observability

• Built-in analytics, plus diagnostic logs and traces to Application Insights and Azure Monitor
• Correlation IDs, per-API and per-consumer usage and latency

7. Developer experience and monetization

• Self-service portal with documentation and a test console
• Products and subscriptions let you onboard partners, issue keys, and apply different limits per tier

Example policies

Validate an Entra ID token, rate limit, and forward using managed identity:

<policies>
  <inbound>
    <base />
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401"
                  failed-validation-error-message="Unauthorized">
      <openid-config url="https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration" />
      <audiences>
        <audience>api://<api-client-id></audience>
      </audiences>
      <required-claims>
        <claim name="roles" match="any">
          <value>Orders.Read</value>
        </claim>
      </required-claims>
    </validate-jwt>

    <rate-limit-by-key calls="100" renewal-period="60"
                       counter-key="@(context.Request.IpAddress)" />

    <authentication-managed-identity resource="api://<backend-client-id>" />
  </inbound>
  <backend>
    <base />
  </backend>
  <outbound>
    <base />
    <set-header name="X-Powered-By" exists-action="delete" />
  </outbound>
  <on-error>
    <base />
  </on-error>
</policies>

Response caching:

<inbound>
  <base />
  <cache-lookup vary-by-developer="false" vary-by-developer-groups="false" />
</inbound>
<outbound>
  <base />
  <cache-store duration="60" />
</outbound>

Tiers

Tier	Typical use
Consumption	Serverless, pay per call, scale to zero; good for low or spiky traffic (no VNet injection, limited features)
Developer	Non-production, for evaluation and testing (no SLA)
Basic / Standard	Small to mid-sized production workloads (classic tiers)
Premium	Multi-region, availability zones, VNet injection, self-hosted gateway, highest scale
v2 tiers (Basic v2, Standard v2, Premium v2)	Newer generation with faster provisioning and scaling, and simpler VNet integration

Tier names and feature sets change over time, so check the current pricing and feature comparison before choosing.

Typical architecture

Client ─► Front Door / App Gateway (WAF) ─► APIM ─► Backends
                                              │       ├─ App Service (Orders API)
                                              │       ├─ Functions (Webhooks)
                                              │       └─ AKS / Container Apps (Inventory)
                                              └─► Application Insights

Lock backends down so they only accept traffic from APIM (access restrictions, private endpoints, or a shared header or token check). Otherwise callers can bypass your policies by hitting the backend directly.

When APIM is a good fit

• You expose APIs to external partners or the public and need keys, quotas, and a developer portal
• You have multiple backend services and want one consistent entry point
• You need centralized auth, throttling, and logging without changing each service
• You're modernizing legacy services and want to hide their quirks behind a clean facade
• You need to publish APIs across regions or hybrid environments

When it may be overkill

• A single internal API with one consumer, where app-level auth and Easy Auth suffice
• Very low-budget or prototype projects (the non-Consumption tiers carry a meaningful fixed monthly cost)
• Scenarios needing only WAF and routing, where Front Door or Application Gateway is simpler
• Latency-critical hot paths, where every extra hop matters (APIM adds some overhead, usually small)

APIM vs. related services

	APIM	Front Door / App Gateway	Easy Auth
Focus	API lifecycle, policy, consumer management	Global routing, WAF, load balancing	Simple built-in authentication
Understands API operations and products	Yes	No	No
Rate limiting per consumer/key	Yes	Basic (WAF rate rules)	No
Developer portal	Yes	No	No

They're complementary: Front Door provides global entry and WAF, and APIM provides API governance behind it.

Good practices:

• Define APIM as code (Bicep or Terraform, with policies in versioned files) and deploy through CI/CD. Use the APIOps approach to promote API definitions between environments.
• Use managed identity for backend authentication, and Key Vault-backed named values for secrets.
• Validate tokens in APIM and also in the backend (defense in depth), and restrict backends to APIM traffic only.
• Keep policies simple and reusable with fragments, because complex policy logic is hard to test and debug.
• Send diagnostics to Application Insights and watch for gateway versus backend latency and failures.
• Use revisions and versions deliberately: revisions for non-breaking changes, versions for breaking ones.
• Plan capacity and region placement: choose a tier that supports the VNet and availability needs you actually have, because some of these can't be changed later without redeploying.

What deployment options are available for a Web API in Azure—App Service or AKS?

Deployment Options for a Web API in Azure

App Service and AKS sit at opposite ends of a spectrum: App Service is a managed platform where you deploy code or a container and Azure runs everything else, while AKS is managed Kubernetes where you get full control of the orchestration layer and take on the operational work that comes with it. There are also middle-ground options, covered below.

App Service

A PaaS for web apps and APIs. You deploy code (zip, Git, CI/CD) or a single container, and Azure handles the OS, patching, load balancing, TLS, and scaling.

Strengths:

• Fastest path to production, with very little operational overhead
• Built-in deployment slots (Standard tier and above) for zero-downtime swaps and instant rollback
• Autoscale, custom domains, managed certificates, Easy Auth, VNet integration, and managed identity
• Native .NET support, with no Dockerfile required
• A predictable, per-plan price

Limitations:

• Less control over networking, scheduling, and the runtime environment
• Multi-container setups are limited. It's one app per container, with no real orchestration
• Not suited to complex microservice meshes, sidecars, or custom operators
• Scale is bounded by plan limits (though it's plenty for most APIs)

Deploying:

az webapp up --name my-api --resource-group my-rg --runtime "dotnet:8"
# or, in CI/CD: azure/webapps-deploy@v3 with a staging slot, then swap

AKS (Azure Kubernetes Service)

Managed Kubernetes. Azure runs the control plane, and you manage the workloads, node pools, networking, ingress, and upgrades. AKS Automatic is a newer mode that manages more for you (node provisioning, scaling, and defaults), which narrows the gap with simpler platforms.

Strengths:

• Full Kubernetes ecosystem: Helm, operators, service meshes, GitOps, custom controllers
• Fine-grained control over scheduling, networking, resource limits, and node types (including GPU or spot nodes)
• Good for many services, sidecars, and portability across clouds
• Efficient bin-packing of many workloads onto shared nodes

Limitations:

• Real operational burden: cluster upgrades, node patching, ingress, certificates, observability, and security hardening
• Needs Kubernetes expertise on the team
• You must containerize everything
• Costs include the nodes (paid whether busy or idle) plus the effort to run the platform

Deploying:

az acr build --registry myacr --image my-api:1.0.0 .
az aks get-credentials --name my-aks --resource-group my-rg
kubectl apply -f deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata: { name: my-api }
spec:
  replicas: 3
  selector: { matchLabels: { app: my-api } }
  template:
    metadata: { labels: { app: my-api } }
    spec:
      containers:
      - name: my-api
        image: myacr.azurecr.io/my-api:1.0.0
        ports: [{ containerPort: 8080 }]
        readinessProbe: { httpGet: { path: /health, port: 8080 } }
        resources:
          requests: { cpu: 250m, memory: 256Mi }
          limits: { memory: 512Mi }

You'd also add a Service and an Ingress (for example, Application Gateway for Containers or NGINX), use workload identity for Azure access, and roll out with Helm or Flux/Argo CD.

Side-by-side

	App Service	AKS
Model	PaaS, you deploy an app	Managed Kubernetes, you run workloads
Packaging	Code or container	Container (required)
Operational effort	Low	High
Learning curve	Gentle	Steep
Scaling	Autoscale rules, per plan	Pod autoscaling (HPA/KEDA) plus node autoscaling
Zero-downtime release	Deployment slots	Rolling updates, canary, blue/green via ingress or mesh
Networking control	Moderate (VNet integration, private endpoints)	Very high (CNI options, network policies, service mesh)
Multi-service / microservices	Possible, one plan hosting many apps	Native fit
Cost model	Pay per plan	Pay for nodes, plus platform effort
Best for	Typical APIs and web apps	Large, complex, multi-service platforms

Other options worth considering

• Azure Container Apps: serverless containers built on Kubernetes (with KEDA and Dapr) but without cluster management. Supports scale-to-zero, revisions with traffic splitting, and event-driven scaling. For many teams it's the best middle ground between App Service and AKS.
• Azure Functions: for small, event-driven, or bursty APIs where per-execution billing and scale-to-zero make sense.
• App Service Environment (ASE v3): single-tenant, VNet-injected App Service for strict isolation and compliance needs.
• Azure Container Instances: simple, short-lived containers. Rarely the right choice for a production API on its own.
• Virtual Machines: only if you need OS-level control or have legacy requirements.

How to choose

• A single API or a handful, a small or mid-sized team, and you want to ship quickly → App Service
• Containerized microservices, but you don't want to run Kubernetes → Container Apps
• Spiky or event-driven workloads, minimal API surface → Functions
• Dozens of services, a platform team, a need for service mesh, operators, custom scheduling, or multi-cloud portability → AKS
• Strict network isolation or compliance requirements on a PaaS model → App Service Environment

A practical rule: start with App Service (or Container Apps) and move to AKS only when you hit a concrete limit. Teams often adopt AKS for the flexibility they imagine they'll need, then spend a lot of effort on cluster operations that App Service would have handled. Because both can run the same container image, moving later is less painful if you containerize from the start.

Cross-cutting concerns (the same on all of them)

• Use managed identity and Key Vault instead of stored credentials.
• Put APIM, Front Door, or Application Gateway in front for routing, WAF, and rate limiting.
• Send telemetry to Application Insights and define health checks and alerts.
• Deploy through CI/CD with infrastructure as code (Bicep or Terraform).

How do you implement CI/CD for a .NET application in Azure?

CI/CD for a .NET Application in Azure

CI (continuous integration) builds and tests every change automatically. CD (continuous delivery/deployment) ships the tested build through environments to production in a repeatable, low-risk way. The two common tool choices are GitHub Actions and Azure Pipelines (Azure DevOps). The structure is the same in both.

The pipeline shape

Commit/PR ─► Build ─► Test ─► Publish artifact ─► Deploy Dev ─► Deploy Staging ─► (approval) ─► Production
                                  (build once)                    (slot / test)                  (swap)

Principles:

• Build once, deploy the same artifact everywhere. Don't rebuild per environment. Differences come from configuration, not code.
• Run tests on every PR and block merges when they fail (branch protection).
• No stored credentials. Authenticate to Azure with OIDC (workload identity federation).
• Gate production with approvals and automated checks.

Option 1: GitHub Actions

One-time setup: passwordless Azure login

Create an app registration (or user-assigned managed identity), add a federated credential trusting your repo, and grant it a role on the target scope.

# App registration + service principal
az ad app create --display-name gh-deploy-my-app
az ad sp create --id <appId>

# Trust GitHub Actions for the main branch
az ad app federated-credential create --id <appId> --parameters '{
  "name": "gh-main",
  "issuer": "https://token.actions.githubusercontent.com",
  "subject": "repo:my-org/my-repo:environment:production",
  "audiences": ["api://AzureADTokenExchange"]
}'

# Least-privilege role at resource group scope
az role assignment create --assignee <appId> --role "Website Contributor" \
  --scope /subscriptions/<sub-id>/resourceGroups/my-rg

The subject must match how the workflow runs. For jobs using a GitHub environment, use environment:<name>. For branch-based runs, use ref:refs/heads/main. You need one federated credential per subject.

Store AZURE_CLIENT_ID, AZURE_TENANT_ID, and AZURE_SUBSCRIPTION_ID as repository secrets or variables. They're identifiers, not credentials.

Workflow

name: ci-cd

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

permissions:
  id-token: write   # needed for OIDC
  contents: read

jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.0.x'

      - run: dotnet restore
      - run: dotnet build --no-restore -c Release
      - run: dotnet test --no-build -c Release --logger trx --collect:"XPlat Code Coverage"

      - run: dotnet publish src/MyApi/MyApi.csproj -c Release -o ./publish --no-build

      - uses: actions/upload-artifact@v4
        with:
          name: api
          path: ./publish

  deploy-staging:
    needs: build-test
    if: github.ref == 'refs/heads/main'   # PRs build and test only
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/download-artifact@v4
        with: { name: api, path: ./publish }

      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      - uses: azure/webapps-deploy@v3
        with:
          app-name: my-api
          slot-name: staging
          package: ./publish

      - name: Smoke test
        run: curl --fail --retry 5 --retry-delay 5 https://my-api-staging.azurewebsites.net/health

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production        # configure required reviewers on this environment
    steps:
      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      - name: Swap staging into production
        run: |
          az webapp deployment slot swap \
            --name my-api --resource-group my-rg \
            --slot staging --target-slot production

Notes:

• GitHub Environments (staging, production) give you required reviewers, wait timers, and environment-scoped secrets.
• Deployment slots require Standard tier or above. Slot swaps warm up the staging instance first, so production sees no cold start.
• To roll back, swap again. The previous version is still sitting in the staging slot.

Option 2: Azure Pipelines (YAML)

Create a service connection to Azure using workload identity federation (the recommended option over secret-based connections).

trigger:
  branches:
    include: [main]

pool:
  vmImage: ubuntu-latest

variables:
  buildConfiguration: Release

stages:
- stage: Build
  jobs:
  - job: BuildTest
    steps:
    - task: UseDotNet@2
      inputs:
        packageType: sdk
        version: 8.0.x

    - script: dotnet restore
    - script: dotnet build --no-restore -c $(buildConfiguration)

    - task: DotNetCoreCLI@2
      displayName: Test
      inputs:
        command: test
        projects: '**/*Tests.csproj'
        arguments: '-c $(buildConfiguration) --no-build'

    - task: DotNetCoreCLI@2
      displayName: Publish
      inputs:
        command: publish
        publishWebProjects: true
        arguments: '-c $(buildConfiguration) -o $(Build.ArtifactStagingDirectory)'
        zipAfterPublish: true

    - publish: $(Build.ArtifactStagingDirectory)
      artifact: drop

- stage: Staging
  dependsOn: Build
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
  jobs:
  - deployment: DeployStaging
    environment: staging
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            inputs:
              azureSubscription: my-service-connection
              appType: webAppLinux
              appName: my-api
              deployToSlotOrASE: true
              resourceGroupName: my-rg
              slotName: staging
              package: $(Pipeline.Workspace)/drop/**/*.zip

- stage: Production
  dependsOn: Staging
  jobs:
  - deployment: DeployProd
    environment: production      # add Approvals and checks on this environment
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureAppServiceManage@0
            inputs:
              azureSubscription: my-service-connection
              action: Swap Slots
              webAppName: my-api
              resourceGroupName: my-rg
              sourceSlot: staging
              targetSlot: production

Azure DevOps Environments provide approvals, checks, and deployment history, the same role that GitHub Environments play.

Infrastructure as Code

Don't create Azure resources by hand. Define them in Bicep (or Terraform) and deploy them through the pipeline, so environments stay consistent and reviewable.

- uses: azure/arm-deploy@v2
  with:
    scope: resourcegroup
    resourceGroupName: my-rg
    template: ./infra/main.bicep
    parameters: ./infra/prod.bicepparam
    failOnStdErr: false

A common pattern is to deploy infrastructure first and the app second. Use what-if on pull requests to preview infrastructure changes before merging.

Database migrations

Don't let the app run migrations on startup in production. Prefer an explicit pipeline step:

# Idempotent SQL script, reviewable and safe to re-run
dotnet ef migrations script --idempotent -o migrate.sql \
  --project src/MyApi --startup-project src/MyApi

# Or a self-contained migration bundle
dotnet ef migrations bundle -o efbundle --project src/MyApi
./efbundle --connection "<connection-string>"

Authenticate to SQL with the pipeline's Entra identity rather than a password. Write migrations in an expand/contract style (add new columns and tables first, remove old ones later) so the previous version keeps working during a slot swap or rollback.

Configuration and secrets per environment

• Keep non-secret settings in app settings, applied per slot or environment. Mark settings that must not move during a swap as slot settings (sticky).
• Store secrets in Key Vault and use Key Vault references. Give the app a managed identity to read them.
• Never put secrets in the repo or the build artifact. Use environment-scoped secrets only for pipeline identifiers.
• Use Azure App Configuration with feature flags if you want to release code dark and enable features separately.

Containerized apps

If you deploy containers (Container Apps, AKS, App Service for Containers):

- run: |
    az acr login --name myacr
    docker build -t myacr.azurecr.io/my-api:${{ github.sha }} .
    docker push myacr.azurecr.io/my-api:${{ github.sha }}

- run: |
    az containerapp update --name my-api --resource-group my-rg \
      --image myacr.azurecr.io/my-api:${{ github.sha }}

Tag images with the commit SHA (never rely on latest), and give the app a managed identity with the AcrPull role. Container Apps revisions let you shift traffic gradually (blue/green or canary). For AKS, use Helm or GitOps (Flux/Argo CD).

Quality and safety gates

Add these as the pipeline matures:

• Static analysis and security: Roslyn analyzers, dotnet list package --vulnerable, Dependabot or Renovate, CodeQL, secret scanning, and container image scanning (Defender for Cloud).
• Integration tests against ephemeral resources (Testcontainers or a dedicated test environment).
• Post-deploy smoke tests and health checks, which block the swap if they fail.
• Load or performance checks on staging for critical paths.
• Automated rollback if post-release metrics or alerts degrade.
• Branch protection: required reviews, required status checks, and no direct pushes to main.

Good practices

• Keep pipelines in the repo (YAML), versioned and reviewed like code.
• Cache NuGet packages and use --no-restore and --no-build flags to speed up runs.
• Use reusable workflows or templates to share logic across services.
• Separate subscriptions or resource groups per environment, and use separate identities with least privilege for each.
• Version your builds (for example, with MinVer or the commit SHA) and surface the version in a /health or /version endpoint, so you can confirm what's running.
• Mark deployments in Application Insights (release annotations) so you can correlate regressions with releases.
• Prefer small, frequent releases over large batches. They're easier to test and roll back.

Minimal starting point:

1. Create a workflow that restores, builds, and tests on every PR.
2. Add OIDC-based Azure login and deploy to a staging slot on merge to main.
3. Add a smoke test and a manual approval on a production environment, then swap slots.
4. Move infrastructure into Bicep and deploy it from the pipeline.
5. Add security scanning, migrations as a controlled step, and alerts tied to releases.

Find employees who have the same salary as their manager.

To find employees who earn the exact same salary as their manager, you need to perform a Self-Join. This means you join the employees table to itself—treating one instance as the "Employee table" and the second instance as the "Manager table."

The Query

The join links the employee's manager_id to the manager's employee_id, and the WHERE clause filters for matching salary values:

sql

SELECT 
    e.employee_id AS emp_id,
    e.employee_name AS emp_name,
    e.salary AS emp_salary,
    m.employee_name AS manager_name,
    m.salary AS manager_salary
FROM employees e
INNER JOIN employees m ON e.manager_id = m.employee_id
WHERE e.salary = m.salary;

Use code with caution.

How It Works

• employees e: Represents the table context looking down at the regular employees.
• employees m: Represents the table context looking up at the managers.
• ON e.manager_id = m.employee_id: Establishes the relationship path between the employee and their boss.
• WHERE e.salary = m.salary: Isolates the records where both parties make the exact same amount of money.

---

Complete Playground Script (Schema + Test Data)

Copy and execute this script to test the logic live:

sql

-- 1. CREATE TABLE SCHEMA
CREATE TABLE employees (
    employee_id INT PRIMARY KEY,
    employee_name VARCHAR(100),
    salary DECIMAL(10, 2),
    manager_id INT,
    FOREIGN KEY (manager_id) REFERENCES employees(employee_id)
);

-- 2. INSERT SAMPLE DATA
-- Top levels (No managers)
INSERT INTO employees (employee_id, employee_name, salary, manager_id) VALUES
(1, 'Fiona Gallagher', 120000.00, NULL), -- CEO
(2, 'Alice Smith', 95000.00, NULL);     -- VP

-- Reports
INSERT INTO employees (employee_id, employee_name, salary, manager_id) VALUES
(3, 'Bob Jones', 75000.00, 1),      -- Reports to Fiona (Diff Salary)
(4, 'Charlie Brown', 95000.00, 2),  -- Reports to Alice (SAME Salary - Matches!)
(5, 'Diana Prince', 95000.00, 2),   -- Reports to Alice (SAME Salary - Matches!)
(6, 'Evan Wright', 60000.00, 3);    -- Reports to Bob (Diff Salary)

-- 3. EXECUTE THE SELF-JOIN QUERY
SELECT 
    e.employee_name AS employee_name,
    e.salary AS employee_salary,
    m.employee_name AS manager_name
FROM employees e
INNER JOIN employees m ON e.manager_id = m.employee_id
WHERE e.salary = m.salary;

Use code with caution.

Expected Query Output

employee_name	employee_salary	manager_name
Charlie Brown	95000.00	Alice Smith
Diana Prince	95000.00	Alice Smith

How do you troubleshoot a production API issue in Azure?

Troubleshooting a Production API Issue in Azure

The goal is to stabilize first, diagnose second, fix third. Work from the outside in: is it the platform, the network, your code, or a dependency?

1. Triage (first 5 minutes)

Establish the facts before touching anything:

• What is the symptom? Errors (5xx/4xx), slowness, timeouts, or total outage?
• Scope: all users or some? All endpoints or one? One region or instance, or everywhere?
• When did it start? Line it up against deployments, config changes, certificate expiries, and traffic spikes. Most incidents trace back to a recent change.
• Is it Azure? Check Azure Service Health and Resource Health for your subscription and the specific resource. Platform incidents and maintenance show up here.

If a recent deployment is the likely cause, roll back first and investigate later. With deployment slots, swap back. That's the fastest mitigation you have.

2. Check the golden signals in Application Insights

Open Application Insights and go through these in order:

• Failures blade: which operations and exception types are spiking, with sample failed requests.
• Performance blade: which operations got slower, and whether the time is in your code or in a dependency.
• Application Map: which node is red (slow or failing). This shows quickly whether the API or something it calls is at fault.
• Live Metrics: real-time view while you test or mitigate.
• End-to-end transaction details: follow a single failed request through all services using its operation ID.

Useful KQL:

// Failure trend by result code
requests
| where timestamp > ago(2h)
| summarize total = count(), failed = countif(success == false) by bin(timestamp, 5m)
| extend failureRate = todouble(failed) / total
| render timechart

// Is it a dependency?
dependencies
| where timestamp > ago(2h) and success == false
| summarize count() by target, type, resultCode
| order by count_ desc

// Latency percentiles by operation
requests
| where timestamp > ago(2h)
| summarize p50 = percentile(duration, 50), p95 = percentile(duration, 95), count() by name
| order by p95 desc

// Top exceptions
exceptions
| where timestamp > ago(2h)
| summarize count() by type, outerMessage
| order by count_ desc

Compare the bad period against the same time yesterday or last week to separate real regressions from normal patterns.

3. Narrow down by symptom

Symptom	Likely causes	Where to look
500s after a deploy	Bug, missing config, bad migration	Exceptions, deployment history, diff of app settings
500s / timeouts, no deploy	Failing dependency (SQL, Redis, downstream API), expired secret or cert	Dependencies table, Application Map
401/403	Expired token or secret, changed app role or RBAC, clock/audience mismatch, rotated key	Entra sign-in logs, role assignments, Key Vault access logs
429	Throttling by a downstream service (Cosmos DB RU limits, Key Vault, Storage) or by APIM	Response headers, service metrics
502/503/504	App crashing or restarting, instances unhealthy, gateway timeout (App Gateway/Front Door ~230s limit on App Service)	Health check status, restarts, Diagnose and solve problems
Slow responses	Slow SQL queries, cold starts, thread pool starvation, CPU/memory pressure, chatty calls	Performance blade, dependency durations, App Service metrics
Intermittent failures	One bad instance, SNAT port exhaustion, transient faults without retries, DNS issues	Per-instance breakdown (cloud_RoleInstance), connection metrics
Works in one place, not another	NSG/firewall/private endpoint/DNS change	Network diagnostics (below)

4. Platform-level diagnostics

App Service / Functions:

• Diagnose and solve problems blade: guided detectors for HTTP 5xx, high CPU, memory, slow requests, SNAT exhaustion, and app crashes. Start here when the cause isn't obvious.
• Metrics: CPU, memory working set, requests, response time, HTTP 5xx, and instance count. Look for saturation or a scale-out that didn't happen.
• Log stream for live output: az webapp log tail --name my-app --resource-group my-rg
• Kudu (SCM) console for process explorer, environment variables, and crash dumps.
• Health check: verify the path is configured and which instances are being removed from rotation.

Containers / AKS / Container Apps:

• kubectl get pods, kubectl describe pod, kubectl logs --previous for restart loops (CrashLoopBackOff, OOMKilled).
• Check readiness and liveness probes, resource limits, and node health.
• For Container Apps, use the Log stream and ContainerAppConsoleLogs / ContainerAppSystemLogs tables.

APIM / Front Door / Application Gateway (if in front):

• Check whether failures originate at the gateway or the backend. Gateway logs show backend response codes, backend time vs. total time, and WAF blocks.
• A WAF rule or rate limit blocking legitimate traffic often looks like an app problem.

5. Check dependencies

Most production API incidents originate in something the API calls:

• Azure SQL: Query Performance Insight, blocking and deadlocks, DTU/vCore saturation, connection limits, failover events. Check whether a new query plan or missing index is the cause.
• Cosmos DB: 429s and RU consumption, hot partitions.
• Service Bus / Event Hubs: growing queue depth, dead-letter counts, lock-expired errors, throttling.
• Key Vault: throttling, or access denied after a role or network change.
• Redis: memory pressure, evictions, connection limits.
• Storage: throttling and latency metrics.
• Third-party APIs: check their status pages and your outgoing call durations.

6. Network and connectivity

If the app can't reach something or can't be reached:

• Network Watcher: Connection troubleshoot, IP flow verify, and NSG flow logs show whether a rule is dropping traffic.
• DNS: private endpoints need correct private DNS zone links. From Kudu, run nameresolver <host> and tcpping <host:port> (on Windows App Service).
• Firewall and access restrictions: recent changes to storage, SQL, or Key Vault firewalls often cause sudden 403s or timeouts.
• SNAT port exhaustion: many outbound connections to the same endpoint can exhaust ports. Reuse HttpClient through IHttpClientFactory, use connection pooling, or add a NAT Gateway.
• TLS and certificates: expired or rotated certificates cause sudden handshake failures.

7. Compare against change history

Ask "what changed?" and verify it from records, not memory:

• Activity Log: shows control-plane changes (config updates, scaling, role assignments, deployments, key rotations). Filter by time window around the incident start.
• Deployment history / CI-CD pipeline runs and any app setting changes.
• Entra audit logs: app registration, secret, or permission changes.
• Resource Graph or Change Analysis (in Diagnose and solve problems) to see configuration diffs.

8. Go deeper when needed

• Memory or CPU issues: capture a memory dump or profiler trace through Diagnose and solve problems (Collect Memory Dump, Profiler) or dotnet-dump/dotnet-trace in containers.
• Thread pool starvation (common with sync-over-async): look for rising response times with low CPU, and check ThreadPool metrics in Application Insights or dotnet-counters.
• Reproduce in a lower environment using the same request payload and the operation ID details from the failure.
• Increase logging temporarily for the affected component, then revert it. Sampling can hide rare failures, so check whether it's dropping the data you need.

9. Mitigate while you investigate

• Roll back or swap slots.
• Scale up/out if it's resource saturation (buys time, doesn't fix the cause).
• Restart the app or a single bad instance as a last resort. Note the time and capture evidence first, because a restart destroys state.
• Disable the faulty feature with a feature flag, or route traffic away (Front Door / Traffic Manager) from an unhealthy region.
• Add retries with backoff and circuit breakers (Polly, or Microsoft.Extensions.Http.Resilience) if a dependency is flaky.
• Communicate: post status updates early, even if the cause is unknown.

10. Afterwards

• Write a blameless post-incident review: timeline, root cause, detection gap, and action items.
• Add the missing alert that would have caught it sooner (failure rate, p95 latency, dependency failures, queue depth, certificate and secret expiry).
• Add health checks, synthetic availability tests (Standard tests), and dashboards for the signals you had to hunt for.
• Make the fix safer to ship: deployment slots, canary releases, automated rollback, and load testing for the failure mode.

Quick checklist:

1. Check Service Health and recent changes (deploys, config, secrets, certs).
2. Open Application Insights: Failures, Performance, Application Map.
3. Decide: my code, a dependency, or the platform/network?
4. Pull logs and traces for a single failing operation ID.
5. Mitigate (rollback, scale, failover) before the deep dive if users are affected.
6. Confirm recovery from the metrics, then run the post-incident review.

How do you implement logging and monitoring using Application Insights?

Logging and Monitoring with Application Insights

Application Insights is the application performance monitoring (APM) feature of Azure Monitor. It collects requests, dependencies (SQL, HTTP, Service Bus), exceptions, traces, custom metrics, and custom events, and gives you tools to query, visualize, and alert on them.

Current Application Insights resources are workspace-based: the data is stored in a Log Analytics workspace, so you can query it alongside other Azure logs with KQL. Classic (non-workspace) resources are retired, so create new ones as workspace-based.

1. Create the resource

az monitor log-analytics workspace create \
  --resource-group my-rg --workspace-name my-logs --location centralindia

az monitor app-insights component create \
  --app my-app-insights --resource-group my-rg --location centralindia \
  --workspace my-logs --kind web

Get the connection string (use this, not the old instrumentation key alone):

az monitor app-insights component show --app my-app-insights \
  --resource-group my-rg --query connectionString -o tsv

2. Instrument a .NET app

There are two options. Microsoft's recommended path for new ASP.NET Core apps is the Azure Monitor OpenTelemetry Distro, which replaces the older Application Insights SDK as the main approach. The classic SDK still works and is fine for existing apps.

Option A: Azure Monitor OpenTelemetry (recommended)

dotnet add package Azure.Monitor.OpenTelemetry.AspNetCore

using Azure.Monitor.OpenTelemetry.AspNetCore;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddOpenTelemetry().UseAzureMonitor();

var app = builder.Build();

Set the connection string via configuration (not in code):

APPLICATIONINSIGHTS_CONNECTION_STRING=InstrumentationKey=...;IngestionEndpoint=https://...

This automatically collects incoming requests, outgoing HTTP calls, SQL calls, exceptions, ILogger output, and performance counters.

Option B: Classic Application Insights SDK

dotnet add package Microsoft.ApplicationInsights.AspNetCore

builder.Services.AddApplicationInsightsTelemetry();

Again, provide APPLICATIONINSIGHTS_CONNECTION_STRING through app settings or environment variables.

Azure Functions (isolated worker)

dotnet add package Microsoft.Azure.Functions.Worker.ApplicationInsights

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services =>
    {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .Build();

Note that the isolated worker applies a default logging filter that can hide Information logs from your code. If your logs are missing, remove it in ConfigureLogging.

App Service with no code changes

For App Service, you can enable Application Insights under the app's Monitoring blade (auto-instrumentation, "codeless"). It's the quickest start, but code-based instrumentation gives you more control for custom telemetry.

3. Logging with ILogger

Use the standard .NET ILogger<T>. Application Insights captures it automatically, and your structured properties become searchable custom dimensions.

public class OrdersController : ControllerBase
{
    private readonly ILogger<OrdersController> _logger;

    public OrdersController(ILogger<OrdersController> logger) => _logger = logger;

    [HttpPost]
    public IActionResult Create(Order order)
    {
        _logger.LogInformation("Creating order {OrderId} for customer {CustomerId}",
            order.Id, order.CustomerId);
        try
        {
            // ...
            return Ok();
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Failed to create order {OrderId}", order.Id);
            throw;
        }
    }
}

Use message templates with named placeholders, not string interpolation. Templates keep the properties as structured fields you can filter on.

Set log levels in appsettings.json. Note the provider-specific section so you control what is sent to Application Insights:

{
  "Logging": {
    "LogLevel": { "Default": "Information", "Microsoft.AspNetCore": "Warning" },
    "ApplicationInsights": { "LogLevel": { "Default": "Information" } }
  }
}

4. Custom telemetry

Events and metrics (with the OpenTelemetry distro, use System.Diagnostics.Metrics; with the classic SDK, use TelemetryClient):

// Custom metric with OpenTelemetry / .NET Meter
static readonly Meter Meter = new("MyApp.Orders");
static readonly Counter<long> OrdersCreated = Meter.CreateCounter<long>("orders_created");

OrdersCreated.Add(1, new KeyValuePair<string, object?>("region", "EU"));

Register the meter so it's exported:

builder.Services.AddOpenTelemetry()
    .UseAzureMonitor()
    .WithMetrics(m => m.AddMeter("MyApp.Orders"));

// Classic SDK
_telemetryClient.TrackEvent("OrderPlaced",
    new Dictionary<string, string> { ["region"] = "EU" });
_telemetryClient.GetMetric("OrderValue").TrackValue(order.Total);

Custom spans (distributed tracing) with ActivitySource:

static readonly ActivitySource Source = new("MyApp.Orders");

using var activity = Source.StartActivity("ProcessPayment");
activity?.SetTag("order.id", order.Id);

Register it with .WithTracing(t => t.AddSource("MyApp.Orders")).

5. Distributed tracing across services

Application Insights correlates calls across services using the W3C traceparent header. Requests, dependencies, logs, and exceptions that belong to one operation share an operation ID, so you can follow a single user action across APIs, queues, and functions. Use Application Map and the End-to-end transaction details view to see this visually. Service Bus and HTTP calls propagate context automatically with the standard Azure SDKs.

Set a meaningful cloud role name so each service appears as its own node on the map:

builder.Services.AddOpenTelemetry()
    .ConfigureResource(r => r.AddService("orders-api"))
    .UseAzureMonitor();

6. Querying with KQL

In Application Insights → Logs (or the Log Analytics workspace):

// Failed requests in the last hour
requests
| where timestamp > ago(1h) and success == false
| summarize count() by resultCode, name
| order by count_ catch desc

Correction: catch isn't valid KQL there. The correct form is:

requests
| where timestamp > ago(1h) and success == false
| summarize failures = count() by resultCode, name
| order by failures desc

// Slowest operations (p95)
requests
| where timestamp > ago(24h)
| summarize p95 = percentile(duration, 95) by name
| order by p95 desc

// Exceptions with context
exceptions
| where timestamp > ago(24h)
| project timestamp, type, outerMessage, operation_Id, cloud_RoleName

// All telemetry for one operation
union requests, dependencies, traces, exceptions
| where operation_Id == "<id>"
| order by timestamp asc

// Slow or failing dependencies (SQL, HTTP, Service Bus)
dependencies
| where timestamp > ago(24h) and success == false
| summarize count() by target, type

Note: in a workspace-based resource queried from the Log Analytics workspace, the table names are AppRequests, AppDependencies, AppExceptions, AppTraces, and so on, with different column names (TimeGenerated, DurationMs). Queries from the Application Insights Logs blade use the classic names shown above.

7. Monitoring features worth using

• Live Metrics: near-real-time view of requests, failures, and CPU while you deploy or debug.
• Application Map: dependency graph with failure and latency per link.
• Failures and Performance blades: group exceptions and slow operations, then drill into samples.
• Availability tests: synthetic checks from multiple regions (URL ping is being replaced by Standard tests; use those).
• Smart detection: automatic anomaly alerts for failure-rate and latency changes.
• Workbooks and dashboards: shared visual reports built from KQL.
• Profiler and Snapshot Debugger: deeper diagnostics for slow code and exceptions (primarily classic SDK and App Service scenarios).

8. Alerts

Create alert rules on metrics or on KQL queries, and route them to an action group (email, SMS, Teams, webhook, Logic App).

az monitor metrics alert create \
  --name high-failed-requests --resource-group my-rg \
  --scopes <app-insights-resource-id> \
  --condition "count requests/failed > 10" \
  --window-size 5m --evaluation-frequency 1m \
  --action <action-group-id>

Typical alerts: failed request spike, p95 latency above a threshold, exceptions rate, availability test failures, and dependency failures. Prefer log-based alerts for business conditions (e.g., no orders in 30 minutes).

9. Cost and data control

Application Insights is billed by data ingested (GB) to the workspace, so control volume deliberately:

• Sampling: adaptive sampling is on by default in the classic SDK. With OpenTelemetry, set SamplingRatio (or use rate-limited sampling) in AzureMonitorOptions. Sampled telemetry keeps correlated items together.
• Log levels: don't send Debug or Trace in production, and raise noisy framework categories to Warning.
• Daily cap: set a cap on the workspace as a safety net, knowing that data stops being collected when it's hit.
• Retention: default is 90 days for Application Insights tables (30 days for Log Analytics generally); extend or archive only what you need.
• Filter noise: drop health-check requests and static files with a processor or filter.

10. Security and good practice

• Never log secrets or PII (tokens, passwords, card numbers, full emails). Sanitize or omit them before logging.
• Use Entra authentication for ingestion (DefaultAzureCredential with the Monitoring Metrics Publisher role) and disable local (key-based) auth, so a leaked connection string can't be used to inject fake telemetry.
• Use RBAC to control who can read logs (Log Analytics Reader, Monitoring Reader).
• Use private link (Azure Monitor Private Link Scope) if telemetry must stay off the public internet.
• Use consistent correlation: include IDs such as OrderId in log templates so you can search by business key.
• One resource per environment (or at least distinct cloud role names and an environment dimension) so dev noise doesn't pollute production.

Enabling Entra ingestion with the OpenTelemetry distro:

builder.Services.AddOpenTelemetry().UseAzureMonitor(o =>
{
    o.Credential = new DefaultAzureCredential();
});

Minimal setup checklist

1. Create a workspace-based Application Insights resource.
2. Add Azure.Monitor.OpenTelemetry.AspNetCore and call UseAzureMonitor(), with the connection string in app settings.
3. Log through ILogger with structured templates.
4. Set the service name so Application Map shows each service.
5. Add alerts for failures, latency, and availability.
6. Configure sampling, log levels, and a daily cap to control cost.

How do you implement authentication using Entra ID, OAuth, and JWT?

Authentication with Entra ID, OAuth 2.0, and JWT

These three pieces fit together as follows:

• Microsoft Entra ID is the identity provider (IdP). It authenticates users and apps and issues tokens.
• OAuth 2.0 is the authorization framework: how a client gets permission to call an API on behalf of a user or as itself.
• OpenID Connect (OIDC) is a layer on OAuth 2.0 for sign-in. It adds an ID token that tells your app who the user is.
• JWT is the token format. Entra issues access tokens and ID tokens as signed JSON Web Tokens.

Access tokens are for APIs ("this caller may do X"). ID tokens are for the client app ("this user signed in"). Never send an ID token to an API.

1. Choose the flow

Scenario	Flow
SPA or mobile app, user signs in, calls your API	Authorization code + PKCE
Server-side web app with user sign-in	Authorization code (with a client secret or certificate)
Service-to-service, no user (daemon, background job)	Client credentials
API calls another API as the signed-in user	On-behalf-of (OBO)

Avoid the implicit flow and the password (ROPC) flow. Both are legacy and discouraged.

2. Register the apps in Entra ID

You typically register two apps: one for the API and one for the client.

API registration:

1. Go to Entra ID → App registrations → New registration.
2. Under Expose an API, set the Application ID URI (e.g. api://<api-client-id>) and add a scope such as access_as_user for delegated (user) permissions.
3. Under App roles, add roles such as Orders.Read for app-only callers (and for user roles).
4. In the manifest, make sure requestedAccessTokenVersion is 2 so you get v2.0 tokens.

Client registration:

1. Add a redirect URI. Use the SPA platform for SPAs, which enables PKCE, or Web for server apps.
2. Under API permissions, add your API's scope or role and grant admin consent if needed.
3. For confidential clients, add a certificate (preferred) or client secret under Certificates & secrets.

3. Protect an ASP.NET Core API (validate JWTs)

dotnet add package Microsoft.Identity.Web

appsettings.json:

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "<tenant-id>",
    "ClientId": "<api-client-id>",
    "Audience": "api://<api-client-id>"
  }
}

Program.cs:

using Microsoft.Identity.Web;

var builder = WebApplication.CreateBuilder(args);

builder.Services
    .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"));

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("OrdersRead", p => p.RequireRole("Orders.Read"));
});

var app = builder.Build();

app.UseAuthentication();
app.UseAuthorization();

app.MapControllers();
app.Run();

Controller:

[Authorize]
[ApiController]
[Route("api/orders")]
public class OrdersController : ControllerBase
{
    // Delegated (user) token: check the scope claim
    [HttpGet]
    [RequiredScope("access_as_user")]
    public IActionResult GetMine() => Ok(new { user = User.Identity?.Name });

    // App-only token (client credentials): check the roles claim
    [HttpGet("all")]
    [Authorize(Policy = "OrdersRead")]
    public IActionResult GetAll() => Ok();
}

User tokens carry scopes in the scp claim, and app-only tokens carry app roles in the roles claim. Check the right one for the flow you expect.

4. Sign users in to a web app (OIDC)

builder.Services
    .AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd"))
    .EnableTokenAcquisitionToCallDownstreamApi(new[] { "api://<api-client-id>/access_as_user" })
    .AddInMemoryTokenCaches();

Inject ITokenAcquisition to get an access token for the signed-in user and call your API:

var token = await _tokenAcquisition.GetAccessTokenForUserAsync(
    new[] { "api://<api-client-id>/access_as_user" });

_http.DefaultRequestHeaders.Authorization =
    new AuthenticationHeaderValue("Bearer", token);

For a SPA, use MSAL.js (@azure/msal-browser, or @azure/msal-react / @azure/msal-angular). It handles the code + PKCE flow, token caching, and silent refresh:

const msal = new PublicClientApplication({
  auth: { clientId: "<spa-client-id>", authority: "https://login.microsoftonline.com/<tenant-id>" }
});

const result = await msal.acquireTokenPopup({
  scopes: ["api://<api-client-id>/access_as_user"]
});

fetch("https://my-api/api/orders", {
  headers: { Authorization: `Bearer ${result.accessToken}` }
});

5. Service-to-service (client credentials)

When there's no user, the caller authenticates as itself. Always request the .default scope, which returns the app roles granted to that client:

var credential = new DefaultAzureCredential(); // managed identity in Azure

var token = await credential.GetTokenAsync(
    new TokenRequestContext(new[] { "api://<api-client-id>/.default" }));

Prefer a managed identity over a client secret. Assign the API's app role to the managed identity's service principal (via Graph, PowerShell, or Azure CLI). Outside Azure, use ConfidentialClientApplication from Microsoft.Identity.Client with a certificate.

6. What your API must validate in a JWT

A JWT has three base64url parts, header.payload.signature. AddMicrosoftIdentityWebApi does the following for you, but you should know what's being checked:

• Signature: verified using Entra's public signing keys, fetched from the OIDC metadata endpoint (.../.well-known/openid-configuration → jwks_uri) and cached and rotated automatically.
• iss (issuer): must be your tenant, e.g. https://login.microsoftonline.com/<tenant-id>/v2.0.
• aud (audience): must be your API (its client ID or Application ID URI). A token meant for another API must be rejected.
• exp / nbf: token is within its validity window (access tokens last roughly 60 to 90 minutes).
• scp or roles: the caller has the permission required for this operation.
• tid: for multi-tenant APIs, check that the tenant is one you allow.

Key claims you'll use: oid (user or service principal object ID), sub, tid, scp, roles, preferred_username, appid/azp (the calling client).

If you ever need manual configuration without Microsoft.Identity.Web:

.AddJwtBearer(o =>
{
    o.Authority = "https://login.microsoftonline.com/<tenant-id>/v2.0";
    o.TokenValidationParameters = new()
    {
        ValidAudience = "api://<api-client-id>",
        ValidateIssuer = true,
        ValidateAudience = true,
        ValidateLifetime = true
    };
});

7. Common pitfalls

• Mixing up token types: APIs accept access tokens only, never ID tokens.
• Wrong audience or token version: a v1 token has a different iss and aud format than v2, so set the API's accepted token version to match your validation.
• Checking only authentication: a valid token isn't enough. Always check scopes or roles, otherwise any app in your tenant that can get a token for your API is authorized.
• Storing tokens in localStorage: this exposes them to XSS. Let MSAL manage caching, or use a backend-for-frontend (BFF) with HttpOnly cookies.
• Client secrets in code or SPAs: public clients (SPAs, mobile) can't keep secrets, which is why they use PKCE.
• Decoding without validating: reading claims from a JWT without verifying its signature proves nothing.
• Forgetting admin consent for application permissions, which causes 403s.
• Rolling your own JWT handling: use MSAL and Microsoft.Identity.Web rather than hand-parsing tokens and keys.

8. Alternative: let Azure handle it (Easy Auth)

On App Service or Azure Functions, built-in authentication validates the token before your code runs and passes claims to your app via headers (X-MS-CLIENT-PRINCIPAL). It's the least-code option, though you get less control over fine-grained authorization than with middleware in your own code.

Summary

1. Register an API (with scopes and app roles) and a client in Entra ID.
2. Use auth code + PKCE for users and client credentials (ideally with a managed identity) for services.
3. The client acquires an access token via MSAL and sends it as Authorization: Bearer <token>.
4. The API validates the JWT (signature, issuer, audience, expiry) and enforces scopes/roles.