"Architects don't configure services. They choose the right service for the right job. AZ-305 tests that judgment — not your ability to click through the portal."
The Logistics Analogy
Compute — The IaaS to Serverless Spectrum
Every compute choice is a tradeoff between control and management overhead. More control means more you manage. Less control means less cost and complexity — but less flexibility.
COMPUTE SPECTRUM: Control <-> Managed
Virtual Machine App Service AKS ACI Functions
(IaaS) (PaaS web) (Containers) (Single) (Serverless)
| | | | |
You manage: Deploy code only Container One-off Code only
OS patches orchestration containers
Scaling config Auto-scale Full K8s No cluster
Networking built-in control management
Middleware SSL, slots,
custom domains
WHEN TO USE EACH:
VM: Need OS access, legacy software, specific kernel version,
lift-and-shift of on-prem servers
App Service: Web apps and APIs, fast deployment, auto-scale,
don't want to manage infrastructure
AKS: Microservices, container orchestration, team already using Docker,
need advanced deployment patterns (canary, blue-green)
ACI: Short-lived container tasks, CI/CD runners, batch jobs,
no cluster management needed
Functions: Event-driven logic, background jobs, webhooks,
processing queue messages, pay per execution
Storage — Match Tier to Access Pattern
Storage choices in AZ-305 are almost always about cost optimisation. The same data at different stages of its lifecycle should be on different storage tiers.
Lifecycle Management Policy — the architect's tool for automatic tiering. Define rules: after 30 days move to Cool, after 90 days move to Archive, after 365 days delete. The data manages itself. No manual intervention.
Database — Relational vs NoSQL Decision
The most common AZ-305 scenario question about databases is: Cosmos DB or Azure SQL? The answer depends on the data structure, access pattern, and consistency requirements.
Architect Scenario
A retail company needs to store product images — millions of files, mostly accessed once during an order, then rarely accessed after 30 days, and never accessed after 90 days except for compliance audit. They want minimum cost. What is the optimal design?
Show Answer + Reasoning
Azure Blob Storage with a Lifecycle Management Policy: Hot to Cool at 30 days, to Archive at 90 days.
Why not Azure Files? Files is for shared file system access (SMB/NFS mounts) — not for serving images to a web application. It costs more and adds unnecessary complexity.
Why not just Hot tier for everything? Because the access pattern clearly changes over time. Paying Hot tier prices for data that has not been accessed in 60 days wastes money. Lifecycle policies automate the tiering — no manual management required.
The architect's job here is to recognise that the access pattern IS the cost signal. Images accessed once → Hot. Images older than 30 days → Cool. Images older than 90 days → Archive. Lifecycle Policy handles it automatically.
🎯 Quick Check — Module 2
Q1: A startup wants to deploy a web API. They have a small team and want to minimise infrastructure management. They expect variable traffic with occasional spikes. What is the most appropriate compute service?
Show Answer
Azure App Service. PaaS — deploy code, no OS management. Built-in auto-scale handles traffic spikes. Deployment slots enable zero-downtime deployments. AKS would be over-engineered for a small team. VMs would require too much management overhead. Functions could work but App Service is better for a persistent API.
Q2: An enterprise has a legacy .NET application that requires Windows Server 2016 and a specific version of IIS with custom modules. What Azure compute option is most appropriate?
Show Answer
Azure Virtual Machine. The requirement for a specific OS version and custom IIS modules means you need full OS control — which only IaaS (VM) provides. App Service uses Microsoft-managed runtime environments you cannot customise at the OS level. This is a classic lift-and-shift scenario where VM is the correct first step, with modernisation considered for later phases.
Q3: A global gaming company needs a leaderboard that serves players in 30 countries with under 10ms latency for reads and must handle 1 million writes per second. What database is appropriate?
Show Answer
Azure Cosmos DB with multi-region writes enabled. The signals are: global distribution (30 countries), strict low latency (under 10ms), and massive write throughput (1M writes/second). Cosmos DB is purpose-built for this profile — SLA-backed single-digit millisecond latency globally, native multi-region writes, horizontally scalable throughput. Azure SQL cannot match this at global scale with these latency requirements.
Key Takeaways — Module 2
- VM to App Service to Functions: more managed means less control but lower operational overhead — choose based on how much control the workload actually needs
- Match storage tier (Hot/Cool/Archive) to access frequency — Lifecycle Management Policy automates tiering without manual intervention
- Azure SQL for relational OLTP with complex transactions; Cosmos DB for global distribution, flexible schema, and sub-10ms latency at scale
- AKS for container orchestration at scale; ACI for individual containers without cluster management
- The AZ-305 signal: "minimise infrastructure management" = avoid VMs; "OS-level customisation required" = VMs are appropriate