← AZ-104: Azure administration in production
12 / 17 · 40 MIN

Storage replication, delegation and restoration

Distinguish copying, version identity, authorization and recovery granularity.

Replicated population

Block blob object replication requires compatible account types, versioning on both accounts and source change feed. A new rule ignores blobs predating its creation by default; configure time scope when history is required. Success for new objects does not establish delivery of the older population.

The destination assigns its own version IDs: equal content does not guarantee equal cross-account identifiers. Confirm the object and version the consumer actually expects.

Recovery scope

Blob soft delete and container soft delete protect different operations. To recover content in a preserved deleted container, first restore the whole container. Do not promise selective restore directly from a still-deleted container.

On hierarchical-namespace accounts, soft delete does not capture the overwrite in these exercises. Increasing retention after the incident does not create history never captured. Seek another recoverable copy and distinguish account availability from recovery of correct state.

Share and path authorization

For identity-based SMB access, ordinary Storage File Data SMB Share Contributor does not bypass a directory’s Windows ACL. Check both controls. Privileged roles and key access follow different rules and are outside that example.

Default share permission can exceed a specific Reader assignment; the lower assignment does not automatically reduce access. Analyze the ACL after determining share authorization, without adding these mechanisms as if they were equivalent RBAC roles.

Delegation and data acceptance

Two service SAS tokens referencing the same stored access policy share its revocation effect. Prepare separate access when only one partner must lose access. For a temporary failure, compare start and expiry times and clocks before broadening permissions.

Finally, authorized upload establishes a storage operation, not content validity. In the ingestion exercise, check schema, types, file identity and consumer invariants before publishing data.

IN PRACTICE

A copy contains today’s blobs but lacks history required by a report. Before activating the consumer, reconcile the population, identify destination versions and validate a sample against the contract. Replication status does not replace those delivery criteria.

Common pitfalls

Do not confuse redundancy with logical recovery, valid SAS with valid contents, or equal names with equal versions.

Related topics: Templates, modules and intended state · Machines, disks and effective capacity

Take this idea with you

Usable delivery needs the correct population, bounded authorization and an identified recoverable state.

Create account

References

Azure is a trademark of the Microsoft group of companies. bigsavant.com is an independent preparation platform and is not affiliated with, associated with, sponsored, authorised or endorsed by Microsoft. Content and questions are original, are not official exam questions, and completing our tests does not award or guarantee any certification. Names are used only to identify the subject. All other trademarks belong to their respective owners.