Technical Lab: Create and Configure Storage Accounts
Questions
Question 1 — Multiple Choice
A data team needs to store log files with frequent access in the first 30 days and rare access after that period. Storage cost is a central concern, but the team doesn't want to manage manual file movement.
Which combination of default access tier and lifecycle management feature best meets this requirement?
A) Create the account with Hot default tier and configure a lifecycle management policy to move blobs to Cool after 30 days
B) Create the account with Cool default tier and configure a lifecycle management policy to move blobs to Hot in the first 30 days
C) Create the account with Hot default tier and enable versioning to automatically control cost after 30 days
D) Create the account with Archive default tier and configure a lifecycle management policy to move blobs to Hot in the first 30 days
Question 2 — Technical Scenario
A developer executes the following command to create a storage account:
az storage account create \
--name mystorage \
--resource-group rg-prod \
--location eastus \
--sku Standard_LRS \
--kind StorageV2 \
--allow-blob-public-access false
After creation, they try to access a blob via public URL and receive a 403 error. The manager states that the container was created with anonymous access enabled at the container level.
What is the correct cause of the error?
A) The --kind StorageV2 parameter doesn't support anonymous blob access
B) The Standard_LRS SKU automatically blocks any external access
C) The --allow-blob-public-access false parameter disables anonymous access at the account level, making the container configuration irrelevant
D) The container needs to be recreated with the --public-access blob flag after account creation
Question 3 — True or False
A storage account configured with GRS (Geo-Redundant Storage) redundancy allows applications to read data from the secondary region at any time, without the need for failover.
Question 4 — Technical Scenario
A company needs only resources within a specific VNet to access a storage account. The administrator configures the storage account firewall to deny all public traffic and adds the desired subnet to the virtual network rules.
After configuration, resources in the VNet still receive connection denied errors.
AuthorizationFailure: This request is not authorized to perform this operation.
What is the most likely cause?
A) The storage account firewall only works with BlobStorage accounts, not StorageV2
B) The Service Endpoint for Microsoft.Storage was not enabled on the subnet before adding it to the storage account network rules
C) The VNet rule requires the storage account to be in the same region as the compute resources
D) VNet access is only supported when redundancy is configured as ZRS or higher
Question 5 — Multiple Choice
When comparing the storage account types available in Azure, which statement correctly describes a relevant functional difference between StorageV2 (General Purpose v2) and BlobStorage?
A) BlobStorage supports queue storage (Queue Storage) and tables (Table Storage), while StorageV2 is restricted to blobs
B) StorageV2 supports all storage services (Blob, File, Queue, Table), while BlobStorage supports only blobs, without Azure Files support
C) BlobStorage exclusively offers the Archive access tier, while StorageV2 only offers Hot and Cool tiers
D) StorageV2 doesn't support lifecycle management policies, requiring BlobStorage for this feature
Answer Key and Explanations
Answer Key — Question 1
Answer: A
The correct configuration is to start with the Hot tier to ensure performance in the first 30 days and use lifecycle management to automatically move data to Cool after that period. This combination meets the cost requirement without requiring manual intervention.
- Alternative B reverses the logic: setting the default as Cool and trying to automatically warm data at the beginning is not the behavior supported by lifecycle policies, which move blobs to cooler tiers, not warmer ones.
- Alternative C confuses versioning with cost management by tier, completely distinct concepts.
- Alternative D is technically unfeasible: the Archive tier requires rehydration (hours to days) for any read, making it unsuitable for data accessed frequently in the first 30 days.
Answer Key — Question 2
Answer: C
The --allow-blob-public-access false parameter acts at the storage account level and functions as a global switch: regardless of how individual containers are configured, no anonymous access will be allowed. The container configuration becomes inoperative in this scenario.
- Alternative A is false:
StorageV2normally supports anonymous access when enabled at the account level. - Alternative B is false: the SKU defines data redundancy, not access policies.
- Alternative D describes a valid step under normal conditions, but doesn't solve the problem while public access is disabled at the account level.
This behavior is relevant in audit and compliance scenarios, where disabling at the account level ensures protection even against incorrect configurations in individual containers.
Answer Key — Question 3
Answer: False
GRS asynchronously replicates data to a secondary region, but this region is read-only only after a failover is initiated, either manually or by Azure. For continuous reading from the secondary region without failover, you need to use RA-GRS (Read-Access Geo-Redundant Storage), which is a distinct variant.
Confusing GRS with RA-GRS is a common mistake that can result in high availability architectures with incorrect assumptions about geographic read availability.
Answer Key — Question 4
Answer: B
For a subnet to be used in the virtual network rules of a storage account, the Service Endpoint for Microsoft.Storage must be enabled on that subnet. Without it, VNet traffic is not recognized as originating from within the virtual network by the Azure Storage control plane, resulting in access denial even with the rule configured.
- Alternative A is false: StorageV2 is fully compatible with VNet rules.
- Alternative C is false: storage accounts and VNets can be in different regions with Service Endpoint enabled.
- Alternative D is false: the redundancy type has no relation to virtual network restriction functionality.
Answer Key — Question 5
Answer: B
StorageV2 (General Purpose v2) is the account type recommended by Microsoft precisely because it supports all services: Blob, Azure Files, Queue, and Table Storage, plus all access tiers (Hot, Cool, Archive). BlobStorage is a legacy type focused exclusively on block blobs and append blobs, without support for Azure Files, queues, or tables.
- Alternative A reverses the behavior: it's BlobStorage that has reduced scope, not StorageV2.
- Alternative C is false: both types support all three access tiers (Hot, Cool, Archive) for blobs.
- Alternative D is false: lifecycle management is supported in StorageV2 and is, in fact, the most common scenario for its use.