Free AZ-400 practice questions

A .NET team consumes packages from the public NuGet gallery, but a recent outage of that gallery broke their builds, and they also want every external package version that the build ever restored to remain available even if it is later unlisted upstream. Within "Azure Artifacts", which feed capability should they configure to meet both needs?

• AAdd the public NuGet gallery as a separate service connection and point each build's restore step at that connection instead of at the Azure Artifacts feed, so restores skip the feed entirely.
• BConfigure the public NuGet gallery as an upstream source on the feed, so the feed proxies and caches each requested package version and continues serving the saved copy when the upstream is unavailable.check_circle Correct
• CCreate a release view on the feed named for the public gallery and promote external packages into that view manually after each build, so a curated copy of every external version is retained.
• DEnable retention policies on the feed with a high keep count, so the feed automatically downloads the public gallery and preserves a copy of each external package version for builds.

Why A is wrong: Pointing restores straight at the public gallery is tempting because it keeps the existing source, but it leaves the build directly dependent on gallery uptime and saves no copy locally, so neither requirement is met.

Why B is correct: An upstream source makes the feed a caching proxy that saves every restored version into the feed, which both insulates builds from upstream outages and retains versions even after they are unlisted upstream.

Why C is wrong: Views filter and label packages that already live in the feed, and manual promotion of every external version is unworkable, so a view cannot proxy the gallery or guarantee automatic retention.

Why D is wrong: Retention policies only decide which already-stored package versions are pruned, so they neither fetch from the public gallery nor proxy it during an outage, leaving the outage requirement unmet.

A platform team publishes an internal npm package to an "Azure Artifacts" feed. Many consuming teams should pull only versions that have passed validation and been blessed for general use, while the platform team keeps publishing in-progress builds to the same feed. Which feed mechanism lets consumers subscribe to only the blessed versions without a separate feed?

• AApply a retention policy that deletes any package version below a quality threshold, so only validated versions survive in the feed and consumers therefore receive only the blessed ones.
• BGive each consuming team a personal access token scoped to read only the validated packages, so the token itself filters the feed down to the blessed versions for those consumers.
• CPromote validated versions into the feed's @Release view and have consumers connect to the feed @Release endpoint, so they resolve only versions promoted into that view.check_circle Correct
• DPublish each validated version a second time to a separate release feed and have consumers point at that feed, so only blessed versions ever reach the consuming teams.

Why A is wrong: Retention policies prune versions by age or count, not by validation state, and deleting in-progress builds would break the platform team's own workflow, so this does not separate blessed from unblessed versions.

Why B is wrong: A token controls authentication and feed-level permission, not which versions are visible, so it cannot present consumers with a blessed-only subset and would still expose in-progress builds.

Why C is correct: Feed views expose a filtered slice of a single feed; promoting blessed versions into @Release and pointing consumers at that view endpoint gives them only validated versions while the platform team keeps publishing to @Local.

Why D is wrong: A separate feed does isolate blessed versions, but it forces duplicate publishing and re-resolution of the same artifact, which the requirement explicitly rules out by asking to avoid a second feed.

A company already hosts all its source code in "GitHub" and wants its container images and npm packages stored as close to the repositories as possible, governed by the same repository permissions and visible in the repository's interface, with the least extra tooling. Which package hosting choice best fits this requirement?

• ACreate an "Azure Artifacts" feed in a new Azure DevOps organisation and wire a synchronisation pipeline so packages published from GitHub are mirrored into the feed for storage.
• BPush the container images to a self-managed registry on a virtual machine and the npm packages to a network file share, so the team controls all storage directly next to GitHub.
• CStore both the npm packages and the container images as release assets attached to GitHub Releases, so they live in the repository and use the repository's existing permissions.
• DPublish the npm packages and container images to "GitHub Packages", which stores them alongside the source repositories and inherits the repository's access permissions and interface.check_circle Correct

Why A is wrong: Azure Artifacts is a capable feed, but standing up a separate Azure DevOps organisation and a sync pipeline adds tooling and breaks the requirement to keep packages under the same GitHub repository permissions.

Why B is wrong: A self-managed registry and file share give control but demand significant operational overhead and provide none of the repository-permission inheritance or repository visibility the requirement calls for.

Why C is wrong: Release assets do sit in the repository, but they are opaque downloads with no npm or container registry protocol, so clients cannot restore or pull them as packages as required.

Why D is correct: GitHub Packages hosts packages and container images within the same GitHub repository or organisation, governed by repository permissions and shown in the repository interface, which matches the stated proximity and least-tooling requirement.

A team hosts source in "Azure Repos" and tracks work in "Azure Boards". They want every commit and pull request that implements a user story to appear automatically on that story's work item, giving end-to-end traceability from requirement to code. What should a developer include so the link is created without anyone editing the work item by hand?

• AReference the work item by its identifier with the hash syntax, for example "Fixes #142", in the commit message or pull request description so the link is created on save.check_circle Correct
• BAdd the work item title as a tag on the pull request so the boards service can match the wording and attach the commit to the matching story automatically.
• COpen the work item and paste the commit URL into its Discussion field so reviewers can follow the hyperlink back to the implementing change in the repository.
• DAssign the work item to the same person who authored the commit so the boards service infers the relationship and records the change under that story by ownership.

Why A is correct: Azure Repos parses the hash-prefixed work item identifier in commit messages and pull requests and writes a development link onto that item, giving automatic source traceability.

Why B is wrong: Matching on free-text titles is unreliable and is not how the boards link is formed, so a tag would not create the development link on the work item.

Why C is wrong: Pasting a URL is a manual edit that produces only a comment hyperlink, not a tracked development link, and the requirement is explicitly to avoid editing the item by hand.

Why D is wrong: Assignment records who owns the item, not which commit implements it, so shared ownership cannot establish a commit-to-requirement link on its own.

A small product team wants a lightweight branching model where every change starts from a short-lived branch off main, is reviewed and validated through a pull request, and is deployed to production immediately after merge, with main always remaining deployable. Which branching strategy matches these characteristics?

• A"Gitflow", in which work flows through long-lived develop and release branches with separate hotfix branches before changes reach a protected main branch.
• B"GitHub Flow", in which short-lived branches are cut from main, merged through a reviewed pull request, and released straight to production while main stays deployable.check_circle Correct
• CTrunk-based development with release trains, in which developers commit directly to the trunk many times a day and changes ship only on a fixed periodic schedule.
• DA fork-and-pull model, in which each contributor works in a personal fork of the repository and the maintainer pulls vetted changes from those external forks into main.

Why A is wrong: Gitflow adds long-lived develop and release branches and a heavier ceremony, so it conflicts with the lightweight deploy-on-merge model the team wants.

Why B is correct: GitHub Flow is defined by short-lived feature branches off a single deployable main and release on merge, which is precisely the workflow the team describes.

Why C is wrong: Trunk-based development favours direct commits to the trunk and often scheduled release trains, which does not centre on per-change branches deployed immediately after merge.

Why D is wrong: Forking suits external open-source contribution rather than an internal team, and it describes repository topology, not the deploy-on-merge release cadence asked about.

An organisation keeps its repositories on "GitHub" but plans and tracks work in "Azure Boards". They want GitHub commits and pull requests to link to Azure Boards work items so the board shows development progress against each story. What is the recommended way to establish this cross-product linking?

• AMirror each GitHub repository into Azure Repos with a scheduled import so the existing Azure Repos work item linking parses the imported commits and updates the board.
• BAdd a personal access token as a pipeline secret and run a scheduled script that reads the GitHub commit feed and posts updates onto matching Azure Boards work items.
• CInstall the "Azure Boards" app for GitHub, connect the repositories to the project, and reference work items in commits and pull requests using the "AB#" mention syntax.check_circle Correct
• DEnable GitHub Advanced Security on the repositories so its code scanning results are forwarded to Azure Boards and attached to the related stories as development links.

Why A is wrong: Mirroring duplicates the source of truth and adds sync overhead, and the team wants to keep developing on GitHub rather than migrate the repositories into Azure Repos.

Why B is wrong: A bespoke script with a long-lived token is fragile and adds operational burden when a supported integration already performs the linking natively.

Why C is correct: The Azure Boards app connects GitHub repositories to a board, and the AB-hash mention in commits and pull requests creates the supported development link on each work item.

Why D is wrong: GitHub Advanced Security scans code for vulnerabilities and secrets and does not create work item links, so it solves a different problem than cross-product traceability.

A team of twelve engineers integrates code many times a day and wants to keep merge conflicts and integration debt to a minimum by avoiding long-lived branches. They rely on a continuous integration build that runs on every commit to validate the shared line. Which branching strategy best matches this way of working?

• ATrunk-based development, where everyone commits small changes to a single shared branch frequently and short-lived branches are merged back within hours rather than days.check_circle Correct
• BA release branch model, where each version gets a dedicated long-lived branch that stabilises independently of the main line before any code is shipped to customers.
• CA forking workflow, where each engineer maintains a personal server-side fork and contributes changes back to the central repository only through pull requests across forks.
• DGitFlow, where parallel develop and feature branches accumulate work that is periodically promoted through release and hotfix branches before reaching the main branch.

Why A is correct: Trunk-based development keeps everyone integrating to one shared line with very short-lived branches, which directly minimises merge conflicts and integration debt for a team committing many times a day.

Why B is wrong: Release branches suit stabilising a specific version in parallel with ongoing work, but their long-lived nature is the opposite of the frequent small integrations the team wants, so it does not fit.

Why C is wrong: Forking workflows suit untrusted external contributors to open projects, but for a co-located trusted team they add cross-fork overhead and slow the frequent shared integration that is required here.

Why D is wrong: GitFlow is tempting because it is a well-known model, but its develop and feature branches encourage longer-lived divergence, increasing the integration debt the team is explicitly trying to avoid.

A product is preparing version 2.0 for a customer pilot. The team must freeze and stabilise the 2.0 code so only bug fixes go into it, while new feature work for version 2.1 continues to land on the main branch without disturbing the pilot build. Which approach satisfies both needs?

• ATag the current commit on main as version 2.0 and ask everyone to pause new feature merges until the pilot ends, then resume normal merging on main once the customer signs off.
• BCut a release branch for 2.0 from main, allow only bug fixes to be committed to that branch, and let new 2.1 feature development continue on main in parallel.check_circle Correct
• CCreate a feature branch per outstanding 2.0 fix off main, merge each fix straight back to main, and rebuild the pilot from main whenever a customer-reported bug is resolved.
• DLock the main branch with a branch policy that blocks all merges, deploy the pilot from the locked main, and unlock it again after the customer pilot has been completed.

Why A is wrong: A tag marks a point in history but cannot keep receiving isolated bug fixes, and pausing all feature work stalls 2.1 development, so neither requirement is met cleanly.

Why B is correct: A release branch isolates the 2.0 line so only stabilising fixes land there, while main keeps moving with 2.1 work, satisfying both the freeze and the continued development requirement.

Why C is wrong: Short feature branches off main are fine for fixes, but rebuilding the pilot from main pulls in unrelated 2.1 feature work, which breaks the requirement to freeze the 2.0 line.

Why D is wrong: Locking main with a policy is tempting for a freeze, but it halts 2.1 feature work entirely and offers no isolated place to take 2.0 bug fixes, so both needs fail.

A team requires that the history of the main branch shows exactly one commit per completed pull request, with no intermediate work-in-progress commits from the feature branch, so that reverting a feature is a single-commit operation. Which pull request completion merge strategy in "Azure Repos" delivers this?

• ARebase and fast-forward, which replays each source-branch commit individually onto the target branch so the target tip advances without creating a merge commit.
• BA basic merge with a merge commit, which records all source-branch commits plus an extra merge commit that ties the two branch histories together on the target.
• CSquash merge, which combines all commits on the source branch into a single new commit on the target branch when the pull request is completed.check_circle Correct
• DSemi-linear merge, which rebases the source commits onto the target tip and then adds a merge commit to preserve a clear record of the pull request boundary.

Why A is wrong: Rebase and fast-forward preserves every individual feature commit on main, so a pull request adds many commits rather than one, failing the single-commit-per-PR requirement.

Why B is wrong: A standard merge keeps each work-in-progress commit and adds a merge commit, so the history grows by many commits per pull request instead of the single commit the team wants.

Why C is correct: Squash merge collapses every feature-branch commit into one commit on main, giving exactly one commit per pull request and making a feature revert a single-commit operation as required.

Why D is wrong: Semi-linear merge is tempting for tidy history, but it still keeps the individual rebased commits alongside a merge commit, so reverting the feature is not a single-commit action.

A platform team stores database connection strings and API keys in "Azure Key Vault" and wants their web application on "Azure App Service" to read them with no secret ever placed in app settings or code, while access can be revoked centrally if the app is compromised. They also want the secrets to be authorised through Microsoft Entra role assignments rather than legacy vault access policies. Which two measures together satisfy these requirements? Select TWO.

• AEnable a system-assigned managed identity on the App Service and grant that identity a Key Vault data-plane RBAC role such as Key Vault Secrets User on the vault.check_circle Correct
• BStore the vault access in the application's appsettings.json file as a connection string so the runtime can present it to the vault when it requests each secret.
• CReference each secret from an App Service application setting using a Key Vault reference so the platform resolves the value from the vault at runtime instead of holding the literal secret.check_circle Correct
• DCreate a long-lived service principal client secret, store it as an App Service setting, and add a classic vault access policy granting that principal Get on secrets.

Why A is correct: A system-assigned managed identity gives the app an Entra identity with no stored credential, and granting it the Key Vault Secrets User RBAC role authorises secret reads centrally and revocably, meeting both requirements exactly.

Why B is wrong: Placing any credential in appsettings.json is precisely the stored secret the team wants to avoid, so although it would technically authenticate it violates the no-secret-in-settings constraint.

Why C is correct: A Key Vault reference lets App Service settings point at the vault and resolve the value at runtime using the app's managed identity, so the literal secret is never stored in configuration or code.

Why D is wrong: This both stores a long-lived secret in app settings and uses the legacy access-policy model the team is moving away from, so it fails the no-stored-credential and RBAC-authorisation requirements.

A pipeline in "Azure Pipelines" deploys to an Azure subscription through an Azure Resource Manager service connection. A security review requires that the pipeline hold no long-lived credential that could be exported or leaked, while still authenticating to Microsoft Entra to obtain Azure access tokens. Which way of configuring the service connection meets the requirement?

• ACreate the service connection using a Microsoft Entra service principal with a client secret, then store that secret in "Azure Key Vault" and have the pipeline read it at run time so it is never committed to the repository.
• BCreate the service connection using workload identity federation so Azure DevOps presents an OpenID Connect token to Microsoft Entra and exchanges it for an access token, with no secret or certificate held on the connection.check_circle Correct
• CCreate the service connection using a Microsoft Entra service principal authenticated with a certificate, and rotate the certificate automatically every ninety days so a leaked credential has a short useful lifetime.
• DCreate the service connection from a personal access token scoped only to release management, and grant that token rights on the subscription so the pipeline authenticates without storing an Entra service principal secret.

Why A is wrong: Keeping the secret in a vault improves storage hygiene and is tempting, but a client secret is still a long-lived credential that can be exported, so it does not satisfy the no-stored-credential requirement.

Why B is correct: Workload identity federation lets the service connection exchange a short-lived OpenID Connect token for an Azure access token through a federated credential, so no secret or certificate is ever stored, meeting the requirement exactly.

Why C is wrong: Certificate credentials with rotation reduce exposure and look secure, but the certificate is still a long-lived secret stored against the connection, which is exactly the artefact the review wants eliminated.

Why D is wrong: A personal access token authenticates to Azure DevOps itself rather than to an Azure subscription, and it is still a long-lived secret, so it can neither perform the deployment nor satisfy the requirement.

A team is configuring workload identity federation so an "Azure Pipelines" service connection authenticates to Microsoft Entra and deploys to an Azure subscription with no client secret or certificate held anywhere. They are creating a federated credential on the Microsoft Entra application. Which two values must the federated credential be configured with so that only this service connection's pipeline runs can exchange their token for Azure access? Select TWO.

• AA copy of the service principal client secret, pasted into the federated credential so the pipeline presents both the secret and the federated token at sign-in.
• BAn issuer pointing at the Azure DevOps organisation's OpenID Connect token issuer, so Microsoft Entra trusts tokens minted for that organisation.check_circle Correct
• CA Contributor role assignment on the resource group, entered directly in the federated credential record so that authorisation travels with the trust definition.
• DA subject identifier that matches the specific service connection, so only tokens issued for that connection's organisation and project satisfy the trust.check_circle Correct

Why A is wrong: Workload identity federation exists to eliminate the client secret entirely, so requiring a pasted secret contradicts the secretless goal and is not part of a federated credential at all.

Why B is correct: The issuer names the trusted OpenID Connect provider; setting it to the Azure DevOps organisation issuer lets Microsoft Entra accept the run-time tokens that organisation mints, which is required for the federated exchange.

Why C is wrong: Authorisation is granted by a separate Azure role assignment on the resource, not stored inside the federated credential, so this conflates the trust definition with role-based access control.

Why D is correct: The subject claim scopes the trust to one service connection's identity, so only pipeline runs using that connection present a matching subject and can complete the token exchange, keeping the trust narrow.

A team runs an ASP.NET web API on Azure App Service and wants automatic collection of request rates, response times, failure counts, and end-to-end dependency calls to downstream databases, with distributed traces that correlate a single user request across services. Which Azure capability should they enable to gather this application-level telemetry?

• AEnable VM Insights on the underlying compute so the platform collects processor, memory, and disk counters together with a map of network connections between the hosts running the web API.
• BEnable Container Insights for the App Service plan so the platform scrapes container processor and memory usage and surfaces node and pod health for the workload hosting the web API.
• CEnable "Application Insights" for the web API so it auto-collects request and dependency telemetry, failure counts, and correlated distributed traces across the calls a single user request makes.check_circle Correct
• DEnable a diagnostic setting that streams the App Service platform logs to a Log Analytics workspace so the team can query raw HTTP server logs and stored console output for the web API.

Why A is wrong: VM Insights gathers guest performance counters and a dependency map for virtual machines, which is tempting for any compute, but it does not capture request rates, traces, or application dependency calls inside the API.

Why B is wrong: Container Insights monitors container and node resource usage for AKS and container workloads, which sounds plausible, but it reports infrastructure metrics rather than the per-request application traces and dependency calls the team needs.

Why C is correct: "Application Insights" is the application performance management service that auto-instruments requests, dependencies, and exceptions and correlates them into end-to-end distributed traces, exactly matching the stated need.

Why D is wrong: Streaming platform logs to a workspace captures coarse HTTP and console output, which is useful, but it provides no automatic dependency tracking or correlated distributed traces across services.

An operations team runs microservices on an Azure Kubernetes Service cluster and wants node-level and pod-level processor and memory usage, container restart counts, and cluster health surfaced in Azure Monitor without deploying and maintaining their own metrics stack. Which capability should they turn on for the cluster?

• AEnable "VM Insights" on the AKS agent nodes so the platform collects guest operating system performance counters and a dependency map of the processes running across the cluster's worker machines.
• BDeploy a self-hosted Prometheus and Grafana pair onto the cluster and configure scrape targets manually, then expose dashboards for node and pod processor, memory, and restart metrics for the team.
• CAdd a diagnostic setting on the cluster that sends Kubernetes control plane and audit logs to a Log Analytics workspace so operators can query API server and scheduler events for the cluster.
• DEnable "Container Insights" on the AKS cluster so the managed agent collects node and pod processor and memory metrics, container restart counts, and cluster health into Azure Monitor.check_circle Correct

Why A is wrong: VM Insights instruments virtual machine guests and is tempting because AKS nodes are VMs, but it does not understand pods, containers, or controllers, so it misses the Kubernetes-aware metrics the team needs.

Why B is wrong: A self-hosted Prometheus and Grafana stack can produce the metrics but adds deployment, scaling, and patching work, which directly conflicts with the stated goal of avoiding a self-managed stack.

Why C is wrong: Control plane and audit log diagnostic settings expose API server and scheduler events, which is useful, but they do not deliver node and pod resource metrics or container restart counts.

Why D is correct: Container Insights deploys a managed agent that gathers node, pod, and container resource metrics plus controller and cluster health into Azure Monitor, meeting the requirement with no self-managed stack.

A team running a fleet of Azure virtual machines wants guest operating system performance counters together with an automatically discovered map of the network connections and process dependencies between those machines, so they can see which servers talk to each other. Which Azure Monitor feature delivers both the counters and the dependency map?

• A"VM Insights", because it collects guest operating system performance counters from each machine and automatically discovers a map of the network connections and process dependencies between the servers.check_circle Correct
• B"Application Insights", because instrumenting the applications on each virtual machine collects request and dependency telemetry that can be assembled into a map of how the servers communicate with one another.
• C"Container Insights", because enabling it on the virtual machines gathers resource usage for the workloads and draws a topology of the connections that the hosted containers make between the servers.
• DA metric alert rule on the virtual machine resource, because configuring processor and memory thresholds collects the guest counters and the alert evaluation builds a dependency map of the affected machines.

Why A is correct: VM Insights is purpose-built for virtual machines, collecting guest performance counters and using its dependency agent to discover and draw the connection and process map between hosts.

Why B is wrong: Application Insights maps application-level request and dependency calls, which sounds related, but it requires application instrumentation and does not provide guest operating system performance counters or a host network dependency map.

Why C is wrong: Container Insights targets container and Kubernetes workloads, so it is a poor fit for plain virtual machines and does not produce guest counters or a host-to-host connection map.

Why D is wrong: A metric alert rule evaluates platform metrics and fires notifications, which is tempting for monitoring, but it neither collects guest counters nor produces any dependency map between machines.