Azure DevOps – Interview Revision Notes

1. Azure DevOps Fundamentals

Q1. 🔴 What is DevOps, why is it needed, and what is the DevOps lifecycle?

DevOps combines Development and Operations to deliver software faster and more reliably through collaboration and automation.

Lifecycle: Plan → Code → Build → Test → Release → Deploy → Operate → Monitor → Repeat.

Q2. 🔴 What is Azure DevOps, why is it used, and what are its main services?

Azure DevOps is Microsoft's platform for managing the software development lifecycle (SDLC).

• Boards: Work tracking and Agile planning.

• Repos: Git source control.

• Pipelines: CI/CD automation.

• Test Plans: Manual and exploratory testing.

• Artifacts: Package management.

Q3. 🔴 What is CI/CD, and what is the difference between Continuous Integration, Continuous Delivery, and Continuous Deployment?

• CI: Automatically builds and tests code when changes are integrated.

• Continuous Delivery: Keeps tested applications ready for release, often with manual approval.

• Continuous Deployment: Automatically releases successful changes to Production without manual approval.

Q4. 🟡 What are Azure DevOps Organizations and Projects, and how are they related?

An Organization is the top-level container for managing Azure DevOps users, billing, and projects.

A Project contains Boards, Repos, Pipelines, and other resources for a particular application or team.

One Organization can contain multiple Projects.

Q5. 🟢 What is the difference between Azure DevOps Services and Azure DevOps Server?

• Azure DevOps Services: Cloud-hosted by Microsoft, with automatic updates and minimal infrastructure maintenance.

• Azure DevOps Server: Installed on-premises, with infrastructure and updates managed by the organization.

2. Azure Boards

Q1. 🟡 What is Azure Boards, and how is it used to manage development work?

Azure Boards is an Agile project management tool used to plan, assign, track, and monitor development work.

It supports work items, backlogs, Kanban boards, sprints, and dashboards.

Q2. 🟡 What are Epic, Feature, User Story, Task, and Bug, and what is their hierarchy?

• Epic: Large business objective.

• Feature: Functionality within an Epic.

• User Story: User requirement within a Feature.

• Task: Development activity needed to complete a story.

• Bug: Defect that needs fixing.

Typical Agile hierarchy: Epic → Feature → User Story → Task. Bugs can be managed as requirements or tasks depending on configuration.

Q3. 🟡 What are Backlogs, Sprints, Iterations, and Area Paths?

• Backlog: Prioritized list of pending work.

• Sprint: Fixed development period, commonly 2 weeks.

• Iteration Path: Assigns work to a sprint or time period.

• Area Path: Organizes work by team, product, or functional area.

Q4. 🟡 How do you assign and link work items and associate them with commits and Pull Requests?

Create a work item in Azure Boards and assign an owner, priority, and iteration.

Link related work using Parent/Child or Related relationships.

Include the work item ID in a commit message, such as Fix login issue AB#123, or link the work item directly to a Pull Request.

Q5. 🟢 What are Kanban boards, Scrum boards, Queries, and Dashboards?

• Kanban Board: Visualizes work across columns such as To Do, Doing, and Done.

• Scrum/Sprint Taskboard: Tracks work within a sprint.

• Queries: Filter and retrieve work items.

• Dashboards: Display charts, widgets, and project progress.

3. Azure Repos

Q1. 🔴 What is Azure Repos, and how does it use Git for source control?

Azure Repos is a source control service that hosts private Git repositories and also supports TFVC.

Developers use Git to clone, branch, commit, push, and merge code. Azure Repos provides Pull Requests, code reviews, and branch policies.

Q2. 🔴 What is a Pull Request, and what is the typical Azure Repos PR and code-review workflow?

A Pull Request (PR) proposes merging code from one branch into another.

Flow: Feature Branch → Push → Create PR → Code Review → Build Validation → Approval → Merge.

PRs help maintain code quality and collaboration.

Q3. 🔴 What are branch policies, and how do you enforce reviewers, build validation, and prevent direct pushes to main?

Branch policies protect important branches such as main.

Configure minimum reviewers, required build validation, comment resolution, and optional linked work items.

Restrict direct pushes using branch security permissions and prevent users from bypassing policies.

Q4. 🔴 How do you handle branches, merges, and merge conflicts in Azure Repos?

Developers create feature branches, commit changes, and submit Pull Requests.

If a merge conflict occurs, update the source branch with target-branch changes, resolve conflicts locally, test, and push the resolution.

Complete the PR after validation and approval.

Q5. 🟡 How are Git branching strategies such as feature branches, GitFlow, and trunk-based development used with Azure Repos?

• Feature Branching: Each feature is developed separately and merged through PRs.

• GitFlow: Uses main, develop, feature, release, and hotfix branches.

• Trunk-Based: Developers frequently integrate small changes into the main branch.

Azure Repos supports all these strategies through Git and branch policies.

4. Azure Pipelines Fundamentals

Q1. 🔴 What is Azure Pipelines, and how is it used to implement CI/CD?

Azure Pipelines is a CI/CD automation service used to build, test, and deploy applications.

It automatically executes pipelines when code changes occur and supports YAML pipelines, Classic pipelines, and multiple deployment platforms.

Q2. 🔴 What are stages, jobs, steps, and tasks, and what is their execution hierarchy?

• Stage: Major phase, such as Build, Test, or Deploy.

• Job: Collection of steps executed on an agent or server.

• Step: Individual action within a job.

• Task: Prebuilt step, such as DotNetCoreCLI or AzureCLI.

Hierarchy: Pipeline → Stage → Job → Step (Task/Script).

Q3. 🔴 What is an Agent and Agent Pool, and what is the difference between Microsoft-hosted and self-hosted agents?

An Agent is a machine that executes pipeline jobs. An Agent Pool is a collection of agents.

• Microsoft-hosted: Managed by Microsoft, with fresh environments for jobs.

• Self-hosted: Managed by your organization, allowing custom software and private network access.

Q4. 🔴 When would you use a self-hosted agent instead of a Microsoft-hosted agent?

Use a self-hosted agent when the pipeline requires access to internal servers, private databases, or on-premises resources.

It is also useful for custom tools, persistent caches, and specialized build environments.

Q5. 🔴 What can trigger an Azure Pipeline, such as commits, Pull Requests, schedules, and manual runs?

Azure Pipelines supports CI triggers for code pushes, PR validation, scheduled triggers, and manual execution.

Pipelines can also run based on completion of another pipeline or other configured resources.

5. YAML Pipelines

Q1. 🔴 What is an Azure DevOps YAML pipeline, what is azure-pipelines.yml, and what is its basic structure?

A YAML pipeline defines CI/CD automation as code in a file usually named azure-pipelines.yml.

It is stored in Git and commonly contains triggers, pools, variables, stages, jobs, and steps.

trigger: [main]  steps:  - script: dotnet build

Q2. 🔴 How do stages, jobs, steps, tasks, and scripts work in YAML?

A stage contains jobs, and a job contains steps.

Steps can execute predefined tasks or custom scripts. Jobs can run in parallel when dependencies and agent capacity permit.

steps:  - script: dotnet build

Q3. 🔴 How do CI and PR triggers work in YAML pipelines?

A CI trigger starts a pipeline when code is pushed to configured branches.

A PR trigger validates proposed changes. For Azure Repos Git, configure PR validation using branch policies rather than YAML pr: triggers.

trigger:  - main

Q4. 🔴 What are pipeline variables and parameters, and what is the difference between them?

• Variables: Store values used during pipeline execution; can be updated at runtime.

• Parameters: Supply typed values evaluated during template expansion, before runtime.

Use variables for configuration and parameters for reusable pipeline customization.

Q5. 🔴 How do conditions work, and how can you conditionally execute stages/jobs based on branch or environment?

Conditions determine whether a stage, job, or step should execute.

For example, deployment can run only when the pipeline succeeds and the source branch is main.

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

Q6. 🔴 What are YAML templates, and how do you create reusable pipelines for multiple applications?

YAML templates allow common stages, jobs, steps, or variables to be defined once and reused.

Multiple applications can reference the same template and pass different parameters, reducing duplication.

steps:  - template: templates/build.yml

Q7. 🟡 How do you pass variables/output values between jobs and stages?

Use output variables with isOutput=true to share values between dependent jobs.

Reference them through dependencies for jobs or stageDependencies for stages, with the appropriate output syntax.

Q8. 🟢 What are pipeline resources?

Pipeline resources define external resources consumed by a pipeline, such as other pipelines, repositories, containers, and packages.

They support resource version selection, dependencies, and certain completion-based triggers.

6. Classic vs YAML Pipelines

Q1. 🟡 What is the difference between Classic and YAML pipelines, and why are YAML pipelines commonly used for new CI/CD implementations?

• Classic: Pipelines configured through the Azure DevOps graphical interface.

• YAML: Pipelines defined as code and stored in Git.

YAML is commonly preferred because it supports version control, code review, templates, and easier reuse.

Q2. 🟡 Can CI and CD be implemented in a single multi-stage YAML pipeline?

Yes. A multi-stage YAML pipeline can perform Build, Test, and Deployment operations.

Example flow: Build → Test → Dev → SIT → UAT → Production.

Approvals and conditions can control progression between environments.

Q3. 🟢 What is a Classic Release Pipeline, and how can Classic pipelines be migrated to YAML?

A Classic Release Pipeline deploys build artifacts to environments using a graphical interface.

To migrate, recreate the deployment stages, tasks, variables, service connections, and approvals in a multi-stage YAML pipeline.

Validate the new pipeline before retiring the Classic release.

7. ASP.NET Core Build Pipeline

Q1. 🔴 Explain how you build an ASP.NET Core application using Azure Pipelines from source checkout to artifact generation.

The pipeline checks out source code, installs the required .NET SDK, restores NuGet packages, builds the solution, and executes tests.

After successful validation, dotnet publish generates deployment files, which are uploaded as a Pipeline Artifact.

Q2. 🔴 How are dotnet restore, dotnet build, dotnet test, and dotnet publish used in a CI pipeline?

• restore: Downloads NuGet dependencies.

• build: Compiles the application.

• test: Executes automated tests.

• publish: Generates deployment-ready application files.

dotnet restore && dotnet build --no-restore  dotnet test --no-build && dotnet publish -c Release

Q3. 🔴 What is a build artifact, and how do you publish and consume artifacts between CI and deployment stages?

A build artifact contains compiled application files required for deployment.

Use PublishPipelineArtifact to upload files and DownloadPipelineArtifact to retrieve them in deployment stages.

This allows the same tested build to be deployed across multiple environments.

Q4. 🔴 What happens when compilation or unit tests fail in a pipeline?

If compilation or required unit tests fail, the pipeline job normally fails.

Dependent deployment stages are skipped by default because they require successful previous stages.

Developers review pipeline logs, fix the issue, and rerun the pipeline.

Q5. 🔴 How do you automatically trigger the ASP.NET Core build pipeline after code is committed or merged?

Configure a CI trigger for the required Git branch.

When changes are pushed or merged into main, Azure Pipelines automatically starts the build.

trigger:  - main

Q6. 🟡 How do you build and test multiple .NET projects in one pipeline?

Use a solution file (.sln) to build and test multiple related projects together.

Alternatively, define separate jobs for independent projects to enable parallel execution.

dotnet build MySolution.sln  dotnet test MySolution.sln --no-build

8. Deployment / CD Pipeline

Q1. 🔴 Explain how an ASP.NET Core application is deployed from Azure Pipelines to Azure App Service.

The CI pipeline builds, tests, and publishes the ASP.NET Core application as an artifact.

The CD pipeline downloads the artifact and deploys it using AzureWebApp task with an Azure Service Connection.

Azure App Service hosts the deployed application.

Q2. 🔴 How do you deploy the same build artifact across Dev → SIT → UAT → Production?

Build the application once and publish a versioned artifact.

Deploy that same artifact sequentially to Dev → SIT → UAT → Production, using environment-specific configuration.

Use approvals and checks before sensitive deployments.

Q3. 🔴 What are Azure DevOps Environments and deployment jobs?

An Environment represents a deployment target such as Dev, SIT, UAT, or Production.

A deployment job is a special YAML job that targets an Environment and records deployment history.

Environments support approvals, checks, permissions, and deployment tracking.

Q4. 🔴 How do approvals and checks work, and how do you require approval before Production deployment?

Approvals and checks control whether a pipeline can use protected resources, including Environments.

Configure an Approval Check on the Production Environment and assign authorized approvers.

The deployment waits until approval is granted and other checks pass.

Q5. 🔴 How do you restrict who can deploy to Production?

Use Environment security permissions to restrict which users and pipelines can deploy.

Configure Production approvals, protect deployment branches, and restrict Service Connection access.

Apply least privilege to all deployment identities.

Q6. 🔴 How do you handle a failed deployment and roll back/redeploy a previous successful version?

Review deployment logs, application logs, and health checks to identify the failure.

Redeploy the previous successful artifact or container image. For App Service, deployment slots can support quick rollback by swapping back.

Q7. 🟡 How do you deploy ASP.NET Core to an Azure VM/IIS?

Build and publish the ASP.NET Core application using Azure Pipelines.

Use a self-hosted agent, deployment agent, or suitable deployment task to copy files to the VM.

Configure IIS, application pool, ASP.NET Core Hosting Bundle, and application settings.

Q8. 🟡 How do deployments differ for App Service, Container Apps, and AKS?

• App Service: Deploy application files or containers to a managed web-hosting platform.

• Container Apps: Deploy container images with managed scaling and revisions.

• AKS: Deploy containers using Kubernetes manifests or Helm, with greater orchestration control.

9. Variables, Secrets & Configuration

Q1. 🔴 What are pipeline variables and Variable Groups, and how are they used?

Pipeline variables store configuration values used by pipeline tasks and scripts.

Variable Groups centrally store variables and secrets that can be shared across multiple pipelines.

variables:  - group: Dev-Variables

Q2. 🔴 How do you manage different configuration values for Dev, SIT, UAT, and Production?

Maintain separate Variable Groups or configuration files for each environment.

For example: Dev-Variables, SIT-Variables, UAT-Variables, and Prod-Variables.

Select the appropriate configuration during deployment without rebuilding the artifact.

Q3. 🔴 How do you securely manage passwords, connection strings, API keys, and other secrets in Azure Pipelines?

Store sensitive values in Azure Key Vault or protected secret variables.

Use authorized Variable Groups and Service Connections to retrieve secrets securely.

Never hardcode passwords or API keys in YAML, source code, or repository files.

Q4. 🔴 How do you integrate Azure Key Vault with Azure Pipelines?

Create an Azure Key Vault and store the required secrets.

Configure an authorized Azure Resource Manager Service Connection.

Use a Key Vault-linked Variable Group or AzureKeyVault@2 task to retrieve secrets during pipeline execution.

Q5. 🔴 What is the difference between Variable Groups and Azure Key Vault?

• Variable Groups: Store and share pipeline configuration values, including protected secrets.

• Azure Key Vault: Dedicated Azure service for securely managing secrets, keys, and certificates.

Variable Groups can link to Azure Key Vault to retrieve centrally managed secrets.

Q6. 🔴 Why should secrets never be stored directly in YAML, and how do you prevent them from appearing in pipeline logs?

YAML files are stored in source control, so hardcoded secrets may be exposed through repository history.

Use Key Vault, secret variables, and restricted permissions.

Avoid printing secrets, passing them as command-line arguments, or enabling sensitive diagnostic output.

10. Service Connections & Authentication

Q1. 🔴 What is a Service Connection, why is it required, and how does Azure DevOps use it to access Azure resources?

A Service Connection stores the authentication configuration needed for pipelines to access external services.

It enables secure connections to Azure subscriptions, Azure Container Registry, Kubernetes, and other services.

Pipelines use the connection to authenticate and perform authorized operations.

Q2. 🔴 How do you configure an Azure Resource Manager Service Connection?

Navigate to Project Settings → Service Connections → New Service Connection → Azure Resource Manager.

Choose an authentication method, preferably workload identity federation.

Select the required Azure scope, configure permissions, and authorize the pipeline.

Q3. 🔴 What is workload identity federation, and how can pipelines authenticate to Azure without storing client secrets?

Workload Identity Federation (WIF) allows Azure Pipelines to authenticate using short-lived identity tokens instead of stored client secrets.

Microsoft Entra ID validates the federated token and issues an access token.

This reduces credential leakage and secret rotation requirements.

Q4. 🔴 How should Service Connection permissions be secured using least privilege?

Grant the Service Connection identity only the Azure RBAC permissions required for its deployment tasks.

Scope access to the appropriate resource group or resource instead of the entire subscription whenever possible.

Restrict authorized pipelines and avoid granting access to all pipelines unnecessarily.

Q5. 🟡 How do you troubleshoot Service Connection authentication and permission failures?

Verify the Service Connection status, identity configuration, and pipeline authorization.

Check Azure RBAC roles, resource scope, federated credentials, and token errors.

Review pipeline logs for authentication failures, expired credentials, or missing permissions.

11. Azure Artifacts

Q1. 🟡 What is Azure Artifacts, what is a feed, and why is it used?

Azure Artifacts is a package management service used to store, share, and manage software packages.

A feed is a repository of packages such as NuGet, npm, Maven, Python, and Universal Packages.

It helps teams securely reuse libraries across applications.

Q2. 🟡 How do you publish and consume private NuGet packages using Azure Artifacts?

Create a feed in Azure Artifacts and configure NuGet authentication.

Publish packages using dotnet nuget push and consume them through the feed configured in NuGet.config.

dotnet pack -c Release  dotnet nuget push MyLibrary.1.0.0.nupkg --source MyFeed

Q3. 🟡 What is the difference between Azure Artifacts packages and pipeline build artifacts?

• Azure Artifacts: Stores versioned, reusable packages such as NuGet libraries.

• Pipeline Artifacts: Stores build outputs used by pipeline stages for deployment.

Key difference: Package sharing versus build/deployment file sharing.

Q4. 🟢 What are upstream sources and package versioning?

Upstream sources allow Azure Artifacts feeds to retrieve packages from external feeds such as NuGet.org.

Package versioning identifies different releases of a library, commonly using Semantic Versioning such as 1.2.3.

12. Testing & Code Quality

Q1. 🔴 How do you run unit/integration tests, publish test results, and collect code coverage in Azure Pipelines?

Use dotnet test to execute automated unit and integration tests.

Generate test results using TRX format and publish them through PublishTestResults@2.

Collect code coverage using XPlat Code Coverage and publish supported coverage reports.

dotnet test --logger trx --collect:"XPlat Code Coverage"

Q2. 🔴 How do you prevent deployment when tests fail?

Configure the pipeline so deployment depends on successful build and test stages.

When tests fail, the test job fails and dependent deployment stages are skipped by default.

Use branch policies and build validation to prevent failed code from being merged.

Q3. 🟡 How do you integrate SonarQube with Azure DevOps?

Install the SonarQube extension and configure a SonarQube Service Connection.

Add Prepare Analysis → Build/Test → Run Analysis → Publish Quality Gate tasks to the pipeline.

SonarQube analyzes code for bugs, vulnerabilities, and maintainability issues.

Q4. 🟡 What is a SonarQube Quality Gate, and how can it prevent bad code from progressing through the pipeline?

A Quality Gate checks code against defined quality conditions, such as coverage and new-code issues.

Configure the pipeline or PR policy to fail or block progression when the Quality Gate fails.

This prevents code that violates quality requirements from reaching Production.

13. Security & Permissions

Q1. 🔴 How do users, groups, roles, and permissions work in Azure DevOps?

• Users: Individuals accessing Azure DevOps.

• Groups: Collections of users, such as Contributors and Project Administrators.

• Permissions: Control actions such as reading, contributing, and managing resources.

• Roles: Control access to specific resources such as Environments and Agent Pools.

Q2. 🔴 How do you secure repositories, pipelines, Service Connections, and Production environments?

Use RBAC, security groups, branch policies, and pipeline permissions.

Restrict Service Connections to authorized pipelines and configure Production approvals.

Protect secrets using Azure Key Vault and apply least privilege.

Q3. 🔴 How do you protect main using branch policies and Pull Request approval?

Configure minimum reviewers, build validation, and comment resolution for the main branch.

Restrict direct pushes and policy bypass permissions through branch security.

Require successful validation and approval before merging.

Q4. 🔴 How do you securely manage pipeline secrets and prevent credentials from appearing in logs?

Store secrets in Azure Key Vault or protected pipeline variables.

Pass secrets securely through task inputs or environment variables instead of printing them.

Restrict access to secret resources and avoid exposing sensitive values in debug logs.

Q5. 🔴 What is least privilege, and how should it be applied in Azure DevOps?

Least privilege means granting only the permissions necessary to perform a specific task.

For example, a deployment Service Connection should have access only to its required Azure resources.

Avoid unnecessary Owner, Contributor, and administrator permissions.

Q6. 🟡 How do you control Production approvers and audit code/deployment changes?

Configure Environment Approvals and Checks with authorized approvers.

Use Pull Request history, pipeline runs, deployment history, and Azure DevOps audit logs to track changes.

Restrict who can modify Production deployment configurations and approvals.

14. Docker & Container Pipelines

Q1. 🔴 How do you build a Docker image using Azure Pipelines and push it to Azure Container Registry (ACR)?

Create a Dockerfile for the application and configure an ACR Service Connection.

Use the Docker@2 task to build the Docker image and push it to ACR.

- task: Docker@2    inputs: { command: buildAndPush, containerRegistry: 'ACR-Connection', repository: 'myapi' }

Q2. 🔴 How does Azure DevOps authenticate with ACR?

Azure Pipelines uses a Docker Registry Service Connection or Azure authentication with appropriate ACR permissions.

The connection authenticates the pipeline so it can push and pull container images.

Prefer identity-based authentication and least-privilege access.

Q3. 🔴 Explain the complete CI/CD flow for a containerized ASP.NET Core application.

The pipeline restores dependencies, builds and tests the application, then creates a Docker image.

The image is tagged and pushed to Azure Container Registry.

The CD pipeline deploys that image to Azure Container Apps or AKS.

Q4. 🟡 How do you tag and version Docker images and roll back to an earlier image?

Tag images using build numbers, release versions, or Git commit IDs.

For example, myapi:1.0.0 and myapi:1.0.1.

To roll back, redeploy the previous known-good image tag or digest.

Q5. 🟡 How do you deploy Docker images to Azure Container Apps or AKS?

• Container Apps: Deploy an ACR image using Azure CLI or Azure Container Apps deployment tasks.

• AKS: Deploy the image using Kubernetes manifests or Helm charts.

Both platforms retrieve images from ACR using configured registry authentication.

15. Database Deployment

Q1. 🟡 How do you deploy SQL Server database changes through Azure DevOps?

Database changes can be deployed using SQL scripts, DACPAC files, or EF Core migrations.

Store database changes in source control and execute them through a controlled deployment pipeline.

Use backups, approvals, and validation before Production deployment.

Q2. 🟡 How do you execute EF Core migrations in an Azure Pipeline, and should Production migrations be automatic?

Use EF Core tools to generate a migration SQL script or migration bundle.

dotnet ef migrations script --idempotent -o migration.sql

For Production, prefer reviewed and approved migrations with backup and recovery procedures rather than uncontrolled automatic execution.

Q3. 🟡 How do you deploy a DACPAC through Azure DevOps?

Build a SQL Database Project to generate a .dacpac file.

Use SqlPackage or an Azure SQL deployment task to publish the DACPAC to the target database.

Review schema changes and deployment warnings before Production execution.

Q4. 🔴 How do you securely manage database connection strings in CI/CD?

Store connection strings and credentials in Azure Key Vault or protected secret variables.

Retrieve them securely during deployment using authorized identities.

Prefer Microsoft Entra authentication or managed identities where supported, and never hardcode credentials in YAML.

Q5. 🟡 How do you handle database deployment failures and rollback?

Stop deployment, review SQL errors and deployment logs, and assess database consistency.

Restore from a verified backup or apply a tested corrective migration when necessary.

Database rollback requires careful planning because schema and data changes may not be automatically reversible.

16. Branching & Release Strategy

Q1. 🔴 What branching strategy would you use with Azure DevOps, and how do GitFlow and trunk-based development differ?

Choose a strategy based on team size, release frequency, and deployment requirements.

• GitFlow: Uses develop, release, feature, and hotfix branches for structured releases.

• Trunk-Based: Integrates small changes frequently into the main branch.

Q2. 🔴 How do feature, release, and hotfix branches fit into a CI/CD process?

• Feature Branch: Used to develop new functionality.

• Release Branch: Used to stabilize and prepare a release.

• Hotfix Branch: Used to fix urgent Production issues.

CI validates changes, while CD deploys approved builds.

Q3. 🔴 How would you handle an emergency Production hotfix?

Create a hotfix branch from the current Production release.

Apply the fix, run required tests, create an expedited PR, and obtain approval.

Deploy through the controlled pipeline and merge the fix back into active development branches.

Q4. 🔴 How do branch policies and approvals ensure that only approved code reaches Production?

Branch policies require code review and successful build validation before merging.

Environment approvals control whether the approved build can be deployed to Production.

Together, they protect both source code integration and release execution.

Q5. 🟡 How can Git tags be used for application releases?

Git tags identify specific commits associated with releases, such as v1.0.0.

They help track which source version produced a release and support reproducible builds.

git tag v1.0.0  git push origin v1.0.0

17. Pipeline Troubleshooting

Q1. 🔴 How do you troubleshoot a failed Azure Pipeline using pipeline logs and diagnostic/debug logging?

Open the failed pipeline run and identify the failed stage, job, and task.

Review error messages, task output, and recent configuration changes.

Enable diagnostic logging using system.debug=true when additional details are required, while protecting secrets.

Q2. 🔴 How would you troubleshoot failures in restore, build, test, artifact publishing, and deployment stages?

• Restore: Check NuGet feeds, network access, and authentication.

• Build/Test: Check compiler errors, SDK versions, and test failures.

• Artifact: Verify output paths and publishing permissions.

• Deployment: Check Service Connections, target availability, and application logs.

Q3. 🔴 How do you troubleshoot Service Connection, authentication, and permission failures?

Verify Service Connection authorization, identity configuration, and credential validity.

Check Azure RBAC permissions, resource scope, and federated identity configuration.

Review error codes such as 401 Unauthorized and 403 Forbidden to identify authentication or authorization problems.

Q4. 🟡 Why might a pipeline work on one agent but fail on another?

Agents may have different SDK versions, installed tools, operating systems, environment variables, or network permissions.

Compare agent capabilities and pipeline logs.

Use pinned tool versions and consistent agent configurations to reduce failures.

Q5. 🟡 Why might a pipeline work manually but fail when triggered automatically?

Manual and automatic runs may use different branches, variables, permissions, or trigger conditions.

Check the triggering identity, source branch, YAML conditions, and resource authorization.

Compare both pipeline runs to identify the difference.

18. Real-Time Scenario Questions

Q1. 🔴 Explain the complete flow: Developer → Branch → Commit → Pull Request → Code Review → Merge → CI → Build → Test → Artifact → Dev → SIT → UAT → Approval → Production.

Developers commit code to a feature branch and create a Pull Request.

After code review and build validation, changes are merged into main, triggering CI to build, test, and publish an artifact.

CD deploys the same artifact through Dev → SIT → UAT → Approval → Production.

Q2. 🔴 Design a complete Azure DevOps CI/CD pipeline for an ASP.NET Core Web API.

Create a multi-stage YAML pipeline with Restore → Build → Unit Test → Publish Artifact.

Add deployment stages for Dev, SIT, UAT, and Production.

Use Service Connections, Variable Groups, Key Vault, and Environment Approvals for secure deployments.

Q3. 🔴 How would you implement CI/CD for Angular + ASP.NET Core applications?

Build the Angular frontend using Node.js/npm and the ASP.NET Core Web API using the .NET SDK.

Run frontend and backend tests, then publish their deployment artifacts.

Deploy Angular to a suitable web host and the Web API to App Service, IIS, or containers, with environment-specific configuration.

Q4. 🔴 How would you deploy the same artifact across Dev → SIT → UAT → Production while managing environment-specific configuration?

Build the application once and generate an immutable, versioned artifact.

Deploy it through Dev, SIT, UAT, and Production using separate Variable Groups or Key Vault secrets.

Apply environment configuration during deployment or runtime without rebuilding the application.

Q5. 🔴 How would you integrate unit tests, SonarQube Quality Gates, and approvals so that bad builds cannot reach Production?

Configure Build → Unit Tests → SonarQube Analysis → Quality Gate Validation.

Fail the pipeline when required tests or quality checks fail.

Allow Production deployment only after successful validation and authorized Environment Approval.

Q6. 🔴 How would you securely retrieve secrets from Azure Key Vault and use them during deployment?

Create an Azure Resource Manager Service Connection with access to the required Key Vault secrets.

Use AzureKeyVault@2 or a Key Vault-linked Variable Group to retrieve them.

Pass secrets securely to deployment tasks without printing their values in logs.

Q7. 🔴 A Production deployment fails. How would you investigate it and roll back to the previous successful version?

Check pipeline logs, deployment history, application logs, and health checks.

Identify whether the issue is related to application code, configuration, infrastructure, or database changes.

Redeploy the previous successful artifact/image, validate application health, and investigate the root cause.

Q8. 🔴 How would you handle an emergency Production hotfix while maintaining your normal CI/CD process?

Create a hotfix branch from the current Production release and apply the required fix.

Run automated tests, obtain expedited code review and approval, then deploy through the existing pipeline.

Verify Production and merge the fix back into the relevant development branches.

Q9. 🔴 How would you secure the complete Production CI/CD pipeline, including repositories, branch policies, secrets, Service Connections, environments, and approvals?

Protect repositories using branch policies, PR reviews, and build validation.

Store secrets in Azure Key Vault and secure Service Connections using least privilege.

Restrict Production Environment access, require approvals, and monitor deployment audit history.

Q10. 🟡 How would you implement reusable YAML pipelines for multiple ASP.NET Core microservices?

Create shared YAML templates for build, test, Docker image creation, and deployment.

Each microservice references the templates and supplies parameters such as project path, image name, and environment.

This ensures consistent CI/CD while reducing duplicated YAML.

Q11. 🟡 A pipeline suddenly starts failing even though application code hasn't changed. How would you troubleshoot it?

Check pipeline logs and recent changes to agents, SDK versions, dependencies, certificates, and Service Connections.

Compare the failed run with the last successful run.

Investigate external services, package feeds, network connectivity, and credential expiration.

Q12. 🟡 How would you implement zero-downtime deployment?

Use Azure App Service deployment slots, Container Apps revisions, or Kubernetes rolling deployments.

Deploy the new version, verify health checks, and gradually switch traffic where supported.

Keep the previous version available for quick rollback and use backward-compatible database changes.

All 18 sections are covered, maintaining the question order and revision-focused format.