Azure DevOps Interview Questions

Microsoft-hosted agent pools are the fully managed option in Azure DevOps. Microsoft provisions a fresh virtual machine for each pipeline run and discards it afterward, requiring no infrastructure management. Self-hosted and scale set pools, by contrast, are set up and maintained by the user on their own infrastructure.

A self-hosted Azure DevOps agent requires the Azure Pipelines agent software, downloadable from the agent pool settings in Azure DevOps. After installation, the agent is configured with a personal access token so it can register with the pool and begin polling for jobs. Docker, the Azure CLI, and Visual Studio are not required prerequisites.

An organization-level agent pool in Azure DevOps must be explicitly added to a project before that project's pipelines can use it. You do this from the project's Project Settings under Agent Pools. Project-scoped pools are available immediately within the project that created them, but organization-level pools require this per-project step.

The correct order is: a fresh VM is provisioned → source code is checked out → pipeline tasks execute → the VM is discarded. Microsoft-hosted agents spin up a clean virtual machine for each job, run the work, then destroy it so every build starts from a known-clean state with no leftover artifacts.

The correct sequence is: download and extract the agent package → run the config script with the pool URL and a PAT → the agent appears online in the pool → optionally install it as a background service. Each step depends on the one before it; the config script both registers the agent and brings it online.

The true statements are that each machine in a deployment group must have the Azure Pipelines agent installed and registered, tags on individual machines can be used to target specific subsets during deployment, and rolling deployment is a supported strategy. A deployment group is a distinct resource from a standard agent pool — it is purpose-built for deploying to sets of target machines, whereas agent pools primarily serve build and release job execution.

A deployment group is a logical collection of deployment target machines. You register an Azure Pipelines agent on each target machine, then deploy to all or a subset of those machines. In Classic Release pipelines you use a Deployment Group job; in YAML pipelines you can reference the same deployment group through a deployment job with a deploymentGroup strategy.

You add a Deployment Group job (also referred to as a deployment group phase) to the release pipeline. This job type runs the defined tasks on each target machine that is a member of the deployment group.

Each target machine must have the Azure Pipelines agent installed and registered with the deployment group, typically by running the registration script generated from the deployment group page in Azure DevOps.

The correct order is: create a PAT, download the agent software, run the configuration script with the PAT and pool details, then start the agent as a service or interactive process. Each step depends on the previous one — the config script needs both the PAT (for authentication) and the downloaded binaries (to execute), and the agent can only start listening for jobs after it has been successfully configured and registered to a pool.

When you run a pipeline job on a Microsoft-hosted agent, Azure DevOps provisions a fresh virtual machine for that job. Once the job finishes, the VM is discarded, so any files written or software installed during the run are lost and unavailable to subsequent jobs.

A team needs to deploy an application to database servers that sit behind a corporate firewall and are not reachable from the public internet. In this scenario they should use a self-hosted agent, because Microsoft-hosted agents run in Microsoft's cloud and cannot reach those internal servers without additional networking configuration.

With a Microsoft-hosted agent you never need to install or update the operating system or the Azure Pipelines agent software yourself, because Microsoft handles patching, updates, and maintenance. With a self-hosted agent, however, this upkeep is the responsibility of your organization.

A self-hosted agent belongs to exactly one pool, Microsoft-hosted agents run on ephemeral VMs discarded after each job, and pipeline permissions can restrict which YAML pipelines target a given pool. Self-hosted agents do not auto-reset their working directory between runs — that requires the clean checkout option.

For the same package name and version, Azure Artifacts always serves the local feed copy first — upstream sources are only consulted when the version is absent locally. When falling back to upstreams, they are searched in priority order and the first match is saved as a read-only copy. Upstream-saved versions cannot be directly overwritten by a local publish (the cached version must be deleted first), and upstream sources are read-only from the downstream side — publishing downstream never propagates upstream.

No files, caches, or installed artifacts persist between runs on a Microsoft-hosted agent — every run starts from a known clean state. You must either re-download/rebuild everything each time, use the Azure DevOps Cache task or an external cache store (Azure Blob, Artifactory), install custom tooling in every run, or switch to a self-hosted agent where the local filesystem persists between runs.

A self-hosted agent resolves this. You install the agent on a machine or container that already has line-of-sight to the on-premises network (inside the corporate network or a peered/VPN-connected VNet). The agent polls Azure DevOps over outbound HTTPS (port 443) to fetch jobs and report results — no inbound firewall rules are required — then executes the deployment locally, where it can reach the private SQL Server.

Deployment groups in Azure DevOps are logically backed by a special-purpose deployment pool (distinct from standard agent/machine pools). Each deployment group is a deployment pool scoped to a single project, and the machines registered into it run the self-hosted Azure Pipelines agent in a mode where the agent polls Azure DevOps for deployment jobs rather than general build/release jobs. At the orchestration layer, Azure DevOps Service/Server pushes a job-targeting manifest to the deployment pool; the registered agents on each target machine pick up only the jobs tagged for their group + tags. The pipeline's 'Deployment group job' phase type resolves targets by querying the deployment group's membership and tag metadata, then dispatches the job definition (as a JSON-serialized DAG of tasks) to each matching agent's long-poll connection. Inside each target, the agent executes tasks sequentially under the configured service account, writes logs back over the same HTTPS channel, and reports success/failure so the orchestrator can apply the phase's 'all succeed' or 'rolling batch' success criteria before advancing.

It is not recommended to register the same physical machine's agent into both a standard self-hosted agent pool and a deployment group, though it is technically possible because the same agent binary supports both modes. The operational conflicts are: (1) Job contention — the agent has a single concurrent-job capacity by default; a build job and a deployment job can compete for the machine's CPU, disk, and ephemeral working directories (_work folder), causing timing-sensitive deployments to fail or produce inconsistent state. (2) Working-directory collisions — both job types use _work/1, _work/2, etc.; concurrent or interleaved jobs can clobber each other's artifacts. (3) Identity and permissions drift — the agent's personal access token (PAT) used for registration grants pool-level and deployment-group-level scopes; mixing roles broadens the blast radius if the token or machine is compromised. (4) Tag/targeting ambiguity — deployment-group tags and agent-pool demands are evaluated independently, so a machine could be selected for a deployment by its group tags while simultaneously being claimed by a build job via pool demands. The recommended pattern is to run separate agents (even separate _work directories or separate service accounts) for build/release pools versus deployment groups, ideally on separate VMs or at minimum as separate agent registrations with --agent names that make the role explicit.

True. Azure DevOps parallel jobs limit concurrent job execution, not agent registration. Idle self-hosted agents consume no parallel job slot; the slot is claimed only when a job is dispatched to that agent and released on completion. You can register more agents than your parallel job grant allows — the grant just caps how many can run simultaneously.

False. Disabling a self-hosted agent in Azure DevOps prevents new jobs from being dispatched to it but does not terminate or re-queue a job already running on it. The in-progress job runs to completion normally; only afterward does the agent stop accepting work. To stop a running job you must cancel the pipeline run itself, which is separate from disabling the agent.

True. System capabilities in Azure DevOps — like Agent.OS, Agent.OSVersion, and Agent.Name — are auto-discovered by the agent process at startup from the host environment and are read-only in both the pool UI and the .capabilities config file; they are regenerated on each restart. Only user-defined capabilities can be added or modified by an administrator.

Version scheme and uniqueness: Each CI build produces a SemVer string of the form MAJOR.MINOR.PATCH-prerelease.{BuildId} — for example, 2.1.0-ci.4521 for an internal CI build or 2.1.0-rc.4521 for a release-candidate build. The differentiator is $(Build.BuildId), which is monotonically increasing across the entire project and never repeats, so every build yields a globally unique prerelease suffix. ADO Artifacts enforces version immutability at the feed level: once a version string exists in the feed, any attempt to publish that exact string again is rejected. Because the suffix is sourced from a never-repeating build ID, two builds can never generate the same string; and if the publish step retries after a transient failure, the immutability guard turns the retry into a no-op rather than a collision or an overwrite.

Promotion flow: CI publishes every successful build to the @local view. A separate release pipeline promotes the chosen version from @local to @prerelease (for RC validation) and then to @release (for GA). Promotion changes which view the version is visible in — it does not create a new version, re-publish the binary, or alter the version string. Downstream consumers restore from the feed using a view qualifier (e.g., configuring their NuGet restore to resolve from the @release view), so they only ever see versions that have passed the full promotion gate, not raw CI output.

Hotfix isolation: Each of the 15 packages carries its own independent SemVer — the monorepo does not share a single umbrella version. A hotfix branch modifies only the package(s) that need the fix, bumps only those packages' PATCH (or appropriate) component, and CI publishes only the changed packages. Unaffected packages keep their current version and are never re-published or re-promoted — so a hotfix to Contoso.Logging at 2.1.1 does not force Contoso.Auth off its stable 3.0.0.

Upstream collision prevention: Because Azure Artifacts uses local-first resolution — any locally published name@version permanently shadows an identically named-and-versioned upstream package for every consumer of the feed — every internal package is namespaced with an org prefix (e.g., Contoso.Logging, Contoso.Auth). Third-party packages from the nuget.org upstream never share that prefix, so the two namespaces can never collide on name@version, and the shadowing behavior can only ever apply to a name the team deliberately chose to publish locally.

Create two Azure DevOps organizations: one for the commercial division (SOC 2) and one for the government division (FedRAMP Moderate). The split is driven by the regulatory boundary — FedRAMP Moderate requires specific data-handling controls, separate audit trails, and potentially different Azure infrastructure (government cloud regions) that cannot be satisfied within a single organization's shared audit log and extension marketplace. Both organizations use the same Entra ID tenant for identity (the tenant itself supports conditional access policies scoped per org), but each org's data, service connections, agent pools, and audit logs remain isolated. This satisfies the data-isolation requirement without fragmenting identity.

Within each organization, map one Azure DevOps project per development team or product line, targeting 20-30 projects per org. This gives each team its own security boundary for repos, boards, pipelines, and test plans while keeping cross-project visibility for portfolio-level stakeholders who can run cross-project work-item queries and view roll-up dashboards within the org. The trade-off: one project per team provides clean permission isolation and keeps each team's boards uncluttered, but it requires governance automation to keep policies consistent across dozens of projects. The alternative — cramming all teams into a handful of shared projects — creates noisy boards, makes per-team permission management fragile (relying on area-path-level permissions which are error-prone), and complicates pipeline-trigger scoping. The other extreme — one project per microservice (hundreds of projects) — makes cross-project queries sluggish and multiplies admin overhead; the per-team/per-product line granularity is the right balance.

Security uses the built-in group hierarchy: Project Collection Administrators (PCA) at the org level manage org-wide settings, extensions, marketplace, org-level service connections, and org-level agent pools — limit PCA to a small set of platform engineers. Within each project, Project Administrators manage project-level settings and project-level service connections. Contributors get read/write on repos, boards, and pipelines; Readers get view-only. For fine-grained access, create custom Azure DevOps groups per project (e.g., 'Acme-Billing-Developers', 'Acme-Billing-QA') and nest Entra ID security groups inside them so identity lifecycle (joiners/movers/leavers) is managed by the identity team while Azure DevOps permissions are managed by project admins. Apply explicit 'deny' permissions on production service connections and production environment approvals so that even if a contributor is accidentally added to a broader group, they cannot trigger a production deployment.

Cross-project shared resources follow this model: (1) Service connections — create org-level service connections for shared infrastructure (the production Azure subscription, container registry, Key Vault) and authorize them per-project so each project admin explicitly approves which projects can use them; this prevents a new project from automatically inheriting access to production. Use project-level service connections only for team-specific resources. (2) Variable groups — store shared non-secret configuration in org-level variable groups; store secrets in Azure Key Vault-backed variable groups linked per project. (3) Pipeline templates — maintain a central 'platform' repository in a dedicated platform project containing reusable YAML templates (build, test, scan, deploy stages); reference them from each project's pipelines via the 'extends' keyword with the template repo path, ensuring every pipeline inherits mandatory security scans. (4) Agent pools — use org-level managed agent pools for general-purpose CI/CD and project-level self-hosted pools only when a team needs specialized network access (e.g., agents inside a VNet peered to a specific subscription).

Governance is enforced through five mechanisms: (1) Required branch policies on every main/release branch — minimum two reviewers, build validation, and no direct pushes — applied automatically by a provisioning script. (2) Mandatory pipeline templates that inject SAST, dependency-vulnerability scanning, and license compliance checks into every build; teams cannot bypass these because the template's stages are inherited via 'extends'. (3) Azure DevOps audit log streaming to Microsoft Sentinel (or equivalent SIEM) with alerting on sensitive actions (project deletion, permission changes, service-connection creation). (4) Automated compliance scanning via the Azure DevOps REST API (or tools like azure-devops-policy-as-code) that runs nightly, compares every project's branch policies and security group membership against a baseline, and files a work item for any drift. (5) A project provisioning pipeline that creates new projects from a template with standard groups, branch policies, pipeline scaffolding, and org-level service-connection authorizations pre-configured — no project is created by hand. The government division's org additionally enforces that all agent pools run within government-cloud-connected VNets and that all service connections target government-region Azure subscriptions only.

We adopt a phased migration with GitHub Enterprise as the eventual single source of truth, retaining Azure Pipelines as the CI/CD engine during the transition and allowing GitHub Actions only for net-new, non-deployment workflows.

Repository migration: We use git clone --mirror to push each repo to GitHub Enterprise, preserving all branches, tags, and full commit history. GitHub becomes the single source of truth for each repo at its individual cutover date — not on a single global flag-day. During the 6-month window, repos migrate in batches by team. Critical repos are dual-run via a push-mirror (Azure Repos to GitHub) until the team's cutover is verified; afterward, the Azure Repos copy is set to read-only as an archive.

CI/CD strategy: Rather than rewriting all pipelines immediately, we connect Azure Pipelines to the new GitHub repos via a GitHub service connection. This reuses existing YAML pipelines, agent pools, and approval gates with minimal changes (mainly the repository resource type). The key trade-off: Azure Pipelines retains Azure RBAC integration and deployment-group management that would require re-establishing self-hosted runners and Azure service principals if we moved to GitHub Actions. For deployment-heavy pipelines, we standardize on Azure Pipelines. Net-new CI-only workflows may use GitHub Actions, but any pipeline that deploys to Azure infrastructure goes through Azure Pipelines.

Branch protection mapping: Azure Repos required reviewers map to GitHub required pull request reviews (matching review count). Build validation maps to required status checks (Azure Pipelines publishes commit status back to GitHub via the service connection). Merge-type enforcement maps to linear-history or squash-merge-only settings in branch protection. Required code reviewers map to a CODEOWNERS file with required review.

Authentication & security: We register an Azure DevOps GitHub App as the primary authentication mechanism rather than a PAT — this provides per-repo granularity, doesn't tie access to individual credentials, and is auditable. Azure DevOps service connections to Azure remain unchanged; the GitHub-to-Azure DevOps direction uses the GitHub App for webhook triggers and repo access. For SOC 2, we enable GitHub audit-log streaming to our SIEM alongside existing Azure DevOps audit logs, ensuring continuous coverage across the transition.

Migration sequencing & rollback: Phase 1: pilot with 1–2 low-risk teams — mirror to GitHub, validate pipelines and branch-protection parity. Phase 2: batch migration by business unit (5–10 repos per batch), each dual-running for 2 weeks before Azure Repos is set to read-only. Phase 3: decommission Azure Repos after all teams cut over and a 30-day read-only period. Rollback: during the dual-run window, if GitHub integration fails, we revert the pipeline source back to Azure Repos (which retains full write capability until decommission). The push-mirror ensures no commits are lost.