AZ-305 Practice Question: Design identity, governance, and monitoring solutions
You are designing a monitoring solution for a cloud-native application that uses Azure Functions, Azure Storage, and Azure Cosmos DB. The solution must provide centralized log collection and analysis, enable proactive alerting on application errors, and support long-term log retention for compliance (7 years). What should you include in the design?
⚠ Common exam trap
Candidates often confuse Application Insights' export-to-blob feature as a complete solution, overlooking that exported logs become cold storage and lose the centralized query and alerting capabilities required by the scenario.
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
✓
Configure diagnostic settings for each Azure resource to send logs and metrics to a Log Analytics workspace.
It leverages Log Analytics workspace as a centralized destination for diagnostic settings from Azure Functions, Storage, and Cosmos DB, enabling unified log collection, Kusto Query Language (KQL)-based analysis, proactive alerting, and long-term retention (up to 7 years) for compliance. This design satisfies all requirements: centralized logging, alerting on application errors, and archival-grade retention.
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 Storage with cool tier for logs and enable Azure Storage Analytics logs.
Why it's wrong here
Storage Analytics logs are scoped to a single storage account and only record requests made against that account, not the platform-level logs of your Azure resources. They lack a centralized query plane, cannot be analyzed with KQL, and do not support alerting or cross-resource correlation. Archiving blobs to cool tier optimizes cost but does nothing to make logs searchable or actionable.
- ✗
Store logs in Azure Monitor Metrics with a retention of 93 days.
Why it's wrong here
Azure Monitor Metrics is a time-series database optimized for storing numeric performance counters and aggregated data, not free-form text logs or application trace output. The default retention for metrics is only 93 days (or less for higher granularity), which falls far short of long-term auditing or compliance needs. You cannot run Log Analytics-style query language against metrics, nor can you store unstructured log events in this store.
- ✗
Use Application Insights to collect logs and set retention to 90 days, then export to Azure Blob Storage for archival.
Why it's wrong here
Application Insights is an application performance management (APM) service for telemetry like requests, dependencies, and traces, not a central hub for all Azure resource logs. Its interactive retention is limited to 90 days by default, and exporting to Blob Storage only creates a passive archive without enabling KQL queries or cross-resource correlation in the same workspace. Adding a continuous export pipeline increases operational complexity while still leaving you without a unified monitoring and query layer for the entire cloud-native application.
- ✓
Configure diagnostic settings for each Azure resource to send logs and metrics to a Log Analytics workspace.
Why this is correct
Configuring diagnostic settings on each Azure resource sends resource logs, activity logs, and metrics to a central Log Analytics workspace, which provides a single repository for storage, querying, alerting, and long-term retention. This approach supports cross-resource KQL queries and allows you to align retention policies with your compliance requirements. It is the recommended Azure-native pattern for a cloud-native application because it centralizes logs and metrics on the platform's unified monitoring plane.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
One of 795 original AZ-305 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.