{"id":25179,"date":"2026-10-11T10:46:40","date_gmt":"2026-10-11T10:46:40","guid":{"rendered":"https:\/\/www.exam-labs.com\/blog\/?p=25179"},"modified":"2026-10-11T10:46:40","modified_gmt":"2026-10-11T10:46:40","slug":"microsoft-az-104-practical-lab-secure-and-recover-azure-workload","status":"publish","type":"post","link":"https:\/\/www.exam-labs.com\/blog\/microsoft-az-104-practical-lab-secure-and-recover-azure-workload","title":{"rendered":"Microsoft AZ-104 Practical Lab: Secure and Recover an Azure Workload"},"content":{"rendered":"

An administrator is asked to deploy a small internal application environment in Azure. The work looks simple on a diagram: one resource group, a virtual machine, a storage account, a network, and an alert. Real operating risk appears between those boxes. Who can change the resources? Can the VM reach the data while unwanted clients cannot? How can an accidentally overwritten file be recovered? Will the alert reach its intended operator? What remains billable after the exercise ends?<\/p>\n

This practical Microsoft Azure Administrator scenario connects identity, governance, storage, compute, virtual networking, and monitoring\/recovery in one controlled environment. Each phase includes a configuration decision, an expected test, a failure to investigate, and evidence to record. It is intended for an eligible Azure subscription with appropriate permissions; the steps are a documented lab design, not a claim that Exam-Labs has executed the deployment or validated every result in a live Azure tenant<\/strong>.<\/p>\n

Define the lab boundary before provisioning<\/h3>\n

The current Microsoft AZ-104<\/a> objectives span five skill groups rather than one isolated command. This lab deliberately touches each group with a small workload and related permissions. The purpose is to explain a change through the platform, not memorize the position of a portal button. Choose a subscription and region where the required services are supported, then record a unique lab prefix and resource group that will not conflict with production naming.<\/p>\n

Use one dedicated resource group for disposable components whenever possible, but remember that some billing, identity, backup or network resources might not be contained in it. Azure resources may continue to incur charges when a VM is stopped inside its guest OS, an unattached managed disk is retained, a public IP remains allocated, or a backup vault retains recovery points. An Azure Cost Management budget can send alerts, but a budget does not stop resource consumption or enforce a spending cap<\/strong>. Microsoft documents delays in cost reporting and daily budget evaluation, so the operator must supervise costs and clean up resources independently.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Lab element<\/th>\nReason for including it<\/th>\nEvidence to keep<\/th>\n<\/tr>\n<\/thead>\n
Dedicated resource group and budget<\/td>\nGovernance, scope and responsibility<\/td>\nResource inventory, chosen owner and budget alert policy<\/td>\n<\/tr>\n
Test identity with limited RBAC scope<\/td>\nLeast privilege and denied-operation testing<\/td>\nAssignment scope and permitted\/denied results<\/td>\n<\/tr>\n
Storage account and a blob container<\/td>\nData access and recovery<\/td>\nNetwork\/data role state, original blob and previous version<\/td>\n<\/tr>\n
Virtual network, NSG and bounded test VM<\/td>\nCompute and network isolation<\/td>\nIP plan, effective security rules and approved reachability test<\/td>\n<\/tr>\n
Azure Monitor alert plus action group<\/td>\nOperational detection and notification<\/td>\nRule condition, fired alert, action receipt and incident owner<\/td>\n<\/tr>\n
Optional VM backup with explicit cost approval<\/td>\nRecovery Services policy and restore limits<\/td>\nVault configuration, successful job and independent restore check<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The table is an implementation inventory, not a demand to create every service in every learning environment. If a Bastion host, VM, premium networking plan, or backup option exceeds the user’s budget or permissions, evaluate that step on paper and document why it was skipped. Do not improvise insecure remote access or bypass organization policy just to make a sample lab complete.<\/p>\n

Phase 1 \u2014 establish resource scope and cost ownership<\/h3>\n

In the Azure portal, confirm the correct tenant, subscription and available permissions. Create a plainly named test resource group in a supported region. Use the subscription or resource-group Cost Management experience to set a budget and notifications appropriate to the experiment. The budget should identify the accountable operator and thresholds that give a useful early warning. Note that pricing varies by region, SKU, availability, transfer and retention settings.<\/p>\n

Record the lab’s planned shutdown date before you provision anything. A useful first verification is listing all resources assigned to the group and checking that no existing production service was unintentionally added. If the budget cannot be created due to authorization restrictions, document the missing cost-management role instead of broadening access without review.<\/p>\n

The Azure cost-management tagging model<\/a> explains why ownership metadata matters across subscriptions. Apply a simple lab purpose\/owner tag when supported and keep the group inventory. A tag can improve reporting and filtering, but it does not block an accidental deletion or prevent overspending.<\/p>\n

Phase 2 \u2014 assign identity permissions and test an intentional denial<\/h3>\n

Create or select a separate nonproduction identity approved for the exercise, rather than using a production human administrator account for every test. Assign an appropriate limited Azure role at the lab resource-group scope. A Reader assignment can inspect certain resource configuration, for example, but cannot create the resources. A Contributor role has broader resource-management powers but still does not automatically grant every resource’s data-plane read\/write permission.<\/p>\n

Observe the effective role assignment from the target identity or an approved controlled test session. Attempt one action the role permits and one harmless action outside the granted scope that should be denied. Record the intended result, the actual error or success, the inherited assignments and any propagation delay. An unexpectedly successful operation outside the assigned group may be explained by a broader inherited role, group membership or another authorized path; it is a finding to investigate, not a signal to remove arbitrary permissions.<\/p>\n

Work through the current Azure RBAC scope and inheritance model<\/a> when explaining this outcome. Directory identity and Azure resource authorization are distinct; the correct role at the wrong subscription or resource group can create an unintended access boundary.<\/p>\n

Phase 3 \u2014 protect a blob before testing an overwrite<\/h3>\n

Create a supported general-purpose storage account inside the agreed lab scope and choose its redundancy deliberately. A basic test does not require geo-redundant storage, and more replicas do not protect against accidental logical overwrites. Configure the storage account’s allowed network path according to the organization’s rules; do not enable anonymous public blob access merely to bypass an authentication problem. Then create a private blob container and assign the test identity the data-plane role appropriate for the intended read or upload.<\/p>\n

For a storage account type that supports it, enable blob versioning and blob soft delete with a documented retention period. Microsoft warns that versioning is not supported for accounts with a hierarchical namespace. Blob soft delete and versioning interact: an overwritten blob can have a previous version, and deleting the current blob with versioning enabled does not always restore a current version merely by selecting an Undelete action. Review the actual feature combination before deciding that an object is recoverable.<\/p>\n

Upload a small harmless text file with a known value such as version=one<\/code> and record its blob path and version identity. Modify the content to version=two<\/code> and inspect the available versions. Under an authorized account and supported configuration, promote the previous version or use the correct recovery operation and read the current content again. The proof of recovery is the data actually returned, not only a notification that a version was selected.<\/p>\n

Before deleting any test blob, record the container name, version identifier, configured retention and whether the blob is used by another application. A bounded deletion test can demonstrate the difference between a deleted current blob, a previous version and a soft-deleted version, but it should be attempted only with intentionally disposable data. The blob versioning and soft-delete recovery guide<\/a> explains the different recovery outcomes and why storage redundancy is not a replacement for them.<\/p>\n

Phase 4 \u2014 choose a network and VM configuration without accidental exposure<\/h3>\n

Choose a private address range that does not overlap with any connected environment. Create a virtual network and subnet sized for the planned lab resources, then associate a network security group (NSG) with the appropriate subnet or network interface. Record the destination IP and port that the application is expected to use. A private subnet is not automatically an isolation guarantee: effective routes, NSG rules, platform paths and application-level authentication still determine what a client can reach.<\/p>\n

Provision a small compatible VM only if the lab budget and organizational policy allow it. Select a supported region and SKU, disk configuration, identity and administration method before deployment. Do not create an unrestricted public management port as a shortcut. For private administration, use an organization-approved access service or a permitted internal jump path; Azure Bastion can be suitable but is a separate billable service whose tier and subnet requirements must be checked. If no approved private access is available, perform the configuration review without creating an exposed VM.<\/p>\n

Record the network interface and private IP allocation, the VM’s effective NSG rules and any assigned public IP. If the VM is intended to consume the private storage account, verify name resolution and its permitted network path. Then authenticate using the narrowly scoped managed identity or other approved principal and attempt an authorized storage operation. A successful TCP connection does not prove the identity can read the blob, and a storage role alone does not prove the VM can reach the endpoint.<\/p>\n

The NSG and ASG control-design model<\/a> shows how effective rules and platform defaults differ from a simple firewall sketch. A useful negative test is an intentional denied network attempt from a source that should not be permitted. Record whether the block was produced by an NSG, a route, endpoint policy or a data-plane authorization check rather than treating all failures as equivalent.<\/p>\n

Phase 5 \u2014 configure monitoring with a measurable signal<\/h3>\n

Before creating alerts, decide what operational symptom the team actually needs to detect. For a test VM, CPU percentage can provide a familiar numeric metric; for an application, a specific failure counter may be more useful. Choose an alert rule’s intended resource scope, signal, threshold, aggregation and evaluation settings, then attach an action group owned by the team responsible for responding. Avoid putting real personal contact information into public examples.<\/p>\n

Microsoft’s current action-group workflow includes a portal test feature. Where supported, first test the notification channel separately using a sample alert type, then validate the actual rule against an appropriately generated or observed signal. An action-group test establishes a route can deliver a sample action; it does not prove that a real metric threshold evaluates as expected or that a human will investigate the incident.<\/p>\n

Check whether any alert processing rule could suppress actions for the chosen scope or maintenance window. A fired alert can remain visible even when notification actions are intentionally suppressed. The action group and alert processing workflow<\/a> explains how to trace a missing notification through the fired alert, notification configuration, overlapping processing rules and the destination’s actual response.<\/p>\n

Save a short record with the observed signal value, alert state, timestamp, selected action group, attempted delivery and operational response. If the test alert does not fire, investigate the threshold and evaluation interval. If it fires but nothing arrives, investigate the actions and processing rules rather than changing the underlying metric to hide the problem.<\/p>\n

Phase 6 \u2014 add backup only when the recovery task and costs are clear<\/h3>\n

An optional extension protects the test VM through the supported Recovery Services vault workflow. Microsoft documents creating the vault, selecting a supported backup policy, enabling protection for the VM, triggering an initial backup and checking the job and recovery point. Actual restore capabilities and vault choices depend on the workload and subscription; a Backup vault should not be substituted for a Recovery Services vault without verifying feature support.<\/p>\n

A real backup exercise must describe what is being restored. Restoring the VM, recovering individual files, or rebuilding an app in another region may require different procedures. If cost, regional support or insufficient permissions prevent a full restore test, record that limitation and treat recovery as not yet verified<\/em> instead of reporting the job’s green status as proof of business continuity.<\/p>\n

The backup vault and restore planning model<\/a> explains why recovery policies, vault security, restored dependencies and application-level verification need separate owners. Do not leave a trial backup vault with retained recovery points unnoticed when deleting the resource group. Understand the service’s stop-protection and deletion controls before cleanup.<\/p>\n

Use a results matrix to separate configuration from evidence<\/h3>\n

The central learning artifact is a short matrix comparing intended behavior with observed results. An administrator who can say \u201cthe VM was created\u201d has demonstrated less than one who can say \u201cthis specific identity was denied outside scope, the protected blob was restored to the expected content, the intended network path worked and the alert reached the right team.\u201d The evidence should still distinguish a live observation from a planned test that was not performed.<\/p>\n\n\n\n\n\n\n\n\n\n
AZ-104 domain<\/th>\nExpected test<\/th>\nEvidence to collect<\/th>\nFailure question<\/th>\n<\/tr>\n<\/thead>\n
Identity and governance<\/td>\nApproved role works only in its intended scope<\/td>\nAssignment and allowed\/denied-operation result<\/td>\nWas access inherited or granted at a broader scope?<\/td>\n<\/tr>\n
Storage<\/td>\nTest blob can be read and prior content restored<\/td>\nVersion identity and verified current object content<\/td>\nIs the block due to data permission, network, retention or version choice?<\/td>\n<\/tr>\n
Compute<\/td>\nVM meets the planned size, disk and identity conditions<\/td>\nVM configuration, health state and known cost<\/td>\nIs the failure VM lifecycle, managed identity or an application dependency?<\/td>\n<\/tr>\n
Virtual networking<\/td>\nPermitted path works and a disallowed path fails<\/td>\nSource\/destination, route and effective NSG rule<\/td>\nDid the wrong DNS answer or policy cause the outcome?<\/td>\n<\/tr>\n
Monitoring and recovery<\/td>\nAlert detects intended condition and action reaches its owner<\/td>\nSignal, fired alert, delivery result and backup evidence where applicable<\/td>\nDid detection fail, notification fail or an alert processing rule suppress it?<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

A report should identify where the environment differs from the example. If the user cannot create a VM because of a subscription quota, that is a real administration constraint to document. If the test identity has unexpectedly broad access, investigate and stop before attempting an unsafe negative test. If a storage account’s hierarchical namespace means versioning is unsupported, use another supported test account or document the limitation. The purpose is to develop sound operational judgment, not to force all expected checkmarks at any cost.<\/p>\n

Diagnose one deliberately ambiguous outage<\/h3>\n

Imagine that the VM-based application suddenly cannot download the test blob. The storage object exists, the operator sees a healthy VM and the alert has fired. Three plausible causes are a storage account firewall change, a private DNS or route mismatch, or a missing blob data role. A fourth is that the application requests a path or version that does not exist.<\/p>\n

Begin with a timestamp and the actual error. From the VM’s supported diagnostics, verify the storage hostname resolution and intended IP. Check effective routing and the NSG rules for the relevant source and destination. Inspect the storage service’s network restrictions and the exact identity used by the workload; finally compare data roles and the object’s actual path\/version. Do not use a storage account key or disable the firewall as an unexplained shortcut. Changing several controls at once can obscure the original fault.<\/p>\n

The Azure Monitor troubleshooting approach<\/a> asks which evidence can falsify each hypothesis. A timeout, name resolution failure, 403 authorization error or missing blob should lead to different next checks. Record the first layer where expected behavior differs from what the system actually does, then test the smallest safe repair.<\/p>\n

Close out the environment without leaving charges or access behind<\/h3>\n

Before deleting resources, preserve only the learning evidence that does not expose credentials or personal data: anonymized role-scope notes, expected versus actual checks, a clean diagram, generic resource configurations and permitted logs. Remove test files containing any real business information, and follow the organization’s data-retention and security policy rather than copying sensitive content into a personal note.<\/p>\n

Inventory every created resource, including those outside the lab resource group: vaults and retained recovery points, separately provisioned network access services, public IPs, storage accounts, action groups, alert rules, test users, role assignments, and any long-lived keys or SAS tokens. Delete only the resources known to belong to the lab. Do not remove a shared resource group, a broad production role assignment, or a certificate that other applications still use.<\/p>\n

After cleanup, confirm the intended items are gone, supported deleted-data retention behaves as expected, and any remaining charges or recovery objects are documented. Some billing entries arrive later than resource deletion, so a \u201cno resources found\u201d screen cannot prove that final charges are zero. Review costs again after the provider’s reporting delay and close the lab owner record.<\/p>\n

Turn the five-domain scenario into exam readiness<\/h3>\n

The lab should leave the candidate able to answer why an action succeeded or failed. Why can a Contributor create a storage account but still fail to read its blob contents? Why does a healthy peering configuration not guarantee a private endpoint resolves correctly? Why does a geo-redundant storage account still need blob versioning? Why can a fired alert generate no notification? Why does a successful backup job not prove the application can be recovered?<\/p>\n

If these questions remain difficult, repeat only the relevant domain step with a new controlled scenario and observe the result rather than memorizing a sample answer. The strongest evidence of practical Azure administration is being able to predict the effect of a scope, resource state or network configuration, then test that prediction and explain the outcome using records anyone authorized to operate the service can inspect.<\/p>\n

Official exam objectives, Azure product capabilities and supported lab environments can change. Always check the current Microsoft AZ-104 skills-measured guide and first-party service instructions before creating resources or repeating a security-sensitive procedure. This independent learning exercise is not Microsoft exam registration and does not guarantee certification or exam performance.<\/p>\n","protected":false},"excerpt":{"rendered":"

An administrator is asked to deploy a small internal application environment in Azure. The work looks simple on a diagram: one resource group, a virtual machine, a storage account, a network, and an alert. Real operating risk appears between those boxes. Who can change the resources? Can the VM reach the data while unwanted clients […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1045],"tags":[],"class_list":["post-25179","post","type-post","status-publish","format-standard","hentry","category-microsoft"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t