AZ-104 Scenario Questions: How to Read and Answer Them (2026)

VM1 runs Windows Server in Subnet1 of VNet1 and has a public IP address. NSG1 is associated with Subnet1¹ and has an inbound rule, priority 100, that allows TCP 3389 from 203.0.113.0/24. NSG2 is associated with the network interface of VM1² and has an inbound rule, priority 200, that denies TCP 3389 from the Internet service tag³. VNet1 is peered with VNet2 in West Europe⁴. An administrator must connect to VM1 by using RDP from the public IP address 203.0.113.10⁵. The company plans to deploy Azure Bastion next quarter⁶. Each option is one solution from a Yes/No series. Decide whether it would meet the goal⁷ on its own.

1. 1Keyword. Inbound traffic is evaluated by the subnet NSG first. Rule 100 already allows 203.0.113.10, so this layer is not the problem.
2. 2Keyword. Traffic that passes NSG1 is then evaluated by the NIC NSG. Both NSGs must allow it, so look here next.
3. 3Constraint. 203.0.113.10 is an internet address, so this deny matches it. Any fix must beat priority 200 in NSG2 or remove this rule.
4. 4Noise. Peering carries traffic between VNets. An RDP session from a public address never crosses it, so ignore it.
5. 5Constraint. Fixes the source. It sits inside NSG1's allowed range and inside NSG2's Internet tag, which tells you exactly which layer blocks it.
6. 6Noise. A future service cannot be part of today's solution. Bastion would avoid public RDP, but it does not exist yet in this scenario.
7. 7Qualifier. In a Yes/No series the bar is binary: the solution alone must make the connection work. A correct first step is still a No.

1. AAdd an inbound rule to NSG1 with priority 110 that allows TCP 3389 from 203.0.113.10.OutNo. NSG1 already allowed this traffic through rule 100. The packet still reaches NSG2, where the priority 200 deny matches. It fixes a layer that was not broken.
2. BAdd an inbound rule to NSG2 with priority 150 that allows TCP 3389 from 203.0.113.10.AnswerYes. NSG1 allows the traffic through rule 100, then NSG2 evaluates priority 150 before the 200 deny. Processing stops at the first match, so RDP is allowed.
3. CAdd an inbound rule to NSG2 with priority 300 that allows TCP 3389 from 203.0.113.10.OutNo. Lower numbers are processed first. The priority 200 deny matches before rule 300 is reached, and processing stops at the first match.
4. DDissociate NSG1 from Subnet1.OutNo. Without NSG1 the traffic goes straight to NSG2, which still denies it at priority 200. It also removes filtering for every other VM in Subnet1.

The lesson: In a Yes/No series the same scenario repeats with a new solution and you cannot go back, so test each solution alone against the full inbound path (subnet NSG, then NIC NSG) and answer No to anything that fixes only one layer.

Contoso stores scanned invoices as block blobs in a general-purpose v2 storage account configured for geo-redundant storage (GRS)¹. Invoices are read often during the first 30 days², then rarely. After 90 days, an invoice must be available to an auditor within 24 hours³ of a request, and it must be kept in the lowest-cost tier that meets that window⁴. Invoices must be deleted seven years after upload⁵. A line-of-business app uploads about 3,000 invoices each day⁶. You need to implement the data lifecycle. The solution must minimize administrative effort⁷.

1. 1Keyword. Looks like background but decides two options: Archive is supported on LRS, GRS and RA-GRS accounts, while smart tier requires zone-redundant storage.
2. 2Constraint. New invoices must stay in an online tier that is cheap to read. Anything that puts them straight into Archive fails here.
3. 3Constraint. Standard-priority rehydration from Archive can take up to 15 hours for blobs under 10 GB, so Archive is allowed after day 90.
4. 4Constraint. Archive has the lowest storage cost. Because the 24-hour window allows it, any design that stops at Cool or Cold fails this constraint.
5. 5Constraint. Needs an automatic delete about 2,555 days after creation. Lifecycle management rules can tier and delete using the same creation-time condition.
6. 6Noise. Volume changes the bill, not the design. A lifecycle rule applies to every matching blob regardless of how many there are.
7. 7Qualifier. Prefer a built-in policy that Azure runs for you daily over a script or runbook you must schedule, secure and maintain.

1. ASet the account's default access tier to Smart, and add a lifecycle management rule that deletes blobs 2,555 days after creation.OutSmart tier requires zone-redundant storage, and this account is GRS. Smart tier also moves data only between hot, cool and cold, so it never reaches Archive and fails the lowest-cost constraint.
2. BUpload new invoices directly to the Archive tier, and add a lifecycle management rule that deletes blobs 2,555 days after creation.OutFails 'read often during the first 30 days'. Archived blobs are offline; every read needs a rehydration that can take hours, and moving them out within 180 days adds early-deletion charges.
3. CCreate an Azure Automation runbook that runs daily, sets each blob's tier based on its age, and deletes blobs older than seven years.OutCould meet every technical requirement, but you have to build, schedule, secure and maintain it. A lifecycle management policy does the same work natively, so the qualifier eliminates this.
4. DCreate a lifecycle management rule that moves blobs to Cool 30 days after creation, to Archive 90 days after creation, and deletes them 2,555 days after creation.AnswerKeeps new invoices in Hot, reaches the lowest-cost tier the 24-hour window allows, deletes at seven years, and Azure runs it automatically once a day. GRS supports Archive.

The lesson: 'Minimize administrative effort' only ranks options that already pass every constraint, and a detail that looks like background (here, GRS) can be the constraint that decides the answer.