15 real AZ-400 sample questions, each with a worked explanation and a rationale for every option, right and wrong. No account, no card. This is the reasoning the AZ-400 tests: knowing why the tempting answer is wrong, not just spotting the right one.
The real AZ-400 is Typically 40 to 60 questions questions in 150 minutes, pass mark 700 / 1000. For a domain-by-domain breakdown and a study plan, read the AZ-400 study guide. The full bank has 293 questions.
lock_openFree sampleDesign and Implement Build and Release Pipelineshard
A classic release pipeline in "Azure Pipelines" uses a pre-deployment gate that calls an external monitoring service and a query on "Azure Monitor" alerts before promoting to production. The first evaluation often fails because telemetry has not yet settled, but the release should keep re-checking and proceed once both signals are healthy, rather than failing the release outright. Which two gate settings achieve this automatic re-evaluation behaviour? Select TWO.
- ASet a sampling interval so each gate is re-evaluated periodically, and a timeout after which the gate is treated as failed if it has not yet passed.check_circle Correct
- BEnable the option that requires all gates to pass on the same successful sampling interval before the deployment proceeds.check_circle Correct
- CConvert the pre-deployment gate into a manual pre-deployment approval so a release manager re-runs the query by hand each time.
- DAdd a deployment queue settings rule that deploys only the latest release and cancels older ones still in the gate window.
Release gates re-evaluate on a configurable sampling interval up to a timeout, and all gates must pass within one interval before deployment proceeds. Gates in Azure Pipelines poll their evaluations on the sampling interval and keep retrying until the timeout; the release only advances when every configured gate returns healthy within the same sampling pass, which lets transient unhealthy telemetry settle before promotion.
Why A is correct: The sampling interval drives repeated re-evaluation of every gate, and the timeout bounds how long re-checking continues before the release is failed, which is exactly the polling behaviour described.
Why B is correct: Requiring all gates to succeed within a single sampling interval ensures both the monitoring service and the alert query are simultaneously healthy at the same check, which is the correct stabilisation condition.
Why C is wrong: A manual approval is tempting because it also pauses promotion, but it replaces automated re-evaluation with human clicking and does not poll the telemetry, so it fails the unattended re-checking requirement.
Why D is wrong: Queue settings control which release deploys when several are pending, which sounds related to waiting, but it never re-evaluates gate health and so does not deliver the automatic stabilisation re-check.
lock_openFree sampleDesign and Implement Build and Release Pipelineshard
A team wants its pull request validation pipeline in "Azure Pipelines" to act as a quality gate on code coverage. Coverage is collected in Cobertura format during the test run. The team needs the run summary to show the coverage report, and they need the pull request blocked from completing when line coverage falls below an agreed target. Which two actions together implement this coverage quality gate? Select TWO.
- AAdd a step that publishes the Cobertura file so the coverage percentage and browsable report appear on the run summary's coverage tab.check_circle Correct
- BEnable the pull request setting that automatically completes the pull request once the validation pipeline reports a coverage percentage.
- CAdd build validation as a branch policy on the target branch so the pull request cannot complete unless the validation pipeline succeeds.check_circle Correct
- DAttach a post-deployment gate to the production environment that queries the coverage percentage before release.
Surfacing coverage requires publishing the Cobertura report, while enforcing a coverage floor on merges requires a build validation branch policy that blocks completion on a failing run. The coverage report becomes visible only after the Cobertura results are published to the run; making it a merge gate requires a build validation branch policy, because that policy is the mechanism that prevents pull request completion when the validating pipeline fails its coverage threshold.
Why A is correct: Publishing the collected Cobertura results is what surfaces the coverage percentage and the browsable report on the run summary, satisfying the visibility half of the requirement.
Why B is wrong: Auto-complete is tempting because it also reacts to pipeline status, but it merges when checks pass rather than blocking on low coverage, so it does not enforce a coverage floor.
Why C is correct: A build validation branch policy ties pull request completion to a passing pipeline run, so a pipeline that fails on low coverage will block the merge, which enforces the gate.
Why D is wrong: A post-deployment gate runs after a deployment and on an environment, not on a pull request, so it cannot block a merge and applies far too late to act as a pull request coverage gate.
lock_openFree sampleDesign and Implement Build and Release Pipelinesmedium
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.
Use an upstream source on an Azure Artifacts feed to proxy and cache a public registry so builds survive outages and retain pulled versions. An upstream source turns the Azure Artifacts feed into a transparent caching proxy in front of a public registry. The first request for a version pulls it from upstream and saves it into the feed; later requests are served from the feed copy, which keeps builds working during an upstream outage and preserves versions even after they are unlisted at the source.
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.
lock_openFree sampleDesign and Implement Processes and Communicationsmedium
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.
Link commits and pull requests to Azure Boards work items by referencing the item identifier with hash syntax in the message. Azure Repos scans commit messages and pull request descriptions for work item references written with the hash syntax. When it finds one, it adds a development link from that commit or pull request to the named work item, so traceability from requirement to source builds itself as developers work rather than needing manual edits.
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.
lock_openFree sampleDesign and Implement Processes and Communicationsmedium
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.
Identify GitHub Flow as the lightweight model of short-lived branches off a deployable main merged via pull request and released on merge. GitHub Flow keeps a single main branch that is always deployable. Each change lives on a short-lived branch, is opened as a pull request for review and automated checks, then is merged and deployed. The absence of long-lived develop or release branches is what distinguishes it from Gitflow and makes it the match here.
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.
lock_openFree sampleDesign and Implement Processes and Communicationsmedium
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.
Use the Azure Boards app for GitHub with the AB-hash mention syntax to link GitHub commits and pull requests to work items. The Azure Boards app for GitHub establishes a connection between named GitHub repositories and an Azure Boards project. Once connected, an "AB#" mention in a commit message, pull request, or issue is recognised and a development link is written to the referenced work item, so the board reflects GitHub activity without migrating the source.
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.
lock_openFree sampleDesign and Implement a Source Control Strategymedium
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.
Match a high-frequency integrating team to trunk-based development to minimise merge conflicts and integration debt. Trunk-based development has all developers commit to a single shared trunk with short-lived branches merged within hours, so changes integrate continuously and conflicts stay small. Models that rely on long-lived parallel branches let divergence accumulate, which is exactly what a team integrating many times a day is trying to prevent.
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.
lock_openFree sampleDesign and Implement a Source Control Strategymedium
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.
Use a release branch to stabilise a shipping version for fixes while the main branch keeps advancing new work. A release branch is forked from main at the point a version is feature-complete and thereafter accepts only stabilising bug fixes, isolating that version from ongoing change. Because main continues to receive new feature work in parallel, the team ships a stable 2.0 pilot without blocking 2.1 development.
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.
lock_openFree sampleDesign and Implement a Source Control Strategymedium
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.
Select the squash merge strategy when main must record exactly one commit per completed pull request. Squash merge takes all commits on the source branch and writes them as one new commit on the target, discarding the intermediate work-in-progress history from main. This yields a clean one-commit-per-pull-request line where reverting a whole feature is a single git revert of that commit.
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.
lock_openFree sampleDevelop a Security and Compliance Planhard
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.
Use workload identity federation on an Azure Resource Manager service connection to authenticate to Microsoft Entra without storing any long-lived secret. Workload identity federation configures a federated credential in Microsoft Entra that trusts tokens issued by Azure DevOps. At run time the service connection presents a short-lived OpenID Connect token and exchanges it for an Azure access token, so authentication succeeds without any client secret or certificate being stored on the connection.
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.
lock_openFree sampleDevelop a Security and Compliance Planhard
A self-hosted "Azure Pipelines" agent runs on an Azure virtual machine and needs to read secrets from "Azure Key Vault" during deployments. The team wants the virtual machine's own identity to be used so that no credential is configured anywhere in the pipeline or on the agent, and the identity exists only for the lifetime of that virtual machine. Which approach should the team use?
- ARegister a Microsoft Entra service principal for the agent, store its client secret as a secret pipeline variable, and grant the principal a get and list access policy so the deployment can read the vault secrets.
- BCreate a user-assigned managed identity in a shared resource group, assign it to the virtual machine, and grant it a get and list access policy so multiple agents can reuse the same identity to read secrets.
- CEnable a system-assigned managed identity on the virtual machine, grant it a get and list access policy on the key vault, and have the deployment read secrets using that identity through the instance metadata endpoint.check_circle Correct
- DInstall a personal access token on the agent scoped to secrets, configure the deployment task to send that token to the vault, and rely on the token expiry date to limit how long the credential remains valid.
Select a system-assigned managed identity when an Azure resource needs credential-free access tied strictly to that resource's lifetime. A system-assigned managed identity is created in Microsoft Entra and bound to a single Azure resource, sharing its lifecycle and disappearing when the resource is deleted. The virtual machine obtains tokens from the instance metadata endpoint with no stored secret, and a key vault access policy lets it read secrets, matching the lifecycle and credential-free requirements.
Why A is wrong: A service principal with a stored secret would work and is tempting, but it places a credential in the pipeline and its lifetime is independent of the virtual machine, breaking both stated conditions.
Why B is wrong: A user-assigned identity also avoids stored credentials, but it is a standalone resource that survives beyond the virtual machine and is meant for sharing, so it does not exist only for that machine's lifetime.
Why C is correct: A system-assigned managed identity is tied to the virtual machine's lifecycle and needs no stored credential, and granting it get and list on the vault lets the agent read secrets, which satisfies every stated condition.
Why D is wrong: Personal access tokens authenticate to Azure DevOps, not to "Azure Key Vault", and storing one on the agent is exactly the configured credential the team wants to avoid, so it cannot read the vault.
lock_openFree sampleDevelop a Security and Compliance Planhard
An organisation wants a single automation that opens pull requests and posts checks across many repositories on "GitHub". It must act under its own identity rather than a person's, request only the repository permissions it needs, and authenticate with short-lived tokens that are scoped to each installation. Which identity should the organisation use for the automation?
- AA personal access token created by a service account user and granted the repo scope, shared by the automation so it can open pull requests and post checks across all of the organisation's repositories.
- BAn OAuth app authorised by an organisation owner, which acts on behalf of that owner using the user-to-server token issued during the authorisation flow to open pull requests and post checks.
- CA deploy key added to each repository, which the automation presents over SSH to authenticate and then uses the repository contents permission that the key grants to open pull requests and post checks.
- DA GitHub App installed on the organisation with the specific repository permissions it requires, authenticating as an installation to mint short-lived installation access tokens for opening pull requests and posting checks.check_circle Correct
Choose a GitHub App when automation needs its own identity, granular permissions, and short-lived installation-scoped tokens across many repositories. A GitHub App is registered with a defined set of fine-grained permissions and acts as its own identity rather than a user. When installed it authenticates as that installation and mints installation access tokens that are short-lived and scoped to the granted repositories, satisfying the least-privilege and ephemeral-token requirements better than a personal access token or OAuth app.
Why A is wrong: A service-account personal access token can perform the actions and is tempting, but it ties the automation to a user identity, carries broad coarse scopes, and is a long-lived secret rather than short-lived installation tokens.
Why B is wrong: An OAuth app is designed to act on behalf of the authorising user and inherits that person's access, so it neither runs under its own identity nor offers the per-installation scoped permissions the requirement demands.
Why C is wrong: Deploy keys grant Git access to a single repository and cannot post checks or call the wider API, so although they are scoped credentials they cannot perform the required cross-repository automation.
Why D is correct: A GitHub App is a first-class identity with granular, requested-only permissions, and installation authentication mints short-lived tokens scoped to each installation, which matches the own-identity, least-privilege, and short-lived token requirements.
lock_openFree sampleImplement an Instrumentation Strategymedium
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.
Select Application Insights to auto-collect request, dependency, and failure telemetry with correlated distributed traces for an application. Application Insights is the application performance monitoring component of Azure Monitor. When enabled on a web app it auto-instruments incoming requests, outbound dependency calls, and exceptions, then correlates them by operation id into distributed traces. Infrastructure-focused options such as VM Insights or Container Insights report host and container resource counters rather than per-request application behaviour, so they cannot supply the dependency and trace data described.
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.
lock_openFree sampleImplement an Instrumentation Strategymedium
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
Choose Container Insights to collect Kubernetes node, pod, and container resource metrics into Azure Monitor without a self-managed stack. Container Insights is the Azure Monitor feature for containerised workloads. On AKS it deploys a managed agent that scrapes node, pod, and container processor and memory usage along with restart counts and controller health, surfacing them in Azure Monitor. VM Insights treats nodes as plain virtual machines and is not Kubernetes-aware, while a self-hosted Prometheus and Grafana stack reintroduces the operational burden the team wants to avoid.
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.
lock_openFree sampleImplement an Instrumentation Strategymedium
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.
Select VM Insights to collect guest performance counters and an automatic network and process dependency map across virtual machines. VM Insights is the Azure Monitor solution for virtual machines. It collects guest operating system performance counters and uses a dependency agent to discover the processes running on each machine and the network connections between them, rendering a topology map. Application Insights maps application dependencies rather than hosts, Container Insights targets containers, and a metric alert rule only evaluates existing metrics, so none of those supply both the guest counters and the host dependency map.
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.
Examworthy is not affiliated with or endorsed by Microsoft. All questions are original, blueprint-aligned practice material. We never reproduce live exam items. AZ-400 and related marks belong to their respective owners.
