Choosing the Right Azure Storage Service
Before any question of tiers or redundancy, a design has to pick the right storage abstraction, and that choice is driven entirely by how the data is accessed. Blob storage holds unstructured objects addressed by URL, which is what applications, backups, media and data lakes want. Azure Files presents a real SMB or NFS share that several machines can mount at the same time, which is what lift-and-shift applications expecting a drive letter or a mount point need. A managed disk is one machine's own block device, attached to a single VM, and is the wrong answer whenever the requirement says shared. Queue storage passes simple messages between components, and Table storage holds schemaless key-value rows cheaply, though anything with real scale or global reach is better served by Cosmos DB. Enabling the hierarchical namespace turns a blob account into Azure Data Lake Storage Gen2, where directories become real objects, making renames and directory-level permissions atomic, which is what analytics engines depend on. When the requirement mentions extreme throughput, rich NFS features or enterprise snapshot behaviour, Azure NetApp Files is the escape hatch above Azure Files.
Exam tip. The word shared is the strongest signal in the whole domain. Shared access across machines means Azure Files or NetApp Files, never a managed disk, no matter how fast the disk option in the answers looks.
The Storage Redundancy Ladder and What Each Rung Survives
Storage redundancy is one of the most reliably tested decisions on this exam and it has a clean logic: match the redundancy option to the exact failure named in the scenario and go no further. Locally redundant storage keeps several copies inside a single datacentre, which covers a failed drive or rack and nothing larger. Zone-redundant storage spreads copies across separate availability zones in one region, so the loss of a whole zone, including its power and cooling, is survivable. Geo-redundant storage keeps local copies and asynchronously replicates to the paired region, which is what covers a regional outage, and geo-zone-redundant storage combines the zone spread in the primary with that geographic copy. The read-access variants add a separate secondary endpoint so the second copy can be read before any failover happens, and that specific phrasing about reading from the other region is what forces them. Two caveats matter more than the ladder itself. Replication is asynchronous across regions, so a failover can lose the most recent writes, and after a customer-managed failover the account is left locally redundant and has to be reconfigured. Redundancy is also not backup, because a deletion or corruption replicates perfectly.
Exam tip. Answer the failure that is written down and nothing more. Choosing GZRS when the scenario only mentions a zone outage is as wrong as choosing LRS when it mentions a region, because the exam is testing cost discipline as much as resilience.
Access Tiers, Lifecycle Rules and the Cost of Cold Data
Blob access tiers exist because most data is written once and read rarely, and paying premium storage prices for it forever is waste. Moving down the tiers reduces what you pay to keep the data and increases what you pay to read it, along with a longer minimum retention before the data can move again without an early deletion charge. Hot is for data in active use, cool for data that is still online but touched infrequently, and cold sits below cool with the same immediate availability. Archive is different in kind rather than degree: it is offline, so a blob in archive cannot be read at all until it has been rehydrated to an online tier, and that takes hours. That single fact resolves a great many exam questions, because any requirement mentioning immediate or on-demand access rules archive out no matter how attractive its price is. The design recommendation is almost never to manage tiers by hand. A lifecycle management policy on the account moves blobs between tiers and eventually deletes them based on how long ago they were modified or last accessed, and versions and snapshots can be aged out on their own schedule, which turns retention into a property of the account rather than a task somebody has to remember.
Exam tip. Scan the scenario for a phrase about how quickly the data must be available. Anything resembling immediately, on demand or within minutes rules out archive, and the answer is cool or cold instead.
Protecting and Securing Data in Azure Storage
Securing a storage account is a stack of independent decisions and a good design makes each one deliberately. Identity comes first: Microsoft Entra ID with RBAC on the account is the recommended way for applications and people to authenticate, because the access can be scoped and audited like anything else, and the account key should ideally be disabled entirely. Where a shared access signature is genuinely needed, a user delegation SAS is the right kind, since it is signed with an Entra credential rather than the account key and can therefore be revoked without rotating a key that everything else also depends on. Network exposure is the next decision, and a private endpoint with public network access disabled is the strong form, while a service endpoint only keeps traffic on the Microsoft backbone and leaves the public endpoint answering. Encryption at rest is always on, so the real choice is between platform-managed and customer-managed keys, and customer-managed keys are what a requirement about controlling or revoking the key is asking for. Finally there is protection from your own mistakes: soft delete recovers deleted blobs and containers, versioning keeps every prior state, point-in-time restore rolls a container back, and immutability policies stop anything being changed at all.
Exam tip. Distinguish the two things a question can mean by protecting data. Compliance wording about not being altered or deleted for a period means immutability, while wording about recovering from a mistake means soft delete, versioning or backup.
Azure SQL Deployment Options: Database, Managed Instance or VM
Relational database questions on this exam are usually asking you to move as far up the managed ladder as the requirements allow. Azure SQL Database is a single logical database with the platform handling patching, backups and high availability, and it is where the exam wants you to land unless something stops you. SQL Managed Instance sits one step down and offers near-complete instance-level compatibility, which matters because a large number of real applications depend on things a lone database cannot host: SQL Agent jobs, cross-database queries, Service Broker, CLR assemblies and linked servers. When you see any of those named, Managed Instance is the intended answer, and it is also the natural target for a lift-and-shift of an existing instance with minimal change. SQL Server on an Azure VM is the bottom rung and should only be recommended when the requirement genuinely reaches the operating system: a specific SQL Server version or build, third-party software installed alongside the engine, or full control over the machine. The trade running down the ladder is always the same, more compatibility and control in exchange for taking back responsibility for patching, backup and availability that the managed options were doing for you.
Exam tip. Read the migration requirements before the performance ones. A single mention of SQL Server Agent jobs or cross-database queries settles the question in favour of Managed Instance, whatever else the scenario says about scale.
Sizing and Scaling Azure SQL Database
Once the deployment option is settled, the next set of decisions is about how the database is bought and how it grows. The purchasing model comes first: DTU bundles compute, memory and IO into one opaque unit and is simple but inflexible, while vCore separates compute from storage so each can be sized independently, and it is the only model that can apply Azure Hybrid Benefit to licences you already own. Within vCore the service tiers describe the storage and availability architecture. General Purpose is the balanced default. Business Critical keeps local high-speed storage and replicas for the lowest latency and the fastest failover, and it includes a free readable secondary. Hyperscale separates compute from a distributed storage layer so the database can grow far past the usual ceiling, with fast backups and quick read scale-out. Compute can also be provisioned or serverless, and serverless is the right recommendation for intermittent workloads with genuine idle periods, because it scales automatically and can pause, whereas a steadily busy database costs less provisioned. Finally, an elastic pool is the answer when there are many databases with peaks at different times, since they share one budget of resources rather than each paying for its own peak.
Exam tip. Watch for the shape of the load. Intermittent with idle gaps means serverless, many small databases peaking at different times means an elastic pool, and very large or rapidly growing means Hyperscale.
Azure Cosmos DB Design Decisions
Cosmos DB earns its place in a design when the requirements include global distribution with low latency, a schema that changes, or request volumes with strict latency expectations. Once it is chosen, three decisions define whether it works. The API is largely a migration decision: pick MongoDB, Cassandra, Gremlin or Table when there is existing code that speaks that protocol, and pick the NoSQL API for anything new, because it is the native surface and gets capabilities first. The partition key is the decision you cannot undo cheaply, and a good one has high cardinality and spreads both storage and request volume evenly, ideally matching the field your queries filter on, because a key that funnels traffic into one logical partition creates a hot partition that no amount of provisioned throughput fixes. Consistency is the third: the ladder runs from strong, which gives the freshest reads at the highest latency and constrains multi-region writes, down through bounded staleness, session, consistent prefix and eventual, which is fastest and cheapest but can serve stale data. Session is the sensible default for user-facing applications because a user always sees their own writes. Adding a second write region buys local write latency and continued writes during a regional failure, at the cost of conflict resolution.
Exam tip. Consistency questions usually turn on a single phrase. Users must see their own updates means session, and any wording about the absolute latest value across every client means strong, which you should then check against a multi-region write requirement.
Data Migration and Integration Strategy
Moving data into Azure splits into two very different problems, and the exam tests both. The first is bulk transfer, where the deciding factor is simply whether the available bandwidth can carry the volume inside the time allowed. If it can, network tools do the job: AzCopy for storage, Azure Data Factory for orchestrated movement, and the Database Migration Service for databases, which can run offline for a one-off cutover or online with continuous sync so the final switch is short. If the link cannot carry the volume, no amount of tuning will help and the answer is the Azure Data Box family, where a physical appliance is shipped, loaded and returned. The second problem is ongoing integration, and Azure Data Factory is the usual answer, orchestrating extraction, movement and transformation on a schedule or trigger, using a self-hosted integration runtime to reach sources behind a firewall. Assessment matters as much as transfer, because Azure Migrate and the Data Migration Assistant tell you what will break before it does, which is the difference between a migration plan and a hope. And for cutover design, the recurring theme is minimising the window: replicate continuously first, keep the source available, and make the final switch the smallest possible step.
Exam tip. Do the arithmetic the scenario is inviting. When it gives you a data volume and a slow or constrained link, it is steering you towards Data Box, and the network-based options are there as distractors.