Free AZ-400 Practice Questions

Correct: A. Azure Boards-GitHub integration natively links commits, PRs, and branches to work items referenced by ID (e.g. "AB#123") — no manual pasting required. A Teams webhook only notifies; it doesn't create traceability links. A comment-required policy doesn't enforce linking. A wiki diagram documents intent but automates nothing.

Correct: A. Lead time measures the full span from work starting (first commit) to delivery — exactly what's being asked. Velocity measures throughput of completed story points per sprint, not elapsed time for a single change. Burndown tracks remaining work within a sprint. Open PR count is a snapshot, not a time-based flow metric.

Correct: A. A webhook is the general-purpose integration mechanism for pushing custom-formatted events to external systems like Teams when no built-in connector matches the required format. Conditional access governs sign-in behavior, unrelated to pipeline notifications. A work item automation rule operates on Boards items, not pipeline events. Branch protection rules gate merges, not notifications.

Correct: A. Trunk-based development already describes what the team is doing — short-lived branches merged frequently into a single trunk — and needs no new structure. Gitflow adds permanent branch types the team explicitly doesn't need. A long-lived staging branch and permanent per-feature branches both reintroduce the long-lived-branch overhead trunk-based development is designed to avoid.

Correct: A. Git LFS is purpose-built for large individual files — it replaces the file content in Git with a lightweight pointer, keeping repository size and clone time manageable. Scalar solves large-repository (many files, deep history) performance, not large individual files — a different scaling problem. A shallow clone policy isn't a real enforceable Git feature via branch protection. A release branch per asset version doesn't address the underlying large-file storage problem.

Correct: A. Removing data from source control history requires rewriting the commits that contain it (via a history-rewriting tool) and force-pushing, followed by every clone being reset — a new commit or .gitignore entry leaves the secret fully intact in prior commits' history. Rotating the key is a necessary follow-up but does not itself remove the secret from the repository, which the requirement explicitly calls for.

Correct: A. SemVer's major.minor.patch structure explicitly communicates breaking vs. compatible changes to consumers, which is exactly the stated need. CalVer communicates release cadence, not compatibility. A bare incrementing build number and reusing the pipeline's build ID both carry no compatibility semantics at all — consumers would have no way to infer breaking-change risk.

Correct: A. Feed views let a package version be published freely to a local/working view while only promoting vetted versions to a release view that consumers point at — exactly the gate described. A naming convention is a manual, unenforced signal. Branch policies gate code merges, not which package versions reach a feed. A retention policy manages storage, not quality gating.

Correct: A. Jobs with no dependency on each other's output can run in parallel across multiple agents within the same stage, directly cutting wall-clock time. Splitting into separate manually-triggered pipelines adds coordination overhead without automatic parallelism. Merging into a single script step forces sequential execution. Reducing run frequency doesn't address per-run duration and delays feedback.

Correct: A. A shared YAML template centralizes common steps so a single edit (adding the scan step) propagates to every referencing pipeline. Copy-pasting into twelve files reintroduces the exact duplication problem being solved. Merging into one monorepo pipeline is a disproportionate restructuring not required by the stated problem. A drift-detection task finds the problem after the fact rather than preventing it.

Correct: A. A hybrid pipeline mixes Microsoft-hosted agents (for stages with no special environment needs, like build) with a self-hosted agent placed where it can reach the on-prem, non-internet-facing target and has the required proprietary software installed. Microsoft-hosted agents alone cannot reach an isolated on-prem server regardless of VPN, since the hosted agent pool itself isn't deployed there. Using self-hosted for both stages is unnecessary when the build stage has no special requirement. Azure Deployment Environments provision on-demand Azure dev/test environments — not a way to virtualize an existing on-prem server.

Correct: A. Canary deployment is specifically designed to expose a new version to a small percentage of live traffic and scale exposure based on observed metrics — exactly the requirement. Blue-green swaps all traffic to the new environment at once, which doesn't provide graduated, percentage-based exposure. The other two options describe having no staged rollout mechanism at all, which is the opposite of what's being asked for.

Correct: A. The code is already deployed everywhere — the requirement is purely about which users experience the feature, and toggling that instantly without a new deployment. A feature flag does exactly that: it gates a code path already present in the build. Deployment rings and canary releases both control which servers/infrastructure receive a build, not which end users see a feature within an already-deployed build. A blue-green swap would require redeploying to the previous environment, which contradicts "without a new deployment."

Correct: A. A hotfix path plan is precisely an alternate, faster route through the pipeline — reduced scope testing focused on the affected area, still gated by review/approval — that balances urgency against risk. Disabling all gates removes necessary safeguards entirely. Waiting for the next full run defeats the "within hours" requirement. Bypassing the pipeline entirely removes traceability, testing, and approval altogether, which a hotfix path plan is specifically designed to avoid while still being fast.

Correct: A. Bicep (or ARM) templates in source control, deployed via pipeline, are exactly what "declarative, version-controlled, pipeline-reviewed infrastructure" describes — the core of an infrastructure-as-code strategy. Manual portal configuration with wiki documentation isn't declarative or version-controlled and drifts easily. Ad hoc scripts run by whoever is on call lack the consistency and review process required. Azure Advisor gives recommendations; it does not define or enforce a desired state.

Correct: A. Migrating classic pipelines to YAML gives version-controlled, diffable, code-reviewable pipeline definitions and gets ahead of the deprecation of the classic editor — exactly what "maintain pipelines" as an AZ-400 skill covers. Leaving them unchanged ignores both the stated deprecation risk and the version-control requirement. A PDF export documents but doesn't make the pipeline itself version-controlled or reviewable. Manual runbooks remove automation entirely, which is a regression, not a migration.

Correct: A. Workload identity federation lets GitHub Actions authenticate to Azure via a short-lived, federated token with no long-lived secret stored anywhere — the secretless option external CI/CD needs. A longer rotated secret is still a long-lived credential, just rotated. A personal access token ties automation to an individual's identity and is also a stored, long-lived credential. Moving the same client secret into Key Vault relocates it but doesn't eliminate the credential itself.

Correct: A. Defender for Cloud DevOps Security is the unified posture layer purpose-built to connect both GitHub and Azure DevOps into a single Defender for Cloud view covering secrets, misconfigurations, and open-source risk — exactly the consolidated view requested. Dependabot alone only covers dependency vulnerabilities on GitHub. CodeQL performs code scanning, not secrets/misconfiguration posture, and doesn't cover GitHub in this option. A manually aggregated spreadsheet is not a consolidated, automated view.

Correct: A. Application Insights distributed tracing follows a single request as it flows across multiple services, pinpointing exactly which hop introduces latency — precisely what's needed here. A Log Analytics workspace with no telemetry configured to feed it has nothing to analyze. Build agent capacity is unrelated to runtime request latency. An NSG rule is a network security control, not a diagnostic tool for latency.

Correct: A. A basic KQL query against the requests table, filtered by failure result code and a time window, is the direct way to interrogate logs stored in Azure Monitor Logs — exactly the AZ-400 "interrogate logs using basic KQL" skill. The Activity Log records management operations (like resource changes), not application request telemetry. A pipeline YAML variable is a build-time construct, unrelated to querying runtime logs. A branch policy prevents deployments; it doesn't retrieve log data for an incident report.