Azure AZ-305: Fabrikam Media: 1.2 PB archive with a 12-hour retrieval promise

Fabrikam Media: 1.2 PB archive with a 12-hour retrieval promise

Fabrikam Media stores 1.2 PB of video masters on an on-premises NAS reachable over a 2 Gbps ExpressRoute circuit. About 40 TB is actively used by rendering nodes every month; the remaining archive is read in roughly 5% of months, but legal requires any asset to be retrievable within 12 hours and kept immutable for three years. The Linux render nodes must mount the working set over NFSv4.1 and will not be changed. Fabrikam must survive the loss of an entire Azure region, and finance wants the archive cost per TB as low as possible. Migration must finish in eight weeks, and the largest single asset is 900 GB.

1. Recommend the storage accounts, service, and protocols for the 40 TB working set and the 1.2 PB archive. Justify the protocol choice against the stated constraint.

Read the worked answer

Two accounts, because the protocols and performance tiers are incompatible.

40 TB working set. The binding constraint is NFSv4.1. Blob NFS speaks NFSv3 only; NFSv4.1 is offered by Azure Files premium (FileStorage account) and by Azure NetApp Files. Since the render nodes cannot be changed, choose premium Azure Files, or Azure NetApp Files if 40 TB of parallel read throughput and latency exceed what a premium file share delivers. Validate per-share IOPS and throughput before committing.
1.2 PB archive. A standard general-purpose v2 account using block blobs on Cool, Cold, and Archive tiers. Enable hierarchical namespace only if analytics over the archive is planned - it changes namespace semantics and disables some features without changing blob pricing.
Size check. A 900 GB asset is well inside both block blob and premium file share limits.
Do not merge them. Premium and standard performance tiers cannot coexist in one account, and the archive needs different replication and immutability settings than the working set.

2. Design the lifecycle and tiering rules. Explain how the 12-hour retrieval requirement constrains which tier the 5%-read data can sit in, and where early-deletion penalties bite.

Read the worked answer

Lifecycle rules do the tiering, but the retrieval SLA decides the floor.

Master rule: base blobs → Cool at 30 days idle → Cold at 90 → Archive at 180. Minimum billable durations are 30 days (Cool), 90 (Cold), and 180 (Archive); tiering a week-old blob to Archive costs more than it saves.
Transient rule: render outputs and proxies → delete at 7 days. Keep them out of the master rule so they never accumulate archive penalties.
The 12-hour promise. Standard-priority rehydration from Archive can take up to 15 hours, which breaches the SLA for large assets. So the frequently-requested body of content should live on Cold (online, millisecond access, still cheap), and Archive should hold only the portion legal never pulls. Where Archive is unavoidable, budget high-priority rehydration as an operational cost.
Versioning and soft delete interact with lifecycle: old versions need their own version-level rule or they accumulate forever, and an immutability policy can block the tier change or deletion a rule attempts. Pilot the rules on a test container before locking a retention policy over them.

3. Specify the redundancy and immutability design that satisfies region-loss survival and a three-year legal hold, and name the governance mistakes to avoid.

Read the worked answer

GZRS for the archive, with a locked container-level retention policy.

Redundancy. GZRS gives zone redundancy in the primary region plus replication to the paired region; RA-GZRS adds read access to the secondary, which matters if the primary region is lost and legal requests an asset during the outage. The 2 Gbps ExpressRoute makes initial seeding the real constraint - plan an Azure Data Box for the bulk and use the circuit for the delta.
Immutability. A container-scoped time-based retention policy of three years, then locked. Locking is irreversible and cannot be shortened by anyone, including a Global Administrator - pilot it first, because a mistake here is permanent. Use a legal hold for specific matters that may need to exceed three years.
Separate planes. Do not give the team that writes video the Storage Account Contributor or data-plane delete rights on the immutable container. Managing the retention policy should be a distinct, rarely-used role.
Mistakes to avoid: relying on soft delete as an immutability control (it is a 14-day safety net, not a legal hold), locking the policy before lifecycle rules are validated, and assuming the secondary region is readable under plain GRS.