Azure Dashboards and Workbooks

Azure Dashboards and Azure Workbooks are both visualization tools within the Azure portal, but they serve different purposes and have distinct architectures.

Azure Dashboards are a portal feature that allows you to create a customizable, single-pane-of-glass view of your Azure resources. They are essentially a collection of tiles (called 'parts') that display metrics, charts, logs, and other data. Dashboards are persistent, always-on views that refresh automatically (default refresh interval for metrics is 5 minutes, but can be set to 1 hour or disabled). They are ideal for operational monitoring where a team needs to quickly check the health of systems.

Azure Workbooks are a more advanced, interactive reporting tool built on top of Azure Monitor. They combine text, queries, metrics, and parameters into a rich, interactive document. Workbooks are not always-on; they load on demand and can execute queries against Log Analytics workspaces, Application Insights, Azure Resource Graph, and other data sources. They support complex visualizations, drill-downs, and step-by-step troubleshooting guides. Workbooks are designed for deep analysis, post-incident reviews, and creating sophisticated reports.

Dashboards are stored as JSON files within the Azure portal. When you create a dashboard, you pin various tiles (metrics, logs, charts, etc.) to a grid layout. Each tile is a 'part' that renders a specific visualization. The dashboard is rendered on the server and delivered to the browser as HTML. The refresh behavior depends on the tile type: metric charts refresh based on the metric's default granularity (e.g., 1-minute or 5-minute aggregates), while log-based tiles require manual refresh or a set interval. Dashboards can be shared with other users via role-based access control (RBAC), but they are not designed for real-time data streaming—they are best for near-real-time monitoring.

Workbooks are built using the Azure Workbooks engine, which is part of Azure Monitor. A workbook consists of one or more 'steps' that can include markdown text, parameter controls, and queries. Each query step executes against a data source (e.g., Log Analytics, Application Insights, Azure Resource Graph) using Kusto Query Language (KQL) or Resource Graph queries. The results are rendered as tables, charts, or maps. Workbooks support interactivity: parameters allow users to filter data, and selecting a row in a grid can drill into a detailed view. Workbooks are loaded on demand, meaning they execute queries when opened or when parameters change. They are not automatically refreshed; you must manually refresh or set auto-refresh (up to every 5 minutes for some visualizations).

Azure Dashboards: - Grid Layout: Dashboards use a 24-column grid. Tiles can span multiple columns and rows. - Tile Types: Metrics chart, log query, markdown, text, clock, etc. - Refresh: Metrics tiles auto-refresh every 5 minutes by default. Log tiles do not auto-refresh; you must click 'Refresh' or set a custom refresh interval (minimum 1 minute). - Sharing: Shared dashboards are stored in a resource group (as a resource type Microsoft.Portal/dashboards). Private dashboards are stored in the user's personal storage. - Cost: No additional cost for dashboards themselves, but data sources (e.g., Log Analytics) incur charges.

Azure Workbooks: - Steps: Each workbook is a sequence of steps. Steps can be text, parameters, queries, or visualizations. - Data Sources: Log Analytics, Application Insights, Azure Resource Graph, Azure Data Explorer, and more. - Query Language: KQL for Log Analytics/Application Insights; Resource Graph query language for Azure Resource Graph. - Parameters: Workbooks support user-defined parameters (e.g., time range, subscription, resource type) that filter all subsequent queries. - Auto-refresh: Can be enabled per visualization with a minimum interval of 5 minutes. - Cost: Workbooks are free to create and view, but each query execution against data sources incurs costs based on data ingestion and query volume. - Storage: Workbooks are stored as Azure resources in a resource group (type microsoft.insights/workbooks). They can be shared via RBAC.

Creating a Dashboard: In the Azure portal, navigate to Dashboard from the left menu or the Azure portal home. Click 'New dashboard' and select a layout. Use the tile gallery to add tiles. No CLI command exists to create a dashboard directly; you must use the portal or REST API.

Creating a Workbook: In the Azure portal, go to Azure Monitor > Workbooks. Click 'Create' or 'New workbook'. You can also use ARM templates or PowerShell to deploy workbooks. Example ARM template snippet:

{
  "type": "microsoft.insights/workbooks",
  "apiVersion": "2021-08-01",
  "properties": {
    "displayName": "My Workbook",
    "serializedData": "{\"version\":\"Notebook/1.0\",\"items\":[...]}",
    "category": "workbook",
    "sourceId": "/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.OperationalInsights/workspaces/{workspace}"
  }
}

To verify a workbook is deployed correctly, use:

Get-AzResource -ResourceType Microsoft.Insights/workbooks | Where-Object {$_.Name -eq "My Workbook"}

Both dashboards and workbooks integrate with Azure Monitor, Log Analytics, Application Insights, and Azure Resource Graph. Dashboards are more tightly coupled with the portal's pinning mechanism, while workbooks are more flexible in querying multiple data sources. For example, a workbook can combine data from Log Analytics (for log data) and Application Insights (for application performance) in a single visualization, whereas a dashboard tile is typically sourced from a single data source per tile.

Dashboards can also display alerts from Azure Monitor, but they do not support interactive drill-downs. Workbooks can include alert data and allow users to click through to detailed views. Workbooks also support exporting to PDF or CSV, making them suitable for reporting.

For AZ-305, you need to know when to use each tool. Dashboards are for operational monitoring—quick status views for teams. Workbooks are for deep analysis, troubleshooting, and reporting. The exam may present a scenario where you need to decide between the two based on requirements like interactivity, real-time data, or sharing with external stakeholders.

| Feature | Dashboard | Workbook | |---------|-----------|----------| | Purpose | Operational monitoring | Deep analysis & reporting | | Refresh | Auto (5 min default for metrics) | On-demand or auto (min 5 min) | | Interactivity | None (static tiles) | High (parameters, drill-downs) | | Data Sources | Single per tile | Multiple per workbook | | Cost | Free (data costs apply) | Free (query costs apply) | | Sharing | RBAC on dashboard resource | RBAC on workbook resource | | Export | Not supported | PDF, CSV | | Real-time | Near-real-time (5 min lag) | Not real-time |

Understanding these differences is critical for the AZ-305 exam, where you will be asked to recommend the appropriate tool for a given monitoring requirement.

A large e-commerce company uses Azure to host its web application across multiple regions. The operations team needs a live view of system health: CPU, memory, request rates, and error counts per region. They create a shared Azure Dashboard pinned to the portal home page. The dashboard has tiles for each region showing key metrics from Azure Monitor. The dashboard auto-refreshes every 5 minutes, giving the team a quick status check. However, when a performance issue occurs, the dashboard only shows that errors are high—it doesn't help diagnose why. For that, the team uses an Azure Workbook that queries Application Insights and Log Analytics to correlate error spikes with specific code deployments or database queries. The workbook includes parameters for time range and region, allowing engineers to drill into the data. The workbook is shared with the development team via RBAC for post-incident analysis. Misconfiguration: if the workbook's queries are not optimized (e.g., scanning too much data), they can timeout or incur high costs. Engineers must use KQL best practices like filtering by time and using summarize to reduce data volume.

An MSP manages multiple customer environments in Azure. They need to provide each customer with a view of their own resources without seeing other customers. The MSP creates separate dashboards for each customer, stored in the customer's subscription or a shared resource group with proper RBAC. Each dashboard shows customer-specific metrics (e.g., VM performance, web app health). However, dashboards cannot aggregate data across subscriptions easily; each tile is scoped to a specific resource or resource group. For cross-customer reporting (e.g., total usage across all customers), the MSP uses an Azure Workbook that queries Azure Resource Graph to retrieve inventory and cost data across all subscriptions. The workbook uses parameters to filter by customer, allowing the MSP to generate per-customer reports. Performance consideration: workbooks that query many subscriptions may be slow; use Resource Graph's pagination and limit results. Common mistake: sharing a single dashboard with all customers via a link—since dashboards do not support row-level security, each customer would see all tiles, potentially exposing other customers' data. Correct approach: create per-customer dashboards or use workbooks with identity-based filtering.

A healthcare organization needs to generate monthly compliance reports showing access logs and resource usage for audit purposes. They use an Azure Workbook that queries Log Analytics for sign-in logs and resource activity. The workbook includes text steps explaining the report purpose, parameters for date range, and query steps that produce tables and charts. The workbook is exported to PDF for submission to auditors. The workbook is stored in a central resource group with restricted RBAC (only auditors have read access). Misconfiguration: if the workbook queries are not scoped to the correct Log Analytics workspace, they might miss data. Also, if the workbook is edited by mistake, the report format changes. To prevent this, the workbook should be version-controlled or locked via Azure Resource Manager locks.