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)

RequirementRecommended approachWhy
App-to-Azure authenticationManaged IdentityNo secrets to store; rotates automatically
Human access controlAzure RBAC + PIMLeast privilege with just-in-time elevation
SaaS app auth to your APIEntra ID app registrationStandard OAuth/OIDC patterns
Partner accessEntra B2B guests + access reviewsExternal collaboration with governance
Secrets/certs/keysKey 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)

ControlUse whenCommon design move
Management groupsorg-wide policy and reportingSeparate platform vs landing zones
Subscriptionsisolation, billing, quotasSplit by environment or business unit
Resource groupslifecycle boundaryDeploy/delete as a unit
Tagscost allocation, ownershipEnforce with Policy Append/Modify
Policy initiativescompliance 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?)

NeedPrimary Azure serviceDesign note
Metrics + alertsAzure MonitorMetric alerts are fast and cheap
Central log searchLog Analytics WorkspaceStandardize workspace strategy early
App tracing/APMApplication InsightsCorrelate requests, dependencies, failures
Long-term raw log retentionStorage accountCheap retention; query later via tools
Stream logs to SIEM/3rd partyEvent HubsDecouple 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…PickNotes
Minimal ops, modern appAzure SQL DatabaseBuilt-in HA; elastic pools for many DBs
Near-100% SQL Server compatibility + instance featuresSQL Managed InstanceBest for “lift and modernize”
Full OS/SQL control, custom extensionsSQL Server on VMHighest ops responsibility
Open-source relationalAzure Database for PostgreSQL/MySQLManaged patching/backups

Tier heuristics (SQL Database)

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

Semi-structured (NoSQL / document)

NeedPickDesign cue
Global distribution + low latencyCosmos DBMulti-region reads/writes; consistency trade-offs
JSON docs with flexible schemaCosmos DB (SQL API)Partition key choice is critical
Mongo-compatible workloadsCosmos DB (Mongo API)Validate feature parity constraints

Unstructured (files/blobs)

NeedPickNotes
Object storage + lifecycle tiersBlob Storage / ADLS Gen2Use lifecycle rules + access tiers
SMB/NFS file sharesAzure FilesConsider 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).
RequirementTypical patternExample services
“Minutes RPO/RTO”active-active or hot standbyCosmos multi-region, SQL failover groups
“Hours RTO”warm standby + automationVMSS/AKS redeploy, DB geo-restore
“Days RTO”backup-onlyAzure 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 shapeRecommended computeWhy
Needs OS control, legacy agentsVMs / VM Scale SetsFull control; you manage patching
Web apps/APIs (managed)App ServiceFast deploy, autoscale, slots
Containers with orchestrationAKSKubernetes control plane + ecosystem
Simple containerized appsContainer Apps / ACILower ops than AKS (use case dependent)
Event-driven glueFunctionsConsumption, scale to zero
Batch / HPC style jobsAzure BatchJob 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

NeedPickWhy
Command queue + ordering + DLQService Bus queuesEnterprise messaging features
Pub/sub with topicsService Bus topicsMultiple consumers with filters
Reactive events (routing)Event GridPush-based eventing, fan-out
High-throughput ingestion/telemetryEvent HubsPartitioned streaming
Workflow orchestrationLogic AppsLow-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

NeedPickNotes
Fast setup, encrypted tunnelVPN GatewayInternet-based; variable latency
Private connectivity, predictableExpressRouteDedicated/private; higher cost
Many sites/branchesVirtual WANHub-based connectivity at scale

Ingress & load balancing (most-tested)

ScenarioBest fitWhy
Global anycast entry + WAF/CDNFront DoorGlobal edge, caching, smart routing
Regional L7, private apps, WAFApplication GatewayTLS offload, path rules
L4 TCP/UDP inside regionLoad BalancerHigh throughput, simple
DNS-based routing/failoverTraffic ManagerDNS-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