Domain 5 · 5–10%

Implement an instrumentation strategy

The smallest domain, and the cheapest to earn marks on: knowing which Azure Monitor feature collects which signal, how to alert on it, how a request is traced across services, and enough KQL to read the data.

Two objectives:

Configure monitoring for a DevOps environment — Azure Monitor, the Insights family, GitHub insights, alerts
Analyze metrics from instrumentation — infra & app metrics, distributed tracing, basic KQL

The July 2026 refresh flagged both Domain 5 objectives as minor updates — expect a little more GitHub-side monitoring and the current Azure Monitor naming.

5.1 Configure monitoring for a DevOps environment

Azure Monitor — the platform

Azure Monitor is the single pane through which all telemetry flows. Everything else in this domain is a feature of it.

flowchart LR subgraph SRC[Sources] APP[Applications] INF[VMs / containers] AZ[Azure resources] ADO[Azure DevOps] GH[GitHub] end subgraph STORE[Data stores] MET[(Metrics
time-series)] LOG[(Logs
Log Analytics)] end SRC --> MET SRC --> LOG MET --> OUT LOG --> OUT subgraph OUT[Consume] DASH[Dashboards / Workbooks] AL[Alerts + action groups] KQL[KQL queries] PBI[Power BI / Grafana] end

Two pillars — Metrics (numeric time-series) and Logs (Log Analytics) — feed dashboards, alerts and KQL.

Data type	Stored in	Queried with	Examples
Metrics	Azure Monitor Metrics (time-series DB)	Metrics explorer	CPU %, request count, response time
Logs	Log Analytics workspace	KQL	App logs, audit events, traces
Traces	Application Insights (in Log Analytics)	KQL / transaction view	Distributed request spans
Changes	Change Analysis	Portal	Resource/config change history

Caveat — metrics vs logs

Metrics are lightweight, pre-aggregated numeric time-series — cheap, fast, near-real-time, ideal for alerting and dashboards. Logs are rich, structured/unstructured records in Log Analytics you query with KQL — flexible but higher latency and cost. "Alert when CPU > 80% for 5 minutes" is a metric alert; "find every request that returned 500 in the last hour" is a log query.

Agents — use the Azure Monitor Agent

The Azure Monitor Agent (AMA) is the current agent for VMs and Arc servers, configured via Data Collection Rules (DCRs). The Log Analytics agent (MMA) is retired — if it appears as an answer for a new deployment, it is wrong.

Application Insights (APM)

Capability	Answers
Live Metrics	What's happening right now (sub-second)?
Application Map	How do my services connect, and where's the slow/failing hop?
Failures	Which requests/exceptions are failing and why?
Performance	Which operations and dependencies are slowest?
Availability tests	Is the app reachable from around the world?
Usage (users, sessions, funnels)	How are people actually using it?
Smart Detection	Has something anomalous started happening automatically?
Distributed tracing	What was the end-to-end path of this one request?

Instrumentation approach	How
Auto-instrumentation (codeless)	Enable in the App Service / Functions / AKS portal — no code change; .NET, Java, Node, Python (varies)
SDK / OpenTelemetry (code-based)	Add the Azure Monitor OpenTelemetry distro for custom events, metrics and full control

C# connect + custom telemetry

// Modern approach: Azure Monitor OpenTelemetry distro
builder.Services.AddOpenTelemetry().UseAzureMonitor(o =>
    o.ConnectionString = builder.Configuration["APPLICATIONINSIGHTS_CONNECTION_STRING"]);

// Custom signals
_telemetryClient.TrackEvent("OrderPlaced",
    new Dictionary<string,string> { ["orderId"] = order.Id },
    new Dictionary<string,double> { ["orderValue"] = order.Total });
_telemetryClient.TrackMetric("ActiveUsers", userCount);
try { /* ... */ }
catch (Exception ex) { _telemetryClient.TrackException(ex); throw; }

Caveat — connection string, not instrumentation key

Application Insights now uses a connection string (which embeds the key and the regional endpoints). The bare instrumentation key is deprecated — an answer that configures only an instrumentation key is dated. For "enable monitoring with no code change", the answer is auto-instrumentation on the App Service.

The Insights family

Insight	Monitors	Key signals
Application Insights	Applications (APM)	Requests, dependencies, exceptions, traces
VM Insights	VMs & scale sets	CPU, memory, disk, network, process & connection map
Container Insights	AKS & Container Instances	Node/pod/container CPU & memory, restarts, K8s events
Storage Insights	Storage accounts	Transactions, availability, latency, capacity (agentless)
Network Insights	Network resources	Topology, traffic, connectivity (Network Watcher, Connection Monitor)

azure cli enable Container Insights on AKS

az aks enable-addons \
  --resource-group myRG --name myAKS \
  --addons monitoring \
  --workspace-resource-id "$LOG_ANALYTICS_WORKSPACE_ID"

Caveat — pick the Insight by resource type

These are almost pure recognition questions: AKS pods → Container Insights; VM CPU/memory → VM Insights; custom app events / dependency latency → Application Insights; storage account transactions → Storage Insights; network topology/connectivity → Network Insights.

Monitoring in GitHub

Repository Insights — Pulse (activity summary), Traffic (views/clones/referrers), Contributors, Community Standards, Dependency graph, Network.
GitHub Projects Insights — build charts from project data: items by status/assignee, burn-up, velocity; historical and current.
Actions usage metrics — workflow run history, job timing, minutes and storage consumption for cost/health tracking.

Creating and configuring charts

The skills measured call out "enabling insights and creating and configuring charts" — that's GitHub Projects → Insights, where you add a chart, choose the metric (e.g. items completed over time), filter, and group. Enabling the dependency graph is the prerequisite for Dependabot (see Domain 4).

Alerts for GitHub Actions and Azure Pipelines

Signal	Mechanism
Azure Pipelines run failed	Notifications (Project Settings) or Service hooks → Teams/Slack, filtered to failures
GitHub Actions run failed	`if: failure()` step posting to Teams/Slack; watch/notification settings
Azure resource metric crossed a threshold	Azure Monitor metric alert → action group
A log condition occurred	Azure Monitor log (scheduled query) alert
Auto-remediation	Action group webhook → Azure DevOps REST API to trigger a pipeline

azure cli metric alert + action group

az monitor metrics alert create \
  --name "High CPU" --resource-group myRG \
  --scopes "$VM_ID" \
  --condition "avg Percentage CPU > 80" \
  --window-size 5m --evaluation-frequency 1m \
  --action "$ACTION_GROUP_ID" \
  --description "CPU over 80% for 5 minutes"

Action groups are the fan-out

An action group is a reusable set of notification and action targets — email/SMS/push, webhook, Logic App, Azure Function, ITSM, runbook. One alert points at an action group so the same response (notify + auto-remediate) is reused across many alerts. Wiring a webhook to the Azure DevOps REST API is how "an alert triggers a remediation pipeline".

5.2 Analyze metrics from instrumentation

Infrastructure performance indicators

Indicator	Watch when	Usually means
CPU %	> 80% sustained	Scale up/out
Memory %	> 85% sustained	Leak or undersized
Disk I/O latency	> 20 ms	Storage bottleneck
Disk space	> 85% used	Imminent outage
Network throughput	Near NIC/bandwidth limit	Throttling / cost

Application metrics and usage

Metric	Example alert threshold
Server response time	> 2 s average
Failed request rate	> 5% (HTTP 5xx / exceptions)
Request rate	Anomaly vs baseline (Smart Detection)
Availability	< 99.9% from availability tests
Dependency duration/failures	Slow DB/API calls in the Application Map

The Four Golden Signals / RED / USE

Frameworks worth recognising: Four Golden Signals (latency, traffic, errors, saturation), RED for services (Rate, Errors, Duration), and USE for resources (Utilization, Saturation, Errors). They map cleanly onto Application Insights (RED) and VM/Container Insights (USE).

Distributed tracing

flowchart LR R[Request
operation_Id: abc-123] --> A[Service A
span 50ms] A --> B[Service B
span 200ms] B --> D[(Database
span 120ms)]

One operation_Id ties every span together, so you can reconstruct the whole request across services.

Application Insights propagates the W3C traceparent header (and legacy Request-Id) so spans across services correlate automatically.
View a full request in Transaction search → end-to-end transaction details (waterfall).
Sampling reduces volume/cost while preserving whole traces — adaptive (default), fixed-rate, or ingestion. It keeps complete transactions, not random events, so traces stay intact.

Caveat — the Application Map is for cross-service problems

"A request touches five microservices and one is slow — find which" → distributed tracing / Application Map, correlated by operation_Id. "Find the slowest database call in one app" → Application Insights Performance → Dependencies. Both are Application Insights, but the map is the answer whenever the problem spans services.

Kusto Query Language (KQL) basics

KQL queries Log Analytics, Application Insights, Microsoft Sentinel and Azure Data Explorer. The exam expects you to read and lightly write it — a table name, then a pipeline of operators.

Operator	Does	Example
`where`	Filter rows	`where success == false`
`project` / `project-away`	Choose/drop columns	`project name, duration`
`summarize`	Aggregate, usually by a key or time bin	`summarize count() by bin(timestamp, 1h)`
`extend`	Add a computed column	`extend sec = duration / 1000`
`order by` / `sort by`	Sort	`order by duration desc`
`take` / `top`	Limit / top-N	`top 10 by duration desc`
`join`	Combine tables	`join kind=inner (exceptions) on operation_Id`
`render`	Visualise	`render timechart`

KQL the queries the exam reuses

// Failed requests over the last 24h, charted
requests
| where timestamp > ago(24h)
| where success == false
| summarize failures = count() by bin(timestamp, 1h), resultCode
| render timechart

// Slowest operations — p95 is what SLOs care about
requests
| where timestamp > ago(1h)
| summarize avg(duration), p95 = percentile(duration, 95), count() by name
| order by p95 desc
| take 20

// Exceptions grouped by type
exceptions
| where timestamp > ago(24h)
| summarize count() by type
| order by count_ desc

// Availability % by location
availabilityResults
| where timestamp > ago(7d)
| summarize availability = round(100.0 * countif(success == true) / count(), 2)
    by location, bin(timestamp, 1d)
| render timechart

Caveat — the KQL patterns that show up

Recognise these on sight: where timestamp > ago(1h) (time filter), summarize ... by bin(timestamp, 1h) (bucket by hour), percentile(duration, 95) (p95 latency), render timechart (time-series chart). "Group results by hour" is bin() inside summarize; "show as a chart" is render.

Availability tests

Type	Does
Standard test	HTTP GET from multiple regions with SSL, status-code and content checks (the current recommended test)
URL ping test	Simple reachability check (classic; being retired in favour of Standard)
Custom TrackAvailability()	Multi-step / authenticated flows run from a Function or pipeline reporting via the SDK

Test from multiple locations

Configure at least five geographic locations so a single region's blip doesn't page you, and alert when a threshold number of locations fail. "Monitor the app's availability from around the world" → Application Insights availability (Standard) test.

Domain 5 rapid recap

The requirement says…	Answer
Alert when CPU > 80% for 5 minutes	Azure Monitor metric alert → action group
Find every 500 in the last hour	KQL log query on `requests`
Monitor AKS pod CPU/memory	Container Insights
Monitor VM CPU and memory	VM Insights
Track a custom business event	Application Insights `TrackEvent()`
Find the slowest dependency in one app	App Insights Performance → Dependencies
Trace a request across five services	Distributed tracing / Application Map
Enable monitoring with no code change	Auto-instrumentation on App Service
Reduce telemetry cost but keep whole traces	Adaptive sampling
Monitor availability from around the world	App Insights availability (Standard) test
Group KQL results by hour	`summarize ... by bin(timestamp, 1h)`
Show a KQL result as a time chart	`\| render timechart`
Get the 95th-percentile response time	`percentile(duration, 95)`
Reuse one response across many alerts	Action group
An alert should trigger a remediation pipeline	Action group webhook → Azure DevOps REST API
Modern agent for VM telemetry	Azure Monitor Agent (MMA is retired)