AZ 400 sample questions with answers

These az 400 sample questions follow Microsoft's weighting.

Question 1 (Instrumentation)

During a rollout of a new release, a public sector agency needs to watch the live request rate, failure rate, and response time of its App Service app. Engineers must see changes within seconds of requests completing so they can correlate them with configuration updates. They do not need to keep this view after the rollout. What should you use?

A. Pin a Log Analytics query over requests to a dashboard.

B. Pin a Metrics Explorer chart for requests to a dashboard.

C. Open the Live Metrics Stream view in Application Insights.

D. Use the Application Insights Users and Events usage views.

Answer: C

Explanation: The Live Metrics Stream option is correct because it is the only choice built for sub-second observability: it displays current request rate, failure rate, and response time within about a second, and because the scenario drops the retention requirement, its lack of storage is not a problem. The strongest distractor is the Log Analytics query option: it can analyze the same request telemetry and would be a good long-term dashboard, but Log Analytics ingestion latency is measured in minutes, so it cannot meet the “within seconds” constraint. Metrics Explorer is also near-real-time but aggregates on one-minute intervals, and the usage views are intended for historical behavioral analysis rather than live operations. General rule: for live incident diagnosis use Live Metrics Stream; use Log Analytics and Metrics Explorer for stored, queryable, alert-capable analysis.

Question 2 (Pipelines)

Your gaming studio publishes a multiplayer backend through Azure Pipelines. As part of the release pipeline, you must add a continuous 72-hour soak test of the login service. The JMeter script is ready, and the test must run unattended as one automated stage. Which approach should you use?

A. Use the Azure Load Testing task in the release pipeline for one continuous 72-hour run of the JMeter script.

B. Add a self-hosted agent and run the JMeter script in a pipeline job with a 72-hour timeout.

C. Split the soak into three sequential 24-hour Azure Load Testing runs chained in the pipeline.

D. Run the JMeter script on a Microsoft-hosted agent and configure the pipeline job timeout for 72 hours.

Answer: B

Explanation: The self-hosted agent option is correct because the requirement is a single continuous 72-hour run, and a self-hosted Azure Pipelines agent can be configured with a multi-day job timeout. The strongest distractor is the managed Azure Load Testing option: it is purpose-built for load tests and needs no infrastructure, but a single Azure Load Testing test run is capped at 24 hours, so it cannot complete a continuous 72-hour soak. The Microsoft-hosted agent distractor fails because Microsoft-hosted jobs have a far shorter maximum timeout. The split-run distractor fails because three sequential runs are not a continuous soak and would not expose the long-run failures a soak test is meant to catch. General rule: when a requirement exceeds a documented service quota, choose a workload location you can control instead of assuming the managed service can be extended.

Question 3 (Security)

An airline is migrating a classic release pipeline to a single YAML pipeline. After the build and integration stages finish, the production deployment job calls a partner API that requires a key Azure Key Vault rotates several times a day. Compliance policy permits the key to be read from Key Vault only when the production job is about to start. The build stage alone takes about 45 minutes. Where should the YAML pipeline read the key?

A. From an AzureKeyVault@2 task placed in the build stage and reused in the production job.

B. From an AzureKeyVault@2 task placed as the first step of the production deployment job.

C. From a Key Vault reference in the deployed app's application settings, resolved when the app starts.

D. From a variable group linked to Key Vault, referenced in the pipeline-level variables block.

Answer: B

Explanation: Using the AzureKeyVault@2 task as the first step of the production job is correct because the task fetches the named secrets at task execution time, so the key is read exactly when the production job starts. A Key Vault variable group referenced at pipeline level is fetched when the pipeline run begins and then remains fixed for that run; with a 45-minute build phase, that both reads the key too early and risks a stale key. The App Service Key Vault reference option is a runtime pattern for the deployed application, but here the pipeline job, not the app, makes the partner API call. The general rule is: use a linked variable group when a fixed snapshot at run start is acceptable, and use the Azure Key Vault task at the point of use when freshness is required.

Question 4 (Security)

A healthcare provider's web app runs in Azure App Service and uses a storage account connection string stored as a secret in Azure Key Vault. The DevOps pipeline rotates the storage account key every 24 hours and updates the Key Vault secret. Compliance requires the app to use the rotated secret within five minutes; restarting the app is not acceptable. The app cannot afford a Key Vault call on its storage data path. You need to design how the app obtains the connection string. Which approach should you use?

A. Use the Key Vault SDK in the app to cache the secret and refresh it before the five-minute limit expires.

B. Add a Key Vault reference to the App Service application setting that holds the connection string.

C. Use the app's managed identity to call Key Vault before every storage operation and use the returned secret.

D. Use Azure App Configuration with a Key Vault reference and set the refresh interval to one hour.

Answer: A

Explanation: The Key Vault SDK caching option is correct because it meets both constraints: the app does not call Key Vault on the per-operation storage data path, and a five-minute cache refresh matches the compliance limit on stale secret usage. The strongest distractor is the Key Vault reference in an App Service application setting: it is a supported, no-code way to inject a secret, but App Service resolves Key Vault references at application start and when app settings are updated, so the rotated secret would not be picked up within five minutes without restarting or changing app settings. The general rule is that when a long-running app must honor a short secret-rotation window without a restart, use runtime code to fetch and cache the secret with a TTL no larger than the allowed staleness, and use managed identities for Key Vault access.

Question 5 (Source control)

Fabrikam University's bioinformatics group keeps shared modeling code in an Azure Repos repository. The sponsor requires every pull request to main to be approved by all 12 named principal investigators before merge. The group has exhausted its Azure Pipelines grant, so build-validation policies are not available. You must enforce the approval requirement with native branch policies. How should the branch policy be configured?

A. Turn on automatic include-reviewers for all 12 PIs.

B. Add all 12 named PIs as required reviewers.

C. Add a build-validation policy that requires 12 approvals.

D. Set the minimum number of reviewers policy to 12.

Answer: B

Explanation: The required-reviewers option is correct because it is a native Azure Repos branch policy: it enforces that each listed PI approves the latest pull request before merge, and it uses no pipeline minutes. The minimum-reviewers option is the strongest distractor: it appears to satisfy the approval-count requirement, but Azure Repos caps the minimum reviewer count at 10, so 12 cannot be selected. The build-validation option could technically enforce the rule with a custom check, but it violates the stated constraint that pipeline capacity is gone. Automatic include-reviewers only adds reviewers to the request; it does not require their approval. The general rule is to map the exact compliance condition to the native policy first, and to know the service quota before choosing a workaround.

Question 6 (Source control)

A global ecommerce retailer keeps networking configuration for two Azure subscriptions in one Azure Repos Git repository. The two VNets use the same 10.0.0.0/16 address space, and both teams tag releases as v1.0 or v2.0, sometimes moving an existing tag after a hotfix. You need to make each environment's release snapshot unambiguous and auditable. What should you configure?

A. Create annotated tags with names such as cde-2026.07.27 and corp-2026.07.27, and add tag protection policies for those tag patterns.

B. Create separate branches for each environment and use branch policies to require pull requests into those branches before the release tag is created.

C. Create annotated tags on the default branch after each merge, using the CIDR value in the tag name, and do not protect the tags.

D. Create lightweight tags named v1.0 and v2.0 on the same commits as the deployment branches, and document that the teams must not move them.

Answer: A

Explanation: Environment-specific annotated tags are required. The two intended networks use the same 10.0.0.0/16 range, so a tag that names only a CIDR or a generic v1.0 cannot identify which environment snapshot it points to. Prefixing tags with cde/corp and protecting those patterns makes the release marker both unambiguous and immutable. The CIDR-based annotated-tag option is the strongest distractor: it uses the right object type, but the tag name is exactly the value that overlaps, so the two releases would still be confused, and unprotected tags can be moved after a hotfix, destroying the audit trail. General rule: production release tags should be annotated, namespaced by the dimension that distinguishes otherwise identical artifacts, and protected with tag policies.

Question 7 (Pipelines)

An industrial IoT platform runs an Azure Pipelines build that compiles a C# service, executes unit tests, and must publish code coverage reports into the pipeline run. Security policy allows the test phase to connect to a test database only from an agent inside the plant network. The pipeline uses Azure DevOps Services. Which action satisfies the requirement?

A. Use a Microsoft-hosted agent to run the tests, then store the coverage file as a pipeline artifact for manual download.

B. Use a Microsoft-hosted agent to run the pipeline, and add the PublishCodeCoverageResults task to publish the coverage report.

C. Install a self-hosted agent inside the plant network, and run the tests plus the PublishCodeCoverageResults task on it.

D. Use the PublishTestResults task to upload the test run, and enable the code coverage view on the Tests tab.

Answer: C

Explanation: The self-hosted agent option is correct because the test phase must reach an on-premises test database, and the coverage report is generated during that test phase. A Microsoft-hosted agent runs outside the plant network, so the policy prevents the tests from running even though PublishCodeCoverageResults could publish the report afterwards. The artifact-download option stores a file but does not make coverage visible in the pipeline run. The PublishTestResults option uploads test results, not coverage; code coverage in the Tests tab is published by PublishCodeCoverageResults or an equivalent coverage task. General rule: when a build or test task depends on a resource reachable only from inside a private network, choose a self-hosted agent in that network; cloud-hosted agent selection is independent of code coverage publishing.

Question 8 (Pipelines)

A healthcare provider's pipeline already runs unit tests and an Azure Load Testing smoke test on a nightly schedule. You need to add isolated integration tests on every pull request: the API, PostgreSQL, and Redis must be started together, used by the tests, and removed afterward. The team has no permanent test environment and must minimize Azure cost and maintenance. What should the testing strategy use?

A. Create an Azure Container Instances container group with API, PostgreSQL, and Redis containers for each integration test run.

B. Use an Azure DevTest Labs VM and run a Docker Compose startup script before the integration test task.

C. Use an Azure Container Apps environment with API, PostgreSQL, and Redis container apps backed by a permanent virtual network.

D. Provision an Azure Kubernetes Service cluster and deploy the API, PostgreSQL, and Redis as pods for the integration tests.

Answer: A

Explanation: This is correct because the scenario demands an isolated, disposable integration test environment with the lowest Azure cost and maintenance burden. Azure Container Instances runs a container group on demand, starts all containers together, and can be deleted by the pipeline after the tests, so billing stops when the containers stop. The strongest distractor is the Azure Kubernetes Service option: AKS is a legitimate way to run containerised integration tests, but it requires a running cluster, node pools, patching, networking, and continuous cost. It is a premium solution that exceeds the stated target. The general rule is that when a test environment is needed only for the duration of a test run, choose ephemeral, pay-per-use compute instead of persistent clusters, environments, or VMs.

Question 9 (Security)

A public sector agency runs a VNet-integrated App Service; the VNet has no route to the public internet. A compliance rule says feature-flag evaluation traffic must stay on the agency's private network, and App Configuration can be accessed only by Azure AD identities, never by shared keys. The agency uses Azure App Configuration Feature Manager so flags can be changed at runtime without redeploying. What should you implement?

A. Export feature flags from App Configuration into app settings during deployment so Feature Manager reads them locally.

B. Connect App Service to App Configuration over the public endpoint using a user-assigned managed identity and enforce TLS 1.2.

C. Deny public access to App Configuration, attach a private endpoint, and let the App Service managed identity read feature flags.

D. Attach a private endpoint to App Configuration and store a read-only access key in Key Vault for the App Service to use.

Answer: C

Explanation: This is correct because the compliance rule has two explicit constraints: feature-flag traffic must stay on the private network, and App Configuration must be accessed with Azure AD identities, never shared keys. A private endpoint with public access denied satisfies the network boundary, while the App Service managed identity satisfies the identity-only requirement. The strongest distractor is the answer that also attaches a private endpoint but stores a read-only access key in Key Vault; it fixes the network issue but misses the ban on shared secrets. The rule that generalises is that a compliance boundary is not satisfied by one mechanism alone: when the policy prohibits both public endpoints and shared credentials, pair Private Link with an Azure AD-managed identity and avoid any connection-string fallback.

Using these AZ 400 practice questions

Read the reasoning behind every option, not just the letter. Each scenario maps to the exam objectives, which shape our study plan and practice test. Check exam format and prerequisites first.

Nine questions cannot represent an entire exam; the real exam may include interactive tasks a question cannot reproduce.

Exam facts on this page come from Microsoft’s own pages (official exam page). Prices, versions and policies change — confirm there before you book.