S3 Lifecycle Policy practice questions

A company stores large amounts of log data in Azure Blob Storage. Logs are accessed frequently for the first 30 days, then rarely accessed afterward, but must be retained for 7 years for compliance. The company wants to minimize storage costs. They need to configure automatic data movement and retention policies. Which combination of Azure Blob Storage access tiers and lifecycle management policy should they use?

Trap 1: Use Hot tier for 30 days, then use Cool tier for 7 years, with a…

Using the Cool tier for a seven-year retention period overlooks that Archive tier provides a substantially lower storage price for data that is no longer actively accessed. While the lifecycle rule correctly automates deletion after 7 years, the Cool tier's storage rate is significantly higher than Archive for long-lived, rarely read data, making this solution unnecessarily expensive over the retention period. Since the data is only frequently accessed for the first 30 days, Cool tier is an economically suboptimal middle ground for the remaining 6+ years.

Trap 2: Use Cool tier for 30 days, then use Archive tier for 7 years, no…

Choosing Cool tier for the initial 30 days is cost-inefficient because Cool tier has higher per-GB read and retrieval costs than Hot tier, which already offers the lowest access costs for frequently used data. Additionally, without a lifecycle rule, the data will never be automatically deleted after 7 years, resulting in ongoing storage charges indefinitely. The correct pattern pairs a Hot tier for frequent reads with an Archive tier for infrequent, long-term retention, coupled with a lifecycle policy that deletes the blob at a specific age.

Trap 3: Use Archive tier immediately, with a lifecycle rule to delete after…

Placing data directly into Archive tier fails to account for the high frequency of access during the first 30 days; Archive tier's retrieval latency (typically minutes to hours) and per-GB read charges make it inappropriate for active use. Although the lifecycle rule handles the eventual deletion correctly, immediate archiving would force repeated expensive rehydration operations for the very data users need most often. A tiering strategy must match early access patterns with Hot tier, then transition to Archive only once the data becomes rarely accessed.

A
Use Hot tier for 30 days, then use Cool tier for 7 years, with a lifecycle rule to delete after 7 years.
Why wrong: Using the Cool tier for a seven-year retention period overlooks that Archive tier provides a substantially lower storage price for data that is no longer actively accessed. While the lifecycle rule correctly automates deletion after 7 years, the Cool tier's storage rate is significantly higher than Archive for long-lived, rarely read data, making this solution unnecessarily expensive over the retention period. Since the data is only frequently accessed for the first 30 days, Cool tier is an economically suboptimal middle ground for the remaining 6+ years.
B
Use Hot tier for 30 days, then use Archive tier for the remaining period, with a lifecycle rule to delete after 7 years.
Hot tier provides low-latency access during the frequent access period. Archive tier provides the lowest storage cost for data that is rarely accessed. A lifecycle policy can automatically move data from Hot to Archive after 30 days and delete it after 7 years.
C
Use Cool tier for 30 days, then use Archive tier for 7 years, no lifecycle rule needed.
Why wrong: Choosing Cool tier for the initial 30 days is cost-inefficient because Cool tier has higher per-GB read and retrieval costs than Hot tier, which already offers the lowest access costs for frequently used data. Additionally, without a lifecycle rule, the data will never be automatically deleted after 7 years, resulting in ongoing storage charges indefinitely. The correct pattern pairs a Hot tier for frequent reads with an Archive tier for infrequent, long-term retention, coupled with a lifecycle policy that deletes the blob at a specific age.
D
Use Archive tier immediately, with a lifecycle rule to delete after 7 years.
Why wrong: Placing data directly into Archive tier fails to account for the high frequency of access during the first 30 days; Archive tier's retrieval latency (typically minutes to hours) and per-GB read charges make it inappropriate for active use. Although the lifecycle rule handles the eventual deletion correctly, immediate archiving would force repeated expensive rehydration operations for the very data users need most often. A tiering strategy must match early access patterns with Hot tier, then transition to Archive only once the data becomes rarely accessed.

Question 2mediummultiple choice

A company stores log data in Azure Blob Storage. The logs are accessed frequently for the first 30 days, then only occasionally for up to 1 year, and after that must be retained for 7 years for compliance purposes. The company wants to minimize storage costs by automatically moving data to cheaper tiers. Which Azure Blob Storage lifecycle management policy should they implement?

Trap 1: Move to Cool tier after 30 days, move to Archive tier after 365…

The flaw is not the tier transitions but the deletion expression: '7 years' is not a valid Azure lifecycle numeric value. Azure lifecycle management rules only accept integers for 'days after creation' or 'days after last modification', so the policy would be rejected at validation time. Using '2555 days' is the correct equivalent for 7 years and removes ambiguity around leap-year intervals; therefore this option fails because the rule cannot be executed as written.

Trap 2: Move to Cool tier after 30 days, move to Archive tier after 30…

Moving to Archive after only 30 days violates the intended access pattern: for the first year logs are accessed occasionally, and Cool tier is designed for that exactly—it offers lower storage cost than Hot while still allowing near-real-time reads. Archive, by contrast, requires rehydration and can add minutes to hours of latency before access. If you transition to Archive at day 30, you'll incur unnecessary retrieval and rehydration costs for every one of the occasional accesses during the remaining 335 days, which is more expensive than leaving the data in Cool.

Trap 3: Move to Archive tier after 30 days, keep in Archive until deletion…

Skipping Cool and placing logs into Archive at day 30 means the most frequently used period (the first 30 days) remains Hot, but from day 31 through day 365, when logs are still occasionally queried, you're hit with Archive's rehydration latency and per-GB retrieval charges. Also, once a blob is in Archive it cannot be read directly; you must 'rehydrate' it, adding operational complexity and cost for each access. The correct sequence is Hot→Cool→Archive, so this option misplaces the first-year data and penalizes normal operational workflows.

A
Move to Cool tier after 30 days, move to Archive tier after 365 days, delete after 2555 days
This policy correctly matches the log usage lifecycle: for the first 30 days data remains Hot for frequent queries; from day 30 to day 365 it is moved to Cool because access becomes occasional but still needed; after 365 days it is moved to Archive for long-term compliance while deletion occurs after 2555 days (exactly 7 years). That transition sequence minimizes cost: Hot for active use, Cool for sporadic retrieval with no rehydration fee, and Archive for rarely accessed records, with deletion eliminating any further storage charges. The rule uses numeric day values as Azure requires.
B
Move to Cool tier after 30 days, move to Archive tier after 365 days, delete after 7 years
Why wrong: The flaw is not the tier transitions but the deletion expression: '7 years' is not a valid Azure lifecycle numeric value. Azure lifecycle management rules only accept integers for 'days after creation' or 'days after last modification', so the policy would be rejected at validation time. Using '2555 days' is the correct equivalent for 7 years and removes ambiguity around leap-year intervals; therefore this option fails because the rule cannot be executed as written.
C
Move to Cool tier after 30 days, move to Archive tier after 30 days, delete after 2555 days
Why wrong: Moving to Archive after only 30 days violates the intended access pattern: for the first year logs are accessed occasionally, and Cool tier is designed for that exactly—it offers lower storage cost than Hot while still allowing near-real-time reads. Archive, by contrast, requires rehydration and can add minutes to hours of latency before access. If you transition to Archive at day 30, you'll incur unnecessary retrieval and rehydration costs for every one of the occasional accesses during the remaining 335 days, which is more expensive than leaving the data in Cool.
D
Move to Archive tier after 30 days, keep in Archive until deletion after 2555 days
Why wrong: Skipping Cool and placing logs into Archive at day 30 means the most frequently used period (the first 30 days) remains Hot, but from day 31 through day 365, when logs are still occasionally queried, you're hit with Archive's rehydration latency and per-GB retrieval charges. Also, once a blob is in Archive it cannot be read directly; you must 'rehydrate' it, adding operational complexity and cost for each access. The correct sequence is Hot→Cool→Archive, so this option misplaces the first-year data and penalizes normal operational workflows.

Question 3mediummultiple choice

A company ingests IoT sensor data into Azure Blob Storage. Data is written frequently and is accessed rarely after the first 24 hours. The company must retain the data for exactly 90 days for compliance. They want to minimize storage costs by automatically moving data to the cheapest possible storage tier as soon as possible. Which Azure Blob Storage lifecycle management policy should they implement?

Trap 1: Move to Archive tier after 1 day, delete after 90 days

Selecting Archive after one day seems tempting for cost savings, but the Archive tier imposes a 180-day minimum retention period, so deleting after 90 days triggers an early deletion fee proportional to the remaining 90 days. While Archive has the lowest storage price, that price advantage is erased by this penalty, plus retrieval operations are more expensive and slower than Cool. The data does not need archival-grade long-term storage; it must simply be retained for 90 days, so Cool is the appropriate and cheaper choice.

Trap 2: Move to Cool tier after 30 days, delete after 90 days

Keeping data in the Hot tier for the first 30 days is unnecessary because data is rarely accessed after 24 hours. This results in higher costs for those 29 days compared to moving to Cool after 1 day.

Trap 3: Move to Archive tier after 30 days, delete after 90 days

Keeping the data in Hot for the first 30 days creates unnecessary cost, since the sensor readings are rarely accessed after the first day; this wastes approximately 29 days of Hot-tier pricing. Then moving to Archive for only 60 days still falls short of the 180-day minimum retention requirement, causing an early deletion charge that makes the total cost higher than a straightforward Cool-tier lifecycle. The combination of a Hot wait and an Archive penalty maximizes cost rather than minimizing it.

A
Move to Cool tier after 1 day, delete after 90 days
Moving the sensor data to the Cool tier after just one day aligns lifecycle costs with actual access patterns, since IoT telemetry is typically queried only briefly after ingestion. Cool tier provides significantly lower per-GB storage costs than Hot, and because the retention period of 90 days exceeds Cool's 30-day minimum commitment, no early deletion penalty is incurred. This policy satisfies the compliance requirement to delete after 90 days while minimizing the cost of storing data that is rarely read after the first 24 hours.
B
Move to Archive tier after 1 day, delete after 90 days
Why wrong: Selecting Archive after one day seems tempting for cost savings, but the Archive tier imposes a 180-day minimum retention period, so deleting after 90 days triggers an early deletion fee proportional to the remaining 90 days. While Archive has the lowest storage price, that price advantage is erased by this penalty, plus retrieval operations are more expensive and slower than Cool. The data does not need archival-grade long-term storage; it must simply be retained for 90 days, so Cool is the appropriate and cheaper choice.
C
Move to Cool tier after 30 days, delete after 90 days
Why wrong: Keeping data in the Hot tier for the first 30 days is unnecessary because data is rarely accessed after 24 hours. This results in higher costs for those 29 days compared to moving to Cool after 1 day.
D
Move to Archive tier after 30 days, delete after 90 days
Why wrong: Keeping the data in Hot for the first 30 days creates unnecessary cost, since the sensor readings are rarely accessed after the first day; this wastes approximately 29 days of Hot-tier pricing. Then moving to Archive for only 60 days still falls short of the 180-day minimum retention requirement, causing an early deletion charge that makes the total cost higher than a straightforward Cool-tier lifecycle. The combination of a Hot wait and an Archive penalty maximizes cost rather than minimizing it.

Question 4hardmultiple choice

A company needs to store large amounts of unstructured data (log files) for analytics. The data is accessed frequently for the first 30 days, then occasionally for the next 90 days, and rarely after that but must be retained for 7 years for compliance. The data must not be modified or deleted during the retention period, and administrative access must not be able to bypass this restriction. They want to minimize storage costs. Which combination of Azure Blob Storage features should they configure?

Trap 1: Enable soft delete and versioning on the storage account, and use a…

Soft delete and versioning protect against accidental or malicious deletion only within the configured retention window and do not guarantee immutability—an administrator with delete or overwrite permissions can still purge versions or disable the protection. A custom script that deletes blobs after 7 years is an out-of-band process that can fail due to permissions, service principal expiry, or throttling, and manual tier moves via PowerShell are neither automated nor reliably scheduled, leaving cost management and compliance enforcement to human intervention. In contrast, a locked time-based retention policy prohibits both deletion and overwrites for the entire 7-year period at the container level, and lifecycle management transitions tiers deterministically.

Trap 2: Set each blob's access tier to Cool on upload, then manually change…

Setting the access tier to Cool on upload only affects storage pricing, not data retention or immutability; blobs in the Cool tier can still be overwritten or deleted at any time by an authorized user. Manually changing each blob to Archive after 30 days is not scalable and is prone to mistakes, missed jobs, or incomplete transitions, especially at enterprise scale, whereas lifecycle management applies rules automatically and idempotently. Azure Backup on the storage account creates recovery point snapshots but does not prevent ongoing writes or deletions, nor does it enforce a required retention period—it simply provides point-in-time restore capabilities, so it fails the core compliance requirement of prohibiting any modification for 2,555 days.

Trap 3: Apply a legal hold on the container to prevent deletion, and…

A legal hold prevents deletion of blobs in the container, but it does not block overwrites or modifications—an authorized user can still change the content of an existing blob, which is insufficient for a strict time-based retention requirement. Additionally, legal hold is a manual, discretionary control that must be explicitly removed after the retention period, and nothing enforces that removal at exactly 7 years; it also lacks the automatic, permanent enforcement of a locked time-based retention policy. Configuring a lifecycle policy to move blobs to Archive after 30 days is valid from a cost perspective, but because the legal hold cannot protect against overwrite, the overall solution does not meet the stated need for both deletion and modification protection for 2,555 days.

A
Configure a lifecycle management policy to move blobs to Cool tier after 30 days and to Archive tier after 120 days. Apply a time-based retention policy with a retention period of 2,555 days and lock it.
A locked time-based retention policy on the container ensures that blobs cannot be deleted or overwritten for the specified duration (7 years = 2555 days). Lifecycle management moves blobs to cost-efficient tiers. Locking prevents bypass.
B
Enable soft delete and versioning on the storage account, and use a custom script to delete blobs after 7 years. Manually move blobs to Cool and Archive tiers using Azure PowerShell.
Why wrong: Soft delete and versioning protect against accidental or malicious deletion only within the configured retention window and do not guarantee immutability—an administrator with delete or overwrite permissions can still purge versions or disable the protection. A custom script that deletes blobs after 7 years is an out-of-band process that can fail due to permissions, service principal expiry, or throttling, and manual tier moves via PowerShell are neither automated nor reliably scheduled, leaving cost management and compliance enforcement to human intervention. In contrast, a locked time-based retention policy prohibits both deletion and overwrites for the entire 7-year period at the container level, and lifecycle management transitions tiers deterministically.
C
Set each blob's access tier to Cool on upload, then manually change to Archive after 30 days. Enable Azure Backup on the storage account for retention.
Why wrong: Setting the access tier to Cool on upload only affects storage pricing, not data retention or immutability; blobs in the Cool tier can still be overwritten or deleted at any time by an authorized user. Manually changing each blob to Archive after 30 days is not scalable and is prone to mistakes, missed jobs, or incomplete transitions, especially at enterprise scale, whereas lifecycle management applies rules automatically and idempotently. Azure Backup on the storage account creates recovery point snapshots but does not prevent ongoing writes or deletions, nor does it enforce a required retention period—it simply provides point-in-time restore capabilities, so it fails the core compliance requirement of prohibiting any modification for 2,555 days.
D
Apply a legal hold on the container to prevent deletion, and configure a lifecycle policy to move blobs to Archive after 30 days.
Why wrong: A legal hold prevents deletion of blobs in the container, but it does not block overwrites or modifications—an authorized user can still change the content of an existing blob, which is insufficient for a strict time-based retention requirement. Additionally, legal hold is a manual, discretionary control that must be explicitly removed after the retention period, and nothing enforces that removal at exactly 7 years; it also lacks the automatic, permanent enforcement of a locked time-based retention policy. Configuring a lifecycle policy to move blobs to Archive after 30 days is valid from a cost perspective, but because the legal hold cannot protect against overwrite, the overall solution does not meet the stated need for both deletion and modification protection for 2,555 days.

Question 5mediummulti select

A company is designing a solution for storing sensitive financial records that must be retained for 7 years. The solution must meet the following requirements: - Data must be immutable during the retention period. - After the retention period, data must be automatically deleted. - The solution must minimize storage costs. Which two Azure services should the company use? (Choose two.)

Trap 1: Microsoft Purview Data Map

Microsoft Purview Data Map is a metadata curation and classification service that registers data assets and builds a lineage/glossary, not a storage or retention backend. It cannot enforce time-based deletion or write-once-read-many (WORM) semantics on stored blobs, files, or shares, so it fails to satisfy a storage-level compliance requirement for sensitive financial data.

Trap 2: Azure NetApp Files with replication

Azure NetApp Files replication asynchronously copies volumes to a secondary region to protect against regional outages or hardware failures, but it does not make data immutable or enforce a mandatory retention period. The replica is a normal read-write volume that can be modified, deleted, or overwritten, nor does it provide time-based expiration, so it cannot serve as a compliance deletion or tamper-proof storage solution.

Trap 3: Azure Files with snapshots

Azure Files snapshots are point-in-time, read-only copies of a share used for crash consistency and quick disaster recovery, but they are not immutable in a governance sense—they can be listed, deleted, or restored over by an administrator, and no time-based retention lock is enforced natively. For regulatory data that must be both unalterable and automatically expired, snapshots fall short because they lack WORM semantics and lifecycle-based deletion scheduling.

A
Microsoft Purview Data Map
Why wrong: Microsoft Purview Data Map is a metadata curation and classification service that registers data assets and builds a lineage/glossary, not a storage or retention backend. It cannot enforce time-based deletion or write-once-read-many (WORM) semantics on stored blobs, files, or shares, so it fails to satisfy a storage-level compliance requirement for sensitive financial data.
B
Azure Blob Storage lifecycle management
Azure Blob Storage lifecycle management automatically transitions blobs to Cool, Cold, or Archive tiers and executes user-defined deletion rules based on blob age, last modification, or index tags. For sensitive financial records that must be purged after a regulatory retention window, a lifecycle rule with an 'expire' action removes the blobs at the exact scheduled time, providing a cost-effective, fully managed deletion mechanism without manual cleanup.
C
Azure NetApp Files with replication
Why wrong: Azure NetApp Files replication asynchronously copies volumes to a secondary region to protect against regional outages or hardware failures, but it does not make data immutable or enforce a mandatory retention period. The replica is a normal read-write volume that can be modified, deleted, or overwritten, nor does it provide time-based expiration, so it cannot serve as a compliance deletion or tamper-proof storage solution.
D
Azure Blob Storage with immutable storage policy
Azure Blob Storage immutable storage policies implement write-once-read-many (WORM) governance, blocking any modification or deletion of blobs during a defined retention interval, which is essential for records that must be retained without risk of tampering. The policy can be applied at the container level and supports both time-based retention and legal hold, making it a strong compliance control; however, on its own it will not automatically delete blobs after the retention period unless a separate lifecycle rule is configured.
E
Azure Files with snapshots
Why wrong: Azure Files snapshots are point-in-time, read-only copies of a share used for crash consistency and quick disaster recovery, but they are not immutable in a governance sense—they can be listed, deleted, or restored over by an administrator, and no time-based retention lock is enforced natively. For regulatory data that must be both unalterable and automatically expired, snapshots fall short because they lack WORM semantics and lifecycle-based deletion scheduling.