Implement and manage storage: free practice questions

The storage account firewall is configured to allow only the specific Azure virtual network. On-premises clients connecting via Site-to-Site VPN traverse the VPN gateway and arrive at the storage service from the on-premises IP range, which is not in the allowed list. Adding the on-premises IP range (or the gateway subnet if using a private endpoint) to the firewall rules resolves the issue. 'Allow trusted Microsoft services' enables Azure platform services (like Azure Backup) to bypass the firewall — it does not help on-premises clients. Azure Files does support access over Site-to-Site VPN; this is a supported and common connectivity pattern. SMB version mismatch could prevent mounting, but the scenario states on-premises users cannot access the share at all, which points to a network/firewall issue rather than an SMB protocol negotiation failure.

Blob versioning automatically creates and retains a new version of a blob each time it is overwritten or deleted. This requires no custom scripting; Azure manages version creation transparently. An administrator can restore a previous version by copying it over the current version. Blob snapshots are read-only copies of a blob at a specific moment, but they must be created manually or via a lifecycle policy that only moves/deletes them — snapshots are not created automatically on every overwrite. Container soft delete retains deleted containers, not overwritten blobs. Point-in-time restore for block blobs allows restoration of a container or account to a prior state but requires blob versioning or change feed to be enabled first — it is a higher-level recovery mechanism, not the feature that 'automatically captures overwrites'.

Blobs in the archive tier are stored offline and cannot be read directly. They must first be rehydrated (moved or copied) to an online tier (hot or cool). Standard-priority rehydration can take up to 15 hours, while high-priority rehydration typically completes in under 1 hour for objects under 10 GB. Copying to a new storage account is not required; rehydration can be done within the same account. Archived blobs cannot be read with any type of SAS token because the data is offline — the SAS grants permission but the data is not accessible until rehydrated. Deleting and re-uploading from a backup is unnecessary and destructive if a backup is not readily available.

The Storage Blob Data Contributor role grants the managed identity permissions to read, write, and delete blobs in the container — which is exactly what is needed for nightly uploads — while following the principle of least privilege. Storage Account Contributor is an Azure RBAC management-plane role that allows managing the storage account's configuration (such as settings and access keys) but does not grant data-plane access to read or write blob data. Storage Blob Data Owner grants full control including the ability to set POSIX ACLs (relevant for ADLS Gen2) and is more permissive than required. The Reader role provides read-only access to Azure resource metadata only and does not grant any data-plane blob access.

With GRS, data is replicated asynchronously to the secondary region. This means there is a non-zero Recovery Point Objective (RPO) — typically less than 15 minutes under normal conditions, but not guaranteed to be zero. After a customer-managed failover, the secondary becomes the new primary, but any data that had not yet been replicated to the secondary before the outage will be lost. All blob data is not permanently lost; the data that was successfully replicated to the secondary region remains intact. Azure Storage does not automatically fail back; failback is a separate manual process initiated by the administrator after the original primary region recovers. After failover, the account is downgraded to LRS (not permanently — you can re-enable geo-redundancy), but this is true only temporarily and the account type can be upgraded back to GRS once the new primary is stable.