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.

• ✗

  Use Azure Policy to audit missing tags and create a custom dashboard in Azure Monitor.

  Why it's wrong here

  Azure Policy enforces and audits tag compliance by evaluating resource properties during a compliance scan, and Azure Monitor dashboards can visualize those compliance results in near real time. However, policy rules operate on static ARM resource properties and cannot assess whether a resource has been orphaned based on a lack of recent activity, since activity data resides in the Activity Log or resource-specific metrics, not in properties. Furthermore, a dashboard is a manually accessed visual surface, not a proactive weekly email report, so this option fails the explicit scheduled-delivery requirement.

• ✗

  Use Azure Monitor alerts with a metric alert for unmodified resources.

  Why it's wrong here

  Azure Monitor metric alerts are designed for real-time, threshold-based notifications—e.g., when CPU stays below 1%—and they fire reactively, not as a scheduled weekly inventory report. More fundamentally, most Azure resources do not expose a meaningful metric like 'last modified' or 'unmodified since'; control-plane changes are recorded in the Activity Log, while data-plane usage appears in separate resource-specific metrics or logs. Even if an alert could approximate low utilization, it would generate individual alert events rather than a consolidated, email-formatted list of thousands of orphaned resources, making this option both technically limited and operationally unscalable.

• ✗

  Use Azure Automation runbook to inventory resources and store in a SQL database, then use Power BI to report.

  Why it's wrong here

  Using Azure Automation runbooks to inventory resources into a SQL database and report with Power BI is effective for custom reporting on resource properties and tags. However, it struggles to efficiently identify "orphaned" resources based on "no recent activity" across thousands of resources. This requires continuous monitoring of activity logs or metrics, which a simple inventory runbook and SQL database are not designed to provide at scale for historical analysis. This solution would be appropriate for complex, custom inventory tasks or integrating data from diverse sources for reporting, where "orphaned" status is determined by static properties.

• ✓

  Use Azure Resource Graph queries in an Azure Logic App scheduled to run weekly, and send the report via email.

  Why this is correct

  This is the correct approach because Azure Resource Graph (ARG) provides a centralized, KQL-queryable inventory of all resource types and properties, including tags and sometimes a lastModified timestamp, which lets you filter for resources that appear orphaned based on staleness. A Logic App with a Recurrence trigger can invoke the 'Run Azure Resource Graph query' connector action weekly, handle pagination via the skip token for thousands of resources, and send the formatted results through an Office 365 Outlook or SMTP email action. This serverless composition avoids standing infrastructure, directly addresses the schedule-and-email requirement, and scales well beyond the resource count in the scenario.

Go deeper

Related to this question