virtual network<\/a> lab becomes architectural when you can explain the path for users, administrators, application traffic, and data separately.<\/p>\nLab ten: run a migration and architecture-review tabletop<\/h3>\n
Take an on-premises application and document dependencies, target platform, network path, identity, data migration, cutover, rollback, monitoring, and recovery. Decide which components should move to IaaS and which should modernize to PaaS.<\/p>\n
Add a tagging and policy exercise to the governance lab. Define required tags for owner, environment, cost center, and data classification, then enforce or audit them conceptually. The goal is to see how governance becomes repeatable across many subscriptions instead of depending on every deployment team remembering the same convention.<\/p>\n
Add a least-privilege review after the Key Vault lab. Inspect whether the workload identity can perform more actions than necessary and reduce scope if possible. Then consider how the same identity would behave during disaster recovery. Credentials and permissions must remain valid in the recovery architecture too.<\/p>\n
For monitoring, add a correlated incident. Trigger one application error and follow it through application logs, platform metrics, network evidence, and alert history. The lab should teach which source answers which question and why centralized evidence can reduce diagnosis time.<\/p>\n
For data, add a partitioning or scale exercise. Even a conceptual Cosmos DB lab should identify the partition key, expected request distribution, consistency need, and throughput model. Then imagine a workload shift that creates a hot partition and decide how the model would change.<\/p>\n
For continuity, test restore credentials and network paths as well as data. A recovered database that applications cannot authenticate to or reach over the network does not satisfy the business RTO. This is an excellent way to see why architects must coordinate several teams during recovery planning.<\/p>\n
For compute, introduce one planned failure. Replace a VM, restart a container replica, or let a serverless instance scale from zero. Observe which state survives and which is recreated. This makes stateless-versus-stateful design much more concrete.<\/p>\n
For messaging, create a poison-message scenario. Send an item that repeatedly fails processing and observe or model dead-letter handling. Define who reviews the dead-letter queue and how corrected work is replayed. Durable messaging requires an operational process around exceptional items.<\/p>\n
For API Management, introduce a breaking backend version and protect consumers with a versioned API path or policy. This shows why API architecture is a contract-management problem as much as a network endpoint problem.<\/p>\n
For networking, compare public service access with private endpoint access. Document DNS, routing, security, and cost differences. Private connectivity can reduce exposure, but it adds dependencies that must be designed and monitored deliberately.<\/p>\n
Finish by handing the architecture to someone else. Give them only the diagram, decision records, monitoring plan, and recovery notes. Ask them to identify how the system works and where it could fail. If the design cannot be understood without verbal explanation, the architecture documentation still has gaps.<\/p>\n
Add a management-group inheritance tabletop. Place a policy or role at a parent scope, then move a subscription or resource into a different branch and predict the effective result. This makes governance inheritance concrete and highlights why organizational restructuring can change security or compliance without touching the workload itself.<\/p>\n
Add one API failure where the backend remains healthy but consumers receive throttling or authentication errors. Use API Management logs or policy reasoning to separate gateway behavior from backend behavior. This teaches that supporting layers can fail independently of the application they front.<\/p>\n
Add a cache-failure test. Remove or bypass the cache and observe whether the application can continue against the source of truth. If the entire workload fails because a performance optimization is unavailable, the architecture has unintentionally made the cache a hard dependency.<\/p>\n
Add a DNS and private-endpoint exercise to the network lab. A private endpoint can exist while clients still resolve the public endpoint or wrong address. Document the DNS zone, resolver path, and expected address. This is a common example of connectivity depending on naming as well as routing.<\/p>\n
Add one regional recovery tabletop that includes Key Vault, identities, DNS, deployment artifacts, application configuration, and data. Restore the full user path, not only the database. This helps reveal why business continuity planning has to coordinate several architecture layers.<\/p>\n
At the end, estimate the operational burden of your design. Count the services that require patching, manual failover, special runbooks, or custom monitoring. Then ask whether a different service model could meet the same requirement with fewer operational responsibilities. Hands-on practice should improve design judgment, not only implementation confidence.<\/p>\n
Add a subscription-boundary exercise where development and production use different policies, budgets, and permissions. Observe how the same deployment template can behave differently under those inherited controls. This is a practical reminder that environment architecture includes governance context, not only resources.<\/p>\n
Add a service-limit tabletop to the compute lab. Identify a quota, connection, throughput, or regional constraint that could become the scaling ceiling. Define how the team would monitor the limit and what the mitigation would be before production reaches it.<\/p>\n
Add a log-retention decision to the monitoring lab. Security, compliance, operations, and cost can require different retention periods. Decide which signals need long-term storage and which high-volume diagnostic logs can use shorter retention without weakening investigations.<\/p>\n
Add one migration rollback rehearsal. Document the point at which the source becomes read-only, how final synchronization happens, how DNS or routing moves, and what event would trigger rollback. Migration architecture is safer when the reversal path is understood before cutover.<\/p>\n
Close the lab by removing temporary resources and verifying that budgets, test identities, backups, endpoints, and diagnostic settings are left in the intended state. Architecture lifecycle includes retirement and cleanup, not only creation.<\/p>\n
Keep the final environment small enough that every component, dependency, owner, and recovery action can still be explained clearly.<\/p>\n
Finish with a Well-Architected review and a short architecture decision record. The AZ-305 design<\/a> skill is demonstrated when another engineer can understand what you chose, what you rejected, and how the deployed system will be operated and recovered.<\/p>\n","protected":false},"excerpt":{"rendered":"Hands-on AZ-305 preparation should test architecture decisions, not turn the candidate into the primary operator of every Azure service. The current exam is about recommending designs across governance, identity, monitoring, data, continuity, compute, application patterns, migration, and networking. Small labs are valuable when they expose the trade-off and evidence behind the design. Use the current […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1648,1647],"tags":[],"_links":{"self":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/26274"}],"collection":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/comments?post=26274"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/26274\/revisions"}],"predecessor-version":[{"id":26275,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/26274\/revisions\/26275"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=26274"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=26274"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=26274"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}