Azure AZ-305 Solutions Architect Data Storage Design

Designing robust, cost-effective, and scalable data storage solutions is a cornerstone of the Azure Solutions Architect role and a significant portion of the AZ-305 certification exam. Your ability to select the correct service for a given set of functional and non-functional requirements directly impacts application performance, security, and total cost of ownership. Critical decision pathways involve moving from relational and non-relational data stores through integration patterns and finally to comprehensive data protection.

Core Concept 1: Architecting Relational Data with Azure SQL

Azure SQL is not a single product but a family of managed services, each optimized for different scenarios. Your first major design decision is choosing the correct deployment model.

Azure SQL Database (Single Database) is a fully managed Platform-as-a-Service (PaaS) database. It is designed for modern cloud applications that need a single, predictable resource for a specific workload. You define the service tier (e.g., General Purpose, Business Critical) and compute size, and Azure handles the rest. This model offers the least administrative overhead and is ideal for software-as-a-service (SaaS) applications where each tenant gets their own isolated database.

Azure SQL Elastic Pool is a collection of single databases that share a pool of resources (e.g., CPU, memory). This is a powerful cost-optimization tool for multi-tenant applications with unpredictable or "bursty" database usage patterns. Instead of provisioning peak performance for each database, you purchase a pool of resources that all databases share. On the exam, you will be presented with scenarios describing variable, unpredictable loads across many databases—this is your cue to select an elastic pool.

Azure SQL Managed Instance is the closest PaaS offering to a full SQL Server instance. It provides near 100% compatibility with on-premises SQL Server, including features like SQL Server Agent, cross-database queries, and native virtual network (VNet) integration. Choose this option for lift-and-shift migrations of complex applications or when you require instance-level features that are unavailable in a single database. The trade-off is higher management responsibility and cost compared to a single database.

Exam Strategy: Expect questions that pit these options against each other. Key discriminators are: the need for instance-scope features (Managed Instance), unpredictable multi-database workloads (Elastic Pool), and simple, modern app development (Single Database).

Core Concept 2: Selecting Non-Relational Storage Services

When your data is unstructured, semi-structured, or requires massive scale and low latency, you turn to Azure's non-relational services. The choice hinges on data model, API compatibility, and access patterns.

Azure Cosmos DB is a globally distributed, multi-model database service. Its most critical design feature is its API choice, which determines how you interact with your data. The core options are:

• SQL (Core) API: For document data using a familiar SQL-like syntax. This is the default and most common choice.
• MongoDB API: Offers wire protocol compatibility with MongoDB, easing migration for existing applications.
• Cassandra API: Provides a wide-column store interface compatible with Apache Cassandra.
• Gremlin API: For graph data, allowing you to model and traverse relationships.
• Table API: A premium version of Azure Table Storage with global distribution and higher throughput guarantees.

Your design must also specify a partition key that distributes data evenly across logical partitions to avoid "hot" partitions that throttle performance.

Azure Table Storage is a simple, cost-effective NoSQL key-value store for semi-structured data. It's ideal for storing massive amounts of non-relational data like device telemetry, user metadata, or log files where you need fast access via a partition key and row key. For advanced features like global distribution, you would upgrade to Cosmos DB Table API.

Azure Blob Storage is the object storage solution for massive amounts of unstructured data like text, images, videos, and backup files. Your key design decision is selecting the correct access tier:

• Hot Tier: For data that is accessed frequently. Highest storage cost, lowest access cost.
• Cool Tier: For data accessed infrequently (e.g., older media, short-term backup). Lower storage cost, higher access cost than Hot.
• Archive Tier: For data that is rarely accessed and can tolerate several hours of retrieval latency. Absolute lowest storage cost, highest access cost.

Exam Strategy: Questions will test your ability to match a scenario to the correct non-relational service. Look for keywords: "globally distributed," "low-latency reads worldwide" (Cosmos DB); "simple key-value pairs," "cost-effective logging" (Table Storage); "store terabytes of images," "backup files" (Blob Storage with appropriate tier).

Core Concept 3: Designing Data Integration and Analytics Pipelines

Data is not static; it must be moved, transformed, and analyzed. The AZ-305 expects you to design the pipelines that make this happen.

Azure Data Factory (ADF) is the cloud Extract, Transform, and Load (ETL) and Extract, Load, Transform (ELT) service. You use ADF to create data-driven workflows (called pipelines) that orchestrate data movement and transformation across more than 90 built-in connectors. Its primary components are Datasets (pointers to data), Linked Services (connection strings), Activities (actions), and Pipelines (the workflow). Use ADF for scheduled batch data integration, such as ingesting on-premises SQL data into an Azure Synapse Analytics data warehouse every night.

Azure Synapse Analytics is an integrated analytics service that brings together enterprise data warehousing and Big Data analytics. At its core is a dedicated SQL pool, which uses a Massively Parallel Processing (MPP) architecture to run complex queries across petabytes of data. A key design task is selecting a distribution strategy (hash, round-robin, or replicated) for your tables to minimize data movement during queries. Synapse also includes serverless SQL pools for querying data in place (e.g., in a data lake) and Apache Spark pools.

Azure Event Hubs is a big data streaming platform and event ingestion service. It can receive and process millions of events per second. Use it as the "front door" for an event-driven architecture, collecting data from distributed devices and applications. Downstream services like Stream Analytics or Azure Functions can then process these events in real-time. The key concept here is throughput units (or processing units), which you provision to define the scale of your ingress capacity.

Core Concept 4: Implementing Data Protection, Backup, and Replication

A resilient architecture is defined by how it handles failure. You must design for recovery and continuity.

Backup Strategies: For Azure SQL Database and Managed Instance, the service automatically performs full, differential, and transaction log backups, enabling Point-in-Time Restore (PITR) within the retention period (up to 35 days by default). For long-term retention (LTR), you can store backups for up to 10 years. For Azure Virtual Machines, you use the Azure Backup service to create application-consistent snapshots of VM disks. For Blob Storage, you can enable soft delete to protect against accidental deletion or overwrites.

Replication for High Availability and Disaster Recovery: Different services offer different replication models.

• Local Redundancy (LRS): Three copies within one datacenter. Low cost, but no protection from a datacenter failure.
• Zone-Redundant Storage (ZRS): Copies data synchronously across three Azure availability zones in the primary region. Protects against zonal failures.
• Geo-Redundant Storage (GRS): Copies data to a secondary region (hundreds of miles away) asynchronously. Protects against regional outages. Read-Access Geo-Redundant Storage (RA-GRS) also allows read access to the data in the secondary region.

For Azure SQL, failover groups enable you to manage the geo-replication and failover of a group of databases to a secondary region, providing a clear Recovery Point Objective (RPO) and Recovery Time Objective (RTO).

Common Pitfalls

1. Over-Provisioning for Predictable Loads: Using an elastic pool for databases with steady, predictable usage wastes resources. Always model your workload; if database usage is consistent and independent, single databases with appropriate sizing are more cost-effective.

1. Misapplying the Cosmos DB API: Choosing the Gremlin API for simple document data or the SQL API when you have an existing MongoDB application creates unnecessary complexity and migration work. Let your application's existing data model and client libraries drive the API choice.

1. Ignoring Access Patterns for Blob Tiers: Storing archive data (like compliance logs) in the Hot Tier incurs massive, unnecessary storage costs. Conversely, trying to run analytics on data in the Archive Tier will fail due to high latency and retrieval costs. Map your data's lifecycle to the tiering model from creation.

1. Confusing Data Factory with Stream Processing: Using ADF for real-time, continuous data processing is an anti-pattern. ADF is for orchestrated batch workloads. For real-time streaming pipelines, you must design with Event Hubs, Stream Analytics, or Azure Functions as the core components.

Summary

• Relational Design: Choose a single database for simplicity, an elastic pool for cost-optimization of variable workloads, and a managed instance for maximum SQL Server compatibility and instance-level features.
• Non-Relational Selection: Use Cosmos DB for globally distributed, low-latency apps, selecting the API based on your data model. Use Table Storage for simple, cheap key-value storage, and Blob Storage for unstructured data, leveraging access tiers (Hot, Cool, Archive) to manage costs.
• Integration Pipeline: Orchestrate batch data movement with Data Factory, perform large-scale analytics with Synapse Analytics, and ingest high-volume event streams with Event Hubs.
• Data Protection: Rely on built-in PITR for operational recovery of Azure SQL, implement long-term retention for compliance, and design for disaster recovery using geo-replication (e.g., GRS, failover groups) based on your RPO and RTO requirements.