AZ-305 Practice Question: Design identity, governance, and monitoring solutions

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Azure Resource Graph

  Why this is correct

  Azure Resource Graph is a fully supported data source in Azure Monitor workbooks. Workbooks include a dedicated query control that natively targets Azure Resource Graph (ARG), enabling you to run KQL-based resource exploration queries across subscriptions, management groups, and resource types. Because ARG provides a live, inventory-level view of Azure resources rather than logs or metrics, it is the correct choice when the workbook’s goal is to visualize resource properties, tags, or compliance-related metadata. This direct integration differentiates ARG from stores like SQL Database or Blob Storage, which require an intermediate log-ingestion step.

• ✗

  Azure SQL Database

  Why it's wrong here

  Azure SQL Database is not a native or direct data source for Azure Monitor workbooks. While you could use a workbook's custom endpoint or data-source options to call a REST API, the typical and supported pattern is to send Azure SQL Database diagnostic logs and metrics to a Log Analytics workspace, then query that workspace from the workbook. Workbooks do not provide a built-in connector that issues T-SQL queries directly against a SQL database. Therefore, selecting Azure SQL Database as a standalone source is incorrect because the workbook would have no direct, built-in mechanism to pull data from it without an intermediary such as Log Analytics or an API-based custom query.

• ✗

  Microsoft Sentinel

  Why it's wrong here

  Microsoft Sentinel is a security information and event management (SIEM) solution that runs on top of a Log Analytics workspace, not a distinct or independent data source for Azure Monitor workbooks. Sentinel data—including alerts, incidents, hunting queries, and bookmarks—is stored in Log Analytics tables (e.g., SecurityAlert, SecurityIncident), and workbooks query those tables via Log Analytics. You cannot add Sentinel as a separate source in a workbook's data-source picker; instead, the workbook connects to the underlying Log Analytics workspace where Sentinel is enabled. Thus, while Sentinel-related data can appear in workbooks, the workbook's actual data source remains Log Analytics, making Sentinel itself an incorrect answer.

• ✓

  Log Analytics workspace

  Why this is correct

  A Log Analytics workspace is a first-class data source in Azure Monitor workbooks; the workbook's 'Log Analytics' data source lets you write KQL queries against tables in that workspace. This is the primary mechanism for pulling operational logs, metrics, and custom telemetry into a workbook, and it supports time-range parameters, filtering, and visualization binding directly to the query results. Since most Azure diagnostics, including resource logs and activity logs, are routed to a Log Analytics workspace, this option is correct when the workbook needs to analyze log-based data. It is distinct from Azure Resource Graph, which provides a real-time resource inventory rather than historical log or metric data.

• ✗

  Azure Blob Storage

  Why it's wrong here

  Azure Blob Storage is not a direct data source for Azure Monitor workbooks. Workbooks do not have a built-in data-source option that points to a blob container or storage account; you cannot write a query that natively reads JSON or CSV files from Blob Storage. The standard supported approach is to stream storage logs or other exported logs into a Log Analytics workspace and query that workspace, or to use an external HTTP endpoint and invoke it via a custom endpoint data source. Even then, the storage account itself is just a repository, not a queryable analytics engine, so selecting Blob Storage as a workbook data source is incorrect.

Go deeper

Related to this question