skip to content

Azure DevOps

1 roadmap17 questions

Microsoft's end-to-end suite: YAML Pipelines, Repos, Boards and Artifacts feeds inside one project. Interviewers ask in .NET and enterprise contexts, where linking work items, packages and deployment environments together is the whole point of the product.

on this pageshow

explore

questions

17

What is a feed in Azure Artifacts, and which package types can a single feed host?

level: juniorimportance: must knowfreq 60%

answer

  1. private registry inside Azure DevOps
  2. one feed, several package protocols
  3. org-scoped or project-scoped
  4. Reader, Collaborator, Contributor, Owner
  5. no container images here

basics

~20 s

An Azure Artifacts feed is a private package registry hosted inside an Azure DevOps organization or project. One feed can hold NuGet, npm, Maven, Python and Universal Packages together, each reached through its own protocol endpoint URL.

solid answer

~40 s

A feed is Azure Artifacts' unit of storage and permission: a private registry that lives in an Azure DevOps organization, or scoped to a single project inside it. The same feed serves several protocols at once — NuGet, npm, Maven, Python (PyPI) and Azure DevOps' own Universal Packages — so a polyglot shop does not need one registry product per language. Each protocol gets its own endpoint on the same feed, for example `https://pkgs.dev.azure.com/{org}/{project}/_packaging/{feed}/nuget/v3/index.json` for NuGet and a `/npm/registry/` path for npm; you point `nuget.config` or `.npmrc` at that URL. Access is governed by feed roles — Reader, Collaborator, Contributor, Owner — rather than by repository permissions. A feed does not host container images; those belong in a container registry.

go deeper

for a junior

Be able to say plainly that a feed is a private package registry in Azure DevOps, name two or three protocols it serves, and describe pointing nuget.config or .npmrc at its URL.

for a middle

Explain the difference between organization-scoped and project-scoped feeds, walk through the four feed roles and which one a restoring versus publishing pipeline needs, and know that views exist.

for a senior

Expect to justify how many feeds an organization should run and where the boundary sits, and to diagnose access failures by reasoning about feed scope plus the identity that is actually making the request.

for a principal

Own the wider question: which artifact types belong in Azure Artifacts versus a container registry or object storage, and what a single shared feed costs in blast radius and permission review compared with per-team feeds.

## What a feed actually is A **feed** is the top-level object in Azure Artifacts. Think of it as one private package registry that you own: it stores package versions, decides who may read or publish them, and exposes standard package-manager endpoints so ordinary clients (`dotnet`, `nuget`, `npm`, `pip`, `twine`, `mvn`) can talk to it without knowing anything about Azure DevOps. Two things make a feed different from "a folder of files": it is **protocol-aware** (it understands NuGet's v3 index, npm's registry API, Maven's repository layout, PyPI's simple index) and it is a **permission boundary** — you grant roles on the feed, not on individual packages. ## Multiple protocols, one feed A single feed can hold packages of several types side by side: - **NuGet** — .NET packages (`.nupkg`) - **npm** — JavaScript packages, including scoped names such as `@myorg/utils` - **Maven** — JVM artifacts addressed by groupId/artifactId/version - **Python** — wheels and sdists, uploaded with `twine`, installed with `pip` - **Universal Packages** — an Azure-DevOps-specific format for arbitrary files (a folder of binaries, test data, a toolchain) versioned semantically and pushed with the Azure CLI or the `UniversalPackages` pipeline task Each protocol has its own endpoint hanging off the same feed. For NuGet: ```text https://pkgs.dev.azure.com/{organization}/{project}/_packaging/{feed}/nuget/v3/index.json ``` and for npm: ```text https://pkgs.dev.azure.com/{organization}/{project}/_packaging/{feed}/npm/registry/ ``` The practical consequence is that one feed can be "the place internal packages live" for a whole polyglot team, with one permission model and one retention configuration, instead of a separate registry product per language. What a feed does **not** host is container images. Those go to a container registry (Azure Container Registry or another OCI registry); Azure Artifacts is a package registry, not an image registry. ## Feed scope: organization or project When you create a feed you choose its scope. - An **organization-scoped feed** lives at the organization level and is visible across projects. Its URL has no project segment. - A **project-scoped feed** belongs to one project, appears under that project's Artifacts hub, and inherits the project's visibility. Its URL carries the project segment. Project scoping is the more common default for new feeds because it keeps a feed alongside the team that owns it and lets project-level administration apply. Organization scoping suits a genuinely shared "golden packages" feed. The scope also affects which build identity can reach it, which is why the choice shows up later as a pipeline permission problem rather than as a naming preference. ## Permissions: feed roles Access is granted through four roles, each a superset of the one before: - **Reader** — can list and download packages. - **Collaborator** — can additionally cause packages to be saved into the feed from an upstream source. - **Contributor** — can publish (push) packages and delete or unlist their versions. - **Owner** — full control, including feed settings, retention policies, upstream configuration, and the recycle bin. You assign these to users, Azure DevOps groups, and — importantly for CI — to the pipeline's build service identity. A pipeline that only restores needs Reader; one that publishes needs Contributor. ## Views Every feed is created with three **views**: `@local`, `@prerelease` and `@release`. `@local` is everything the feed holds; the other two are filtered slices you promote versions into so consumers can subscribe to "blessed" versions only. Consumers select a view by putting it in the URL, e.g. `_packaging/{feed}@release/nuget/v3/index.json`. ## Why interviewers ask The question is a scoping check. A candidate who answers "it's where our NuGet packages go" has used it; a candidate who mentions multi-protocol support, feed scope and the role model has actually administered one. The follow-ups almost always move to upstream sources (how public packages get in), authentication from a pipeline (how CI gets access), and retention (what makes packages disappear).

  • Where do container images go if not into an Azure Artifacts feed?
    Into a container registry — Azure Container Registry or any other OCI-compliant registry. Azure Artifacts speaks package-manager protocols (NuGet, npm, Maven, PyPI, Universal Packages), not the OCI distribution API, so images are stored and tagged elsewhere and referenced by tag or digest from the pipeline.
  • What is a Universal Package good for that a NuGet or npm package is not?
    Arbitrary file payloads that no language ecosystem owns: a compiled toolchain, a large test-data corpus, firmware, signed binaries. You push and pull them by name and semantic version with the Azure CLI or the UniversalPackages pipeline task, getting versioning and retention without pretending the payload is a language package.
  • How does a developer's machine authenticate to a feed for a plain npm install?
    By putting credentials in the user-level client config — an .npmrc entry with a token for the feed host, or for NuGet the Azure Artifacts credential provider, which prompts a browser sign-in and caches a token. The Connect to feed dialog in the Artifacts hub generates the exact snippet per protocol.

saying these in an interview costs you the question

  • Thinking a feed can store Docker container images
  • Assuming one feed per package type is required
  • Confusing feed roles with project or repository permissions
  • Believing feeds are always public inside the organization
  • Calling the feed a build artifact store for pipeline logs and binaries

context

resolving links…

open as a page

In an azure-pipelines.yml file, how do stages, jobs and steps nest, and which of the three is the unit that gets an agent?

level: juniorimportance: must knowfreq 78%

basics

~10 s

Stages contain jobs and jobs contain steps. The job is the unit of agent allocation: one agent runs all of a job's steps in one workspace, so two separate jobs share no filesystem.

open as a page

An Azure Pipelines job fails with 401 Unauthorized while restoring from an Azure Artifacts feed in the same organization. How does a pipeline authenticate to a feed, and what would you check?

level: middleimportance: must knowfreq 50%

basics

~20 s

A pipeline authenticates as its build service identity, and an authentication task injects that identity's token into the package client's config. A 401 usually means the build service identity holds no role on the feed, or the job's authorization scope cannot reach a feed in another project.

open as a page

In an Azure Pipelines YAML pipeline, what does declaring a job as `deployment:` with an `environment:` give you that a plain `job:` does not?

level: middleimportance: must knowfreq 68%

basics

~20 s

A deployment job targets a named environment, so Azure Pipelines records deployment history against it, enforces that environment's approvals and checks before the stage runs, and lets you choose a runOnce, rolling or canary strategy.

open as a page

Azure Pipelines YAML has three expression syntaxes — ${{ }}, $[ ] and $( ). When is each evaluated, and what breaks if you pick the wrong one?

level: middleimportance: must knowfreq 68%

basics

~20 s

Three different times. ${{ }} is a template expression evaluated at compile time before the run is scheduled, $[ ] is a runtime expression evaluated when the stage or job starts, and $( ) is macro syntax substituted just before each task executes.

open as a page

In Azure DevOps, when during a YAML pipeline run are the approvals and checks on a protected resource evaluated, and what is the run doing while they are pending?

level: seniorimportance: must knowfreq 60%

basics

~20 s

Checks are evaluated at the start of any stage that consumes the protected resource. The stage queues no jobs and holds no agent while it waits; every check on every resource the stage uses must pass before any job starts.

open as a page

In Azure Artifacts, what does an upstream source on a feed do the first time a build restores a package the feed does not already hold?

level: middleimportance: should knowfreq 55%

basics

~20 s

The feed fetches that package version from the upstream registry, saves a copy into the feed itself, and serves the saved copy on every later request. Public packages and internal ones then come from one URL, and the copy survives if upstream removes the original.

open as a page

What are the @local, @prerelease and @release views on an Azure Artifacts feed, and what changes when you promote a package version to a view?

level: middleimportance: should knowfreq 45%

basics

~20 s

Views are filtered, read-only slices of one Azure Artifacts feed. @local shows everything the feed holds; @prerelease and @release show only versions you promote into them. Promotion copies no bytes — it just makes a version visible at the view's URL.

open as a page

In an Azure Pipelines deployment job, which lifecycle hooks can a strategy define, and when does each one run?

level: middleimportance: should knowfreq 45%

basics

~10 s

Azure Pipelines deployment strategies expose preDeploy, deploy, routeTraffic and postRouteTraffic hooks, run in that order, plus on: success and on: failure hooks that run last depending on the outcome.

open as a page

In an Azure Pipelines YAML file, what does referencing a variable group under variables: give the run, and what changes when that group is linked to Azure Key Vault?

level: middleimportance: should knowfreq 55%

basics

~20 s

Referencing a variable group pulls every variable stored in that Library group into the pipeline's variable scope. Linking the group to Azure Key Vault means the values are fetched from the vault at run time through a service connection instead of being stored in Azure DevOps.

open as a page

Your team publishes an internal npm package to an Azure Artifacts feed that also has npmjs.com configured as an upstream source. How can a build still end up installing a public package of the same name, and what prevents it?

level: seniorimportance: should knowfreq 38%

basics

~20 s

Resolution is per version, not per name: if a client asks for a version your feed does not hold, the feed will fetch it from the public upstream. A floating range plus a higher public version is the opening. Scoped names, exact pinning and a single configured source close it.

open as a page

What does configuring an Azure DevOps Azure Resource Manager service connection with workload identity federation change, and how does Microsoft Entra ID decide to trust it?

level: seniorimportance: should knowfreq 48%

basics

~20 s

No secret is stored in Azure DevOps. The pipeline presents a short-lived token that Entra ID exchanges for an access token, trusting it because a federated identity credential matches the token's issuer, subject and audience.

open as a page

In Azure Pipelines, how does a pipeline that begins with extends: differ from one that merely references a template under steps:, and why do platform teams standardise on extends?

level: seniorimportance: should knowfreq 42%

basics

~20 s

An included template is content the pipeline chooses to pull in; an extends template owns the whole pipeline, and the extending file can contribute nothing but parameter values. That inversion is what lets a platform team fix the pipeline's shape and let product teams fill in only the holes it leaves.

open as a page

Azure DevOps lets you attach checks to environments, service connections, agent pools, repositories, variable groups and secure files. How would you decide which of those resources should carry a given gate?

level: principalimportance: should knowfreq 33%

basics

~20 s

Attach the gate to the resource that is the thing you actually want to restrict access to. Gate the credential on the service connection, the destination on the environment, and shared build capacity on the agent pool.

open as a page

An Azure Pipelines `deployment:` job runs a script stored in the repository and fails with a file-not-found error, yet the identical step works in a regular `job:`. What is the cause?

level: juniorimportance: nice to knowfreq 36%

basics

~10 s

Deployment jobs do not check out the source repository automatically the way regular jobs do, so the working directory has no repo files. Add an explicit - checkout: self step before the script.

open as a page

In an Azure Pipelines pool: block, what is the difference between setting vmImage and setting name together with demands?

level: middleimportance: nice to knowfreq 38%

basics

~20 s

vmImage asks for a Microsoft-hosted agent built fresh from that image for the job. name selects a specific agent pool — typically self-hosted — and demands filters which agents in it are eligible by matching against the capabilities each agent reports.

open as a page

A rebuild of an old release fails because a package version is no longer in your Azure Artifacts feed, though nobody deleted it by hand. What in the feed's configuration explains this, and how do you recover?

level: seniorimportance: nice to knowfreq 28%

basics

~20 s

The feed's retention policy pruned it. Retention keeps a maximum number of versions per package and spares recently downloaded ones, so a version an old release pins can age out. Recover it from the feed's recycle bin, then promote versions you must keep to a view.

open as a page