AZ-400: Designing and Implementing Microsoft DevOps Solutions

GitHub Flow is a lightweight workflow for managing code changes using branches. It connects with Azure Pipelines to automate building, testing, and deploying code. The process starts with a stable main branch. Developers create separate feature branches for each new task. To protect the main branch, teams set up branch protection rules in GitHub, which can require that changes be approved via a pull request before merging.

Using Azure DevOps Wiki helps teams create and share project documentation in one central place. The wiki supports collaboration and requires good organization and visual aids to be effective. You should structure content using logical folders and clear naming conventions, grouping related pages like "Architecture" or "Processes" together.

To visualize workflow metrics, teams must first gather the correct underlying data from their projects. Work item queries in Azure DevOps serve as the primary data source, pulling specific records like user stories, bugs, or tasks based on set criteria. These queries retrieve items that have transitioned through various lifecycle states, such as proposed, active, and completed. By targeting precise work item states and timeframes, these queries feed clean, accurate data directly into the dashboard configuration.

Managing large files in a standard repository can slow down development because every clone downloads the full history of those assets. Git Large File Storage (Git LFS) addresses this issue by replacing large files in the repository with tiny text pointers while storing the actual data on a remote server. When a developer clones the repository, Git LFS only downloads these pointers and lazily fetches the full files when they are actually needed. This keeps local repositories small and ensures that common Git operations remain fast.

In Azure Repos, teams choose a branching strategy to manage how code is written and integrated. The three main models are trunk-based development, feature branch development, and release branch development. The choice depends on team size, how often you release software, and your level of testing automation. Each model affects how developers collaborate and how quickly you can deliver updates.

Choosing a configuration management technology for Azure infrastructure depends on three main criteria: idempotent operation (the tool can repeatedly apply the same configuration without causing drift), integration with Azure Resource Manager (ARM) templates, and fit into CI/CD pipelines such as Azure DevOps. Each tool handles these requirements slightly differently, so the best choice depends on the team’s existing skills and the complexity of the environment.

Azure DevOps works with Azure Policy to add security and governance checks to your release process. First, you create or manage policies in the Azure portal that can restrict deployments to specific regions, require logging, or enforce other compliance rules. In Azure Pipelines, you add a pre-deployment or post-deployment condition using the Check Azure Policy compliance task, which acts as a gate that stops the deployment if any policies are violated.

When choosing a package management tool, the decision depends on how each option handles security, access control, retention, and pipeline integration. Both GitHub Packages registry and Azure Artifacts offer robust solutions, but they fit different developer workflows and compliance requirements. Security rules, how long packages are stored, and where your code is hosted are the primary factors to consider during this evaluation.

Monitoring pipeline health means tracking how well your automated build and release processes are running. The key metrics to watch are failure rate (how often a pipeline run fails), duration (how long a run takes from start to finish), and flaky tests (tests that pass and fail unpredictably without any code change). A high failure rate signals that something is broken in the pipeline itself or in the code being built, while increasing duration can point to slow steps like long-running tests or resource bottlenecks. Flaky tests are especially dangerous because they erode trust in the pipeline — a team that cannot tell whether a failure is real will start ignoring failures altogether. To manage flaky tests, identify them by tracking test results over time, quarantine them so they do not block the pipeline, and fix them as a priority rather than simply rerunning the pipeline.

Choosing between GitHub Actions and Azure Pipelines depends on your team's existing tools and needs. Both automate building, testing, and deploying code, which is called CI/CD. GitHub Actions works directly inside GitHub repositories, scaling automatically and offering a free tier with usage limits. Azure Pipelines is part of the Azure DevOps ecosystem and offers more flexibility, including the choice between Microsoft-hosted agents and self-hosted agents you run on your own hardware. This control over the build environment is important for meeting strict security or compliance rules.

Blue-green deployment uses two identical environments, often called blue and green. In Azure, you can set these up as separate App Service deployment slots or distinct virtual machine scale sets. The live version (blue) keeps serving all traffic while the new version (green) is deployed and tested. Once the green environment passes health checks, a routing rule on Azure Traffic Manager or Application Gateway switches incoming traffic from blue to green. The switch happens instantly, so downtime is zero. If the green version fails, you simply route traffic back to blue, giving a fast rollback. This model works best when you need a clear, immediate cutover and have the resources to maintain two full environments.

Service Principals and Managed Identities solve the same core problem: they let applications prove their identity to Azure without embedding passwords in code. A Service Principal is an identity you create manually for an application that needs to access Azure resources. When you create one, you also create credentials like a client secret or certificate, and you decide exactly what permissions it should have. Because you manage these credentials yourself, you must store them securely and rotate them on a schedule to reduce risk.

Azure Key Vault is a cloud service that securely stores sensitive information such as secrets, encryption keys, and certificates. It acts as a central repository so that applications and automation scripts can retrieve these values without hardcoding them in code or configuration files. This keeps credentials protected while still making them available to authorized services, which is essential for secure DevOps automation.

Dependency vulnerability scanning checks the open-source libraries and packages an application uses for known security flaws. In Azure DevOps, teams can integrate tools like WhiteSource Bolt or GitHub Dependabot to automatically scan dependencies. The pipeline runs the scan after restoring packages and before building, so outdated or vulnerable components are flagged immediately. If a critical vulnerability is found, the pipeline can fail or send an alert to prevent the insecure dependency from reaching production.

To inspect infrastructure performance, you start by collecting data on CPU, memory, disk, and network usage. Azure Monitor gathers these metrics from all your Azure resources, such as virtual machines, databases, and app services. By watching CPU load, you can spot when a server is working too hard. Memory metrics help you find leaks or insufficient RAM. Disk I/O (input/output) speeds and operation counts reveal storage bottlenecks, and network traffic rates show potential congestion or connectivity problems. Azure Monitor stores this data as time-series metrics and logs, giving you a historical view of how each resource behaves.

To connect Azure monitoring with DevOps platforms, you first set up a telemetry pipeline by configuring diagnostic settings on each Azure resource. These settings decide which metrics and logs to collect and forward them to a Log Analytics workspace, where the data becomes available for analysis. You also choose which data sources to stream, such as performance counters or event logs.