AZ-305 Practice Question: Design identity, governance, and monitoring solutions
Which THREE components are required to implement a complete monitoring solution with Azure Monitor? (Choose three.)
⚠ Common exam trap
A common mix-up: candidates confuse optional monitoring tools (like Application Insights) with mandatory components, or they mistakenly think governance tools (like Azure Policy) are part of the monitoring pipeline, when in fact the three required components are data sources, a Log Analytics workspace, and alert rules.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Alert rules to notify on conditions
Alert rules (C) are a core component of a complete monitoring solution because they define conditions that trigger notifications or automated actions when monitored metrics or log data cross thresholds. Without alert rules, collected data remains passive and cannot proactively inform administrators of issues, making the solution incomplete.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Application Insights for every application
Why it's wrong here
Application Insights is an Azure Monitor capability that provides application performance monitoring (APM) through client- and server-side SDK telemetry, including request rates, dependency failures, and page-view data. It is not required for every application to achieve a complete monitoring solution because Azure Monitor can also collect data directly from Azure resources, virtual machines, and custom sources without instrumenting each application. Unless the goal is specific deep-dive application-level diagnostics (like distributed tracing or user behavior analytics), adding App Insights to every app is optional and can introduce unnecessary overhead and cost.
- ✗
Azure Policy assignments
Why it's wrong here
Azure Policy is fundamentally a governance and compliance tool that evaluates resource configurations against business rules, such as enforcing tagging, restricting resource SKUs, or auditing encryption settings. It does not collect operational telemetry, store logs, or detect runtime performance degradations, and therefore cannot be a component of Azure Monitor's data pipeline. While Policy can integrate with monitoring (for example, auditing diagnostic settings or triggering remediation tasks), assigning policies is not a requisite pillar for a complete monitoring solution—it operates on resource state at deployment time, not on ongoing operational health.
- ✓
Alert rules to notify on conditions
Why this is correct
Alert rules are the active, response-enabling component of a monitoring solution: they evaluate metric or log queries on a predefined schedule and, when conditions are breached, fire notifications or automated actions via action groups. Without alert rules, telemetry is merely stored and visualized, meaning issues like CPU spikes, request failures, or storage capacity overruns would go unnoticed until someone manually queries the workspace. A truly complete monitoring solution must include alerting to convert collected data into actionable notifications, enabling proactive incident response and minimizing downtime.
- ✓
A Log Analytics workspace for log storage
Why this is correct
A Log Analytics workspace is the central data store in Azure Monitor where all collected telemetry—such as Azure activity logs, resource diagnostic logs, VM performance counters, and application traces—is ingested and retained for querying, alerting, and dashboards. It serves as the required backend for most monitoring scenarios, because logs must live somewhere consistent and queryable using Kusto Query Language (KQL), and it also enables cross-resource log analysis across subscriptions and tenants. Without a workspace, you lose the ability to correlate different data sources, define log-based alert rules, or set retention policies, so it is an indispensable pillar of a complete monitoring solution.
- ✓
Data sources such as Azure resources and applications
Why this is correct
Data sources are the foundational inputs of any monitoring system: they are the actual producers of telemetry, including Azure platform resources (like VMs, App Services, and SQL databases), operating system guests (via Azure Monitor Agent or Log Analytics agent), container workloads, and custom applications using the Azure Monitor SDKs. A complete monitoring solution cannot exist without sources because alert rules and log queries have nothing to evaluate if no metrics or logs are flowing into Azure Monitor. The configuration effort often involves enabling diagnostic settings at the resource level, deploying data-collection rules, and ensuring sources meet security and compliance needs before monitoring can be effective.
Go deeper
Related to this question
About these practice questions
Courseiva writes every AZ-305 question from scratch — 795 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-305 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-305 exam.