This chapter covers the integration of Azure DevOps with Azure architecture, a critical topic for the AZ-305 exam. It explains how Azure DevOps services—Azure Boards, Azure Repos, Azure Pipelines, Azure Test Plans, and Azure Artifacts—enable continuous integration and continuous delivery (CI/CD) for Azure solutions. Approximately 15-20% of exam questions touch on DevOps integration, focusing on designing for operability, automation, and secure software delivery. Mastering this topic ensures you can architect solutions that are not only well-designed but also efficiently deployed and managed.
Jump to a section
Imagine constructing a high-rise building. The architect (Solution Architect) designs the blueprint (architecture). The construction project manager (Azure DevOps) doesn't design the building but orchestrates the entire process: scheduling, resource allocation, quality checks, and communication. They use a centralized system (Azure Boards) to track tasks like foundation work, electrical wiring, and finishing. When a change order comes (feature request), the project manager updates the plan, triggers a new work order (work item), and assigns it to the right crew (development team). The project manager also runs automated inspections (CI/CD pipelines) to ensure each floor meets specifications before proceeding. If a concrete pour fails a strength test (build failure), the project manager stops work, logs the issue, and routes it back to the structural engineer (developer) for rework. Without the project manager, the architect's blueprint would be useless—crews would work in silos, miss deadlines, and produce an unsafe building. Similarly, Azure DevOps turns architecture into a living, automated, and traceable process. The key is that the project manager doesn't replace the architect; they execute and enforce the architect's vision through systematic workflows, automated gates, and feedback loops. This mirrors how Azure DevOps integrates with Azure architecture: it enables continuous delivery, infrastructure as code, and monitoring, all aligned with the architectural decisions made during design.
What is Azure DevOps and Why It Exists
Azure DevOps is a set of development tools provided by Microsoft for planning, developing, delivering, and monitoring applications. It evolved from Visual Studio Team Services (VSTS) and was rebranded in 2018. Its purpose is to enable DevOps practices—a combination of development (Dev) and operations (Ops)—to shorten the development lifecycle and deliver high-quality software continuously. In the context of Azure architecture, Azure DevOps is the operational backbone that turns architectural designs into running, monitored, and updated solutions.
How Azure DevOps Works Internally
Azure DevOps consists of five core services: - Azure Boards: Work tracking with Kanban and Scrum boards, backlogs, and dashboards. - Azure Repos: Git repositories for source control, supporting both centralized and distributed version control. - Azure Pipelines: CI/CD system that builds, tests, and deploys code to any platform or cloud. - Azure Test Plans: Manual and exploratory testing tools. - Azure Artifacts: Package management for Maven, npm, NuGet, and more.
These services are integrated via REST APIs and webhooks. For example, when a developer pushes code to Azure Repos, a webhook triggers an Azure Pipeline. The pipeline runs a series of tasks (e.g., compile code, run unit tests, deploy to Azure App Service) defined in a YAML file stored in the repository. Each pipeline execution produces a log and artifacts (build outputs) that can be used for further stages or releases.
Key Components, Values, Defaults, and Timers
Agent Pools: Pipelines run on agents. Microsoft-hosted agents have a default timeout of 60 minutes (configurable up to 360 minutes). Self-hosted agents have no timeout by default but can be configured.
Pipeline Triggers: Continuous integration triggers by default on every push to a branch. Scheduled triggers can be set with cron syntax (e.g., 0 0 * * * for daily at midnight).
Retention Policies: Builds and releases are retained for 30 days by default, but can be customized per project.
YAML Pipelines: Use trigger: and pr: to specify CI and pull request triggers. The pool: section defines the agent pool.
Service Connections: Used to authenticate to Azure resources. For example, an Azure Resource Manager (ARM) service connection uses a service principal with specific roles (e.g., Contributor) on a subscription or resource group.
Variables: Can be defined at pipeline, stage, or job level. Secret variables are encrypted and cannot be read in logs.
Approvals and Gates: Release pipelines support manual approvals and gates (e.g., check Azure Monitor metrics before deployment).
Configuration and Verification Commands
To create a pipeline using Azure CLI:
az pipelines create --name "MyPipeline" --repository https://dev.azure.com/org/project --branch main --yaml-path azure-pipelines.ymlTo list pipelines:
az pipelines list --project "MyProject"To trigger a pipeline run:
az pipelines run --id 123 --project "MyProject"To view pipeline runs:
az pipelines build list --project "MyProject" --pipeline-id 123How Azure DevOps Interacts with Related Technologies
Azure DevOps integrates deeply with Azure services: - Azure Key Vault: Store secrets in Key Vault and reference them in pipelines using variable groups linked to Key Vault. - Azure App Service: Deploy web apps using the Azure Web App task, which supports slot swapping (deploy to staging, then swap to production). - Azure Functions: Deploy function apps with the Azure Function App task. - Azure Kubernetes Service (AKS): Use the Kubernetes manifest task or Helm to deploy containers. - Azure Monitor: Send pipeline telemetry to Application Insights for monitoring deployment success rates. - Azure Policy: Enforce compliance by integrating policy checks in pipelines (e.g., ensure resources are deployed in allowed regions). - Azure Resource Manager (ARM) Templates / Bicep: Deploy infrastructure as code using the Azure Resource Group Deployment task.
Best Practices for Architecture Integration
Infrastructure as Code (IaC): Store ARM/Bicep templates in Azure Repos. Deploy infrastructure via pipelines before application code.
Environment Promotion: Use multi-stage pipelines (e.g., dev -> test -> prod) with approval gates between stages.
Secrets Management: Never hardcode secrets. Use Azure Key Vault and variable groups.
Artifact Versioning: Use Azure Artifacts to store built packages with semantic versioning.
Testing: Integrate unit tests, integration tests, and load tests in pipelines. Use Azure Test Plans for manual testing.
Monitoring Feedback: After deployment, automatically run smoke tests and send metrics to Azure Monitor. If failure rate exceeds threshold, trigger rollback.
Common Pitfalls
Not Using Managed Identities: Relying on service principals with secrets that expire. Prefer managed identities for Azure resources.
Hardcoded Variables: Leads to security breaches. Always use pipeline variables or Key Vault.
Ignoring Retention Policies: Build artifacts accumulate, consuming storage and costs. Set appropriate retention limits.
No Approval Gates: Direct deployment to production without approvals increases risk of outages.
Misconfigured Agent Pools: Using Microsoft-hosted agents for long-running builds may hit timeout limits. Consider self-hosted agents for complex builds.
Design Architecture and Repos
Start by designing the Azure architecture (e.g., App Service, SQL Database, AKS). Create Azure Repos to store application code and infrastructure templates. Use branch policies (e.g., require pull request reviews) to enforce quality. This step ensures that all code changes are tracked and reviewed before integration.
Set Up Continuous Integration
Configure Azure Pipelines to trigger on code pushes to main branch. The pipeline builds the application, runs unit tests, and produces artifacts. Use YAML to define the pipeline. For example, a Node.js app pipeline runs `npm install`, `npm test`, and `npm run build`. If tests fail, the pipeline stops and alerts the team.
Deploy Infrastructure as Code
Add a stage in the pipeline to deploy Azure resources using ARM templates or Bicep. Use the Azure Resource Group Deployment task. For example, deploy a virtual network, subnet, and AKS cluster. Use parameters to customize for each environment. This ensures infrastructure is consistent and repeatable.
Deploy Application to Dev
After infrastructure is ready, deploy the application artifacts to the development environment. Use tasks like Azure Web App Deploy or Kubernetes apply. Run smoke tests (e.g., HTTP GET to check app responds). If tests pass, promote to next environment; otherwise, fail the pipeline.
Promote Through Stages
Configure multi-stage pipeline with manual approval gates for production. For example, after dev, deploy to test environment and run integration tests. Then require approval from a release manager before production. Use release pipelines or environment triggers in YAML (e.g., `environment: 'prod'` with approvals).
Monitor and Rollback
After production deployment, monitor using Azure Monitor and Application Insights. Set up alerts for high error rates or latency. If issues detected, trigger a rollback to the previous successful deployment. Azure Pipelines supports automatic rollback via deployment slots or Kubernetes rolling updates.
Scenario 1: E-commerce Platform on AKS
A large e-commerce company runs its microservices on Azure Kubernetes Service (AKS). They use Azure DevOps for CI/CD. Each microservice has its own pipeline that builds a Docker image, pushes it to Azure Container Registry (ACR), and deploys to AKS using Helm. The architecture includes Azure Front Door for global load balancing, Azure Redis Cache for session state, and Azure SQL Database for orders. The pipeline runs security scans (Trivy) on images and only promotes to production if no critical vulnerabilities are found. In production, they use blue-green deployments: the pipeline deploys the new version to a staging slot, runs smoke tests, and then swaps the slot. If smoke tests fail, the pipeline automatically rolls back. This setup reduced deployment failures by 90% and cut release time from weeks to hours.
Scenario 2: Financial Services with Compliance
A bank needs to deploy a loan processing application to Azure with strict compliance requirements (e.g., PCI DSS). They use Azure DevOps with Azure Policy integration. The pipeline includes a stage that runs Azure Policy compliance checks before any resource deployment. If a resource violates policy (e.g., not using encryption at rest), the pipeline fails. They also use Azure Key Vault to store database connection strings and API keys, referenced via variable groups. The architecture uses Azure App Service with deployment slots for zero-downtime deployments. The pipeline has multiple approval gates: one from the security team and one from the compliance officer. All pipeline runs are logged and retained for 7 years for audit purposes. This ensures every deployment is compliant and auditable.
Scenario 3: SaaS Application with Multi-Tenant Architecture
A SaaS provider uses Azure DevOps to manage deployments across hundreds of tenants. They use Azure Repos with a monorepo containing tenant-specific configuration files. The pipeline uses a matrix strategy to deploy to each tenant's Azure environment (separate resource groups). They use Azure App Service with slot swapping for each tenant. The architecture includes Azure SQL Database with elastic pools and Azure Cosmos DB for global distribution. The pipeline runs tenant-specific integration tests. If a tenant's deployment fails, only that tenant is affected. They use Azure Monitor to aggregate logs and metrics across tenants, and set up alerts for tenant-specific issues. This approach allows them to roll out updates gradually, starting with a small set of beta tenants before full rollout.
What AZ-305 Tests on This Topic
The AZ-305 exam objectives under 'Design for operations' (objective 4.4) include:
Design a DevOps strategy for Azure solutions
Recommend appropriate tools for CI/CD, monitoring, and automation
Design for deployment slots and blue-green deployments
Design for infrastructure as code (ARM, Bicep, Terraform)
Design for secrets management (Key Vault)
Design for release management and approvals
Common Wrong Answers and Why Candidates Choose Them
'Use Azure DevOps for all automation' – Wrong because Azure DevOps is not the only tool; Azure Automation, Logic Apps, and PowerShell can also be used. The exam expects you to choose the right tool for the job.
'Deploy directly to production from the pipeline' – Wrong because best practice is to use deployment slots or staging environments. Candidates often overlook the need for zero-downtime deployments.
'Store secrets in pipeline variables' – Wrong because secrets should be stored in Azure Key Vault and referenced via variable groups. Pipeline variables are not encrypted at rest in some cases.
'Use Azure CLI in a pipeline task' – Wrong because it's better to use built-in tasks (e.g., Azure Web App Deploy) which handle authentication and retries automatically.
Specific Numbers and Terms on the Exam
Retention policy default: 30 days
Microsoft-hosted agent timeout: 60 minutes (max 360)
YAML pipeline triggers: trigger: and pr:
Approval gates: Required for production environments
Service connection types: Azure Resource Manager, Azure Classic, etc.
Variable groups: Linked to Key Vault for secrets
Deployment slots: Supported for App Service, Functions, and Kubernetes
Edge Cases and Exceptions
Self-hosted agents: Can run longer than 360 minutes, but require maintenance.
Open-source projects: Azure Pipelines offers free CI/CD for public repositories (up to 10 parallel jobs).
Multi-stage YAML: Supports dependsOn and condition for complex workflows.
Terraform integration: Azure DevOps supports Terraform tasks, but ARM/Bicep is native.
How to Eliminate Wrong Answers
If the question mentions 'automated approval for production', look for 'Approval gates' or 'Manual intervention'.
If the question asks for 'infrastructure as code', choose ARM/Bicep over PowerShell scripts.
If the question involves 'secrets', the answer should involve Azure Key Vault.
If the question is about 'zero-downtime', look for 'deployment slots' or 'blue-green'.
Azure DevOps consists of Azure Boards, Repos, Pipelines, Test Plans, and Artifacts.
CI/CD pipelines can be defined in YAML or using the classic editor; YAML is preferred.
Use Azure Key Vault to store secrets and reference them via variable groups.
Deploy infrastructure as code using ARM templates or Bicep before deploying application code.
Use multi-stage pipelines with approval gates for production deployments.
Microsoft-hosted agents have a default timeout of 60 minutes; self-hosted agents have no limit.
Default retention policy for build artifacts is 30 days.
Deployment slots enable zero-downtime deployments for App Service and Functions.
Azure DevOps integrates with Azure Monitor for post-deployment monitoring.
Branch policies (e.g., required reviewers) improve code quality in Azure Repos.
These come up on the exam all the time. Here's how to tell them apart.
Azure Pipelines (YAML)
Pipeline as code stored in repo (version controlled).
Supports complex branching and triggers.
Easier to review and audit changes.
Can be copied and reused across projects.
Preferred for modern DevOps practices.
Azure Pipelines (Classic Editor)
UI-based, no code in repo.
Limited to simple triggers.
Changes not easily auditable.
Harder to version and reuse.
Legacy approach, not recommended for new projects.
ARM Templates
JSON-based, verbose syntax.
No native modularization (use linked templates).
Steep learning curve.
Widely supported and mature.
Can be generated from Azure portal.
Bicep
Declarative DSL, concise syntax.
Supports modules and file inclusion.
Easier to read and write.
Newer, but quickly adopted.
Compiles to ARM JSON.
Azure DevOps
Integrated with Azure Boards and Test Plans.
Supports on-premises agents.
Rich set of Azure-specific tasks.
Mature release management with approvals.
Better for large enterprises with existing ADO investment.
GitHub Actions
Tighter integration with GitHub repos.
Larger community marketplace.
Free for public repos.
Simpler YAML syntax.
Better for open-source and GitHub-centric teams.
Mistake
Azure DevOps is only for CI/CD pipelines.
Correct
Azure DevOps includes five services: Azure Boards (work tracking), Azure Repos (source control), Azure Pipelines (CI/CD), Azure Test Plans (testing), and Azure Artifacts (package management). Pipelines are just one component.
Mistake
You must use Azure DevOps to deploy to Azure.
Correct
You can use GitHub Actions, Jenkins, GitLab CI, or other tools. Azure DevOps is not mandatory, but it is deeply integrated with Azure.
Mistake
Pipeline variables are secure for secrets.
Correct
Pipeline variables are not encrypted at rest by default. For secrets, use secret variables (encrypted) or better, Azure Key Vault linked via variable groups.
Mistake
Microsoft-hosted agents are always the best choice.
Correct
Microsoft-hosted agents have a 60-minute timeout (configurable to 360) and limited software. For long-running builds or custom software, self-hosted agents are better.
Mistake
CI/CD pipelines eliminate the need for manual testing.
Correct
Automated tests are essential but manual exploratory testing (via Azure Test Plans) is still valuable for user experience and edge cases.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure DevOps is a full DevOps suite including boards, repos, pipelines, test plans, and artifacts. GitHub Actions is a CI/CD platform integrated with GitHub. Azure DevOps has richer Azure-specific integrations and release management features, while GitHub Actions is simpler and has a larger marketplace. Choose based on your existing toolchain and needs.
Use Azure Key Vault to store secrets, then create a variable group in Azure DevOps that links to Key Vault. In your pipeline, reference the variable group. This way secrets are never stored in the pipeline definition or logs. Alternatively, use secret pipeline variables (encrypted), but Key Vault is more secure and manageable.
A deployment slot is a separate instance of an Azure App Service app that has its own hostname. You deploy your new version to a staging slot, run smoke tests, and then swap the staging slot with the production slot. This provides zero-downtime deployment and easy rollback by swapping again. Slots also allow traffic routing for A/B testing.
Yes, Azure DevOps has a Terraform task that runs Terraform commands (init, plan, apply). You can integrate Terraform into your pipeline to provision Azure resources. However, ARM templates and Bicep are native to Azure and may be easier to use with Azure DevOps.
Approval gates allow you to require manual approval before a stage runs. For example, you can require a release manager to approve deployment to production. Gates can also be automated (e.g., check Azure Monitor metrics before proceeding). They are configured in the pipeline's environment settings.
Create a YAML pipeline with a trigger on your repo. Use the Azure Function App task to deploy the function code. You can also deploy infrastructure using ARM/Bicep in a previous stage. For .NET, use `dotnet build` and `dotnet publish`. For Node.js, use `npm install` and `npm run build`. Ensure the function app is created beforehand or via IaC.
The default retention policy for build artifacts in Azure DevOps is 30 days. You can change this at the project level or per pipeline. Artifacts older than the retention period are automatically deleted. Be careful to set appropriate retention for compliance requirements.
You've just covered Azure DevOps Integration with Architecture — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?