TL;DR: A pipeline has stages, each with jobs, each with steps, and every job runs on an agent from a pool. YAML in the repository rather than the classic visual editor. Microsoft-hosted agents are clean and cannot reach private networks; self-hosted agents can, which is why regulated environments run their own.
How to approach it
Give the hierarchy, then go to agents quickly, because that is where the real design decisions are in the enterprises that run Azure DevOps. Mention environments and approvals too, since deployment gates are the feature that distinguishes this from a plain build tool and they get asked about.
A strong answer
Stages are the coarse phases, typically Build, then Deploy to Dev, then Test, then Production. They run sequentially by default and can be made to depend on each other explicitly. Stages are the level approvals attach to, and the level at which promotion happens: the same immutable artifact built once in the first stage is what every later stage deploys.
Jobs sit inside a stage and run on one agent. Jobs in a stage run in parallel unless you declare dependsOn, and each gets a clean workspace, so anything passing between them goes through a pipeline artifact. A self-hosted agent that keeps its workspace is the exception, and that drift between runs is what makes one agent's results differ from another's.
Steps run in order within a job on the same machine. A step is either a script running a shell command or a task, which is a packaged unit like Docker@2 or AzureWebApp@1.
trigger:
branches: { include: [main] }
stages:
- stage: Build
jobs:
- job: build
pool: { vmImage: 'ubuntu-latest' }
steps:
- task: Docker@2
inputs:
command: buildAndPush
repository: checkout
tags: $(Build.SourceVersion)
- publish: manifests
artifact: manifests
- stage: DeployProd
dependsOn: Build
jobs:
- deployment: prod
environment: production
pool: { vmImage: 'ubuntu-latest' }
strategy:
runOnce:
deploy:
steps:
- download: current
artifact: manifests
- script: kubectl apply -f $(Pipeline.Workspace)/manifests
Two things in there worth pointing at. A deployment job rather than a plain job is what ties the run to an environment, and an environment can carry approvals, business-hours gates and a deployment history you can query. That is how a production gate is implemented without anybody writing a custom step. And a strategy of runOnce, rolling or canary gives you the rollout shape declaratively.
Agent pools are the part that shapes real architectures. A job requests a pool and gets a machine from it.
Microsoft-hosted agents are a fresh VM per job, patched and maintained for you, with a time limit per job and a fixed set of installed software. They live on the public internet, which is the constraint: they cannot reach a private VNet, an on-premises database, or a private AKS API server. For a large share of enterprise pipelines that rules them out immediately.
Self-hosted agents are machines you run, inside your network. They reach private resources, keep caches between runs (which can make builds much faster), and can have whatever toolchain you need. You now own patching them, scaling them, and the fact that a dirty workspace from a previous job can affect the next one. Running them as containers or in a scale set gives back the clean-per-job property.
The middle option worth naming is a managed DevOps pool or a VM scale set agent pool, where Azure scales the agents and they sit inside your VNet, which gets both properties at a cost.
On YAML versus classic: YAML lives in the repository, is reviewed and versioned with the code, and branches independently. Classic pipelines are edited in the UI and have none of that. New work should be YAML; the classic release pipelines are the thing you find in an older organisation and migrate.
What interviewers probe next
"How do you share pipeline definitions across repositories?" Templates, referenced from another repository declared as a resource. That centralises the deploy steps so a fix lands once instead of in forty repositories.
"How do secrets work?" Variable groups, which can be linked to Key Vault so the pipeline reads at run time rather than storing a copy. Secret variables are masked in logs and are not passed into scripts as environment variables unless mapped explicitly, which trips people up the first time.
"Azure DevOps or GitHub Actions?" If the organisation is already in Entra ID with Azure Boards and Repos, staying is usually right, and approvals and environments are more mature. New work with code on GitHub belongs in Actions. Running both, which many organisations do, means two sets of pipeline templates to maintain.
Common mistakes
Reaching for a Microsoft-hosted agent for a deployment into a private network, which cannot work and produces a confusing timeout.
Expecting files to survive between jobs, when each job gets its own agent and workspace.
Building new pipelines in the classic editor, giving up review, history and branching.
Self-hosted agents with persistent workspaces and no cleanup, so a previous job's leftovers change the next one's result.