AZ-305 scenarios are usually trade-off questions rather than product-recognition questions. Several Azure services can often satisfy part of a requirement, but the best design has to preserve security, recovery objectives, operational simplicity, performance, governance, and cost at the same time. The architect should identify the non-negotiable constraint first and then choose the smallest architecture that meets it.
The examples below stay inside the current AZ-305 blueprint. They are not claims about live exam questions. Use them to practice requirement-first architecture reasoning.
Scenario one: an application needs secrets without credentials in code
Use a managed identity for the workload where supported and authorize it to retrieve the required secret or certificate from Key Vault. Storing a client secret in application settings simply moves the secret rather than removing the lifecycle problem.
The Key Vault design should separate secret storage, workload authentication, and resource authorization.
Scenario two: a critical database must survive a regional outage
Start with RTO and RPO rather than choosing a replication feature by name. The answer may require geo-replication, failover groups, backups, or another regional strategy depending on database service, write pattern, acceptable data loss, and failover speed.
High availability inside one region is not automatically disaster recovery across regions.
Scenario three: two application components fail together because calls are synchronous
Introduce asynchronous messaging when the business process can tolerate delayed processing. A queue can isolate temporary downstream failure and allow consumers to recover or scale independently.
Service Bus adds responsibilities such as retries, ordering, dead-letter handling, and idempotence. Decoupling improves resilience only when those behaviors are designed.
Scenario four: API consumers need versioning, throttling, and centralized authentication
API Management can provide a managed policy layer between clients and backend APIs. The service can support versioning, quotas, authentication integration, transformations, analytics, and a controlled developer experience.
The API Management decision is strongest when the requirement is API governance, not merely “put another endpoint in front of the app.”
Scenario five: a read-heavy workload has expensive repeated database queries
A cache may reduce latency and database load if the data can tolerate the chosen freshness and invalidation behavior. The architect should define what is cached, for how long, and what happens after writes.
Azure Cache for Redis is useful when low-latency key access fits the workload, but caching should not hide a fundamentally poor data model.
Scenario six: globally distributed semi-structured data needs low latency
Cosmos DB can be a strong fit when global distribution, horizontal scale, and nonrelational access are central. The design still needs partition-key selection, consistency choice, throughput planning, and cost awareness.
The Cosmos DB decision should follow access pattern and geographic need rather than a generic preference for NoSQL.
Scenario seven: teams need different governance but shared organizational controls
Use management groups and subscriptions to separate ownership or regulatory boundaries while applying common policy at an appropriate parent scope. Putting every workload in one subscription can simplify billing initially but increase blast radius and policy complexity later.
Governance structure should mirror meaningful administrative boundaries.
Scenario eight: a web application needs public traffic distribution and private backends
Choose the routing and load-balancing service based on protocol, layer, regional or global scope, TLS needs, web application protection, and backend architecture. A Layer 4 load balancer and an HTTP-aware application gateway solve different problems.
The Azure Load Balancer context helps with one part of this choice, but the scenario should drive whether the architecture needs Layer 4, Layer 7, or global routing behavior.
Scenario nine: migration deadline is short but target architecture should modernize later
A staged migration can move some workloads to IaaS first while preserving a roadmap to PaaS modernization. Trying to refactor every dependency during a fixed cutover can increase delivery risk.
The Cloud Adoption Framework approach is useful because migration method and target-state maturity do not have to be identical on day one.
Scenario ten: monitoring exists but teams still discover failures from users
Review whether telemetry measures the actual user path, whether alerts are actionable, whether logs are routed to the right place, and whether ownership is defined. Collecting data is not the same as operational monitoring.
Scenario eleven: a development team needs broad freedom while production must meet strict policy. Separate environments through subscriptions or management groups and apply inherited policy at the appropriate scope. Giving production exceptions because development needs flexibility weakens the governance model.
Scenario twelve: a workload runs only a few hours each night and can process tasks independently. Batch or serverless options may reduce idle cost compared with permanently running virtual machines. If tasks require specialized long-running state or custom operating-system dependencies, VM-based compute may still be stronger.
Scenario thirteen: an on-premises application needs low-latency private access to Azure resources. Compare VPN and ExpressRoute based on bandwidth, reliability, lead time, redundancy, and cost. Hybrid connectivity is an architectural requirement, not simply a checkbox labeled “connect to Azure.”
Scenario fourteen: multiple APIs expose the same business capability with inconsistent authentication. Centralizing policy through API Management can reduce duplication and provide a consistent contract, but backend authorization still matters. API gateway policy should complement rather than replace service-level security.
Scenario fifteen: a cache improves performance but users sometimes see stale data after updates. Define invalidation, expiration, and write-through or cache-aside behavior according to the business tolerance for staleness. Caching is a consistency trade-off, not a free performance improvement.
Scenario sixteen: a storage design is cheap but recovery requires many hours while the business requires minutes. Upgrade the protection architecture or change the RTO expectation. Cost optimization cannot override a non-negotiable continuity requirement.
Scenario seventeen: an application needs to migrate quickly but depends on an unsupported database feature. Rehost the database temporarily or select a compatible managed target, then plan modernization later. Migration sequence should reduce cutover risk rather than force an immediate rewrite.
Scenario eighteen: logs are stored in multiple subscriptions and security teams cannot investigate across them efficiently. Design centralized routing, retention, permissions, and workspace strategy that still respects regulatory or business boundaries. Centralization should improve investigation without violating data-separation requirements.
Scenario nineteen: a workload identity needs to access both Azure and an on-premises service. The architecture may require separate authorization methods or federation patterns. Do not assume Azure RBAC automatically grants rights to an on-premises application. Identity architecture spans multiple control planes.
Scenario twenty: two answers meet the technical requirement, but one requires a custom VM fleet and the other uses a managed service. If control requirements are equal, the managed option may reduce patching, availability, and operational burden. Operational simplicity is a legitimate architecture criterion.
Scenario twenty-one: a production application must meet strict compliance while a sandbox needs experimentation speed. Separate scopes and apply stronger inherited governance to production while keeping the sandbox bounded by budget, network, and data restrictions. Governance should be proportional to risk without forcing every environment into the same operating model.
Scenario twenty-two: an API needs to serve both internal and external clients with different authentication rules. Use an API layer that can apply distinct products, policies, or identity requirements while keeping backend authorization intact. Avoid cloning the backend merely to create different client policies.
Scenario twenty-three: a nightly batch job is repeatedly delayed because it competes with interactive workloads. Move batch processing to a compute model or schedule that isolates resource demand and matches the required completion window. Architecture should separate workloads when their performance objectives conflict.
Scenario twenty-four: a global application has stable read traffic but unpredictable write bursts. Separate read scaling, write capacity, queueing, and data consistency requirements before selecting the database and caching pattern. One scaling mechanism may not solve both read and write behavior.
Scenario twenty-five: a company wants to minimize downtime during database migration. Use online or replicated migration patterns where compatible, validate data before cutover, and keep rollback options until the target is proven. A fast copy is not enough if the application cannot tolerate the final synchronization window.
Scenario twenty-six: an architecture meets the user’s performance target but creates excessive cross-region transfer cost. Revisit data placement, replication, caching, and user-routing design. The solution may be to move computation closer to data or reduce unnecessary replication rather than simply accepting the network bill.
Scenario twenty-seven: a workload uses several manually maintained secrets across environments. Consolidate secret management, prefer workload identity where supported, and automate rotation or retrieval. Manual secret distribution is both a security risk and an operational failure point.
Scenario twenty-eight: users require private access to a PaaS database but DNS still resolves the public endpoint. Fix private DNS integration rather than opening the database publicly. Private endpoints depend on name resolution as well as network policy.
Scenario twenty-nine: teams want centralized logging but regulations prevent some data from leaving a regional boundary. Design separate workspaces or routing boundaries with controlled aggregation rather than forcing all telemetry into one global store. Centralization is useful only when it respects data-governance constraints.
Scenario thirty: a queue-based workflow meets availability targets but business events are processed twice. Improve idempotence and deduplication rather than removing the queue. Asynchronous resilience and business correctness must be designed together.
Scenario thirty-one: a company wants the fastest possible regional failover but is unwilling to pay for continuously provisioned standby capacity. The architecture and the requirement conflict. Either relax RTO or accept higher cost; no service choice can eliminate that fundamental trade-off.
Scenario thirty-two: a legacy application can move to Azure immediately on VMs, while a managed PaaS rewrite would take months. Use staged migration if the business deadline is real, but document the modernization roadmap and temporary operational burden. Transition architecture should be intentional.
The Azure Monitor design should connect technical signals to service-level objectives and response. The strongest AZ-305 answer preserves the business requirement across control plane, data, failure domain, runtime, network, and operations.