Task 2.1: Configure access to storage

• AA route table with a route to the Storage service tag

  Incorrect

  Routes don't authorize a subnet in the storage firewall; the rule depends on the subnet's service endpoint.

• BA service endpoint for Azure Storage on the subnet

  Correct

  A virtual network rule identifies traffic from subnets that have a service endpoint for Microsoft.Storage enabled.

• CA NAT gateway so the VMs leave with a static public IP

  Incorrect

  A NAT gateway changes the outbound public address, which IP network rules match; a virtual network rule needs the subnet's service endpoint instead.

• DA network security group that allows outbound port 443

  Incorrect

  Outbound 443 is allowed by default, and an NSG doesn't identify the subnet to the storage firewall.

Virtual network rules in the storage firewall admit traffic from subnets that have a service endpoint for Azure Storage. Enable the endpoint on the subnet, then add the subnet to the account's network rules.

• AAs account SAS tokens scoped to the Blob service

  Incorrect

  An account SAS can be revoked only by rotating the key that signed it, which breaks every other SAS signed with that key.

• BAs user delegation SAS tokens, revoked through the user delegation keys

  Incorrect

  Revoking user delegation keys invalidates every SAS that relies on those keys, not only the vendor's tokens.

• CAs service SAS tokens with an expiry time of one year

  Incorrect

  A long expiry makes revocation harder; without a policy you'd still have to rotate the key to cut the vendor off.

• DAs service SAS tokens tied to a stored access policy on Intake

  Correct

  Deleting or changing the stored access policy revokes every SAS associated with it, without touching the account keys.

A stored access policy on a container groups the terms of service SAS tokens that reference it. Deleting the policy, renaming its identifier or moving its expiry into the past revokes those tokens.

• AAccount SAS tokens that grant read access

  Incorrect

  An account SAS is signed with the account key, so it's refused once Shared Key authorization is disallowed.

• BService SAS tokens linked to a container's stored access policy

  Incorrect

  A service SAS is signed with the account key whether or not it uses a stored access policy, so it's refused too.

• CUser delegation SAS tokens from a user delegation key

  Correct

  A user delegation SAS is secured with Microsoft Entra credentials, so Blob Storage still accepts it.

• DService SAS tokens restricted to the HTTPS protocol

  Incorrect

  The protocol setting doesn't change how the SAS is signed; it's still Shared Key authorization.

Disallowing Shared Key blocks every request authorized with the account key, including service and account SAS tokens. A user delegation SAS is authorized with Microsoft Entra ID and is still permitted for Blob Storage.

• AStorage File Data SMB Share Contributor

  Correct

  Contributor grants read, write and delete on files and directories at the share level, without the right to modify ACLs.

• BStorage File Data SMB Share Reader

  Incorrect

  Reader grants read access only, so users couldn't write or delete files.

• CStorage File Data SMB Share Elevated Contributor

  Incorrect

  Elevated Contributor also grants modify-ACLs access, which the finance group must not have.

• DStorage File Data Privileged Contributor

  Incorrect

  Privileged Contributor overrides existing ACLs and can modify them, which is far more than the group should get.

Share-level permissions for Azure Files include three SMB Share roles: Reader (read), Contributor (read, write, delete) and Elevated Contributor (adds modify-ACLs). The privileged roles bypass NTFS permissions and are meant for administrators.

• AA SAS expiration policy on the storage account

  Correct

  The policy sets a recommended upper limit for SAS validity, and requests using a longer SAS can be logged or blocked.

• BA stored access policy on each container

  Incorrect

  Stored access policies set terms for SAS tokens that reference them; they don't police other tokens.

• CA lifecycle management rule

  Incorrect

  Lifecycle rules tier or delete blobs; they don't evaluate SAS tokens.

• DA key expiration policy on the storage account

  Incorrect

  A key expiration policy reminds you to rotate account keys; it doesn't check SAS lifetimes.

A SAS expiration policy specifies the upper limit for the validity interval of user delegation, service and account SAS tokens on the account.

• AAdd-AzStorageAccountNetworkRule -ResourceGroupName rg1 -AccountName st1 -IPAddressOrRange "0.0.0.0/0"

  Incorrect

  Adding a rule for every address opens the account further instead of restricting it.

• BUpdate-AzStorageAccountNetworkRuleSet -ResourceGroupName rg1 -Name st1 -DefaultAction Allow

  Incorrect

  Allow is what lets every address in; it's the current state.

• CSet-AzStorageAccount -ResourceGroupName rg1 -Name st1 -EnableHttpsTrafficOnly $true

  Incorrect

  Requiring HTTPS secures transport; it doesn't apply network rules.

• DUpdate-AzStorageAccountNetworkRuleSet -ResourceGroupName rg1 -Name st1 -DefaultAction Deny

  Correct

  Network rules have no effect until the default action is Deny.

Network rules are evaluated only when the default action is Deny. Before you switch, make sure the networks that need access are allowed.

• AUnlimited, but each policy can sign one SAS

  Incorrect

  A policy can back many SAS tokens, and the number of policies is limited.

• BOne policy per container

  Incorrect

  You can define several policies, up to the limit.

• CTen policies per container

  Incorrect

  The limit is lower than ten.

• DFive policies per container

  Correct

  A container, table, queue or share can have at most five stored access policies at a time.

Up to five stored access policies can be set on a container, table, queue or share. Group partners that share terms, or give some of them user delegation SAS tokens instead.

• AAssign Storage File Data SMB Share Contributor on each folder

  Incorrect

  Azure roles apply at the share level; they can't be scoped to folders.

• BMount the share with admin-level access and use icacls or File Explorer

  Correct

  Windows ACLs are configured from a Windows client with icacls or File Explorer after mounting with admin-level access.

• CAdd a stored access policy for each folder

  Incorrect

  Stored access policies apply to SAS tokens on a whole share, not to NTFS permissions on folders.

• DSet the folders' access tier in the storage account

  Incorrect

  Access tiers are a blob storage concept and have nothing to do with permissions.

Share-level permissions come from Azure roles; directory and file permissions are Windows ACLs set with icacls or File Explorer, after mounting with the account key or an identity with admin-level share access.