Use this for last-mile review. Pair it with Resources for scope confirmation, then use the exact AZ-305 page on MasteryExamPrep.com when you want the matching practice destination.
PaaS: Platform as a service, where Azure manages more of the platform so the design stays simpler to operate.
PIM: Privileged Identity Management for just-in-time elevation and privileged-role governance.
RTO / RPO: Recovery Time Objective and Recovery Point Objective, which define how fast and how completely the design must recover.
AZ-305 answer sequence
Use this when the stem mixes governance, identity, data, continuity, or infrastructure trade-offs.
flowchart TD
S["Scenario"] --> C["Classify the business requirement"]
C --> B["Name the boundary or target that matters most"]
B --> M["Pick the simplest managed design that fits"]
M --> E["Add private access, monitoring, or resilience if required"]
Fast lane picker
| If the question is really about… |
Focus first on… |
Strongest first move |
| identity, admin access, or secret reduction |
Entra ID, Managed Identity, RBAC, PIM, Key Vault |
remove standing privilege and stored secrets first |
| organizational control at scale |
management groups, subscriptions, Policy, tags, locks |
decide the governance boundary before the service |
| storage or database shape |
OLTP vs analytics vs object vs document |
pick the data model before the SKU |
| private access or ingress |
Private Endpoint, DNS, Front Door, Application Gateway, Load Balancer |
decide whether the path is private, regional, or global |
| continuity and failover |
RTO, RPO, active-active vs warm vs restore-only |
translate the time target before naming the product |
| monitoring and operational visibility |
Azure Monitor, Log Analytics, Application Insights, archiving |
route logs and metrics intentionally, not by default |
AZ-305 decision order
flowchart TD
A["Read the business requirement"] --> B["Classify it: identity, governance, data, continuity, or infrastructure"]
B --> C["Name the boundary or target that matters most"]
C --> D["Prefer the simplest managed Azure design that meets it"]
D --> E["Add private access, monitoring, and resilience only where the scenario requires"]
What to notice:
- AZ-305 is mostly a trade-off exam, not a product recall exam
- the right answer is usually the least operationally heavy managed design that still satisfies the requirement
- private access, continuity, and governance are usually first-class constraints rather than cleanup work
Identity and access chooser
| Requirement |
Strongest first fit |
Why |
Common trap |
| Azure resource calling another Azure service |
Managed Identity |
no secret storage or manual rotation |
reaching for client secrets when identity-based auth is supported |
| privileged admin role with approval and audit |
PIM + RBAC |
reduces standing privilege |
using broad permanent subscription-owner access |
| partner collaboration in your tenant |
Entra B2B |
external identity with governance |
creating duplicate local accounts for every partner |
| app secrets, certs, or keys |
Key Vault or Managed HSM |
centralizes rotation and auditing |
storing secrets in config files or code pipelines |
| resource authorization |
Azure RBAC |
scope-based authorization model |
treating Policy as an access-control system |
Governance boundary model
| Azure boundary |
Use when |
Strongest design cue |
| management group |
cross-subscription policy, compliance, and reporting |
platform-wide standards belong here |
| subscription |
billing, quota, major isolation boundary |
split by environment, business unit, or landing zone intent |
| resource group |
shared lifecycle and deployment boundary |
deploy and delete as a unit |
| tag |
ownership, cost, classification, automation inputs |
use with Policy to keep metadata consistent |
| lock |
prevent accidental delete or change |
safety belt, not full governance |
Policy, RBAC, and locks
| Control |
What it answers |
Best use |
| RBAC |
who may do what |
authorization |
| Policy |
what configurations are allowed or required |
compliance and guardrails |
| lock |
what should not be deleted or changed casually |
accidental-change prevention |
| Blueprint-style landing-zone standardization |
how platform environments are organized |
repeatable architecture at scale |
| Requirement |
Strongest first fit |
Why |
| managed relational OLTP app |
Azure SQL Database |
lowest operational burden for common relational workloads |
| near-full SQL Server instance compatibility |
SQL Managed Instance |
stronger lift-and-modernize fit |
| full OS and SQL control |
SQL Server on Azure VM |
only when control requirements justify the ops burden |
| globally distributed low-latency document workload |
Cosmos DB |
global scale and consistency trade-offs are first-class |
| simple managed open-source relational |
Azure Database for PostgreSQL or MySQL |
managed ops with familiar engines |
| large object storage and lifecycle tiering |
Blob Storage / ADLS Gen2 |
durable storage with lifecycle controls |
| shared SMB/NFS file workload |
Azure Files |
managed file share semantics |
Data service traps
| Pair |
Keep this distinction clear |
| Azure SQL Database vs SQL Managed Instance |
app-first managed SQL vs stronger SQL Server compatibility |
| Cosmos DB partitioning vs relational indexing |
scale and access pattern design, not just “NoSQL” branding |
| Blob Storage vs Azure Files |
object storage vs shared file semantics |
| backup vs geo-replication |
restore safety vs outage-time resilience |
Continuity chooser
| Business clue |
Typical pattern |
Service examples |
| minutes of outage and minimal data loss |
active-active or hot standby |
Cosmos DB multi-region, SQL failover groups, zone-redundant platform tiers |
| restore in hours with some automation |
warm standby |
ASR, regional failover, scripted scale-up |
| restore later from backup |
restore-only path |
Azure Backup, geo-restore, archived storage versions |
| Term |
Meaning |
| RTO |
maximum acceptable restore time |
| RPO |
maximum acceptable data-loss window |
| hot site / active-active |
fastest recovery, highest operating cost |
| warm site |
moderate recovery speed and cost |
| cold or restore-only |
cheapest standby, slowest recovery |
Monitoring and log routing
flowchart LR
R["Azure resource"] --> DS["Diagnostic settings"]
DS --> LAW["Log Analytics Workspace"]
DS --> SA["Storage archive"]
DS --> EH["Event Hubs / SIEM stream"]
LAW --> AL["Alerts / Workbooks"]
R --> M["Platform metrics"]
M --> AL
| Need |
Strongest first Azure service |
Why |
| platform metrics and alerts |
Azure Monitor |
fast metric alerts and broad resource coverage |
| centralized queryable logs |
Log Analytics Workspace |
operational and security search layer |
| app telemetry and tracing |
Application Insights |
request and dependency visibility |
| long-term low-cost raw retention |
Storage account |
cheap archive target |
| external SIEM or streaming analytics |
Event Hubs |
decoupled log export path |
Networking and private access chooser
| Requirement |
Strongest first fit |
Why |
Common trap |
| private access to PaaS service from VNet |
Private Endpoint |
private IP path into the service |
forgetting private DNS |
| keep public endpoint but restrict to VNet traffic |
service endpoint |
lighter pattern when private IP is not required |
confusing it with Private Endpoint |
| global anycast-style web entry with WAF/CDN behavior |
Front Door |
global edge and smart routing |
choosing regional L7 first for a global scenario |
| regional L7 ingress with path-based rules and WAF |
Application Gateway |
regional app gateway semantics |
using it as a global traffic manager |
| L4 balancing inside a region |
Load Balancer |
TCP/UDP, high-throughput simple balancing |
expecting application-layer routing |
| DNS-level failover or routing |
Traffic Manager |
DNS routing, not proxying |
forgetting DNS TTL and caching behavior |
| private dedicated on-prem path |
ExpressRoute |
private connectivity and predictability |
overspending when VPN fits the scenario |
| encrypted internet-based site-to-site path |
VPN Gateway |
faster setup, lower cost |
expecting ExpressRoute-like consistency |
Architecture traps
| Trap |
Better reading of the question |
| choosing VM-based control when the clue rewards reduced ops |
prefer PaaS unless the scenario requires OS or engine control |
| adding private connectivity without DNS planning |
Private Endpoint designs usually live or die on name resolution |
| using backups to satisfy a strict outage target |
outage-time requirements usually need replication or failover, not just restore |
| treating Policy as an authorization feature |
Policy governs configuration, RBAC governs access |
| picking a globally distributed service because it sounds “architectural” |
use global services only when the latency, resilience, or geography clue actually requires them |
Last 15-minute review
| Review this |
Because it fixes… |
| Managed Identity, RBAC, PIM, Key Vault roles |
identity-control misses |
| management group vs subscription vs resource group |
governance-boundary confusion |
| Azure SQL vs MI vs VM, Cosmos vs Blob vs Files |
data-service mispicks |
| Private Endpoint vs service endpoint, Front Door vs App Gateway vs Load Balancer vs Traffic Manager |
networking and ingress distractors |
| RTO/RPO and backup vs DR |
continuity mistakes |
| Monitor vs Log Analytics vs App Insights |
observability-routing misses |
What strong answers usually do
- start from constraints like availability, data sensitivity, latency, and ownership
- choose the simplest Azure-managed design that satisfies the requirement
- separate governance decisions from connectivity decisions and from runtime behavior
- treat private access, continuity, monitoring, and cost as architectural concerns from the start
Keep going
- Objective map: Resources
- Timed drills: matched Azure practice on MasteryExamPrep.com