Cloud / Azure DevOps Interview questions

Azure DevOps is Microsoft's platform for planning, building, testing and releasing software from one place. It bundles work tracking, Git hosting, CI/CD, test management and package feeds.

It grew out of Team Foundation Server and Visual Studio Team Services, and took the Azure DevOps name in 2018. It ships in two flavors: Azure DevOps Services, hosted by Microsoft, and Azure DevOps Server, installed on your own hardware.

The name is slightly misleading. Pipelines can build Java, Node.js, Python, Go or container images and deploy them to AWS, GCP or an on-premises server, so you are not tied to Azure or .NET.

Azure DevOps has five core services, and you can switch each one on or off per project.

Teams often use only a slice of the suite, for example Pipelines for builds while keeping code in GitHub and tickets in Jira.

Azure Boards is the work tracking service. It lets teams capture requirements, bugs and tasks as work items and organize them on backlogs and boards.

The main views are:

• Backlogs to rank and refine work
• Kanban boards with columns, swimlanes and WIP limits
• Sprints with a taskboard and capacity planning
• Queries and dashboards for reporting
• Delivery Plans for a calendar view across teams

Boards supports Scrum, Kanban and hybrid workflows, and work items can be linked to commits, pull requests and builds so you can trace a change back to its requirement.

Azure Repos hosts the source code for a project. It offers unlimited private Git repositories and, for older projects, centralized Team Foundation Version Control (TFVC).

Beyond hosting, it brings the collaboration layer: pull requests with inline comments, branch policies, code search, and webhooks or service hooks that notify other tools.

A single project can hold many Git repositories, so a team can split a monolith into several repos and still keep one backlog and one set of pipelines. Each repo has its own branches, permissions and policies, which is handy when different teams own different services.

Azure Pipelines is the CI/CD service. It builds your code, runs tests and deploys the result to any target, whether that is Azure, another cloud, Kubernetes or a plain VM.

You define a pipeline in a YAML file (usually azure-pipelines.yml) or in the classic visual editor. The work then runs on an agent, which is either a Microsoft-hosted VM or a machine you manage yourself.

It works with repos in Azure Repos, GitHub, Bitbucket and others, so you do not have to move your code to use it.

Azure Test Plans is the service for manual, exploratory and user acceptance testing. Testers organize work into a test plan, which contains test suites, which contain test cases.

Testers run cases in the browser-based test runner, record pass or fail for each step, and file a bug straight from a failed step with screenshots and logs attached.

Automated tests are not run from here. They execute in a pipeline, and their results show up in the pipeline's Tests tab. Test Plans needs the Basic + Test Plans access level, so it is a paid feature.

Azure Artifacts is the package management service. You create a feed and publish versioned packages to it, then consume them from builds or developer machines.

Supported formats include NuGet, npm, Maven, Gradle, Python (pip, twine), Cargo and Universal Packages for arbitrary files.

Feeds can use upstream sources to pull from public registries such as npmjs.com or NuGet.org. The first time someone requests a public package, the feed saves a copy, so builds keep working even if the public package is later removed.

An organization is the top-level container in Azure DevOps Services. It holds your projects, users, billing and settings, and it is what you sign in to at https://dev.azure.com/{organization}.

Several things are managed at this level rather than per project: user licenses and access levels, parallel job purchases, agent pools, installed marketplace extensions, and policies such as which authentication methods are allowed.

It is usually connected to a Microsoft Entra ID tenant, so sign-in and group membership follow your company directory. Many companies run one organization for the whole business and split teams into projects.

A project is a container inside an organization that groups the repos, boards, pipelines, test plans and feeds for a product or team.

When you create one you choose a name, visibility (private or public), the version control type, and the work item process (Basic, Agile, Scrum or CMMI).

Projects are the main security and reporting boundary. Permissions, area paths, iterations and dashboards are scoped to the project, which is why a mistake in one project does not leak into another.

A work item is a record that tracks one piece of work, such as a user story, a bug or a task. It has a title, description, State, assignee, tags and history.

Two fields place it in the plan. Area Path decides which team owns it, and Iteration Path decides which sprint it belongs to.

Work items can be linked as parent/child, related, or to Git artifacts like commits and pull requests. Those links are what let you answer 'which change shipped this requirement?' later.

The Agile process template defines these main types, arranged in a hierarchy:

Test Case, Test Plan and Test Suite also exist, and they are used by Azure Test Plans.

Azure DevOps ships four system processes. They differ mainly in vocabulary and the work item types they include.

System processes are read-only. To add fields, states or custom types, create an inherited process from one of them and assign your project to it.

Azure Repos supports two models, Git and TFVC.

A project can have many Git repos, but only one TFVC repository. For new work, choose Git unless you are maintaining something that is already on TFVC. Tools such as git-tfs or Azure DevOps import can migrate TFVC history into Git when you are ready to move.

A pull request (PR) asks to merge one branch into another, usually a feature branch into main. It gives reviewers a place to read the diff, leave comments and approve or reject.

In Azure Repos a PR can also trigger build validation, enforce branch policies, link work items, and be set to auto-complete once all policies pass.

Reviewers can also vote 'Approve with suggestions' or 'Wait for author'. A draft PR lets you share work in progress without it being completable.

A YAML pipeline is a CI/CD definition stored as a text file in your repository. Because it is code, it is versioned, reviewed in pull requests, and branches carry their own copy.

A minimal example that builds on every push to main:

trigger:
- main

pool:
  vmImage: ubuntu-latest

steps:
- script: echo Building $(Build.BuildNumber)
  displayName: Say hello

Microsoft's newer features, like multi-stage deployments and templates, are built for YAML first.

A pipeline is nested like this: pipeline, stages, jobs, steps. Smaller pipelines can skip the outer levels and list steps directly.

• trigger / pr / schedules decide when it runs
• pool picks the agent
• variables and parameters hold configuration
• stages group jobs, for example Build and Deploy
• jobs run on one agent
• steps are tasks or scripts executed in order

stages:
- stage: Build
  jobs:
  - job: Compile
    pool:
      vmImage: ubuntu-latest
    steps:
    - script: dotnet build

An agent pool is a group of agents that can run your jobs. When a job is queued, Azure Pipelines hands it to a free agent in the pool whose capabilities match its demands.

Microsoft provides hosted pools such as ubuntu-latest, windows-latest and macos-latest. You can also create self-hosted pools made of your own machines.

An agent runs one job at a time. Agents poll Azure DevOps over outbound HTTPS, so they do not need an open inbound port. Pools are defined at organization level and shared to projects with permissions.

A service connection stores how a project authenticates to an outside service such as an Azure subscription, a container registry, a Kubernetes cluster, GitHub or an SSH host.

Pipelines refer to it by name, so credentials never appear in YAML:

- task: AzureWebApp@1
  inputs:
    azureSubscription: 'prod-arm-connection'
    appName: 'orders-api'
    package: '$(Pipeline.Workspace)/drop/*.zip'

Use least privilege: scope the connection to one resource group, limit it to named pipelines, and add approvals or checks for sensitive ones. Review the list of connections regularly and delete any that are no longer used.

Branch policies are rules a branch must satisfy before a PR can complete. They are how you protect main from untested or unreviewed changes, and they also block direct pushes.

Policies are set per branch under Repos, Branches, Branch policies, and admins can bypass them only if granted that permission explicitly.

• Minimum number of reviewers, with an option to block self-approval
• Build validation to run a pipeline on each PR
• Check for linked work items
• Check for comment resolution
• Limit merge types to squash, rebase and so on
• Automatically included reviewers by path

A variable group is a named set of variables you define once under Pipelines, Library and reuse across many pipelines. Typical examples are connection strings or environment URLs that differ between dev and prod.

variables:
- group: shared-prod-settings
- name: buildConfiguration
  value: Release

Individual values can be marked secret. A group can also be linked to Azure Key Vault, so secrets stay in the vault and are fetched at run time. Access to the group itself is controlled with security roles, and a pipeline must be authorized before it can use it.

An environment is a named deployment target such as dev, staging or production. It can contain resources like a Kubernetes namespace or VMs.

A deployment job points to an environment, and Azure DevOps then records the deployment history, including which run and commit are live there.

jobs:
- deployment: DeployWeb
  environment: production
  strategy:
    runOnce:
      deploy:
        steps:
        - script: echo Deploying

Approvals and checks attach to the environment, which makes it the natural place for production gates. Environments also make it easy to see what version is live in staging versus production at any moment.

Approvals and checks pause a pipeline run before it uses a protected resource, until every condition is met.

They attach to resources such as environments, service connections, agent pools, variable groups, secure files and repositories. They are configured on the resource itself, not written in the YAML, so a developer editing the pipeline cannot remove them.

• Manual approval from named users or groups
• Branch control to allow only certain branches
• Business hours windows
• Invoke Azure Function / REST API for custom gates
• Exclusive lock so one run deploys at a time

A Kanban board shows work as cards that move across columns such as New, Active, Resolved and Closed, so the team sees flow and bottlenecks at a glance.

Useful settings you can tune:

• WIP limits highlight a column when it holds too many cards
• Swimlanes separate work by class of service, for example expedite
• Split columns divide a column into Doing and Done
• Definition of done text shown on each column
• Card fields and styles for quick status cues

Dragging a card to a new column updates the work item's state, so the board and the data never drift apart.

Both products offer the same core services. The difference is who runs it.

Choose Server when data residency, air-gapped networks or regulation require everything on-premises. Otherwise Services removes a lot of operational work, and new features usually land there first.

Classic pipelines are built in a visual editor and stored in the service. YAML pipelines are text files that live in your repo.

Classic still works, but Microsoft's new capabilities target YAML, so most teams migrate. A common path is to move the build first, then rebuild release stages as YAML stages with environments.

Microsoft-hosted agents are fresh VMs that Microsoft provisions for each job and discards afterwards. Self-hosted agents are machines you install and maintain yourself.

Pick self-hosted when you need private network access, special software or licenses, big caches, or faster repeated builds. Otherwise hosted is simpler and safer, since nothing leaks between runs.

They are three nested levels, each with different run behavior.

Because all steps of a job share one agent and workspace, files created in step 1 are visible in step 3. Two jobs run on different agents, so they do not share files unless you publish and download an artifact.

stages:
- stage: Build
  jobs:
  - job: Unit
    steps: [{script: echo unit}]
  - job: Lint
    steps: [{script: echo lint}]
- stage: Deploy
  dependsOn: Build
  jobs:
  - job: Release
    steps: [{script: echo release}]

The names are close but the purposes differ.

Example: a build publishes a drop pipeline artifact that the deploy stage downloads. A shared logging library, however, goes to an Artifacts feed so other repos can install it by version.

Both are Microsoft CI/CD options, but they sit in different ecosystems.

The usual deciding factor is where code and planning already live. Many companies run both, for example GitHub for code and Actions for open source, Azure DevOps for enterprise planning and regulated release flows.

When completing a PR you choose how history is written to the target branch.

Squash gives a tidy main history but loses individual commits. Rebase keeps a linear history with detail. No-fast-forward preserves the true branching story. Teams usually pick one and enforce it with the Limit merge types branch policy.

A trigger decides what starts a run. YAML pipelines support several kinds.

• CI trigger (trigger:) runs on pushes to listed branches, tags or paths
• PR trigger (pr:) validates pull requests for GitHub and Bitbucket repos
• Scheduled (schedules:) uses cron syntax, in UTC
• Pipeline resource trigger runs when another pipeline completes

trigger:
  branches:
    include: [main, release/*]
  paths:
    exclude: [docs/*]

schedules:
- cron: '0 2 * * *'
  displayName: Nightly build
  branches:
    include: [main]
  always: true

One catch: for Azure Repos Git, the pr: key is ignored. PR builds are set through a build validation branch policy instead. Use trigger: none to turn CI off, and [skip ci] in a commit message to skip a single run.

Keep secrets out of YAML and source control. Use one of these, from most to least preferred:

1. Azure Key Vault, through a linked variable group or the AzureKeyVault@2 task, so secrets live in the vault
2. Secret variables, marked secret in the pipeline or a variable group
3. Secure files for certificates and keystores
4. Service connections instead of raw credentials wherever possible

Secret variables are masked in logs but are not passed to scripts automatically. Map them explicitly:

steps:
- script: ./deploy.sh
  env:
    API_KEY: $(apiKey)

Log masking is a safety net, not a guarantee. Never echo secrets, and by default builds of forked repositories do not get them.

Workload identity federation lets a pipeline sign in to Azure without any stored secret. Azure DevOps issues a short-lived OIDC token for the run, and Microsoft Entra ID trusts it through a federated credential on an app registration or managed identity.

sequenceDiagram
  participant P as Pipeline run
  participant D as Azure DevOps
  participant E as Microsoft Entra ID
  participant R as Azure resource
  P->>D: Request OIDC token
  D-->>P: Signed token (issuer, subject)
  P->>E: Exchange token
  E-->>P: Access token
  P->>R: Deploy with access token

The federated credential matches on the issuer and a subject that identifies your organization, project and service connection. Since there is no client secret, nothing can expire silently at 2 a.m. or leak from a variable.

It is the recommended way to create new Azure Resource Manager connections. Existing secret-based connections can be converted from the connection's settings.

Templates let you define steps, jobs, stages or variables once and reference them from many pipelines. They accept typed parameters, which are expanded at compile time before the run starts.

# templates/build-steps.yml
parameters:
- name: configuration
  type: string
  default: Release
steps:
- script: dotnet build -c ${{ parameters.configuration }}

# azure-pipelines.yml
steps:
- template: templates/build-steps.yml
  parameters:
    configuration: Debug

Templates can live in a separate repo through resources.repositories and be called as template.yml@shared. There is also extends, where the pipeline must build on a required template, which is how platform teams enforce mandatory steps such as security scans.

A deployment job supports three strategies. Each exposes lifecycle hooks where you place steps.

Hooks run in order: preDeploy, deploy, routeTraffic, then postRouteTraffic. If something fails, the on: failure hook runs, which is the place to roll back.

strategy:
  canary:
    increments: [10, 50]
    deploy:
      steps:
      - script: ./deploy.sh
    on:
      failure:
        steps:
        - script: ./rollback.sh

Use one YAML file with a Build stage that produces an artifact and one deployment stage per environment.

trigger: [main]
pool:
  vmImage: ubuntu-latest

stages:
- stage: Build
  jobs:
  - job: Build
    steps:
    - task: DotNetCoreCLI@2
      inputs:
        command: publish
        publishWebProjects: true
        arguments: '-c Release -o $(Build.ArtifactStagingDirectory)'
    - publish: $(Build.ArtifactStagingDirectory)
      artifact: drop

- stage: Staging
  dependsOn: Build
  jobs:
  - deployment: Deploy
    environment: staging
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            inputs:
              azureSubscription: 'arm-connection'
              appType: webAppLinux
              appName: 'orders-staging'
              package: '$(Pipeline.Workspace)/drop/**/*.zip'

Add a Production stage the same way, and put a manual approval on the production environment. Build once and deploy the same artifact everywhere, so what you tested is exactly what ships.

Jobs in the same stage start in parallel by default. You control order with dependsOn and fan out copies with strategy.

jobs:
- job: Test
  strategy:
    matrix:
      node18:
        nodeVersion: 18
      node20:
        nodeVersion: 20
    maxParallel: 2
  steps:
  - script: echo Testing on Node $(nodeVersion)

A matrix creates one job per entry. parallel: N splits a test run into slices, useful with the VSTest task.

Real parallelism is limited by your parallel job capacity. If you have two parallel jobs and queue five, three wait. Check capacity under Organization settings, Parallel jobs.

Every step, job and stage has an implicit condition of succeeded(). Add condition: to change that.

- task: PublishTestResults@2
  condition: succeededOrFailed()
  inputs:
    testResultsFiles: '**/TEST-*.xml'

- script: ./deploy.sh
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))

Prefer succeededOrFailed() for reporting steps, because always() keeps running after a user cancels. Conditions are evaluated at run time, while ${{ if }} expressions are resolved at compile time.

Setting a variable in a step only affects later steps in the same job. To share it further, create an output variable.

jobs:
- job: A
  steps:
  - script: echo "##vso[task.setvariable variable=version;isOutput=true]1.4.2"
    name: setVer
- job: B
  dependsOn: A
  variables:
    appVersion: $[ dependencies.A.outputs['setVer.version'] ]
  steps:
  - script: echo $(appVersion)

• The producing step needs a name
• Across jobs, read it with dependencies.JobName.outputs['step.var']
• Across stages, use stageDependencies.Stage.Job.outputs['step.var']

The consuming job must declare dependsOn, or the value will be empty.

Measure first. The run summary shows time per job and step, so start with the biggest one.

• Cache dependencies with Cache@2 for npm, NuGet, pip or Maven
• Run independent jobs in parallel and split large test suites
• Shallow clone with fetchDepth: 1 for big repositories
• Path filters so docs-only changes do not trigger a full build
• Self-hosted agents keep warm caches and Docker layers
• Remove unneeded restore and publish steps

- task: Cache@2
  inputs:
    key: 'npm | "$(Agent.OS)" | package-lock.json'
    restoreKeys: |
      npm | "$(Agent.OS)"
    path: $(Pipeline.Workspace)/.npm
- script: npm ci --cache $(Pipeline.Workspace)/.npm

The cache key includes the lock file hash, so it refreshes only when dependencies change.

Work from the outside in.

1. Open the run and expand the first red step. Later errors are often side effects.
2. Re-run with Enable system diagnostics, or set system.debug: true, for verbose logs.
3. If it never started, check for the message This pipeline needs permission to access a resource and approve it.
4. Check YAML validation errors, such as indentation or an unknown template path.
5. Verify the service connection still works and has the right role on the target.
6. For self-hosted agents, read the _diag logs and confirm the agent is online and meets demands.
7. Reproduce locally with the same commands and versions.

Jobs stuck in Queued usually mean no free agent or no parallel job capacity, not a code problem.

A run goes through a compile phase and then an execution phase.

flowchart TD
  A["Trigger fires"] --> B["YAML compiled"]
  B --> C["Templates and parameters expanded"]
  C --> D["Run created with stages"]
  D --> E{Approvals and checks pass?}
  E -- No --> F["Wait or fail"]
  E -- Yes --> G["Job queued to agent pool"]
  G --> H["Agent picks up job"]
  H --> I["Steps run in order"]
  I --> J["Logs, results and artifacts published"]
  J --> K["Next stage starts"]

1. A trigger, schedule, PR or manual run starts it.
2. Azure DevOps reads the YAML, expands templates and ${{ }} expressions, and validates it.
3. For each stage, protected resources are checked and approvals collected.
4. Each job is queued, and a matching agent from the pool picks it up.
5. The agent runs the steps and streams logs. Task outputs and artifacts are uploaded.
6. Dependent stages then start, and the run ends as succeeded, failed or cancelled.

Knowing the split helps in debugging: a syntax or template error fails before any agent is used, while a script error appears in the step log.

Linking creates traceability from requirement to code to release.

• In Azure Repos, add #123 in a commit message or PR description to link work item 123
• In the PR, use Work items to add links manually
• Create a branch straight from a work item using Create a branch in its Development section
• With a GitHub repo connected to Boards, use AB#123, and Fixes AB#123 can move it to Done on merge

To enforce it, enable the Check for linked work items branch policy. Tick Complete associated work items after merging when finishing the PR so states update automatically.

Later, the work item's Development section shows the branches, commits and PRs, and the build summary lists which items shipped.

Two separate systems work together, and mixing them up is a common interview slip.

Built-in groups include Project Administrators, Contributors and Readers. Best practice is to grant permissions to Entra ID groups, not individuals.

Deny overrides Allow, apart from a few admin cases, and permissions inherit down unless broken. Stakeholder access is free and limited, and Basic is free for the first five users.

Neither is universally better. It depends on how you ship.

For most Azure Pipelines teams deploying services, trunk-based wins: fewer merge conflicts, faster feedback and simpler pipelines, with branch policies and build validation protecting main.

Microsoft's own release flow is a middle path: work happens on short topic branches off main, release branches are cut when shipping, and hotfixes are cherry-picked to them. Pick GitFlow when you really maintain multiple versions in parallel.

The usual flow is build an image, push it to Azure Container Registry, then deploy manifests to AKS.

- stage: Build
  jobs:
  - job: Image
    steps:
    - task: Docker@2
      inputs:
        containerRegistry: 'acr-connection'
        repository: 'shop/api'
        command: buildAndPush
        Dockerfile: 'Dockerfile'
        tags: $(Build.BuildId)

- stage: Deploy
  jobs:
  - deployment: AKS
    environment: 'prod.shop'
    strategy:
      runOnce:
        deploy:
          steps:
          - task: KubernetesManifest@1
            inputs:
              action: deploy
              manifests: 'k8s/deployment.yml'
              containers: 'myregistry.azurecr.io/shop/api:$(Build.BuildId)'

Tagging with $(Build.BuildId) keeps every image traceable to a run. The prod.shop environment resource points at a Kubernetes namespace, so approvals and deployment history work as usual. For Helm charts, swap in the HelmDeploy@1 task.

Two options cover most scripting needs.

Azure DevOps CLI is an extension for the Azure CLI:

az extension add --name azure-devops
az devops configure --defaults organization=https://dev.azure.com/contoso project=Shop
az pipelines run --name "Shop-CI" --branch main
az repos pr create --source-branch feature/x --target-branch main
az boards work-item create --title "Fix login" --type Bug

The REST API gives full coverage at https://dev.azure.com/{org}/{project}/_apis/...?api-version=7.1. Typical uses are bulk work item updates, custom reports and queuing runs from other systems.

Authenticate with a Microsoft Entra token or a PAT. Prefer Entra tokens, and keep any PAT narrowly scoped and short-lived. Inside a pipeline, $(System.AccessToken) is available for calls back to the same organization.

Split the work into a plan stage and an apply stage, with a human gate in between.

1. Store Terraform state in an Azure Storage backend with locking.
2. Authenticate through an Azure service connection, ideally using workload identity federation.
3. Run init, validate and plan -out=tfplan, then publish the plan as an artifact.
4. Put apply in a deployment job tied to an environment that requires approval.

- task: AzureCLI@2
  inputs:
    azureSubscription: 'arm-connection'
    scriptType: bash
    scriptLocation: inlineScript
    addSpnToEnvironment: true
    inlineScript: |
      export ARM_CLIENT_ID=$servicePrincipalId
      export ARM_OIDC_TOKEN=$idToken
      export ARM_TENANT_ID=$tenantId
      export ARM_SUBSCRIPTION_ID=$(az account show --query id -o tsv)
      export ARM_USE_OIDC=true
      terraform init
      terraform plan -out=tfplan

Apply the saved plan file so what was reviewed is exactly what runs.

Plan rollback before you need it. The right method depends on the target.

• Revert and redeploy: git revert the change and let the pipeline ship it. This is the cleanest option because history stays honest.
• Redeploy the last good artifact: re-run the earlier successful run's deploy stage, as long as its artifacts are still retained.
• App Service slots: swap the staging slot back to production.
• Kubernetes: use kubectl rollout undo or the reject action of KubernetesManifest.
• Deployment strategy hooks: put recovery steps in on: failure.
• Feature flags: switch the feature off without redeploying.

Make sure artifact retention covers your rollback window, and that database changes are backward compatible, since code rolls back more easily than data.

Assume a PR author can change the pipeline YAML and the scripts it runs, so protect what that code can reach.

• Fork builds: keep secrets unavailable to forks, and require a team member's comment before building them
• Protected resources: add approvals and branch control checks to production environments and service connections
• Restrict service connections to named pipelines with least privilege
• Required templates: use an extends template check so mandatory steps cannot be removed
• Limit job authorization scope to the current project and protect repository access
• Isolate agents: run untrusted code on Microsoft-hosted agents, not shared self-hosted machines
• Avoid script injection: do not paste values like branch names directly into script text

The goal is simple: code from an unreviewed branch should never be able to reach production credentials without a person approving it.