Browse Exams — Mock Exams & Practice Tests

AZ-305 Cheatsheet — Architecture Pickers, Tables, and High-Yield Trade‑offs

Fast reference for AZ-305: service selection tables for compute, networking, data, messaging, and governance; Private Link and DNS gotchas; RTO/RPO patterns; and design heuristics that match Microsoft’s blueprint.

On this page

Use this for last-mile review. Pair with the Syllabus for coverage and Practice for speed.

1) The AZ-305 “design lens” (how to think)

Most questions hide the real requirement. Look for these words:

  • Availability: single zone vs multi-zone vs multi-region
  • Security: public endpoint vs private access; least privilege; key management
  • Performance: latency, throughput, concurrency, caching
  • Operations: monitoring, patching, scaling automation, blast radius
  • Cost: managed services, consumption vs provisioned, data egress, log retention

If two answers “work,” choose the one that is simpler to operate and managed by Azure (PaaS) unless the scenario demands OS/control.

2) Identity & access (design pickers)

Requirement Recommended approach Why
App-to-Azure authentication Managed Identity No secrets to store; rotates automatically
Human access control Azure RBAC + PIM Least privilege with just-in-time elevation
SaaS app auth to your API Entra ID app registration Standard OAuth/OIDC patterns
Partner access Entra B2B guests + access reviews External collaboration with governance
Secrets/certs/keys Key Vault (or Managed HSM) Central rotation + access control + auditing

High-yield gotchas

  • Prefer RBAC over resource-specific keys (storage keys) whenever identity-based auth is supported.
  • If the scenario mentions “rotate secrets/certs,” Key Vault is usually the architectural answer.
  • PIM is the “architect” answer when privileged roles must be controlled and audited.

3) Governance (scale patterns)

Control Use when Common design move
Management groups org-wide policy and reporting Separate platform vs landing zones
Subscriptions isolation, billing, quotas Split by environment or business unit
Resource groups lifecycle boundary Deploy/delete as a unit
Tags cost allocation, ownership Enforce with Policy Append/Modify
Policy initiatives compliance at scale “Baseline security” initiative at MG scope

Rule of thumb: Use Policy for configuration guardrails, RBAC for access, and Locks only for “don’t delete prod.”

4) Logging & monitoring (what routes where?)

Need Primary Azure service Design note
Metrics + alerts Azure Monitor Metric alerts are fast and cheap
Central log search Log Analytics Workspace Standardize workspace strategy early
App tracing/APM Application Insights Correlate requests, dependencies, failures
Long-term raw log retention Storage account Cheap retention; query later via tools
Stream logs to SIEM/3rd party Event Hubs Decouple producers/consumers 
    flowchart LR
	  R["Azure resource"] --> DS["Diagnostic Settings"]
	  DS --> LAW["Log Analytics Workspace"]
	  DS --> SA["Storage Account (archive)"]
	  DS --> EH["Event Hubs (stream)"]
	  LAW --> A["Alerts / Workbooks"]

Cost control levers

  • Collect only required categories; set retention intentionally.
  • Use sampling for high-volume app telemetry.
  • Centralize “platform logs” (activity/diagnostics) for consistent queries and governance.

5) Data services — quick pickers

Relational (OLTP)

If you need… Pick Notes
Minimal ops, modern app Azure SQL Database Built-in HA; elastic pools for many DBs
Near-100% SQL Server compatibility + instance features SQL Managed Instance Best for “lift and modernize”
Full OS/SQL control, custom extensions SQL Server on VM Highest ops responsibility
Open-source relational Azure Database for PostgreSQL/MySQL Managed patching/backups

Tier heuristics (SQL Database)

  • “Spiky / dev/test” → serverless
  • “Highest IO + low latency” → Business Critical
  • “Very large DB” → Hyperscale

Semi-structured (NoSQL / document)

Need Pick Design cue
Global distribution + low latency Cosmos DB Multi-region reads/writes; consistency trade-offs
JSON docs with flexible schema Cosmos DB (SQL API) Partition key choice is critical
Mongo-compatible workloads Cosmos DB (Mongo API) Validate feature parity constraints

Unstructured (files/blobs)

Need Pick Notes
Object storage + lifecycle tiers Blob Storage / ADLS Gen2 Use lifecycle rules + access tiers
SMB/NFS file shares Azure Files Consider identity-based auth
Highest durability (region + zones) GZRS (where available) Align to workload tier and RTO/RPO

6) Business continuity — RTO/RPO cheat sheet

Definitions

  • RPO: max acceptable data loss (time).
  • RTO: max acceptable downtime (time).
Requirement Typical pattern Example services
“Minutes RPO/RTO” active-active or hot standby Cosmos multi-region, SQL failover groups
“Hours RTO” warm standby + automation VMSS/AKS redeploy, DB geo-restore
“Days RTO” backup-only Azure Backup, storage versioning

Backup vs DR
Backups help you restore data, but do not guarantee fast recovery. If the scenario cares about outage time, look for replication/failover patterns (ASR, geo-replication, multi-region).

7) Compute — service selection

Workload shape Recommended compute Why
Needs OS control, legacy agents VMs / VM Scale Sets Full control; you manage patching
Web apps/APIs (managed) App Service Fast deploy, autoscale, slots
Containers with orchestration AKS Kubernetes control plane + ecosystem
Simple containerized apps Container Apps / ACI Lower ops than AKS (use case dependent)
Event-driven glue Functions Consumption, scale to zero
Batch / HPC style jobs Azure Batch Job scheduling + pools

Design hint: If the question stresses “reduce ops,” prefer PaaS (App Service/Functions/managed DB) over VMs.

8) App integration — queues, events, streaming

Need Pick Why
Command queue + ordering + DLQ Service Bus queues Enterprise messaging features
Pub/sub with topics Service Bus topics Multiple consumers with filters
Reactive events (routing) Event Grid Push-based eventing, fan-out
High-throughput ingestion/telemetry Event Hubs Partitioned streaming
Workflow orchestration Logic Apps Low-code connectors and approvals

9) Networking — connectivity + ingress chooser

Private access patterns

  • Private Endpoint: PaaS gets a private IP in your VNet (requires Private DNS).
  • Service endpoints: keep public endpoint, but restrict traffic to VNet/subnet.

On-prem connectivity

Need Pick Notes
Fast setup, encrypted tunnel VPN Gateway Internet-based; variable latency
Private connectivity, predictable ExpressRoute Dedicated/private; higher cost
Many sites/branches Virtual WAN Hub-based connectivity at scale

Ingress & load balancing (most-tested)

Scenario Best fit Why
Global anycast entry + WAF/CDN Front Door Global edge, caching, smart routing
Regional L7, private apps, WAF Application Gateway TLS offload, path rules
L4 TCP/UDP inside region Load Balancer High throughput, simple
DNS-based routing/failover Traffic Manager DNS-level steering 
    flowchart LR
	  U["Users"] --> FD["Front Door"]
	  FD --> AGW["Application Gateway (WAF)"]
	  AGW --> APP["App Service / AKS"]
	  APP --> DATA["Data services"]

10) Migration shortcuts (CAF + tools)

  • Assess: Azure Migrate (discovery + sizing + dependency mapping).
  • Move: rehost (VM), refactor (PaaS), rearchitect (cloud-native).
  • Databases: choose online/offline migration; validate compatibility early.
  • Data: for large transfers use Data Box; for ongoing sync use AzCopy/replication.

Keep going

Syllabus
Practice