MicrosoftProfessional levelAZ-400Page 4 of 4

AZ-400 exam dumps: questions 301 to 306 of 306

Page 4 of the free AZ-400 question bank for the Designing and Implementing Microsoft DevOps Solutions exam. Questions 301 to 306 are listed below, the first 5 in full with answers and explanations. Back to page 1 for the exam overview and FAQ.

Question bank last updated May 2025

Free AZ-400 practice questions

Questions 301 to 305 of 306

Pick an answer before you open the explanation. Each question also has its own page with a permalink.

AZ-400 Question 301

Select 2

You have a microservice-based solution hosted in Azure. Each microservice is instrumented with the Application Insights SDK for .NET, and you're attempting to trace requests that flow through multiple services as part of a single end-to-end transaction. However, you're only seeing separate traces for each service with no correlation in the Application Insights portal. Which two actions should you perform to enable effective distributed tracing in Application Insights?

  1. A

    Configure all microservices to use the same Application Insights connection string (or instrumentation key).

  2. B

    Enable Operation Name Overriding in the Azure portal for all microservices to override incoming request names.

  3. C

    Propagate trace context headers (such as traceparent or Request-Id) from incoming HTTP calls to outgoing calls in the code.

  4. D

    Deploy the same version of the Application Insights SDK (the same NuGet package version) to standardize logging across all microservices.

Show answer and explanation

Correct answers: A, C

Explanation

Distributed tracing in Application Insights requires two primary configurations: first, all services must use the same connection string (or instrumentation key) to send their telemetry data to a common resource. Second, the correlation headers generated by the first service must be passed along to subsequent services to establish an end-to-end transaction context. By ensuring these steps, you can view the entire call chain in the Application Insights portal and diagnose performance issues across microservices. For more information, refer to the official Microsoft documentation on 'End-to-end transaction monitoring in Application Insights.'

  • A. Correct.

    Correct. For Application Insights to correlate telemetry across multiple services, they must share the same connection string or instrumentation key (unless you use specialized cross-AI-resource correlation). This ensures all data reports to the same logical endpoint for correlation.

  • B. Incorrect.

    Incorrect. Simply enabling Operation Name Overriding in the portal won't by itself correlate traces. Overriding operation names can help with naming consistency, but it doesn�t establish distributed tracing across services.

  • C. Correct.

    Correct. You must pass correlation headers (traceparent in W3C protocol or Request-Id/Correlation-Context for legacy) between services. This ensures each service's telemetry is linked to the same overall operation, enabling end-to-end tracing in the Application Insights portal.

  • D. Incorrect.

    Incorrect. While using the same SDK version can help ensure consistent behavior, it doesn't automatically establish distributed trace correlation. You still need to propagate trace context and use the same Application Insights resource.

AZ-400 Question 302

Select 2

You maintain a microservices-based application hosted on Azure App Services, with each microservice configured to use Application Insights. Users report occasional high latency, and you suspect one microservice is causing a bottleneck. You want to perform distributed tracing to identify the root cause. Which two actions should you perform to effectively diagnose latency across all microservices using Application Insights?

  1. A

    Use the Application Map feature in the Azure portal to identify the microservice with elevated latency.

  2. B

    Configure correlation headers (e.g., Request-Id and Request-Context) for incoming and outgoing calls in each microservice.

  3. C

    Disable automatic dependency tracking to reduce noise and overhead in telemetry data.

  4. D

    Create separate Application Insights resources for each microservice to isolate logs and minimize correlation complexity.

  5. E

    Enable only trace-level logs for each microservice and rely on Log Analytics queries to piece together request flows.

Show answer and explanation

Correct answers: A, B

Explanation

To troubleshoot latency in a distributed microservices environment, you must use Application Insights features that correlate requests and dependencies across services. The most critical practices include enabling the Application Map for a real-time overview of service-to-service relationships and ensuring correlation headers are preserved in requests. By doing so, requests across microservices can be traced end-to-end, highlighting bottlenecks. Refer to Microsoft� official documentation on distributed tracing with Application Insights for further guidance on correlation headers and Application Map usage.

  • A. Correct.

    Correct. The Application Map in Application Insights provides an end-to-end view of how requests flow between your microservices. It highlights which resources have higher latency or errors, making it a key tool for diagnosing performance bottlenecks.

  • B. Correct.

    Correct. Ensuring correlation headers (Request-Id, Request-Context, and correlation-conversation-id where relevant) are preserved allows Application Insights to associate requests and dependencies across services. This practice enables true distributed tracing and end-to-end visibility.

  • C. Incorrect.

    Incorrect. Disabling automatic dependency tracking would prevent Application Insights from collecting critical data about service-to-service calls. You need dependency details to understand how latency flows through each microservice.

  • D. Incorrect.

    Incorrect. While separate resources can be preferred in some scenarios, splitting telemetry for each microservice can make correlation more difficult. Using a shared Application Insights resource (or at least ensuring consistent correlation across resources) is often recommended for simpler distributed tracing.

  • E. Incorrect.

    Incorrect. Trace-level logs are useful, but enabling them alone without proper correlation headers or the Application Map would make it difficult to see an end-to-end transaction. You need a combination of correlation and the Application Map for effective distributed tracing.

AZ-400 Question 303

Select 2

You manage a microservices-based application with components running in Azure App Service and Azure Kubernetes Service (AKS). Each microservice is instrumented with the Application Insights SDK, but the operations team reports difficulty tracing individual user requests across multiple services. You need to inspect distributed tracing data in Application Insights to identify performance bottlenecks and track end-to-end transaction flows. Which two actions should you perform to achieve this? (Choose two.)

  1. A

    Enable the Application Insights Profiler for each microservice to record CPU usage.

  2. B

    Configure each microservice to use the same Application Insights connection string.

  3. C

    Pass a custom header named operation_Id in all calls across microservices.

  4. D

    Use the Application Map in Application Insights to visualize service dependencies.

Show answer and explanation

Correct answers: B, D

Explanation

In a distributed microservices architecture, enabling end-to-end tracing in Application Insights depends on consistent telemetry configuration and leveraging built-in tools. First, ensure that each microservice uses the same connection string or instrumentation key so that Application Insights can correlate data under a single resource. Second, use the Application Map feature in the Azure portal to visualize interactions between services, see response times, and troubleshoot failures. Refer to Microsoft Docs (https://docs.microsoft.com/azure/azure-monitor/app/distributed-tracing) for more details on implementing distributed tracing across multiple services with Application Insights.

  • A. Incorrect.

    Incorrect: While the Application Insights Profiler can provide valuable performance metrics (e.g., CPU usage and memory allocation), enabling it does not inherently provide distributed tracing across multiple microservices. Profiler is more about detailed performance profiling rather than connecting request flows end-to-end.

  • B. Correct.

    Correct: To correlate telemetry across different microservices, each service should report to the same Application Insights resource or workspace, which means using the same connection string (or instrumentation key if using older configurations). This ensures a consistent reference enabling end-to-end transaction tracing.

  • C. Incorrect.

    Incorrect: Manually passing operation_Id headers is not required if you use the official Application Insights SDK and properly configure the same Application Insights resource for your microservices. The SDK automatically handles request correlation using standard headers (e.g., Request-Id, Traceparent).

  • D. Correct.

    Correct: The Application Map feature helps visualize how microservices call each other. It provides a graphical view of dependencies, latencies, and potential failure points across the entire request chain, making it easier to inspect distributed tracing data.

AZ-400 Question 304

Single answer

You manage an Azure DevOps environment where pipeline logs are stored in a table named 'PipelineLogs' within Azure Log Analytics. You need to retrieve logs from the last 24 hours that have a severity level of 'Error,' then group these errors by their error type and sort by the count of each error type in descending order. Which KQL query satisfies these requirements?

  1. A

    PipelineLogs | where TimeGenerated < ago(24h) | where Severity == "Error" | summarize count() by ErrorType | order by count_ desc

  2. B

    PipelineLogs | where TimeGenerated >= ago(24h) | where Severity == "Error" | summarize result = count() by ErrorType | order by result desc

  3. C

    PipelineLogs | where TimeGenerated >= ago(24h) | project ErrorType | distinct ErrorType

  4. D

    PipelineLogs | where Severity == "Error" | extend Last24hrs = now() | summarize count() by ErrorType | order by count_ desc

Show answer and explanation

Correct answer: B

Explanation

When troubleshooting Azure DevOps pipelines, you often need to filter logs by a specific time range and summarize error counts. Using 'where TimeGenerated >= ago(24h)' filters logs from the last 24 hours, while 'summarize count() by ' groups and counts results by a given field. The official Microsoft documentation on Kusto Query Language (https://docs.microsoft.com/azure/data-explorer/kusto/query/) provides further guidance on using KQL for queries, filters, and aggregations.

  • A. Incorrect.

    Option A uses a filter with 'TimeGenerated < ago(24h)' which retrieves logs older than 24 hours, not within the last 24 hours. Therefore, it does not meet the requirement.

  • B. Correct.

    Option B is correct because 'TimeGenerated >= ago(24h)' filters the logs from the last 24 hours, 'where Severity == "Error"' picks only error logs, 'summarize result = count() by ErrorType' groups by the error type and computes the count, and 'order by result desc' sorts by the count in descending order.

  • C. Incorrect.

    Option C filters the correct time range but only projects and lists distinct error types without summarizing or ordering by count, so it does not meet the requirement to count and sort by the number of occurrences.

  • D. Incorrect.

    Option D fails to filter logs by time; 'extend Last24hrs = now()' just adds a column with the current timestamp, so it does not specifically select logs from the last 24 hours.

AZ-400 Question 305

Single answer

You manage an Azure Log Analytics workspace that captures request logs for a microservice-based application. The operations team suspects that one of the services is returning HTTP 503 errors more frequently over the past 24 hours. You need to run a KQL query that retrieves all logs with a 503 response in the last 24 hours and groups them by the operation name. Which of the following queries correctly accomplishes this task?

  1. A

    Option A: requests | where timestamp >= now(-24h) | where resultCode == 503 | summarize count() by operation_Name

  2. B

    Option B: requests | where Timestamp < ago(24h) | where resultCode == '503' | count by operation_Name

  3. C

    Option C: requests | where timestamp > ago(24h) and resultCode == '503' | summarize count() by operation_Name

  4. D

    Option D: requests | where timestamp > ago(24h) | where resultCode = '503' | summarize sum() by operation_Name

Show answer and explanation

Correct answer: C

Explanation

When querying Azure Monitor Logs or Application Insights, you typically filter time-based data using 'ago()'. For instance, 'timestamp > ago(24h)' retrieves data from the last 24 hours. To count the results and group by a particular field, you use the 'summarize count() by ' clause. Refer to Microsoft documentation on Kusto Query Language (KQL) for further details on query operators and syntax: https://docs.microsoft.com/azure/data-explorer/kusto/query

  • A. Incorrect.

    Option A Explanation: The operator now(-24h) is not valid KQL syntax for setting a time window. Instead of 'now(-24h)', the correct function is 'ago(24h)'. This query would fail because '>= now(-24h)' is not a standard approach to filter the last 24 hours in KQL.

  • B. Incorrect.

    Option B Explanation: This query uses a comparison 'Timestamp < ago(24h)' instead of '> ago(24h)' which would retrieve logs older than 24 hours, not the most recent 24 hours. Additionally, 'count by operation_Name' is not a valid KQL command. The correct approach is 'summarize count() by operation_Name'.

  • C. Correct.

    Option C Explanation: This option uses 'timestamp > ago(24h)' to filter logs within the last 24 hours and 'resultCode == 503' to filter only 503 errors. It then uses 'summarize count() by operation_Name' to return the grouped count per operation name. This is the correct query.

  • D. Incorrect.

    Option D Explanation: This query attempts to compare 'resultCode = '503'', which KQL treats as an assignment and is invalid. It also uses 'summarize sum() by operation_Name' rather than using 'count()'. Summing over a single field wouldn't correctly return the number of logs or requests.

Timed practice exam

Take a AZ-400 practice test under exam conditions

70 questions in 90 minutes, drawn from this bank, with a score report and a per-question review when you finish.

Start timed exam