AZ-305 Design data storage solutions Practice Question

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 Blob Storage with lifecycle management

  Why it's wrong here

  Azure Blob Storage with lifecycle management is wrong because it provides only cheap, tiered storage without any native log search or query engine. While lifecycle rules can automatically move blobs to cool/archive tiers or delete them after a retention period, operational logs stored here are inert files that must be exported to Azure Monitor, Azure Data Explorer, or a big-data engine before you can run KQL or SQL-style queries. For a company that needs to investigate incidents and analyze trends from App Service logs, the lack of integrated querying makes Blob Storage an impractical primary store.

• ✗

  Azure SQL Database with retention policy

  Why it's wrong here

  Azure SQL Database is not designed for the cost-effective, scalable storage of high-volume, often semi-structured operational logs, which would incur significant storage and processing costs due to its relational nature. Its scalability model is optimised for transactional workloads, not append-only log ingestion. However, it is an excellent choice for structured application data requiring ACID compliance, complex querying, and transactional integrity, where its built-in retention policies are typically for database backups, not raw log data lifecycle management.

• ✓

  Azure Log Analytics Workspace

  Why this is correct

  Azure Log Analytics Workspace is the correct choice because it is purpose-built for ingesting, storing, and querying operational logs from Azure resources via diagnostic settings. It provides native Kusto Query Language (KQL) for fast, interactive analysis, an integrated retention and archive policy for balancing cost and compliance, and direct integration with Azure Monitor alerts, workbooks, and dashboards. This makes it the optimal, low-friction service for operational logs that must be searched, correlated, and visualized without additional tooling.

• ✗

  Azure Cosmos DB with TTL

  Why it's wrong here

  Azure Cosmos DB with TTL is wrong for operational logs because it is a multi-model NoSQL database optimized for low-latency transactional workloads with provisioned throughput, not for high-volume, append-only log ingestion. Enable TTL only deletes expired documents after cleanup, but it does not provide a log query language or analytics engine, and every write consumes Request Units (RU), making it prohibitively expensive compared to a log-optimized store. Its schema flexibility is irrelevant here because logs are semi-structured and better handled by services designed for time-series analytics.

Go deeper

Related to this question