Microsoft DevOps Engineer

Numbers and notices keep a team aligned. You build dashboards for delivery and quality, document practice in wikis, and wire alerts and webhooks into the channels where people already talk.

• Delivery and quality measures for a team
• Dashboards, widgets and Analytics views
• Wikis and living documentation
• Service hooks and webhooks
• Posting build and release events to Teams
• Release notes generated from work items

You build A team dashboard and a notification setup that posts build and release events to Teams.

Branching is a team agreement written into tooling. You compare trunk-based, feature and release-branch models, then enforce them with branch policies, required reviews and status checks in Azure Repos and GitHub.

• Trunk-based development and short-lived branches
• Feature and release branching compared
• Branch policies and required reviewers
• Status checks and build validation
• Merge strategies and the history they leave
• Code owners and review load

You build A branching strategy with enforced policies and a pull request template.

Repositories that grow slowly become repositories nobody can clone. You handle large binaries with Git LFS, trim history, and decide between a monorepo and many repositories, with the tooling each choice needs.

• Git LFS for large files
• Removing large files and sensitive data from history
• Shallow, partial and sparse clones
• Monorepo and multi-repo trade-offs
• Submodules and package-based sharing
• Repository permissions and structure

You build A repository cleanup that moves large files to LFS and measures clone time before and after.

Everything automated rests on a pipeline that is readable and reliable. You learn how pipelines are written in YAML, where they run, and how to choose between Azure Pipelines and GitHub Actions for a given team.

• Azure Pipelines and GitHub Actions compared
• Microsoft-hosted and self-hosted agents and runners
• YAML structure: stages, jobs and steps
• Triggers, schedules and conditions
• Sizing and scaling build capacity
• Reading pipeline logs to find a failure

You build A working CI pipeline for a sample application on both Azure Pipelines and GitHub Actions.

Copy-pasted pipelines drift apart. You factor shared logic into templates and reusable workflows, manage variables and environments in a controlled way, and keep many pipelines consistent without making them rigid.

• Templates in Azure Pipelines and reusable workflows in Actions
• Parameters, variables and variable groups
• Environments, approvals and checks
• Extending and enforcing a shared template
• Versioning shared pipeline code
• Retention and housekeeping

You build A shared template library used by three pipelines, with a version policy.

What a pipeline produces must be stored, found and trusted. You publish packages to feeds, version them in a way consumers can rely on, and control which sources and versions teams may pull.

• Azure Artifacts and GitHub Packages
• Feed views, upstream sources and promotion
• Semantic versioning and automated version numbers
• Pipeline artifacts compared with packages
• Retention policies and cleanup
• Securing the package supply chain

You build A package feed with promotion from prerelease to release, driven by the pipeline.

Automated tests only protect you if the pipeline acts on them. You place unit, integration, load and security tests, decide what blocks a release, and deal with flaky tests before they teach people to ignore failures.

• The test pyramid inside a pipeline
• Code coverage and where it misleads
• Load and performance tests as gates
• Release approvals and gates on external signals
• Quarantining flaky tests
• Test results and trend reporting

You build A pipeline whose stages are blocked by test results and an automated health gate.

How a release reaches users decides how much damage a bad one can do. You compare blue-green, canary and ring deployments, use feature flags, and plan rollback, so exposure grows only as confidence does.

• Blue-green deployments and slot swaps
• Canary and ring-based releases
• Feature flags and dark launches
• Database changes in continuous delivery
• Rollback and roll-forward
• Deploying to containers and serverless targets

You build A release workflow that moves a change through rings and halts on failing health checks.

Environments built by hand cannot be reviewed or reproduced. You describe infrastructure in Bicep and ARM templates, test and deploy it from pipelines, and detect when the live environment drifts from the code.

• Declarative infrastructure and idempotent deployments
• Bicep syntax, modules and parameters
• ARM templates and how Bicep compiles to them
• Validating and previewing changes before deployment
• Deploying infrastructure from a pipeline
• Detecting drift and enforcing standards

You build A Bicep module library and a pipeline that previews and deploys an environment.

Pipelines hold the keys to production, so their permissions need the tightest design. You set rights for people and pipelines, replace stored credentials with federated sign-in, and keep the secrets that remain in Key Vault.

• Service connections and what they can reach
• Workload identity federation instead of stored keys
• Managed identities for agents and deployments
• Key Vault integration in pipelines
• Permissions and approvals for production environments
• Rotating and auditing secrets

You build A permission model for build, test and production, with every stored credential replaced or vaulted.

Defects and vulnerabilities are cheapest to fix before release. You add static analysis, dependency checks and secret detection to the pipeline, decide what fails a build, and keep the findings queue workable.

• Static analysis and code scanning in pipelines
• Dependency updates with Dependabot
• Software composition analysis and licenses
• Secret detection and push protection
• Container image scanning
• Deciding what fails a build

You build Scanning wired into a pipeline with thresholds that fail the build, and a plan for the findings.

Delivery does not end at deployment. You configure Azure Monitor and Application Insights for applications and pipelines, read metrics, traces and logs with KQL, and tie alerts to the people who can act on them.

• Azure Monitor, Log Analytics and Application Insights
• Metrics, traces and logs compared
• Distributed tracing and dependency maps
• KQL queries for troubleshooting
• Alerts, action groups and on-call routing
• Feeding production findings back to the backlog

You build Application Insights and KQL alerts for a deployed service, linked back to the team’s board.

Join every practice in one flow. You plan the work, protect the source, build, test and release with gates, secure the pipeline and watch the result, then explain your choices as you would to the team that must run it.

• Choosing a branching and release strategy
• Building the pipeline and its gates
• Defining infrastructure and deployments
• Securing and monitoring the flow
• Reviewing the design with its team

You build An end-to-end delivery system for a sample application, with its decisions documented.