Courseiva

CCNA Implement an instrumentation strategy Questions

30 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

Sampling preserves representative data and reduces cost while still enabling anomaly detection.

Why this answer

Option B is correct because 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

Measures how often deployments cause failures.

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

This enables automatic dependency tracking for HttpClient.

Why this answer

Option A is correct because `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

Automatically collects JVM metrics.

Why this answer

Option A is correct because Application Insights Java agent automatically collects JVM metrics and can be correlated with deployment markers. Option B is wrong because App Service logs don't include JVM metrics. Option C is wrong because diagnostic settings are for Azure resource logs, not JVM.

Option D is wrong because Visual Studio profiler is not a production monitoring tool.

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

Shows agent status and last contact time.

Why this answer

Option B is correct because the Agent Health dashboard shows agent status and last communication time. Option A is wrong because Pipeline Run Analytics focuses on runs, not agents. Option C is wrong because Test Analytics is for test results.

Option D is wrong because Release Analytics is for release pipelines.

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
AnswerA

It provides the requested metrics.

Why this answer

The Deployment Frequency analytics view in Application Insights is specifically designed to track how often deployments occur and the rate at which they fail, directly aligning with the goal of capturing deployment frequency and change failure rate. This view leverages data from Azure DevOps pipelines to provide these metrics without requiring custom queries or additional instrumentation.

Exam trap

The trap here is that candidates may confuse the Deployment Frequency view with the Application Dashboard, assuming the dashboard can be configured to show these metrics, but the question specifically asks for a built-in analytics view, which only the Deployment Frequency view provides.

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

Same key allows correlation across services.

Why this answer

Option B is correct because 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

Custom tables must be created or data ingested first.

Why this answer

Option C is correct because 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 apiVersion is valid for workspace. Option B is wrong because the API version for savedSearches 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

REST API provides detailed run data.

Why this answer

Options A and D are correct. Option A: REST API can query pipeline run details including stage durations and failures. Option D: Custom logging in tasks writes to the console, which is captured in pipeline logs.

Option B is wrong because it only gives a summary, not per-stage. Option C is wrong because it's a deployment pattern, not instrumentation. Option E is wrong because it's about notifications, not data collection.

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 Index page model 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

If the page model isn't registered, DI can't inject _dbContext.

Why this answer

The Snapshot Debugger shows _dbContext is null, which indicates the dependency was never injected. In ASP.NET Core, page models like IndexModel must be registered in the dependency injection (DI) container (e.g., via AddTransient<IndexModel> or AddScoped<IndexModel>) for DI to resolve and inject the DbContext. Without registration, the runtime creates the page model manually, leaving _dbContext uninitialized and causing a NullReferenceException when OnGet accesses it.

Exam trap

The trap here is that candidates often assume a NullReferenceException always means a missing null check (Option D), but the snapshot's context—showing a dependency that is null—points to a DI registration failure, not a defensive coding oversight.

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

Why this order

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

Practice this question →
12
MCQmedium

A team uses Azure Monitor to collect metrics from their Azure Kubernetes Service (AKS) cluster. They notice that container logs are missing from Log Analytics. The cluster was created with the default settings and no custom configuration was applied. What is the most likely reason for the missing logs?

A.The diagnostic setting for the AKS cluster is not configured to send logs to Log Analytics.
B.The Log Analytics workspace is in a different region than the AKS cluster.
C.The Data Collection Rule does not include the ContainerLogs table.
D.The Azure Monitor agent version on the nodes is outdated.
AnswerC

A DCR must specify which tables to collect; by default, container logs are not collected.

Why this answer

By default, an AKS cluster created with default settings does not have container logs (stdout/stderr) collected by Azure Monitor. Container logs require a Data Collection Rule (DCR) that includes the 'ContainerLogs' table. Without this DCR, the Azure Monitor agent will not collect container logs, even though other metrics may be sent to Log Analytics.

Exam trap

The trap here is that candidates often confuse diagnostic settings (which control platform logs) with Data Collection Rules (which control container logs), leading them to incorrectly select Option A.

How to eliminate wrong answers

Option A is wrong because the diagnostic setting for an AKS cluster controls platform logs (e.g., kube-apiserver logs), not container stdout/stderr logs; container logs are collected via the Azure Monitor agent and DCR, not via diagnostic settings. Option B is wrong because Log Analytics workspaces can receive data from resources in any region; region mismatch does not cause missing container logs. Option D is wrong because the Azure Monitor agent version does not affect the collection of container logs; the agent will collect logs as long as the DCR includes the ContainerLogs table, regardless of version.

Practice this question →
13
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

Timeouts often indicate pool exhaustion.

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 →
14
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 be based on failed requests percentage, not absolute count.

Why this answer

Option B is correct because 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 →
15
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

Option A is correct because 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 →
16
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

Audit Streams captures all required events and Log Analytics provides long-term retention and near real-time querying.

Why this answer

Option A is correct because 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. Application Insights (B) is for application telemetry, not pipeline audit.

Event Grid (C) is event-driven but doesn't store historical data for 7 years query. Pipeline artifacts (D) don't include audit trail of who triggered or secret access.

Practice this question →
17
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

Enables end-to-end correlation.

Why this answer

Options A, D, and E are correct. Option A: OpenTelemetry SDK in the application collects performance data with correlation IDs. Option D: Custom pipeline tasks emit telemetry to Application Insights.

Option E: Using the same Correlation ID across pipeline and application enables correlation. Option B is wrong because Azure Boards does not track pipeline events. Option C is wrong because Azure Monitor Workbooks are visualization tools, not data collection.

Practice this question →
18
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

Performance counters require the 'Microsoft-Perf' stream in the data 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 →
19
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 provides integrated log and metric collection with querying via KQL.

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 →
20
Multi-Selectmedium

Which THREE of the following are valid techniques to reduce the volume of telemetry data sent to Application Insights while preserving diagnostic value?

Select 3 answers
A.Aggregate telemetry into 1-minute buckets before sending
B.Configure fixed-rate sampling
C.Enable adaptive sampling
D.Set a maximum telemetry throughput limit on the Application Insights instance
E.Use ITelemetryProcessor to filter out low-importance telemetry
AnswersB, C, E

Keeps only a percentage of telemetry.

Why this answer

Option B is correct because fixed-rate sampling in Application Insights randomly selects a percentage of telemetry items to send, reducing volume predictably while preserving a representative sample for diagnostics. This technique is ideal when you need consistent, controllable data reduction without losing the ability to detect trends and anomalies across all telemetry types.

Exam trap

The trap here is that candidates often confuse aggregation (Option A) with sampling, not realizing that Application Insights does not natively support pre-send aggregation and that aggregation destroys the per-event diagnostic context needed for root-cause analysis.

Practice this question →
21
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 provides standardized distributed tracing and can export to Application Insights.

Why this answer

Option B is correct because OpenTelemetry is the industry standard for distributed tracing, and the Application Insights exporter allows telemetry data to be sent directly to Azure Monitor. This approach provides a vendor-neutral instrumentation layer that works across multiple languages and platforms, making it ideal for microservices on AKS.

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 →
22
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

OData provides structured telemetry data that can be streamed.

Why this answer

Option D is correct because 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 →
23
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

Correlation ID enables linking pipeline and application telemetry.

Why this answer

Option C is correct because using the Correlation ID in both pipeline variables and OpenTelemetry spans enables correlation. Option A is wrong because Azure Monitor logs don't correlate with pipeline data. Option B is wrong because Application Insights alone doesn't pull pipeline data.

Option D is wrong because pipeline artifacts don't include telemetry.

Practice this question →
24
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 allows data-driven diagnosis of which dependency is causing the delay.

Why this answer

Option D is correct because 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 →
25
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 automatically adjust baselines.

Why this answer

Option B is correct because 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 →
26
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

Option A is correct because enabling verbose logging and comparing the npm install output between agents can reveal differences in package resolution. Option B is wrong because pipeline caching would mask the issue. Option C is wrong because telemetry from the application does not capture build-time dependency issues.

Option D is wrong because self-hosted agents would not match the hosted environment.

Practice this question →
27
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 site extension enables auto-instrumentation with no code changes.

Why this answer

Option A is correct because 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 →
28
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

Key security features in Azure DevOps.

Practice this question →
29
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

Can ingest and query CI/CD logs centrally.

Why this answer

Option A is correct because Azure Log Analytics can ingest logs from GitHub Actions via connectors or API. Option B is wrong because Application Insights is for application monitoring, not CI/CD logs. Option C is wrong because GitHub Insights is a reporting feature, not a log analytics platform.

Option D is wrong because Azure Monitor Alerts is for alerting, not storage/query.

Practice this question →
30
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

Autoscale requires the correct metric and aggregation to trigger.

Why this answer

Option A is correct because 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