Interview Preparation

Azure DevOps is Microsoft’s integrated platform for planning work, storing code, building and releasing software, managing packages, and supporting test management. The core services are Boards, Repos, Pipelines, Artifacts, and Test Plans.

CI focuses on frequent integration with automated build and test feedback. CD extends that by packaging and delivering changes through environments, either to a manual approval point or fully into production.

Because it offers integrated work tracking, repositories, pipelines, artifacts, permissions, and auditability under one platform, which is particularly attractive in Microsoft-centric and regulated environments.

Boards for planning, Repos for source control, Pipelines for CI/CD, Artifacts for package management, and Test Plans for manual testing workflows.

An organization is the top-level boundary, a project groups work for a product or domain, and teams are subsets within a project that can have their own boards and sprint settings.

Classic pipelines are GUI-defined and easier to start visually, while YAML pipelines are pipeline-as-code stored in the repository, making them more reviewable, reusable, and scalable.

A single pipeline with multiple stages such as validate, build, staging deploy, and production deploy, usually promoting one immutable artifact through the release path.

It ensures the exact tested output is what reaches each environment, reducing drift and simplifying rollback and auditability.

A deployment job targets an Azure DevOps environment and gives richer deployment history, governance, and approval integration than a normal job.

Usually on Azure DevOps environments as approvals and checks, because that keeps critical governance outside casually editable YAML.

A service connection is a secure identity configuration that lets Azure DevOps pipelines authenticate to Azure or other external systems such as Kubernetes clusters and registries.

Use secret variables for limited cases, prefer variable groups linked to Azure Key Vault for central management, and apply least privilege to who or what can consume those values.

Because they bridge CI/CD automation to real infrastructure. If overscoped or overexposed, they can enable powerful unintended actions against production systems.

Granting each identity only the permissions it truly needs, such as separate non-prod and prod service connections instead of one highly privileged shared credential.

Because they protect the source branches that trigger releases, ensuring unreviewed or failing changes cannot drive trusted delivery flows.

The pipeline validates code, builds a Docker image, pushes it to ACR, authenticates to Azure and AKS via a scoped service connection, and uses Helm to deploy the chart with the immutable image tag into AKS environments.

Immutable tags provide exact traceability from deployment back to code and make rollback far safer than relying on mutable tags like latest.

Azure Artifacts often supplies internal dependencies during the build, while ACR stores the final deployable container image. They serve different layers of the delivery chain.

Rolling update for simplicity, blue-green for fast rollback and isolation, and canary for progressive risk reduction with monitored traffic shifts.

Commit SHA, build ID, image tag, environment, Helm release revision, approver identity, and deployment time.

I check branch or PR triggers, the correct YAML path, pipeline definition bindings, and whether any UI settings are overriding the expected trigger behavior.

I inspect the selected agent pool, agent availability, job demands, and whether self-hosted agents are online and advertising the required capabilities.

I move to target-side diagnostics such as Helm history, kubectl rollout status, pod events, application logs, and environment-specific configuration differences.

The pipeline is trying to use a service connection, environment, feed, or variable group that it has not been authorized to consume.

Separate trigger, authorization, agent, task, target platform, and application health. That layered approach prevents random guessing and speeds up root-cause isolation.

I would inventory patterns, migrate the common build logic first, introduce shared YAML templates, preserve approvals through environments, and move critical release paths in phases instead of a full one-shot rewrite.

I push back because convenience creates unnecessary blast radius. I prefer scoped service connections aligned to environments or resource boundaries and explicit authorization for usage.

Protected branches control source changes, validated pipelines create immutable artifacts, environments enforce approvals and checks, service connections are scoped, and each production deployment is logged to a run, artifact, commit, and approver.

I measure the slowest parts before redesigning: dependency restore, tests, image build, agent queue time, or overly serialized deployment flow. Optimization should target evidence, not assumptions.

I explain the trade-off honestly: Azure DevOps is strong for enterprise governance, integrated work management, package management, and mature release controls; GitHub Actions is excellent for GitHub-native workflows and marketplace breadth. The right answer depends on the organization’s operating model.