Microsoft Certified: DevOps Engineer Expert — Practice Set 1

Question 1

A DevOps team wants to link Azure Boards work items to GitHub commits so that completing a commit automatically transitions the associated work item to 'Done'. Which integration should be configured?

Accepted Answer

Azure Boards natively integrates with GitHub repositories, allowing teams to link AB# work item IDs in commit messages or pull request descriptions. Azure DevOps can then automatically transition work items based on keywords such as 'fixes AB#123'. Slack webhooks do not update work items. Azure Monitor does not integrate GitHub commits with work item state. Exporting commits to Blob Storage provides no work item automation.

Question 2

A DevOps engineer needs to automatically generate release notes from the Git commit history each time a release pipeline completes successfully. Which capability supports this requirement?

Accepted Answer

Automating release note generation from Git history (using tools like git-changelog, GitVersion, or Azure DevOps tasks that parse commit messages) is a recognized DevOps practice for producing consistent, traceability-linked release documentation without manual effort. A manual email of the commit log (A) requires human effort and is not automated documentation. Azure Boards sprint export (C) captures work item summaries, not commit-level technical changes. Azure Monitor log alerts (D) notify on events but do not generate release documentation.

Question 3

A team uses Azure DevOps and Microsoft Teams. Developers want to receive a notification in their Teams channel whenever an Azure Pipelines build fails. Which configuration achieves this?

Accepted Answer

Azure DevOps has a native integration with Microsoft Teams via the Azure Pipelines app for Teams and subscriptions. Administrators can subscribe a Teams channel to build/release events, including build failures, so notifications appear automatically without custom code. Build badges are static status images, not notifications. Azure Monitor email alerts require additional setup and don't natively appear in Teams channels. A PowerShell REST call works but adds pipeline complexity when a native integration exists.

Question 4

A development team wants contributors to submit changes via short-lived feature branches that are merged into the main branch frequently (at least daily) to reduce merge conflicts and support continuous integration. Which branching strategy does this describe?

Accepted Answer

Trunk-based development (TBD) is a branching strategy where developers commit small changes to the main trunk (or via very short-lived feature branches merged within a day), enabling frequent CI runs and minimizing long-lived branch divergence. GitFlow uses long-lived develop, release, and hotfix branches with infrequent merges. Release branch strategy maintains separate branches for each release version. Forking is an isolation strategy used primarily in open-source projects.

Question 5

A repository contains a binary file (a 500 MB machine learning model) that is version-controlled. The repository clone size has grown to 20 GB, slowing CI agents. Which Git extension should the team adopt to manage this large file?

Accepted Answer

Git Large File Storage (LFS) replaces large binary files in the repository with lightweight text pointers while storing the actual file content on a remote LFS server. This keeps the repository clone small and fast, with large files downloaded on demand. Git submodules reference other repositories but do not address large binary file storage. Sparse checkout reduces the working tree but still downloads all history. Git archive creates snapshots of a repository, not a management strategy for large files.

Question 6

A team has accidentally committed a file containing API secrets to their Azure Repos Git repository. The commit is already in the main branch history. Which Git approach removes the specific file's content from all commits in the repository history?

Accepted Answer

To remove a sensitive file from all commits in a repository's history, you must rewrite the Git history using tools such as git filter-repo or BFG Repo Cleaner. These tools scan every commit and remove the specified file or content. Simply deleting the file in a new commit (A) leaves the content accessible in earlier commits. A .gitignore rule (C) prevents future tracking but does not affect existing commits. Archiving and recreating (D) loses all branch and tag history and is unnecessarily disruptive.

Question 7

A DevOps team wants to define an Azure Pipelines build pipeline using a file stored in the same Git repository as the application code. Which pipeline format should be used?

Accepted Answer

Azure Pipelines YAML pipelines are defined in a YAML file (typically azure-pipelines.yml) stored in the source repository alongside the application code. This enables pipeline-as-code, version control of pipeline definitions, and code review of pipeline changes. Classic (visual) pipelines are configured in the UI and not stored as code in the repo. A PowerShell scheduled task is not an Azure Pipelines pipeline. Jenkins is a separate CI system, not an Azure Pipelines format.

Question 8

A team uses Azure Artifacts to host private NuGet packages. They want to configure a CI pipeline so that downstream projects always consume the latest stable published version of an internal package, following semantic versioning. Which versioning scheme should they apply to pipeline artifact versions?

Accepted Answer

Semantic versioning (SemVer) communicates the nature of changes — MAJOR for breaking changes, MINOR for backward-compatible features, PATCH for bug fixes — allowing consumers to safely define version ranges (e.g., ~1.2.0) to receive patches without unexpected breaking changes. CalVer encodes dates but doesn't signal compatibility. Random GUIDs provide no ordering or compatibility signal. A monotonic counter provides ordering but no compatibility semantics.

Question 9

A DevOps engineer wants to run integration tests in an Azure Pipeline only after all unit tests pass and only on the main branch. How should this be modeled in a YAML pipeline?

Accepted Answer

A multi-stage YAML pipeline allows defining a dependency between stages (dependsOn) so the integration test stage runs only after the unit test stage succeeds, and a condition on the integration test stage (e.g., and(succeeded(), eq(variables['Build.SourceBranchName'], 'main'))) restricts it to the main branch. Running tests in a single job with if conditions is less readable and maintainable. Two separate pipelines with webhooks introduces unnecessary coupling and complexity. Running all tests in parallel defeats the sequential dependency requirement.

Question 10

Contoso's release pipeline deploys to production, but the team requires that a release manager manually reviews and approves the deployment after the staging environment tests pass. How should this be implemented in an Azure Pipelines YAML pipeline?

Accepted Answer

Azure Pipelines YAML environments support pre-deployment checks including required approvals from specified users or groups. When a pipeline stage targets an environment with an approval check, the pipeline pauses and sends the approver a notification. Only after they approve does the stage execute. A PowerShell sleep (A) is a hack that wastes pipeline minutes and cannot handle approver input. A variable group toggle (C) requires manual variable edits and is not an auditable approval workflow. A scheduled delay (D) doesn't allow a human to review and decide.

Question 11

A team wants to implement feature flags in their Azure-hosted application so that new features can be enabled or disabled per user segment without redeploying code. Which Azure service is the recommended solution?

Accepted Answer

Azure App Configuration Feature Manager provides a centralized feature flag management service. Applications query flag state at runtime, enabling operators to toggle features on or off, target specific user segments, or roll out gradually — all without redeploying code. Key Vault stores secrets and keys, not feature flags. Deployment slots enable slot-level code switching (blue-green), not per-user feature targeting. Logic Apps are workflow automation services, not feature flag stores.

Question 12

A DevOps engineer is designing a deployment strategy for a high-traffic web API. The team wants to validate the new version with a small subset of users before full rollout, with the ability to revert immediately if error rates increase. Which TWO deployment strategies directly support progressive exposure with fast rollback? Choose 2.

Accepted Answer

Canary deployments route a small percentage of traffic to the new version, allowing monitoring before full rollout — if errors appear, traffic is shifted back immediately. Blue-green deployments run two identical environments (blue=live, green=new), switch traffic atomically, and roll back by switching traffic back with zero downtime. Big-bang and in-place upgrades replace all instances at once with no ability to gradually validate. Manual FTP upload is not a structured deployment strategy.

Question 13

A team wants to reuse a common set of pipeline steps (build, test, scan) across 15 different Azure Pipelines without duplicating YAML. Which Azure Pipelines mechanism allows them to define steps once and reference them in multiple pipelines?

Accepted Answer

YAML templates in Azure Pipelines allow you to define reusable stages, jobs, steps, or variables in a separate YAML file and reference them with the template keyword from any number of pipelines. This creates a single source of truth for common pipeline logic. Variable groups store shared variable values but not step definitions. Pipeline environments manage deployment targets and approval gates. Retention policies control how long artifacts and runs are kept.

Question 14

A DevOps team is migrating from a classic Azure Pipelines release pipeline to YAML. The classic pipeline has a deployment group task that deploys to on-premises servers. The YAML equivalent must deploy to the same servers and support rolling deployment. What YAML construct replaces the classic deployment group in YAML pipelines?

Accepted Answer

In YAML pipelines, Azure Pipelines Environments support virtual machine resources — on-premises or cloud servers registered by installing the Azure Pipelines agent. Deployment jobs that target these environments support rolling deployment strategies (rolling, canary, runOnce) equivalent to classic deployment group behavior. A container resource targets Docker containers, not on-premises VMs. Using a Microsoft-hosted pool (ubuntu-latest) cannot reach on-premises servers. A REST API template approach bypasses native Azure Pipelines deployment tracking features.

Question 15

A DevOps engineer needs to define the desired configuration state of an Azure Windows VM fleet using a declarative approach, ensuring all VMs consistently have specific Windows features enabled and services running without using custom scripts. Which Azure IaC technology supports this requirement?

Accepted Answer

Azure Automation State Configuration is built on PowerShell Desired State Configuration (DSC) and allows administrators to declaratively define the configuration of Windows (and Linux) nodes — specifying Windows features, services, file system state, and registry settings. The Azure Automation service continuously monitors nodes and remediate drift. ARM templates with Custom Script Extension run imperative scripts, which are harder to maintain and idempotency must be managed manually. Bicep deploys Azure resources but does not manage in-guest OS configuration. Variable groups store pipeline variables, not server configuration state.

Question 16

A DevOps engineer is optimizing a slow Azure Pipeline. The pipeline currently runs 8 independent test suites sequentially and takes 40 minutes. Which TWO YAML pipeline changes will reduce total pipeline duration? Choose 2.

Accepted Answer

Splitting independent test suites into parallel jobs lets multiple agents execute them simultaneously, reducing wall-clock time proportionally to the number of agents. A matrix strategy achieves the same effect with less YAML repetition by generating a job for each matrix entry. Adding more sequential steps (B) increases duration. Increasing the timeout (D) just allows the pipeline to run longer — it doesn't reduce duration. Running everything in one PowerShell script (E) is still sequential and may be worse than the current approach.

Question 17

A pipeline frequently fails on intermittently failing (flaky) tests. The team wants to track the flakiness rate over time and identify which tests are most unstable. Which Azure Pipelines built-in feature provides this visibility?

Accepted Answer

Azure Pipelines has built-in test result reporting that detects and tracks flaky tests over multiple runs. The Tests tab in the pipeline run and the Analytics views display pass/fail rates per test, identify historically flaky tests, and allow teams to mark tests as flaky for suppression. A YAML retry condition can hide flakiness rather than surface it. Azure Monitor log queries require custom configuration and do not natively understand test flakiness. Azure Boards work items track development tasks, not test-level stability metrics.

Question 18

A team publishes NuGet packages to Azure Artifacts. They want internal upstream packages to be available alongside packages from nuget.org in a single feed without managing two separate feed configurations in each project. Which Azure Artifacts feature enables this?

Accepted Answer

Azure Artifacts supports upstream sources, allowing a single feed to proxy and cache packages from external sources like nuget.org alongside internally published packages. Developers configure only one feed URL, and the service handles fetching from upstream sources transparently. Configuring each developer's NuGet.config to list multiple feeds (A) is error-prone and requires maintaining configurations across the team. Manually re-publishing public packages (C) is labor-intensive and creates licensing complications. There is no native Azure Pipelines task to merge feeds (D).

Question 19

A DevOps team deploys a microservice to Azure Container Apps via a pipeline. They need each pipeline run to produce a unique, immutable container image tag so that deployments are traceable to their source commit and earlier versions can be redeployed exactly. Which tagging strategy best meets this requirement?

Accepted Answer

Tagging container images with the Git commit SHA creates a direct, immutable link between the deployed artifact and the source code commit. This enables traceback from a running container to the exact code it was built from, and any previous image can be redeployed by referencing its SHA tag. The 'latest' tag is mutable and overwritten by each push, providing no traceability. A date-only tag may collide if multiple builds run on the same date and provides no commit traceability. Using only the digest is correct for immutability but the digest is not human-readable and not easily referenced in deployment manifests.

Question 20

A DevOps engineer needs to store a database connection string securely so that Azure Pipelines can retrieve it at runtime without storing it in the YAML file or the pipeline variable group in plaintext. Which Azure service should be used?

Accepted Answer

Azure Key Vault is the recommended solution for storing secrets such as connection strings. Azure Pipelines supports linking Key Vault secrets as secret pipeline variables, which are masked in logs and never stored in the pipeline definition. Blob Storage is not a secrets store and does not mask values. Hardcoding secrets in source code exposes them to anyone with repository access. Base64 encoding is not encryption and provides no actual security — the secret is trivially decoded.

Question 21

A GitHub Actions workflow needs to deploy resources to Azure. The team wants to avoid storing long-lived credentials in GitHub Secrets. Which authentication approach should be used?

Accepted Answer

Workload identity federation (OpenID Connect/OIDC) allows GitHub Actions to exchange a short-lived GitHub-issued token for an Azure access token without storing any long-lived credentials. Azure trusts the GitHub OIDC issuer for configured federated credentials, so no secrets need to be stored in GitHub. Storing a client secret (A) still requires a long-lived credential and rotation. A SAS token (C) is a long-lived credential for a specific storage account, not a general Azure deployment credential. Embedding subscription owner credentials (D) is a critical security violation.

Question 22

A DevOps team is implementing a security scanning strategy for their pipeline. Which TWO scanning categories does GitHub Advanced Security provide for code repositories? Choose 2.

Accepted Answer

GitHub Advanced Security provides three main capabilities: code scanning (using CodeQL or third-party tools to find security vulnerabilities in application code), secret scanning (detecting accidentally committed API keys, tokens, and credentials), and Dependabot for dependency vulnerability alerts. Infrastructure performance benchmarking, network packet inspection, and database query analysis are outside the scope of GitHub Advanced Security.

Question 23

A pipeline builds a Docker container image and pushes it to Azure Container Registry. The security team requires that known OS-level CVEs are detected before the image is deployed to production. Which Azure DevOps security automation practice addresses this?

Accepted Answer

Automating container image scanning in the pipeline (using tools such as Trivy, Aqua Security, or Microsoft Defender for Containers image scanning) detects OS and application CVEs in the container image before it is promoted to production. OWASP ZAP performs dynamic application security testing (DAST) against running applications — not container image OS layers. Dependabot scans open-source package dependencies in source code, not OS packages inside container images. Defender for Servers protects the build agent host, not the container image artifact being built.

Question 24

A DevOps engineer needs to write a query to find all Azure Monitor Log Analytics log entries where the HTTP response status code is 500 in the last 24 hours. Which query language is used in Azure Monitor Log Analytics?

Accepted Answer

Azure Monitor Log Analytics uses Kusto Query Language (KQL) as its native query language. KQL is a read-only query language optimized for large-scale log and telemetry data analysis with operators such as where, summarize, project, and render. T-SQL is used by SQL Server and Azure SQL. GraphQL is an API query language. SPARQL queries RDF semantic data and has no relation to Azure Monitor.

Question 25

A microservices application is deployed across 5 Azure services. When a user reports a slow checkout, the support team needs to trace the specific request across all 5 services to find which service introduced the latency. Which Application Insights feature provides this cross-service trace visualization?

Accepted Answer

Application Insights distributed tracing correlates telemetry across all participating services using a shared operation ID propagated via headers. The end-to-end transaction search and Application Map visualize the full call chain, showing which service contributed the most latency. Azure Monitor Metrics show aggregate resource-level metrics but not individual request traces across services. Azure Service Health shows platform-level incidents, not application-level traces. Azure Advisor provides proactive recommendations but not real-time trace diagnostics.

AZ-400 — DevOps Engineer Expert