Azure DevOps Interview Questions 2026: The Complete Guide

Azure is the second-largest cloud platform, and companies running Windows workloads, .NET applications, and hybrid environments lean heavily on it. Here are the 20 questions that consistently come up in Azure DevOps interviews in 2026.

Section 1: Azure Pipelines & CI/CD

1. What is the difference between Azure Pipelines and GitHub Actions?

Why they ask this: They want to know if you understand when to choose each tool — not just that you've used them.

Ideal answer:

Both are YAML-based CI/CD platforms, but they differ in integration and ecosystem.

Azure Pipelines is part of Azure DevOps — it integrates natively with Azure Boards, Azure Repos, Azure Artifacts, and Azure Test Plans. It supports multi-stage pipelines, environments with approval gates, and complex deployment strategies. Best for enterprises already in the Azure ecosystem.

GitHub Actions lives in your repository and triggers on any GitHub event. Has a massive community marketplace. Simpler DX for open-source projects. Less mature for multi-stage enterprise deployments.

Decision framework:

• Azure DevOps-heavy shops → Azure Pipelines
• GitHub-native teams → GitHub Actions
• Many teams run GitHub Actions for CI, Azure Pipelines for CD

Follow-up: "Can they work together?" Yes — GitHub Actions can trigger Azure Pipelines via REST API and vice versa through service connections.

2. Explain multi-stage pipelines in Azure DevOps

Why they ask this: Multi-stage is the production-grade pattern — they want to see you've built real deployment pipelines, not just simple CI.

Ideal answer:

Multi-stage pipelines model your entire CI/CD workflow as a single YAML file with distinct stages: Build → Test → Deploy Dev → Deploy Staging → Deploy Production.

Key concepts:

• Stages contain jobs. Each stage can depend on previous ones.
• Environments define deployment targets with approval gates and deployment history.
• Approval gates allow human sign-off before critical stages proceed.
• Deployment strategies: runOnce, rolling, canary, blueGreen.

stages:
- stage: Build
  jobs:
  - job: BuildApp
    steps:
    - script: npm run build
- stage: DeployProd
  dependsOn: DeployStaging
  condition: succeeded()
  jobs:
  - deployment: ProdDeploy
    environment: production
    strategy:
      runOnce:
        deploy:
          steps: [...]

What impresses interviewers: Mentioning that environments track deployment history and can enforce branch policies — so only the main branch can deploy to production.

3. How do you manage secrets in Azure Pipelines?

Why they ask this: Secret management is a security concern. They want to see you don't hardcode credentials or expose them in logs.

Ideal answer:

Option 1: Azure Key Vault integration (recommended)

Link a Key Vault to your pipeline via variable group. Secrets are fetched at runtime — never stored in pipeline YAML. Access is controlled via Azure AD managed identity or service principal.

variables:
- group: MyKeyVaultGroup  # backed by Azure Key Vault

Option 2: Pipeline secret variables

Mark variables as secret in the pipeline UI. They're encrypted at rest, masked in logs, but live in Azure DevOps — acceptable for non-sensitive values.

Option 3: Service connections

For cloud auth (deploying to Azure, pushing to ACR), use service connections backed by managed identities. Never embed service principal credentials directly in YAML.

What to never do: Print secret values in scripts, echo them in debug output, or store them in YAML committed to source control.

4. What is a service connection in Azure DevOps?

Ideal answer:

A service connection stores credentials to external systems (Azure subscription, GitHub, Docker Hub, Kubernetes cluster) securely in Azure DevOps. Pipelines reference the connection by name — credentials are never exposed in YAML.

Types commonly used:

• Azure Resource Manager: Deploys to Azure. Supports managed identity, service principal, workload identity federation.
• Docker Registry: Push images to ACR or Docker Hub.
• Kubernetes: Deploy to AKS clusters.
• Generic: HTTP connections to any external API.

Best practice in 2026: Use workload identity federation instead of service principal client secrets — it eliminates secret rotation entirely and is significantly more secure.

Section 2: Azure Kubernetes Service (AKS)

5. How does AKS differ from self-managed Kubernetes?

Why they ask this: They want to know what Azure manages for you vs what you're still responsible for.

Ideal answer:

AKS is a managed control plane service. Azure manages the Kubernetes API server, etcd, and control plane nodes — you only pay for and manage worker nodes.

What Azure handles:

• Control plane HA (3 replicas across AZs in paid tier)
• Kubernetes version upgrades
• Certificate rotation and etcd backups
• Integration with Azure AD, Azure Monitor, Azure CNI

What you still own:

• Node pool sizing, scaling, OS patching
• Application workloads and namespaces
• Network policies and ingress configuration
• Node pool upgrades (though Azure can automate these)

Key AKS-specific features: Node pools (system vs user), Spot node pools, KEDA event-driven autoscaling, Azure AD Workload Identity for pod-level auth.

6. Explain AKS networking: kubenet vs Azure CNI

Ideal answer:

Kubenet (basic networking):

Nodes get IPs from the VNet subnet. Pods get IPs from a private overlay network — not routable from outside the cluster. NAT is required for cross-node pod communication. Simpler but limited connectivity.

Azure CNI (advanced networking):

Every pod gets an IP address from the VNet subnet. Pods are directly addressable within the VNet — Azure services, on-premises networks, and peered VNets can reach pods directly. Requires more pre-allocated IP addresses per node.

Decision:

• Azure CNI when you need direct pod connectivity from Azure services or on-premises
• Kubenet for simpler setups where pod-level VNet addressing isn't needed

Azure CNI Overlay (newer): Pods use overlay IPs but route through Azure's network — best of both worlds without consuming VNet IP space.

7. How do you handle persistent storage in AKS?

Ideal answer:

AKS supports several storage options via CSI (Container Storage Interface) drivers:

Azure Disk (ReadWriteOnce):

Backed by Azure Managed Disks. For databases or single-pod stateful workloads. Dynamic provisioning via StorageClass. Not shareable across multiple pods.

Azure Files (ReadWriteMany):

Backed by Azure Files (SMB/NFS). Shareable across multiple pods simultaneously. Use for shared config or multi-pod applications.

Azure Blob (ReadWriteMany):

Via BlobFuse CSI driver. Large object storage. Good for AI/ML data pipelines and media assets.

Production patterns:

• Use Premium_LRS StorageClass for production databases
• Set reclaimPolicy: Retain for production PVCs — don't lose data on pod deletion
• Use Velero for PV backup and disaster recovery

Section 3: ARM Templates & Bicep

8. ARM templates vs Bicep: when do you use each?

Why they ask this: They want to see you know modern Azure IaC practices.

Ideal answer:

ARM templates are verbose JSON-based declarative templates for deploying Azure resources. Hard to read, difficult to modularize. The underlying format Azure always uses — everything compiles down to ARM.

Bicep is a DSL that compiles to ARM JSON. Cleaner syntax, better IntelliSense, native module support, no state files (unlike Terraform).

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: storageAccountName
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}

When to use what:

• Bicep: New projects, Azure-only teams, want ARM integration without Terraform complexity
• Terraform: Multi-cloud, team already invested in Terraform, need state management
• ARM templates: Legacy codebase, compliance mandating ARM format

9. How do you handle Bicep module dependencies and ordering?

Ideal answer:

Bicep handles dependencies in two ways:

Implicit dependencies: When one resource references another, Bicep automatically infers deployment order.

resource vnet 'Microsoft.Network/virtualNetworks@2022-07-01' = { ... }
resource subnet 'Microsoft.Network/virtualNetworks/subnets@2022-07-01' = {
  parent: vnet  // vnet deploys first automatically
}

Explicit dependencies: Use dependsOn when there's no reference relationship but ordering still matters.

Modules: Break large deployments into reusable Bicep files. Pass outputs between modules for chaining.

module networking 'modules/vnet.bicep' = { ... }
module aks 'modules/aks.bicep' = {
  params: {
    vnetId: networking.outputs.vnetId  // implicit dep on networking module
  }
}

10. What is Azure Resource Manager and how does it work?

Ideal answer:

ARM is the management layer for all Azure resources. Every action — via portal, CLI, PowerShell, Terraform, or Bicep — goes through ARM.

How it works:

1. You submit a request (ARM template, CLI command, API call)

2. ARM authenticates via Azure AD

3. ARM authorizes via RBAC

4. ARM routes to the appropriate resource provider (Microsoft.Compute, Microsoft.Network, etc.)

5. Resource provider creates/updates/deletes the resource

Key concepts:

• Resource Groups: Logical containers with shared lifecycle
• Resource providers: Service teams handling specific resource types
• Deployments: Tracked executions with history and rollback capability
• Locks: Read-only or delete locks to prevent accidental changes

Idempotency: ARM deployments are idempotent — same template run twice won't create duplicates. In Complete mode, ARM deletes resources not present in the template.

Section 4: Azure Monitor & Observability

11. How do you set up monitoring for AKS?

Ideal answer:

Container Insights is the primary monitoring solution for AKS. It collects node CPU/memory/disk, pod and container resource usage, live log streaming, and performance charts.

Enable via: az aks enable-addons --addons monitoring

Log Analytics Workspace receives all metrics and logs. Use KQL to query:

ContainerLog
| where LogEntry contains "ERROR"
| project TimeGenerated, ContainerID, LogEntry
| limit 100

Production monitoring stack:

1. Container Insights for cluster health

2. Azure Managed Prometheus for custom application metrics

3. Azure Managed Grafana for dashboards

4. Log Analytics for log aggregation and alerting

5. Diagnostic settings → Storage for long-term retention

12. Explain Azure Monitor vs Application Insights

Ideal answer:

Azure Monitor is the umbrella observability platform. Collects metrics, logs, and traces from all Azure resources, VMs, containers, and custom sources.

Application Insights is an APM service within Azure Monitor, focused on your application code:

• Request rates and response times
• Dependency calls (DB, external APIs)
• Exception tracking with stack traces
• Custom events and metrics via SDK
• Distributed tracing across microservices

Relationship: Application Insights data lands in a Log Analytics Workspace, which is part of Azure Monitor. All telemetry is queryable via KQL in one place.

When to use each:

• Azure Monitor: Infrastructure health, resource metrics, platform-level observability
• Application Insights: Code-level observability, user journey tracking, frontend + backend correlation

Section 5: Azure Security & Governance

13. How does Azure AD (Entra ID) integrate with DevOps workflows?

Ideal answer:

Service Principals: Applications that authenticate to Azure. Used by pipelines to deploy resources. Grant minimum required RBAC roles (e.g., Contributor on a specific resource group, not subscription-wide).

Managed Identities: Azure-native identities for compute resources (VMs, AKS pods, Functions). No secrets to manage — Azure handles token rotation. Preferred over service principals for any workload running in Azure.

Workload Identity Federation: Allows external systems (GitHub Actions, GitLab CI) to authenticate to Azure using OIDC tokens. No credentials to store or rotate ever.

Azure AD Group-based RBAC: Assign roles to Azure AD groups rather than individuals — scales better as team grows and access reviews are simpler.

14. What is Azure Policy and how do you use it in DevOps?

Ideal answer:

Azure Policy enforces organizational rules on Azure resources at scale. Evaluates resources against policy definitions and reports or prevents non-compliant configurations.

Policy effects:

• Audit: Reports non-compliance but allows resource creation
• Deny: Blocks resource creation if non-compliant
• DeployIfNotExists: Automatically deploys a companion resource (e.g., enable diagnostic settings)
• Modify: Automatically modifies resource properties (e.g., enforce tags)

DevOps integration:

• Use az policy assignment list in pipelines to gate deployments on compliance
• Apply Policy Initiatives (groups of policies) for standards like CIS Azure Benchmark
• Use terraform plan + OPA/Sentinel to catch policy violations before deployment

Common policies: Require tags on all resource groups, deny public IPs on VMs, enforce TLS 1.2+ on storage, restrict allowed VM SKUs in production.

15. How do you implement RBAC in Azure DevOps and Azure?

Ideal answer:

Two layers of RBAC:

Azure DevOps RBAC: Controls access within Azure DevOps — projects, pipelines, repos, artifacts. Roles: Reader, Contributor, Project Administrator. Assign at organization, project, or pipeline level.

Azure (ARM) RBAC: Controls access to Azure resources via IAM. Built-in roles: Owner, Contributor, Reader, and 70+ service-specific roles like "AKS Cluster Admin" or "Key Vault Secrets User."

Best practices:

• Use Azure AD groups, not individual users — reduces churn when people leave
• Follow principle of least privilege
• Use custom roles when built-ins are too broad
• Never grant Owner at subscription scope for automation accounts
• Review access quarterly with Azure AD Access Reviews

Section 6: Advanced Scenarios

16. Explain blue-green deployments using Azure Deployment Slots

Ideal answer:

Azure App Service deployment slots are live environments attached to your app (Standard tier+). Each slot has its own URL, environment variables, and connection strings.

Blue-green pattern:

1. Production slot (blue) serves live traffic

2. Deploy new version to staging slot (green)

3. Run smoke tests against staging URL

4. Swap slots — staging becomes production instantly, zero downtime

5. Old production code is now in staging — rollback by swapping again

What makes swaps safe: Warmup requests are sent to the new slot before traffic switches. Connection strings marked "sticky" stay with the slot and don't swap.

AKS equivalent: Update the Kubernetes Service selector label to point to the green Deployment. Less elegant than slots but achieves the same zero-downtime goal.

17. How do you handle database migrations in CI/CD?

Ideal answer:

Database migrations are risky in CI/CD because they can cause downtime or data loss if handled naively.

Safe pattern — expand-contract:

1. Add new column (nullable or with default) — both old and new code work

2. Deploy new code that writes to both old and new column

3. Backfill existing data in background

4. Deploy code that only uses new column

5. Drop old column in a later release

Tooling:

• Flyway / Liquibase: Version-controlled migration scripts, tracks applied migrations in a metadata table
• Entity Framework Migrations: .NET-native migration generation
• Alembic: Python/SQLAlchemy equivalent

Pipeline gate: Run migration in staging first. If it fails or produces errors, block promotion to production. Always take a backup before destructive migrations.

18. What is Azure Container Registry and how does it fit in a pipeline?

Ideal answer:

ACR is a managed Docker registry within Azure, equivalent to ECR in AWS. It integrates natively with AKS via managed identity — no credentials needed.

- task: Docker@2
  inputs:
    containerRegistry: 'my-acr-connection'
    repository: 'myapp'
    command: 'buildAndPush'
    tags: $(Build.SourceVersion)

ACR features worth mentioning:

• Geo-replication: Mirror registry across regions for low-latency pulls
• ACR Tasks: Build images in ACR without a local Docker daemon
• Vulnerability scanning: Microsoft Defender for Containers scans on push
• Retention policies: Auto-delete untagged images older than N days
• Content trust: Sign images, enforce signed-only deployments in AKS

19. How do you implement cost governance in Azure at scale?

Ideal answer:

Prevention:

• Azure Budgets with alerts at 80% and 100% thresholds
• Azure Policy to restrict expensive SKUs (deny GPU VMs except in ML resource groups)
• Dev/test subscription pricing for non-production

Visibility:

• Azure Cost Management dashboards
• Enforce tagging policies so costs are attributable to teams and projects
• Export cost data to Storage → analyze in Power BI

Optimization:

• Azure Advisor for right-sizing recommendations
• Reserved Instances for predictable workloads (40-60% savings)
• Spot VMs for batch, dev, and fault-tolerant workloads
• AKS cluster autoscaler + node auto-provisioning
• Auto-shutdown for dev/test VMs

Pipeline guardrail: Use infracost in Terraform/Bicep pipelines to estimate cost diff before merging IaC PRs.

20. Walk me through responding to a failed Azure production deployment

Why they ask this: They want your incident response mindset — rollback first or investigate first?

Strong answer:

Immediate (first 5 minutes):

• Assess blast radius: what's broken, what's still working?
• If rollback is safe, roll back immediately — restore service before investigating
• Notify stakeholders early — don't wait until you have answers

Rollback options by deployment type:

• App Service: swap deployment slots back
• AKS: kubectl rollout undo deployment/myapp
• Azure Pipelines: re-run the previous successful pipeline run
• ARM/Bicep: re-deploy the previous template from deployment history

Stabilize, then investigate:

• Pull deployment logs from Azure Monitor / Log Analytics
• Check resource activity log for what changed in the last hour
• Identify root cause: bad config? Faulty image? Schema migration issue?

Post-incident:

• Blameless postmortem
• Add a pipeline validation step that would have caught this
• Update runbook with the resolution steps

What interviewers listen for: Rollback first, investigate second. Early communication. Systemic fix after resolution.