Courseiva

CCNA Implement an instrumentation strategy Questions

28 questions · Implement an instrumentation strategy · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
Multi-Selectmedium

A company deploys a web application to Azure App Service. They want to monitor application performance and detect anomalies using Application Insights. Which two components should be configured?

Select 2 answers
A.Deploy the Azure Monitor agent on the App Service instance
B.Configure sampling to reduce data volume
C.Create a Log Analytics workspace and configure data collection rules
D.Enable application-side SDK for telemetry
E.Enable diagnostics settings to stream logs to Event Hubs
AnswersB, D

Configuring sampling in Application Insights filters telemetry while preserving a representative subset of the data. This reduces ingestion and storage costs while still retaining enough data to detect performance anomalies, making it an effective and necessary optimization for high-volume applications.

Why this answer

Sampling in Application Insights reduces the volume of telemetry data while preserving statistically correct analysis, which is essential for managing cost and performance in high-traffic applications. Option D is correct because the application-side SDK (e.g., Application Insights SDK for .NET, Java, or Node.js) is required to instrument the code and collect detailed telemetry such as requests, dependencies, and exceptions for performance monitoring and anomaly detection.

Exam trap

The trap here is that candidates often confuse the Azure Monitor agent (for VMs) with the App Service diagnostics settings or Log Analytics workspaces, thinking they are required for Application Insights instrumentation, when in fact the SDK and sampling are the two core components for application performance monitoring and anomaly detection.

Practice this question →
2
Multi-Selecteasy

Which TWO metrics should you monitor to evaluate the reliability of a web application according to the DORA metrics?

Select 2 answers
A.Lead Time for Changes
B.Change Failure Rate
C.Mean Time to Restore (MTTR)
D.CPU Usage
E.Deployment Frequency
AnswersB, C

Change Failure Rate is the percentage of deployments that cause a failure in production, such as a service impairment or rollback. It is a core DORA reliability metric because it directly quantifies how often changes disrupt service, making it essential for evaluating system stability.

Why this answer

The DORA metrics define four key measures for software delivery performance: Deployment Frequency, Lead Time for Changes, Mean Time to Restore (MTTR), and Change Failure Rate. For evaluating the reliability of a web application, the two most directly relevant metrics are Change Failure Rate (B), which measures the percentage of deployments causing a failure in production, and Mean Time to Restore (MTTR) (C), which measures the time it takes to recover from a failure. These two metrics directly quantify stability and resilience, whereas Deployment Frequency and Lead Time for Changes focus on throughput and speed.

Exam trap

The trap here is that candidates often confuse throughput metrics (Deployment Frequency, Lead Time for Changes) with reliability metrics, but DORA specifically separates them into 'throughput' and 'stability' categories, and the question explicitly asks for reliability.

Practice this question →
3
MCQmedium

A company deploys a .NET Core web application to Azure App Service. The application uses Application Insights for monitoring. The operations team reports that dependency tracking is missing for calls to a third-party REST API made using HttpClient. The application is instrumented with the Application Insights SDK. Which action should be taken to enable dependency tracking for HttpClient calls?

A.Ensure the SDK is configured using services.AddApplicationInsightsTelemetry(); in the Startup.cs file.
B.Install the Application Insights Agent on the App Service instance.
C.Add a reference to Microsoft.ApplicationInsights.DependencyCollector and call DependencyTrackingModule.Initialize().
D.Use the Application Insights Status Monitor to enable dependency tracking.
AnswerA

In ASP.NET Core, calling services.AddApplicationInsightsTelemetry() in the Startup.ConfigureServices method registers all Application Insights services with the built-in dependency injection container. This extension automatically initializes the DependencyTrackingModule, enabling outbound dependency calls (such as HttpClient) to be tracked without writing any additional initialization code, and it reads the instrumentation key or connection string from app settings.

Why this answer

`services.AddApplicationInsightsTelemetry()` in `Startup.cs` automatically registers the `DependencyTrackingModule` for .NET Core applications. This module collects dependency telemetry for `HttpClient` calls made via `IHttpClientFactory` or typed `HttpClient` instances, provided the SDK is properly configured. Since the application already uses the Application Insights SDK, this single line enables automatic dependency tracking without additional packages or agents.

Exam trap

The trap here is that candidates confuse the .NET Core SDK approach with legacy .NET Framework tools like Status Monitor or manual `DependencyTrackingModule.Initialize()`, assuming dependency tracking requires extra packages or agent installation, when in fact `AddApplicationInsightsTelemetry()` handles it automatically for .NET Core.

How to eliminate wrong answers

Option B is wrong because the Application Insights Agent (formerly Status Monitor v2) is designed for .NET Framework applications hosted on IIS or Azure VMs, not for .NET Core on App Service; .NET Core apps require SDK-based instrumentation. Option C is wrong because `DependencyTrackingModule.Initialize()` is a legacy approach for .NET Framework apps; in .NET Core, the module is automatically initialized by the SDK when `AddApplicationInsightsTelemetry()` is called, and adding a manual reference is unnecessary and may cause duplicate initialization. Option D is wrong because Status Monitor is a .NET Framework tool that cannot instrument .NET Core applications; Azure App Service for .NET Core relies on the SDK or the App Service 'Application Insights' blade settings, not Status Monitor.

Practice this question →
4
MCQmedium

You are deploying a Java application to Azure App Service using Azure Pipelines. You want to automatically capture JVM metrics (heap usage, garbage collection) and correlate them with deployment events. What should you do?

A.Use Azure Monitor diagnostic settings for the App Service.
B.Enable Application Insights Java agent in the App Service.
C.Attach a profiler from Visual Studio to the App Service process.
D.Configure App Service diagnostic logs to capture stdout/stderr.
AnswerB

The Application Insights Java agent (javaagent) attaches to the JVM at startup and automatically collects JVM metrics such as heap memory, GC pauses, thread count, and class loading, along with distributed traces and custom telemetry, making it the correct and minimally invasive approach for monitoring a Java app on App Service.

Why this answer

The Application Insights Java agent automatically captures JVM metrics such as heap usage and garbage collection, and it integrates with Azure Pipelines to correlate deployment events with these metrics. Option A is incorrect because Azure Monitor diagnostic settings capture Azure platform logs, not application-level JVM metrics. Option C is incorrect because the Visual Studio profiler is designed for local or development debugging, not for automatic production monitoring.

Option D is incorrect because diagnostic logs for stdout/stderr capture application output, not JVM internals.

Practice this question →
5
MCQeasy

You need to monitor the health of your Azure Pipeline agents. Which Azure DevOps Analytics view should you use to identify agents that have not reported in the last hour?

A.Agent Health dashboard
B.Release Analytics
C.Test Analytics
D.Pipeline Run Analytics
AnswerA

The Agent Health dashboard in Azure DevOps provides a real-time view of pipeline agents, including their status (online/offline), enabled state, and the last time the agent contacted the service. It is the appropriate tool for monitoring agent health, as it directly surfaces connectivity and availability issues for both Microsoft-hosted and self-hosted agents.

Why this answer

The Agent Health dashboard in Azure DevOps provides real-time status of pipeline agents, including their last communication timestamp. By filtering for agents that have not reported in the last hour, you can identify unhealthy or disconnected agents. This dashboard directly surfaces agent connectivity and health metrics.

Note that this is a dashboard, not an Analytics view like Release Analytics, Test Analytics, or Pipeline Run Analytics.

Exam trap

Candidates may confuse 'Release Analytics' or 'Pipeline Run Analytics' with agent health monitoring, because they assume any analytics view related to pipelines would include agent status, but Azure DevOps separates agent infrastructure health (monitored via the Agent Health dashboard) from pipeline execution analytics.

How to eliminate wrong answers

Option B (Release Analytics) is wrong because it focuses on release pipeline performance metrics (e.g., deployment frequency, lead time) and does not expose agent-level health or connectivity status. Option C (Test Analytics) is wrong because it provides insights into test results, pass rates, and test execution trends, not agent reporting or health. Option D (Pipeline Run Analytics) is wrong because it analyzes pipeline run durations, success rates, and stage-level metrics, but does not include agent heartbeat or last-reported-time data.

Practice this question →
6
MCQmedium

You have an Azure DevOps pipeline that deploys a web app to Azure App Service. You want to capture deployment frequency and change failure rate as metrics in Application Insights. Which built-in analytics view should you use?

A.Deployment Frequency
B.Application Dashboard
C.Time to Restore Service
D.Azure DevOps Pipeline Telemetry
AnswerB

The Application Dashboard is a built-in analytics view in Application Insights that can be customized with metric tiles to display deployment frequency and change failure rate.

Why this answer

The Application Dashboard in Application Insights is a built-in analytics view that provides a customizable overview of your application's metrics. While it does not natively display deployment frequency or change failure rate, you can configure it with metric tiles to show these values if telemetry is properly instrumented. Option A is incorrect because 'Deployment Frequency' is a report in Azure DevOps Analytics, not a built-in view in Application Insights.

Exam trap

Candidates may assume that 'Deployment Frequency' is a built-in Application Insights view because it appears in the Azure DevOps UI. However, it is a report within Azure DevOps Analytics, not a view in Application Insights. The question specifically asks for an Application Insights built-in analytics view.

How to eliminate wrong answers

Option B is wrong because the Application Dashboard is a customizable overview of application health and performance metrics (e.g., requests, failures, dependencies), but it does not include built-in views for deployment frequency or change failure rate. Option C is wrong because Time to Restore Service is a separate metric focused on mean time to recovery (MTTR) after an incident, not on deployment frequency or change failure rate. Option D is wrong because Azure DevOps Pipeline Telemetry is not a built-in analytics view in Application Insights; it refers to telemetry data from pipeline runs, but Application Insights does not have a dedicated view with that name for deployment metrics.

Practice this question →
7
Multi-Selecthard

A company uses Azure Monitor and Application Insights to monitor a microservices application deployed on Azure Kubernetes Service (AKS). The development team wants to implement distributed tracing to correlate requests across services. They currently have Application Insights SDKs instrumented in each service. Which TWO configurations are required to enable end-to-end distributed tracing?

Select 2 answers
A.Enable the Live Metrics Stream feature in Application Insights.
B.Ensure all services use the same Application Insights instrumentation key or connection string.
C.Configure adaptive sampling in the Application Insights SDK.
D.Ensure the SDKs are configured to propagate correlation headers (e.g., W3C Trace-Context).
E.Enable Application Map in the Azure portal for each service.
AnswersB, D

For distributed tracing, all services must send telemetry to the same Application Insights resource by using the same instrumentation key or connection string. This ensures that the operation IDs and parent IDs emitted by each service are stored in one logical table, allowing the trace to be stitched together across service boundaries. Using different keys on different services scatters telemetry into separate resources, making it impossible to correlate a request end-to-end even if trace-context headers are present. This is a necessary prerequisite, though not sufficient on its own.

Why this answer

All services must share the same Application Insights instrumentation key or connection string to ensure that telemetry from different microservices is correlated into a single application map and trace. Without a common instrumentation key, the distributed trace data would be siloed across separate Application Insights resources, preventing end-to-end correlation.

Exam trap

The trap here is that candidates often confuse enabling Application Map (a visualization) with the actual configuration needed for correlation, or they think adaptive sampling is required for tracing, when in fact the key requirements are a shared instrumentation key and header propagation.

Practice this question →
8
MCQhard

Refer to the exhibit. You deploy this ARM template to create a Log Analytics workspace and a saved search. After deployment, you notice that the saved search returns no results even though there are failed pipeline runs. What is the most likely reason?

A.The savedSearch API version is not supported.
B.The Log Analytics workspace API version is incorrect.
C.The custom table 'AzureDevOpsPipelineEvents_CL' does not exist in the workspace.
D.The category 'Azure Pipelines' is misspelled.
AnswerC

The ARM template deployment fails because the saved search references the custom log table 'AzureDevOpsPipelineEvents_CL', but that table does not exist in the workspace. Custom tables with the _CL suffix must be created beforehand (or data must be ingested to auto-create them); ARM templates do not implicitly create custom tables just because a saved search queries them.

Why this answer

The query uses a custom log table 'AzureDevOpsPipelineEvents_CL' which requires a custom table or data connector to be created first. Option A is wrong because the savedSearch API version is valid. Option B is wrong because the workspace API version is valid.

Option D is wrong because the category is just a label.

Practice this question →
9
Multi-Selectmedium

Your organization uses Azure Pipelines with multiple release stages. You need to instrument the pipeline to capture the duration of each stage and the number of failed tasks. Which TWO approaches should you use?

Select 2 answers
A.Configure pipeline notifications for failed tasks.
B.Implement a 'runOnce' deployment strategy to ensure sequential stages.
C.Enable the 'Summary' tab in the pipeline run to view stage durations.
D.Use the Azure DevOps REST API to retrieve pipeline run statistics after each run.
E.Add a script task at the end of each stage to log stage duration and task results to a custom log file.
AnswersD, E

The Azure DevOps REST API (e.g., Builds - Get or Timelined endpoints) returns detailed run metadata including stage/task durations, results, and timestamps for every run. Calling this API after each pipeline run lets you programmatically collect and persist the exact statistics needed for performance analysis.

Why this answer

Options D and E are correct. The goal is to capture stage duration and failed task counts. Option D uses the Azure DevOps REST API to programmatically retrieve pipeline run statistics, which includes stage-level durations and failure information.

Option E adds a script task at the end of each stage that logs the stage's duration and task results to a custom log file, providing direct instrumentation. Option A is incorrect because pipeline notifications only alert on failures, they don't capture or log durations. Option B is incorrect because 'runOnce' is a deployment strategy that ensures sequential stages, not an instrumentation method.

Option C is incorrect because the 'Summary' tab in the pipeline run provides a high-level overview, not detailed per-stage duration data that can be programmatically captured.

Practice this question →
10
MCQhard

You are debugging a production issue using Application Insights Snapshot Debugger. The exhibit shows a snapshot from a NullReferenceException. The variable _dbContext is null. What is the most likely root cause?

A.The call to the database is not awaited, causing a race condition.
B.The DbContext is not registered in the dependency injection container.
C.The database connection string is invalid in appsettings.json.
D.The OnGet method is missing a null check for _dbContext before usage.
AnswerB

Incorrect. In Razor Pages, the page model (IndexModel) is automatically instantiated by the framework. It does not need to be registered in the DI container for construction injection to work.

Why this answer

In ASP.NET Core, when a constructor-injected service like a DbContext is null at runtime, the most likely root cause is that the service (the DbContext) has not been registered in the dependency injection container. Page models themselves do not require registration. The missing null check (Option D) is a symptom, not the root cause, and the other options are unrelated.

Exam trap

Candidates may mistakenly choose Option D (missing null check) because it directly prevents the exception, but the root cause is the missing DI registration.

How to eliminate wrong answers

Option A is wrong because an unawaited database call would cause a race condition or incomplete operation, but the snapshot clearly shows _dbContext is null, not that the call was started and not completed. Option C is wrong because an invalid connection string would cause a runtime exception when the DbContext attempts to open a connection, not a NullReferenceException from a null _dbContext variable. Option D is wrong because while adding a null check would prevent the crash, it does not address the root cause—the missing DI registration—and would only mask the underlying configuration error.

Practice this question →
11
Drag & Dropmedium

Drag and drop the steps to configure Azure DevOps artifact feeds for NuGet packages into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

Feed setup starts with creation, upstream sources, permissions, publishing, and consumption.

Practice this question →
12
MCQhard

You are troubleshooting an intermittent performance issue in a web application. Application Insights shows a high number of failed dependency calls to Azure SQL Database. The errors are SqlException with error code -2 (timeout). What is the most likely cause and recommended fix?

A.The application is exhausting the connection pool; increase Max Pool Size in the connection string.
B.The SQL Server firewall is blocking the application IP; add a firewall rule.
C.The database is experiencing deadlocks; enable read committed snapshot isolation.
D.The database DTU limit is being exceeded; scale up the service tier.
AnswerA

Connection pool exhaustion occurs when the application requests more connections than the configured Max Pool Size, forcing new requests to wait for a free connection until the connection timeout threshold is reached, which manifests as intermittent timeouts under load; increasing Max Pool Size or ensuring connections are properly disposed can resolve this.

Why this answer

A is correct because SqlException with error code -2 indicates a connection timeout, which in a high-traffic scenario is most commonly caused by the application exhausting the connection pool. When all connections in the pool are in use and the wait time for a free connection exceeds the Connect Timeout (default 15 seconds), new requests fail with this error. Increasing Max Pool Size in the connection string (e.g., Max Pool Size=200) allows more concurrent connections, reducing contention.

Exam trap

The trap here is that candidates confuse a connection timeout (error -2) with a query timeout or resource throttling, leading them to choose DTU scaling or deadlock solutions instead of recognizing the connection pool exhaustion pattern.

How to eliminate wrong answers

Option B is wrong because a firewall block would produce a different error (e.g., SqlException with error 53 or 18456, not -2) and would affect all requests consistently, not intermittently. Option C is wrong because deadlocks generate error code 1205, not -2, and are resolved by retry logic or snapshot isolation, not by adjusting pool size. Option D is wrong because exceeding DTU limits causes throttling with error codes like 10928 or 40501, not a timeout error -2, and scaling up would not fix connection pool exhaustion.

Practice this question →
13
MCQmedium

You have deployed an Azure Resource Manager (ARM) template for a scheduled query rule as shown. The rule is enabled and targets an Application Insights resource. However, no alerts are firing despite HTTP 500 errors occurring. What is the most likely cause?

A.The severity is set to 2, which suppresses the alert.
B.The threshold of 100 is too high; the rule should use a percentage-based condition on error rate.
C.The metric name 'requests/count' is misspelled; it should be 'requests/count' (correct).
D.The dimension filter for 'request/resultCode' includes '500' but should also include '5xx' wildcard.
AnswerB

The rule should use a percentage-based condition on the failed request rate rather than an absolute count of 100. In low-traffic applications, 100 failed requests may represent a very high error percentage and go undetected, while a percentage threshold would trigger alerts based on the rate of failures relative to total requests.

Why this answer

The threshold of 100 is an absolute count, not a percentage. HTTP 500 errors may occur sporadically, but unless they reach 100 within the evaluation window, the alert will not fire. For error-rate monitoring, a percentage-based condition (e.g., >5% of total requests) is more appropriate to detect anomalies even with lower traffic volumes.

Exam trap

The trap here is that candidates often assume an absolute count threshold is fine for error monitoring, but Azure's alerting logic requires careful consideration of traffic patterns—percentage-based conditions are essential for detecting error rate spikes in variable-load environments.

How to eliminate wrong answers

Option A is wrong because severity level 2 does not suppress alerts; severity levels (0-4) only affect the alert's classification in Azure Monitor, not its firing behavior. Option C is wrong because 'requests/count' is a valid metric name in Application Insights; there is no misspelling. Option D is wrong because the dimension filter for 'request/resultCode' with value '500' is correct; Azure Monitor does not support wildcards like '5xx' in dimension filters—you must specify exact values.

Practice this question →
14
MCQhard

A development team is implementing a distributed tracing solution for a microservices application deployed on Azure. They want to correlate requests across services using OpenTelemetry and send data to Azure Monitor. The application currently generates traces, but the traces are incomplete, showing only individual service spans without end-to-end correlation. The team has already instrumented each service with the OpenTelemetry SDK. What should the team do to ensure proper end-to-end trace correlation?

A.Implement context propagation by passing trace headers between services.
B.Enable the Application Insights auto-instrumentation agent on the application host.
C.Configure the OpenTelemetry SDK to use the Azure Monitor exporter instead of the default exporter.
D.Set the same service name for all services in the OpenTelemetry configuration.
AnswerA

Context propagation is required to correlate spans across services.

Why this answer

Distributed tracing requires propagating trace context (trace ID, span ID) across service boundaries via HTTP headers (e.g., W3C Trace-Context). Without context propagation, each service creates its own trace, resulting in disconnected spans. The OpenTelemetry SDK automatically handles propagation when configured, but the team must ensure that outgoing requests include the trace headers and incoming requests extract them.

Exam trap

The trap here is that candidates often confuse telemetry export (sending data to a backend) with context propagation (passing trace IDs between services), assuming that using the correct exporter or agent automatically correlates spans.

How to eliminate wrong answers

Option B is wrong because the Application Insights auto-instrumentation agent (e.g., for .NET or Java) is a separate solution that does not use OpenTelemetry; it would replace the existing instrumentation rather than fix the missing context propagation. Option C is wrong because changing the exporter (e.g., to Azure Monitor exporter) only affects where telemetry is sent, not how trace context is propagated between services; the correlation issue is in the propagation layer, not the export layer. Option D is wrong because setting the same service name for all services would incorrectly merge telemetry into a single service identity, breaking the ability to distinguish service boundaries and still not propagating trace context.

Practice this question →
15
MCQhard

You are the DevOps lead for a fintech company. The organization uses a multi-tenant Azure DevOps environment with hundreds of pipelines. The compliance team requires that every pipeline run must be auditable with the following attributes captured: who triggered the run, what code changes were included, which artifacts were produced, and whether any secrets (e.g., Azure Key Vault references) were accessed during the run. Additionally, all audit data must be retained for 7 years and be queryable within 5 minutes of a pipeline completion. Current state: pipelines use Azure Key Vault for secrets, and YAML pipelines are defined with variables referencing Key Vault. You need to design an instrumentation strategy to meet these requirements. What should you do?

A.Enable Azure DevOps Audit Streams to send audit events to a Log Analytics workspace. Configure a Log Analytics workspace with 7-year retention. Create a dashboard and alert rules for compliance.
B.Use Azure Event Grid to subscribe to pipeline run events and store them in Azure Cosmos DB with TTL for 7 years.
C.Add a step at the end of each pipeline to upload pipeline logs as pipeline artifacts with a retention policy of 7 years.
D.Instrument each pipeline with custom tasks that send telemetry to Application Insights. Set Application Insights to 7-year retention.
AnswerA

Azure DevOps Audit Streams is the native mechanism that pushes every audit event from the organization, including user/group changes, permissions, service connection modifications, and pipeline run events, to a Log Analytics workspace via a diagnostic setting. Configuring the workspace with interactive retention plus a seven-year archive provides durable, long-term compliance storage, and KQL queries can power dashboards and alert rules to detect anomalous behavior. This matches the compliance requirement because it captures who did what, when, and from where, with near real-time delivery.

Why this answer

Using Azure DevOps Audit Streams to send events to a Log Analytics workspace provides long-term retention and near real-time querying. Azure DevOps Audit logs capture all required attributes including pipeline runs, secret access, and user identity. Option B is incorrect because Azure Event Grid subscription to pipeline run events does not provide long-term retention and querying capabilities; it is event-driven delivery.

Option C is incorrect because adding a step to upload pipeline logs as artifacts does not capture the audit trail of who triggered the run or whether secrets were accessed. Option D is incorrect because instrumenting pipelines with custom tasks sending telemetry to Application Insights is for application telemetry, not pipeline audit, and does not capture all required attributes.

Practice this question →
16
Multi-Selecthard

You are building a comprehensive instrumentation strategy for a large-scale Azure DevOps environment. You need to ensure that all pipeline events (build, release, test) are automatically tracked and correlated with application performance data. Which THREE components should you include?

Select 3 answers
A.A shared Correlation ID that flows from pipeline to application.
B.Azure Monitor Workbooks to visualize pipeline data.
C.Custom pipeline tasks that send telemetry to Application Insights.
D.Azure Boards to track pipeline run metadata.
E.OpenTelemetry SDK in the application to emit trace context.
AnswersA, C, E

A shared Correlation ID that flows from pipeline to application is correct because it enables end-to-end traceability, linking build/release pipeline events to application telemetry. This ID is propagated via environment variables or HTTP headers, allowing every log, metric, and trace to be correlated across the CI/CD boundary, which is essential for diagnosing failures that span pipeline and runtime.

Why this answer

Options A, C, and E are correct. A shared Correlation ID (A) flows from pipeline to application, enabling end-to-end trace correlation. Custom pipeline tasks (C) send telemetry (e.g., build/release events) to Application Insights.

The OpenTelemetry SDK (E) emits trace context from the application, which can include the correlation ID. Option B is wrong because Azure Monitor Workbooks are visualization tools, not data collection components. Option D is wrong because Azure Boards is for work item tracking, not pipeline event capture.

Practice this question →
17
MCQhard

You are reviewing a Data Collection Rule (DCR) for an Azure virtual machine. The DCR is assigned to the VM, and the Azure Monitor Agent is installed. After one hour, no performance data appears in the Log Analytics workspace. What is the most likely cause?

A.The workspace resource ID is incorrectly formatted.
B.The data flow streams property does not include 'Microsoft-Perf'.
C.The counter specifier uses the wrong format for Windows performance counters.
D.The sampling frequency of 60 seconds is too low and data is being throttled.
AnswerB

The data flow streams property does not include 'Microsoft-Perf'. For Windows performance counters to be collected in an Azure Monitor DCR, the 'dataFlows' section must map the 'Microsoft-Perf' stream to the destination workspace; without this stream explicitly listed, the DCR lacks the required linkage for performance data ingestion, and no counter data will flow.

Why this answer

The most likely cause is that the data flow streams property in the DCR does not include 'Microsoft-Perf'. The Azure Monitor Agent uses DCRs to define which data to collect and where to send it. Without the 'Microsoft-Perf' stream specified in the dataFlows section, performance counters are not collected, even if the counter specifiers are correctly defined.

The workspace resource ID and counter format may be correct, but the missing stream prevents any performance data from being ingested.

Exam trap

The trap here is that candidates focus on the counter specifier format or sampling frequency, overlooking the critical data flow stream property which is the actual pipeline that enables data ingestion.

How to eliminate wrong answers

Option A is wrong because an incorrectly formatted workspace resource ID would typically cause a configuration error or a failure to connect, not a silent absence of data after one hour; the agent would log an error. Option B is wrong because it is actually the correct answer, not a wrong option. Option C is wrong because the counter specifier format (e.g., '\Processor(_Total)\% Processor Time' for Windows) is validated at DCR creation time, and an incorrect format would result in a schema validation error, not a one-hour delay with no data.

Option D is wrong because a sampling frequency of 60 seconds is standard and not too low; Azure Monitor does not throttle data based on sampling frequency, and throttling would affect all data types, not just performance counters.

Practice this question →
18
MCQhard

You are designing a centralized logging strategy for multiple microservices hosted in Azure Kubernetes Service (AKS). Each microservice writes logs in JSON format to stdout/stderr. The operations team needs to query logs across all services and correlate them with application performance metrics. Which solution provides the best integration?

A.Configure AKS to send logs to Azure Blob Storage and use Azure Storage Analytics for querying.
B.Enable Container Insights in Azure Monitor to collect stdout/stderr logs and metrics into a Log Analytics workspace.
C.Stream logs to Azure Event Hubs and then to Azure Data Explorer for analysis.
D.Deploy the Application Insights agent as a DaemonSet in AKS and send logs directly to Application Insights.
AnswerB

Container Insights is the native Azure Monitor solution for AKS: it deploys a Log Analytics agent as a DaemonSet to collect stdout/stderr logs, performance metrics, and container inventory into a Log Analytics workspace. This enables rich Kusto Query Language (KQL) queries, alerting, and correlation with other Azure Monitor data, making it the correct centralized logging approach for AKS workloads.

Why this answer

Container Insights in Azure Monitor is the best solution because it natively collects stdout/stderr logs from AKS containers and correlates them with performance metrics (CPU, memory, disk, network) in a single Log Analytics workspace. This enables the operations team to query logs across all microservices using KQL and join them with metrics for end-to-end troubleshooting, without additional infrastructure or data movement.

Exam trap

The trap here is that candidates often confuse Application Insights (designed for application-level telemetry) with Container Insights (designed for container-level logs and metrics), leading them to choose Option D, which lacks the native AKS metric correlation and Log Analytics workspace integration required for centralized querying.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage is a cold storage tier with no native query capability for JSON logs; Storage Analytics provides only storage metrics, not log search or correlation with application performance metrics. Option C is wrong because streaming logs to Event Hubs and then to Azure Data Explorer adds unnecessary complexity and latency; while ADX is a powerful analytics engine, it is not the integrated, out-of-the-box solution for AKS log and metric correlation that Container Insights provides. Option D is wrong because the Application Insights agent as a DaemonSet sends logs directly to Application Insights, which is designed for application-level telemetry (traces, exceptions, requests) rather than container stdout/stderr logs and AKS node/container metrics; it lacks the native integration with AKS cluster-level metrics and Log Analytics workspace that Container Insights offers.

Practice this question →
19
Multi-Selecteasy

A company runs a critical microservices application on Azure Kubernetes Service (AKS). They need to implement distributed tracing across services using Application Insights. Which three actions should be performed?

Select 3 answers
A.Deploy the Application Insights agent as a DaemonSet on each AKS node
B.Use OpenTelemetry SDK with Application Insights exporter
C.Instrument each microservice with the Application Insights SDK
D.Set the same instrumentation key for all microservices
E.Enable Azure Monitor Container Insights on the AKS cluster
AnswersB, C, D

OpenTelemetry SDKs instrument application code to generate standardized distributed traces with context propagation, and the Application Insights exporter sends that telemetry to Azure Monitor, allowing end-to-end correlation and analysis across microservices.

Why this answer

Distributed tracing requires every microservice to emit trace data. This can be achieved by instrumenting each service with the Application Insights SDK (option C) or using OpenTelemetry SDK with the Application Insights exporter (option B). To ensure all spans from different services are correlated into a single distributed trace, all services must use the same instrumentation key so telemetry lands in the same Application Insights resource (option D).

Option A is incorrect because the Application Insights agent is not deployed as a DaemonSet for this purpose, and option E is incorrect because Container Insights is for infrastructure monitoring, not application-level distributed tracing.

Exam trap

The trap here is confusing infrastructure monitoring (Container Insights) with application-level distributed tracing, leading candidates to select options that collect metrics but fail to provide the cross-service correlation needed for distributed tracing.

Practice this question →
20
MCQmedium

Your team uses Azure DevOps for CI/CD. You need to ensure that every build publishes telemetry to Application Insights, including build duration, test pass rate, and deployment frequency. Which approach should you use?

A.Call the Azure DevOps REST API from a custom script in the pipeline to capture telemetry.
B.Run the Azure DevOps CLI command 'az devops telemetry publish' in a build task.
C.Use the built-in 'Pipeline Telemetry' dashboard in Azure DevOps.
D.Use the Azure DevOps Analytics OData endpoint to query pipeline telemetry and send to Application Insights via a release task.
AnswerD

The Analytics Service exposes pipeline run, test, and work item data as OData entities, allowing you to run rich queries. You can then use a release pipeline task (e.g., a PowerShell script) to call the OData endpoint, transform the results, and send them to Application Insights using its TrackEvent or TrackMetric APIs for custom monitoring and alerting. This is the recommended integration path.

Why this answer

The Azure DevOps Analytics OData endpoint provides a standardized, queryable interface to pipeline telemetry data (build duration, test pass rate, deployment frequency). By using a release task to query this endpoint and forward the data to Application Insights, you can instrument your CI/CD pipeline to send custom telemetry without relying on manual scripting or unsupported commands. This approach aligns with the 'Implement an instrumentation strategy' domain by leveraging Azure DevOps Analytics and Application Insights integration.

Exam trap

The trap here is that candidates may assume Azure DevOps has a built-in 'telemetry publish' command or dashboard that directly sends data to Application Insights, but in reality, you must use the Analytics OData endpoint as an intermediary to extract and forward pipeline telemetry.

How to eliminate wrong answers

Option A is wrong because calling the Azure DevOps REST API from a custom script requires manual parsing of pipeline execution data and lacks a built-in mechanism to directly push telemetry to Application Insights, making it error-prone and less maintainable. Option B is wrong because the Azure DevOps CLI command 'az devops telemetry publish' does not exist; the CLI does not support a telemetry publish command for pipeline data. Option C is wrong because the built-in 'Pipeline Telemetry' dashboard in Azure DevOps only displays telemetry within Azure DevOps itself and does not export data to Application Insights for external monitoring or alerting.

Practice this question →
21
MCQhard

You are designing an instrumentation strategy for a microservices application deployed to Azure Kubernetes Service (AKS) using Azure Pipelines. The application emits custom metrics using OpenTelemetry. You need to ensure that all pipeline-related events (build, release, and test results) are correlated with application telemetry to enable end-to-end traceability. What should you do?

A.Configure Application Insights to ingest pipeline telemetry via a custom exporter.
B.Store pipeline logs in an Azure Log Analytics workspace and query them together with application metrics.
C.Use Azure Pipelines' Checks feature to enforce deployment gates based on application metrics.
D.Set a unique Correlation ID in the pipeline variables and pass it to the application's OpenTelemetry instrumentation as a span attribute.
AnswerD

Setting a unique Correlation ID in pipeline variables and passing it into the application's OpenTelemetry instrumentation as a span attribute creates a shared context for all telemetry emitted during that pipeline run. This allows you to query Application Insights for every span and log associated with a specific build/deployment, enabling end-to-end traceability from pipeline to application.

Why this answer

Setting a unique Correlation ID in pipeline variables and passing it as a span attribute to OpenTelemetry allows end-to-end traceability by linking pipeline events with application telemetry. Option A is incorrect because Application Insights can ingest pipeline telemetry, but that alone does not correlate with application telemetry; you need a shared correlation ID. Option B is wrong because storing pipeline logs in Log Analytics and querying with metrics does not provide real-time correlation at the span level.

Option C is incorrect because deployment gates based on application metrics do not create correlation; they only block deployments based on conditions.

Practice this question →
22
MCQhard

You are a DevOps engineer for a large e-commerce company. The company uses Azure DevOps for CI/CD and Application Insights for monitoring. The application is a .NET Core 6 microservice running on Azure Kubernetes Service (AKS) with a Redis cache and Azure SQL Database. Recently, the operations team noticed that the application's response time has degraded significantly during peak traffic hours. Application Insights shows an increase in server-side dependency call duration to Redis and SQL, but no increase in exceptions. The team suspects a connection pooling issue. You have been asked to diagnose and fix the problem. Which approach should you take first?

A.Increase the number of AKS nodes to handle peak traffic and reduce resource contention.
B.Review the application code to ensure that Redis and SQL connections are properly opened and closed using 'using' statements.
C.Run a load test against the application to reproduce the issue and monitor system counters.
D.Use Application Insights 'Dependency' performance blade to analyze call duration percentiles and identify whether the bottleneck is in Redis or SQL. Then adjust connection pool sizes accordingly.
AnswerD

This approach uses telemetry to isolate the dependency (Redis vs SQL) that is causing the delay by comparing p50/p95/p99 call durations, and then lets you tune connection pool max sizes based on measured concurrency and latency, directly addressing the root cause.

Why this answer

The first step in diagnosing a connection pooling issue is to analyze the dependency performance data in Application Insights. The 'Dependency' blade provides detailed percentiles (e.g., P50, P95, P99) for Redis and SQL call durations, allowing you to pinpoint which dependency is the bottleneck. Once identified, you can adjust the connection pool size (e.g., Max Pool Size in SQL connection string or Redis multiplexer settings) to match the peak concurrency demands without overwhelming the database or cache.

Exam trap

The trap here is that candidates assume the issue is a code bug (Option B) or infrastructure scaling (Option A), but the question explicitly states no exceptions and a connection pooling suspicion, so the correct first diagnostic step is to analyze existing telemetry to confirm the bottleneck before making changes.

How to eliminate wrong answers

Option A is wrong because increasing AKS nodes addresses compute resource contention, not connection pooling issues; the problem is at the dependency layer (Redis/SQL), not node CPU/memory. Option B is wrong because while proper disposal of connections is important, the team already suspects a connection pooling issue (not leaked connections), and the code likely already uses 'using' statements in .NET Core 6; the fix is to tune pool sizes, not to fix leaks. Option C is wrong because running a load test to reproduce the issue is a valid step, but it should come after analyzing existing telemetry; Application Insights already has the data needed to identify the bottleneck, making a load test premature and potentially disruptive.

Practice this question →
23
Multi-Selecteasy

Which TWO are best practices when configuring alerts in Azure Monitor for a production application?

Select 2 answers
A.Use metric alerts only for simple threshold-based conditions.
B.Use dynamic thresholds for metrics with seasonal patterns.
C.Create separate alert rules for each condition to avoid complexity.
D.Configure action groups to send notifications and run automated actions.
E.Ensure each alert rule uses a unique action group to isolate notifications.
AnswersB, D

Dynamic thresholds employ machine learning to model historical metric behavior, continuously adjusting the baseline to account for seasonal patterns such as time-of-day, weekly, or yearly fluctuations. This adaptive behavior minimizes false positives during predictable peaks and troughs, while still detecting genuine deviations that deviate from the learned pattern. For metrics with recurring seasonality, dynamic thresholds are the recommended approach because they automatically recalibrate as the baseline shifts, unlike static thresholds that require manual updates.

Why this answer

Dynamic thresholds in Azure Monitor use machine learning to automatically detect and adjust alert thresholds based on historical patterns, making them ideal for metrics with seasonal or cyclical behavior (e.g., CPU usage that spikes during business hours). This reduces alert noise and manual tuning effort compared to static thresholds.

Exam trap

The trap here is that candidates often assume metric alerts are only for simple thresholds (Option A) and overlook that dynamic thresholds are purpose-built for seasonal patterns, while also mistakenly thinking unique action groups per rule (Option E) improve isolation rather than creating unnecessary complexity.

Practice this question →
24
MCQmedium

Your team uses Azure Pipelines to deploy a Node.js application. Recently, deployments have been failing intermittently due to a missing npm package. The pipeline runs successfully on the local agent but fails on the hosted agent. Which instrumentation strategy should you implement to identify the root cause?

A.Replace the hosted agent with a self-hosted agent.
B.Configure Application Insights for the Node.js app to monitor runtime errors.
C.Enable verbose logging for the npm install task and compare the output between pipeline runs.
D.Add a pipeline cache task for npm packages to ensure consistent restore.
AnswerC

Verbose logging shows detailed dependency resolution steps.

Why this answer

Enabling verbose logging for the npm install task allows you to see detailed output of package resolution and installation steps. By comparing the logs between the local agent (success) and hosted agent (failure), you can identify differences in npm registry availability, package versions, or authentication issues that cause the intermittent missing package. Option A is wrong because self-hosted agents might not match the hosted environment's configuration, and the goal is to diagnose the problem on hosted agents.

Option B is wrong because Application Insights monitors application runtime behavior, not build-time dependency installation. Option D is wrong because pipeline caching would reuse previously installed packages, which could mask the problem by not performing a fresh install, and does not help identify why the package is missing on hosted agents.

Practice this question →
25
MCQeasy

You are configuring Application Insights for a .NET Core web application deployed to Azure App Service. The application must capture telemetry for all HTTP requests, exceptions, and dependency calls with minimal code changes. What should you do?

A.Enable the Application Insights site extension in the App Service 'Application Insights' blade.
B.Configure diagnostics logging in the App Service and stream logs to Application Insights.
C.Install the Microsoft.ApplicationInsights.AspNetCore NuGet package and add services.AddApplicationInsightsTelemetry() in Startup.cs.
D.Add the Application Insights JavaScript SDK to each page.
AnswerA

The Application Insights site extension in the App Service 'Application Insights' blade is the correct choice because it attaches the Application Insights agent directly to the App Service runtime, automatically collecting server-side telemetry such as requests, dependencies, exceptions, and performance counters without requiring any code changes, recompilation, or redeployment.

Why this answer

Enabling the Application Insights site extension via the App Service 'Application Insights' blade automatically instruments the .NET Core application without requiring any code changes. This extension injects the necessary telemetry modules to capture HTTP requests, exceptions, and dependency calls at the runtime level, leveraging the Azure App Service integration for zero-code instrumentation.

Exam trap

The trap here is that candidates often assume the NuGet package (Option C) is always required for .NET Core instrumentation, overlooking the zero-code site extension option that meets the 'minimal code changes' requirement more directly.

How to eliminate wrong answers

Option B is wrong because configuring diagnostics logging and streaming logs to Application Insights captures only platform-level logs (e.g., IIS logs, failed request tracing) and does not automatically capture application-level telemetry like dependency calls or exceptions without additional custom code. Option C is wrong because while installing the NuGet package and adding services.AddApplicationInsightsTelemetry() is a valid code-based approach, the question explicitly requires 'minimal code changes,' making the site extension (zero-code) the better choice. Option D is wrong because the JavaScript SDK is for client-side browser telemetry (page views, client exceptions), not for server-side HTTP requests, exceptions, or dependency calls in a .NET Core web application.

Practice this question →
26
Matchingmedium

Match each Azure DevOps security concept to its purpose.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Personal access token for API authentication

Securely stores credentials for external services

Shared variables with optional secret protection

Centralized secure files and variable groups

Why these pairings

Azure AD manages user identities; PATs authenticate scripts; Service Principals authenticate automated services; Security Groups manage user permissions. Common confusions include mixing the roles of Azure AD and Service Principals, or PATs with Security Groups.

Practice this question →
27
MCQeasy

Your team uses GitHub Actions for CI/CD. You need to collect and analyze build and deployment logs centrally to identify recurring failures. Which service should you use to ingest and query these logs?

A.Azure Monitor Alerts
B.Azure Log Analytics
C.GitHub Insights
D.Application Insights
AnswerB

Azure Log Analytics is the log ingestion, storage, and query service within Azure Monitor; it can collect GitHub Actions workflow run logs via diagnostic settings or integrations, enabling you to centralize CI/CD logs and analyze them with KQL queries.

Why this answer

Azure Log Analytics is the correct service for centralizing and querying logs from GitHub Actions. It can ingest logs via connectors or API, enabling analysis of build and deployment logs to identify recurring failures. Azure Monitor Alerts (A) is for setting up alerts, not for storing or querying logs.

GitHub Insights (C) provides reporting and analytics for GitHub repositories but is not designed for custom log querying from CI/CD pipelines. Application Insights (D) focuses on application performance monitoring and telemetry, not CI/CD pipeline logs.

Practice this question →
28
MCQhard

A company has a multi-region application deployed on Azure App Service (Windows) across three regions: West US, East US, and West Europe. The operations team uses Azure Monitor to collect application logs and metrics. Recently, they noticed that the application in West US is experiencing high CPU usage (sustained above 90%) during peak hours, while the other regions remain below 60%. The team has set up an autoscale rule on the App Service plan to scale out when CPU exceeds 80% for 10 minutes. However, autoscale is not triggering, and the application in West US is becoming slow. The team has verified that the autoscale rule is correctly configured, the instance count is below the maximum, and there are no scale-in rules interfering. The metric data appears in Azure Monitor. You suspect that the metric alert that triggers autoscale is not firing. What is the most likely cause?

A.The autoscale rule is using the wrong metric aggregation or namespace, such as 'CpuTime' instead of 'Percentage CPU'.
B.The autoscale rule was created less than 24 hours ago and needs a learning period.
C.The metric collection interval for CPU is set to 30 minutes, causing a delay in autoscale evaluation.
D.The autoscale rule is configured to use Log Analytics queries instead of platform metrics.
AnswerA

Azure autoscale requires the rule to reference the correct resource-specific metric namespace (e.g., Microsoft.Compute/virtualMachineScaleSets for VMSS) and metric name such as 'Percentage CPU' with an aggregation of Average over the evaluated time window; specifying a low-level counter like 'CpuTime' or the wrong namespace prevents the metric signal from being recognized, so the scale-out condition never evaluates to true and no scale operation occurs.

Why this answer

The autoscale rule must use the correct metric name and aggregation to evaluate scaling conditions. If the rule is configured with 'CpuTime' instead of 'Percentage CPU', it will not match the actual CPU utilization metric emitted by the Azure App Service plan. 'Percentage CPU' is the standard platform metric for CPU load, while 'CpuTime' measures total CPU time consumed, which does not trigger the same threshold logic. Since the team verified the rule is correctly configured but autoscale is not firing, the most likely cause is a mismatch in the metric name or namespace.

Exam trap

The trap here is that candidates may assume autoscale is failing due to a learning period or data delay, but the real issue is a subtle metric name mismatch that prevents the rule from evaluating the correct data stream.

How to eliminate wrong answers

Option B is wrong because autoscale rules do not require a 24-hour learning period; the 'learning period' applies to predictive autoscale or certain metric-based rules that need historical data, but standard threshold-based autoscale rules evaluate immediately after creation. Option C is wrong because the metric collection interval for CPU on Azure App Service is typically 1 minute, not 30 minutes; a 30-minute interval would be unusual and would cause significant delays, but the question states metric data appears in Azure Monitor, implying normal collection. Option D is wrong because autoscale rules can only use platform metrics or custom metrics from Azure Monitor, not Log Analytics queries directly; Log Analytics queries are used for alert rules, not autoscale conditions.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Implement an instrumentation strategy questions.

Start 20-question session