Configure access to storage

Ashcombe Financial has a storage account named stashcombeledger in the East US 2 region. Regulations require that virtual machines in the virtual network vnet-core (also in East US 2) reach the blob endpoint only through a private IP address inside the virtual network, and that the storage account's public endpoint be disabled entirely. The virtual machines use the default Azure-provided DNS.

Which two actions should you perform? Each correct answer presents part of the solution.

1. ACreate a private endpoint in vnet-core for the blob sub-resource of stashcombeledger and set Public network access to DisabledA private endpoint gives the blob service a private IP in the subnet, and disabling public network access ensures that is the only path.
2. BCreate the private DNS zone privatelink.blob.core.windows.net, link it to vnet-core, and register the private endpoint's A record in itWithout the privatelink zone, Azure-provided DNS resolves stashcombeledger.blob.core.windows.net to the public IP, and clients never use the private endpoint.
3. CEnable the Microsoft.Storage service endpoint on the subnet and add the subnet as a virtual network rule on the storage firewallService endpoints keep traffic on the Microsoft backbone but still target the storage account's public IP, which does not satisfy the private-IP and disabled-public-endpoint requirements.
4. DSet Public network access to Enabled from all networks and rely on HTTPS for protectionThis leaves the public endpoint open, which the regulation prohibits.
5. ECreate a private endpoint in vnet-core for the file sub-resource of stashcombeledgerEach storage service has its own sub-resource; a private endpoint for file does not expose the blob endpoint.

Oakridge Analytics uses a container named datasets in the storage account stoakdata. The container already has five stored access policies, one for each client that receives data. A sixth client is onboarded and the administrator attempts to create another stored access policy on the datasets container, but the operation fails. The company wants to continue using stored access policies for revocation and to minimize administrative effort.

What should you do?

1. ACreate the new stored access policy on an individual blob inside the datasets containerStored access policies are defined at the container, file share, queue, or table level; they cannot be created on a single blob.
2. BCreate a second container for the sixth client and define the stored access policy on that containerA container supports a maximum of five stored access policies, so placing the new client's data and policy in a separate container stays within the limit with minimal effort.
3. CUpgrade the storage account to a premium performance tierThe five-policy limit per container applies regardless of performance tier.
4. DEnable the hierarchical namespace on the storage accountThe hierarchical namespace changes how blobs are organized and accessed; it does not change stored access policy limits.

Pellham Consulting has an on-premises AD DS domain synchronized to Microsoft Entra ID. Its consultants use laptops that are joined to Microsoft Entra ID only and work remotely with no VPN; they have no network connectivity to the on-premises domain controllers. The company creates an SMB share named engagements in the storage account stpellhamshare and wants consultants to authenticate to the share with their synchronized user accounts and single sign-on, without deploying any additional domain infrastructure in Azure.

Which authentication method should you enable on the storage account?

1. AOn-premises AD DS authenticationAD DS authentication requires the client to obtain a Kerberos ticket from a domain controller, which these laptops cannot reach.
2. BMicrosoft Entra Domain Services authenticationThis requires deploying a managed domain and joining the clients to it, which adds the domain infrastructure the company wants to avoid.
3. CMicrosoft Entra Kerberos authentication for hybrid identitiesEntra Kerberos lets Entra-joined or hybrid-joined Windows clients obtain Kerberos tickets from Microsoft Entra ID for synchronized (hybrid) users, with no line of sight to domain controllers required for authentication.
4. DShared access signature authentication over SMBSAS tokens are not an SMB authentication mechanism and would not provide user identity or single sign-on.

Grenville Pharma has a storage account named stgrenlab in the North Europe region. An application runs on virtual machines in the subnet app-subnet of the virtual network vnet-lab in the same region, and a lab instrument in the company's Dublin office uploads results from the public IP address 203.0.113.40. The security team requires that no other source be able to reach the storage account endpoints, and the solution must use the storage account's built-in network controls.

What should you configure?

1. ASet Public network access to Enabled from selected virtual networks and IP addresses, add app-subnet as an allowed virtual network, and add 203.0.113.40 as an allowed IP addressThe storage firewall accepts virtual network rules (which register a Microsoft.Storage service endpoint on the subnet) and public IP rules, and denies everything else by default once enabled.
2. BSet Public network access to Enabled from selected virtual networks and IP addresses and add the private address range 10.20.0.0/16 of vnet-lab as an IP ruleIP network rules accept only public IP ranges; private (RFC 1918) addresses are rejected, and the subnet must instead be added as a virtual network rule.
3. CAssociate a network security group with the storage account that allows app-subnet and 203.0.113.40Network security groups attach to subnets and network interfaces, not to storage accounts.
4. DLeave Public network access set to Enabled from all networks and restrict access by assigning Azure RBAC roles only to the application's identityRBAC controls who is authorized but does not block network reachability, so it does not meet the requirement that other sources cannot reach the endpoints.