AZ-104 Capstone Lab: Run an Azure Environment
AZ-104 Capstone Lab: Run an Azure Environment
A useful Azure administrator does not merely know how to create a virtual machine, assign a role or configure an alert. The job is to keep an entire environment usable when those controls interact. A change to identity can stop a storage request; a DNS record can make a healthy service unreachable; a successful backup can still fail the business’s recovery objective.
This AZ-104 exam capstone brings all five current Microsoft objective domains into one realistic, controlled exercise. Instead of collecting dozens of unrelated portal screenshots, you will operate a small claims-intake application through deployment, governance, secure data access, monitoring and recovery. The environment is illustrative: use only a disposable Azure subscription or resource group you are authorized to manage, and verify all potential charges and service availability before deployment.
The business brief is intentionally small
Imagine a support team that receives non-sensitive sample claim documents through an internal web application. The app stores files in Azure Storage, records requests, and runs a background processing step. Users work during business hours, but the service must remain recoverable after an accidental deletion. The organization wants the workload identified by owner and environment, exposed only on approved network paths, and monitored so the support team learns about significant failures.
Define three success conditions before creating resources. First, an approved employee can upload and retrieve one sample file using the intended identity. Second, an unapproved identity or network path cannot do the same operation. Third, if a document is accidentally overwritten or a service becomes unreachable, the team can identify the failure and demonstrate recovery in a controlled test.
Those are deliberately modest requirements. They let you judge whether your Azure configuration works without inventing a production-scale architecture or a fictional service-level agreement.
Start with scope, roles and a budget
Create a uniquely named resource group for the lab and record the active subscription, tenant and region. If you have access to a test group in Microsoft Entra ID, assign its operators the least authority necessary for the chosen resource group. Keep role-assignment administration separate from routine resource administration when practical. Document which identity will run deployments and which will access the application’s stored data.
Apply an owner and environment tag to lab resources. Use an appropriately scoped budget with notifications to observe cost, but remember that a standard Azure Cost Management budget alert does not automatically stop resources from consuming money. A disposable environment needs a cleanup plan as well as a budget. Choose inexpensive supported SKUs only after checking the relevant region and your subscription’s entitlement; don’t assume that every advertised free tier applies.
If you can safely use Azure Policy, apply a narrowly scoped test requirement such as an allowed location or required metadata. Prove that a deliberately non-compliant test deployment is refused and a compliant one succeeds. This is governance evidence, not an invitation to change subscription-wide rules on a shared production account.
Deploy repeatably instead of building everything by hand
Put the core lab configuration into a versioned Bicep or ARM template where reasonable. Parameters should represent legitimate environment differences such as a resource name or location. The declaration might include a storage account, a chosen compute resource and essential diagnostic settings. Keep secrets outside source control, and understand which resource properties cannot be changed in place without replacement.
Run an ARM what-if preview before making a meaningful update and inspect the proposed differences. Does the deployment create a new resource, alter an existing setting or attempt a disruptive change? A template is a description of desired infrastructure, not a data-backup or automatic rollback system. Preserve an approved previous version and know which operation would revert a failed configuration.
A detailed Bicep and ARM deployment lab can deepen this stage when the practical challenge is understanding resource identity, dependencies and preview behavior. The capstone only requires that your changes become traceable and repeatable.
Give the application a clear identity and storage permission
Create a private blob container holding only harmless sample documents. Use Microsoft Entra authentication or a managed identity where the chosen client supports it, and give the client a suitable data role rather than a subscription-wide management role. Verify the account, container and principal separately. The platform role that can create a storage account is not automatically the role that authorizes a blob data read.
Test the allowed action using the application’s actual identity. Then remove the data role temporarily in the lab and repeat the request. Capture the failure and compare it with a network-denied attempt. The two errors may look similar in a condensed view, but one is a data authorization failure and the other concerns reachability or service firewall rules.
If the scenario uses a SAS token for a test client, constrain its permissions and lifetime, protect the token as a secret and document its revocation plan. Do not leave broad account-key access in a copied tutorial simply because it makes the first demo work.
Select compute by what the workload actually needs
An internal web API may fit Azure App Service, while a special legacy application may require a VM. A short image-processing step might be handled through an appropriate container runtime. Choose one supported and affordable option for the lab rather than deploying every compute product at once. The point is to explain which operating-system management, scaling, security and release responsibilities the platform handles and which remain with your team.
For an App Service approach, configure the App Service plan, application settings, identity and any networking dependencies. If a deployment slot is available on the chosen tier, test a safe staging deployment and confirm which settings stay with the slot. For a VM, account for guest patching, disk behavior, availability and backup. For containers, separate image storage in Azure Container Registry from execution in the runtime and make sure the runtime can pull its image.
The lab score should depend on whether the application reliably completes its transaction, not on how many expensive Azure services you deployed.
Prove the intended network path and deny the wrong one
Create only the networking required by the selected design. If you use a virtual network with a private endpoint, record the subnets, NSG rules, routing assumptions, private endpoint target and DNS integration. Test the service’s normal hostname from a permitted client and verify that it resolves to the intended address and reaches the appropriate endpoint.
Introduce a controlled DNS or NSG failure and watch the effect on the application. A VNet can exist, peering can appear connected and an NSG can contain an allow rule while a request still fails because the client’s effective route or DNS result is wrong. Trace the source, destination IP, protocol, port, next hop, filtering decision and guest/application listener in order.
Avoid proving connectivity by opening a wide public management port. If VM administration is required, use a supported secure management route such as Bastion where appropriate and available. Administrative access and the application’s exposed service path are different questions.
Monitor failure symptoms before users find them
Choose one metric relevant to the compute resource and configure one diagnostic log stream whose records would help explain a failure. Give the diagnostic setting an intentional destination and examine its retention and access requirements. A Log Analytics workspace is useful only when relevant records are actually arriving; an empty query result may indicate missing collection rather than a healthy application.
Configure an alert that represents a meaningful symptom and route it through an action group with a real owner in the lab. If the chosen workload is under maintenance, understand how an alert processing rule could suppress expected notifications without pretending the underlying condition has disappeared.
Now make a controlled change that produces a failure. Compare the alert, available logs and any Azure Activity Log operation. Determine whether the alert triggered before the simulated user reported the issue, and whether the evidence leads to the correct remedy. The goal is operational observability, not an impressive set of dashboards.
Protect data and prove that a restore actually works
Enable appropriate supported recovery features for the lab’s protected data. Blob versioning or soft delete can help with particular accidental changes; Azure Backup offers supported workload recovery points; Site Recovery addresses selected disaster-recovery replication and failover scenarios. Do not turn on an expensive or unsuitable service merely to complete a checklist. The exercise should identify which protection actually covers the failure you intend to simulate.
Overwrite or delete a harmless test document and recover the intended prior copy. Record its timestamp and test that the application can read it. If you are using a VM with a supported backup policy, an isolated restoration exercise can confirm that the OS, data and services are usable. A successful backup status alone does not establish an application recovery time or data-loss objective.
Write a recovery note stating the latest usable data point, the elapsed restoration time, dependencies required and anything you would change before a production rollout. Do not confuse a storage redundancy setting with a backup or a complete disaster-recovery plan.
Run three deliberate failures without changing the answer key
First, attempt an operation with the wrong Azure resource role or data-plane permission. Second, use a safe network restriction or DNS misconfiguration to prevent the allowed client from reaching a service. Third, make a reversible change that triggers a useful monitoring signal or requires a document restore. For each run, have a second person describe the symptom without revealing the injected fault.
The operator should explain a plausible cause, name the evidence needed to test it, inspect the result and choose the smallest corrective change. An administrator who responds to every storage error by granting Owner or to every network error by allowing all traffic may make the demonstration succeed while creating a much worse environment.
A good record includes timestamps, the exact principal and resource, route or access policy involved, relevant logs or metrics, the remediation and proof that the original business operation works again. Clean up the injected failure after each run so that the next scenario has a known baseline.
Finish with an operator handoff rather than a certificate screenshot
The final deliverable from the lab is a concise operating record: what resources exist, who owns them, how deployments are changed, where secrets and identities are managed, which paths are intentionally reachable, what alerts matter, and how recovery was tested. Include resource names, relevant policies, dashboards and links to versioned deployment definitions. Do not include SAS tokens or live secrets in the report.
Then remove the disposable resources following a known order and verify that costs, vaults, diagnostic settings and network endpoints were not unintentionally left behind. If a lock prevents cleanup, review it and remove it through the approved administrative process rather than weakening subscription security.
The AZ-104 study plan can spread these exercises across preparation sessions. This capstone measures something different: the ability to operate an Azure environment coherently when identity, governance, storage, compute, networking, monitoring and recovery have to work together.
- Category: Certifications Microsoft
- Tags: AZ-104
