Memory hook: Network reachability, authorisation and encryption are separate storage controls.
Must remember
- Storage accounts expose supported services such as blobs, files, queues and tables. Choose the account kind/features, Region and redundancy before relying on a capability. Names and endpoints have service-specific scope rules.
- Prefer Entra/managed-identity authorisation where supported. Account keys are broad credentials; rotate them with a staged client update. A SAS delegates selected operations for a time window and resource scope. User-delegation SAS uses Entra-backed delegation for supported Blob access; service/account SAS have different signing and capabilities.
- A stored access policy can centrally control/revoke associated supported service SAS permissions; it does not apply to every SAS type. Time skew, expiry, signed permissions, protocol and network restrictions can explain an otherwise valid token's failure.
- SAS recall: service SAS is signed with an account key and can reference a stored access policy; account SAS is signed with an account key and can cover supported account/service operations; user-delegation SAS is signed with an Entra-backed delegation key for supported Blob access. Stored access policies do not apply to account SAS or user-delegation SAS. Choose scope and revocation requirements before choosing the token type.
- Storage firewalls restrict network access. A service endpoint uses supported service networking and VNet rules; a private endpoint gives a private IP path and requires correct private DNS. Neither substitutes for authorisation. Disable public access deliberately when the requirement demands it.
- LRS replicates within one location; ZRS spans zones in a Region; GRS/GZRS add asynchronous geographic replication; RA variants allow supported secondary reads. Geo-replication lag affects possible data loss. Redundancy is not backup against authorised deletion.
- Storage encryption protects at-rest data; customer-managed keys add key lifecycle and access responsibilities. Object replication between supported blob accounts has prerequisites and scope; it is not a universal synchronisation of every storage service.
- Use Storage Explorer for interactive data management and AzCopy for scripted transfer. Choose an authentication method and validate source/destination permissions; success transferring a subset does not prove the entire dataset reconciles.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Temporary restricted blob access | A suitably scoped SAS, preferably user delegation when it fits. |
| Private IP access from a VNet | Private endpoint plus DNS and data authorisation. |
| Regional AZ resilience without a second Region | ZRS where supported. |
Traps
- A private endpoint does not automatically disable the public endpoint.
- RA-GRS secondary data may lag.
- A management role can lack permission to read stored data.
Active recall
1. What can invalidate a SAS besides its signature?
Expiry/start time, permissions, resource scope, protocol and network restrictions.
2. Does GRS protect against every accidental deletion?
No. Replication can propagate changes; use appropriate versioning/soft delete/backup controls.
3. Why does private DNS matter?
Clients must resolve the service name to the intended private endpoint address.
4. What is the extra responsibility with customer-managed keys?
Key permissions, availability, rotation and recovery/lifecycle.
5. Why reconcile an AzCopy job?
To detect skipped, failed or mismatched objects rather than assuming process completion proves completeness.