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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 5easymultiple choice

You are reviewing the data protection settings of an Azure Blob Storage container using the above JSON. Which of the following is true?

Exhibit

Refer to the exhibit.

```json
{
  "properties": {
    "isVersioningEnabled": true,
    "deleteRetentionPolicy": {
      "enabled": true,
      "days": 7
    },
    "restorePolicy": {
      "enabled": true,
      "days": 30
    }
  }
}
```

Trap 1: Deleted blobs are retained for 30 days

This statement is incorrect because the delete retention policy for this storage account is configured for 7 days, not 30 days. Soft delete retains deleted blobs, snapshots, and versions only for the specified retention window, which is 7 days in this scenario. After that period, soft-deleted items are permanently purged and cannot be recovered.

Trap 2: Blobs can be restored to any point within the last 7 days

This statement is incorrect because the point-in-time restore policy for this account is set to a maximum of 30 days, not 7 days. Point-in-time restore allows you to roll back blob data to an earlier state within that 30-day window, but it does not limit recovery to the last 7 days. This option confuses the restore policy duration with the soft-delete retention period.

Trap 3: Versioning is disabled

This statement is incorrect because the property isVersioningEnabled is set to true, which explicitly indicates that blob versioning is enabled, not disabled. If versioning were disabled, the property would be false, and previous blob versions would not be automatically retained. The presence of true confirms that the account is using versioning as part of its data protection strategy.

A
Deleted blobs are retained for 30 days
Why it fails: This statement is incorrect because the delete retention policy for this storage account is configured for 7 days, not 30 days. Soft delete retains deleted blobs, snapshots, and versions only for the specified retention window, which is 7 days in this scenario. After that period, soft-deleted items are permanently purged and cannot be recovered.
B
Blobs can be restored to any point within the last 7 days
Why it fails: This statement is incorrect because the point-in-time restore policy for this account is set to a maximum of 30 days, not 7 days. Point-in-time restore allows you to roll back blob data to an earlier state within that 30-day window, but it does not limit recovery to the last 7 days. This option confuses the restore policy duration with the soft-delete retention period.
C
Previous versions of blobs are retained
This statement is correct because the account has blob versioning enabled (isVersioningEnabled is true). When versioning is enabled, every modification or deletion of a blob creates a new version, and all previous versions are preserved. This allows you to retrieve or restore an earlier version of a blob at any time, independent of soft-delete or point-in-time restore policies.
D
Versioning is disabled
Why it fails: This statement is incorrect because the property isVersioningEnabled is set to true, which explicitly indicates that blob versioning is enabled, not disabled. If versioning were disabled, the property would be false, and previous blob versions would not be automatically retained. The presence of true confirms that the account is using versioning as part of its data protection strategy.

Question 6hardmultiple choice

A multinational company uses Microsoft Entra ID with a custom domain. They need to implement a governance strategy for Microsoft 365 groups, ensuring that group expiration policies are enforced and that group owners receive renewal notifications. What should you configure?

Trap 1: Microsoft Purview compliance portal – Data Lifecycle Management

Microsoft Purview compliance portal – Data Lifecycle Management is designed to govern the retention and deletion of organizational data across Microsoft 365 services like SharePoint, OneDrive, and Exchange. It applies retention labels and policies to files and messages, but it has no mechanism for configuring group expiration or automatically deactivating Microsoft 365 groups. Therefore, while it manages the lifecycle of data content, it does not manage the lifecycle of the groups that contain that data, making it irrelevant to the requirement for group expiration.

Trap 2: Microsoft Intune – Device compliance policies

Microsoft Intune – Device compliance policies are used to enforce security and compliance requirements on managed devices, such as requiring a minimum OS version, setting a device PIN, or detecting jailbroken/rooted devices. These policies are evaluated against devices and their results feed into conditional access and zero-trust decisions. Intune operates at the device layer and has no visibility or control over the existence, provisioning, or expiration of Microsoft 365 groups. Thus, it cannot be used to configure group expiration policies, making it an incorrect answer for this requirement.

Trap 3: Microsoft Sentinel – Analytics rules

Microsoft Sentinel – Analytics rules are part of a cloud-native SIEM and SOAR solution that collects security telemetry from various sources to detect and respond to threats. Analytics rules use KQL queries to generate alerts on suspicious activities such as anomalous sign-ins or potential data exfiltration. Sentinel is focused exclusively on security monitoring and incident response, not on administrative lifecycle management of Microsoft 365 groups. Configuring group expiration is an identity governance task, not a security analytics task, so Sentinel is not a valid place to set up group expiration policies.

A
Microsoft Purview compliance portal – Data Lifecycle Management
Why it fails: Microsoft Purview compliance portal – Data Lifecycle Management is designed to govern the retention and deletion of organizational data across Microsoft 365 services like SharePoint, OneDrive, and Exchange. It applies retention labels and policies to files and messages, but it has no mechanism for configuring group expiration or automatically deactivating Microsoft 365 groups. Therefore, while it manages the lifecycle of data content, it does not manage the lifecycle of the groups that contain that data, making it irrelevant to the requirement for group expiration.
B
Microsoft Entra ID – Group settings (Expiration policy)
Microsoft Entra ID – Group settings (Expiration policy) is the correct administrative location because Microsoft 365 group expiration is a tenant-level policy that is enforced by Microsoft Entra ID. In the Entra admin center, you navigate to Identity > Groups > Group settings and configure the 'Expiration policy' to set a fixed validity period (e.g., 180 or 365 days) for all Microsoft 365 groups, with the option to send renewal notifications to group owners. This policy directly controls group lifecycle by automatically expiring inactive groups, and it can also be managed via Microsoft Graph or PowerShell (New-UnifiedGroupExpirationPolicy). This is the native mechanism provided by Microsoft for this exact scenario.
C
Microsoft Intune – Device compliance policies
Why it fails: Microsoft Intune – Device compliance policies are used to enforce security and compliance requirements on managed devices, such as requiring a minimum OS version, setting a device PIN, or detecting jailbroken/rooted devices. These policies are evaluated against devices and their results feed into conditional access and zero-trust decisions. Intune operates at the device layer and has no visibility or control over the existence, provisioning, or expiration of Microsoft 365 groups. Thus, it cannot be used to configure group expiration policies, making it an incorrect answer for this requirement.
D
Microsoft Sentinel – Analytics rules
Why it fails: Microsoft Sentinel – Analytics rules are part of a cloud-native SIEM and SOAR solution that collects security telemetry from various sources to detect and respond to threats. Analytics rules use KQL queries to generate alerts on suspicious activities such as anomalous sign-ins or potential data exfiltration. Sentinel is focused exclusively on security monitoring and incident response, not on administrative lifecycle management of Microsoft 365 groups. Configuring group expiration is an identity governance task, not a security analytics task, so Sentinel is not a valid place to set up group expiration policies.

Question 7hardmultiple choice

A company stores petabytes of image files for a content delivery network. The images are accessed frequently for the first week, then rarely afterward. They must be retained for 5 years for compliance. The company wants to minimize storage costs while maintaining performance for frequently accessed data. Which storage solution and tier strategy should they recommend?

Trap 1: Azure Files with premium tier

Azure Files Premium tier uses SSD-backed shares designed for low-latency SMB access, not for serving petabytes of static image objects via HTTP to a content delivery network; it lacks native CDN integration and object-level tiering to cold storage. This option tempts because Premium tier offers high IOPS for frequently accessed files, which suits a shared file system for active workloads, but the scenario demands blob-based storage with lifecycle management to archive rarely accessed data after one week.

Trap 2: Azure Data Lake Storage Gen2 with hot tier only

Azure Data Lake Storage Gen2 provides a hierarchical namespace on top of Blob Storage, but selecting it with a hot-tier-only configuration is wrong for this scenario because it abandons the lifecycle management benefit that the question demands. While ADLS Gen2 does support tiering policies, the specified option locks all petabyte-scale image data in the hot tier for 5 years, incurring roughly 3–5x the storage cost of Cool tier with zero access after the first week. Moreover, the hierarchical namespace is not needed for CDN origin serving of immutable images and would only add operational complexity without improving HTTP delivery performance.

Trap 3: Azure Blob Storage with archive tier from day 1

Setting the default access tier to Archive from day 1 is wrong because Archive tier is designed for rarely accessed data with retrieval times measured in hours and a per-GB retrieval charge that makes frequent reads extremely costly. In the first 7 days, the images will be actively fetched by the CDN or end users, so placing them directly in Archive would force expensive and slow rehydration operations for every cache miss. A lifecycle policy should instead start the blobs in Hot to handle the high initial demand and only move them to Cool (or later Archive) after the access pattern drops, which is why this option fails the cost and performance requirements.

A
Azure Blob Storage with a lifecycle policy: Hot for 7 days, Cool for the remainder of 5 years
This is correct because Azure Blob Storage is optimized for serving large volumes of static objects over HTTP/S to Azure CDN or Front Door, and its lifecycle management feature automates movement between access tiers based on blob age. Setting a rule for Hot for 7 days matches the period of heavy read traffic, after which transitioning to Cool for the remaining 5 years dramatically reduces storage cost while still providing sub-second latency for occasional access. The lifecycle policy evaluates each blob's last modification date and enforces the tier change without manual intervention, exactly fitting a cost-sensitive archive-with-fast-recent-access pattern.
B
Azure Files with premium tier
Why it fails: Azure Files Premium tier uses SSD-backed shares designed for low-latency SMB access, not for serving petabytes of static image objects via HTTP to a content delivery network; it lacks native CDN integration and object-level tiering to cold storage. This option tempts because Premium tier offers high IOPS for frequently accessed files, which suits a shared file system for active workloads, but the scenario demands blob-based storage with lifecycle management to archive rarely accessed data after one week.
C
Azure Data Lake Storage Gen2 with hot tier only
Why it fails: Azure Data Lake Storage Gen2 provides a hierarchical namespace on top of Blob Storage, but selecting it with a hot-tier-only configuration is wrong for this scenario because it abandons the lifecycle management benefit that the question demands. While ADLS Gen2 does support tiering policies, the specified option locks all petabyte-scale image data in the hot tier for 5 years, incurring roughly 3–5x the storage cost of Cool tier with zero access after the first week. Moreover, the hierarchical namespace is not needed for CDN origin serving of immutable images and would only add operational complexity without improving HTTP delivery performance.
D
Azure Blob Storage with archive tier from day 1
Why it fails: Setting the default access tier to Archive from day 1 is wrong because Archive tier is designed for rarely accessed data with retrieval times measured in hours and a per-GB retrieval charge that makes frequent reads extremely costly. In the first 7 days, the images will be actively fetched by the CDN or end users, so placing them directly in Archive would force expensive and slow rehydration operations for every cache miss. A lifecycle policy should instead start the blobs in Hot to handle the high initial demand and only move them to Cool (or later Archive) after the access pattern drops, which is why this option fails the cost and performance requirements.

Question 8hardmulti select

A company wants to ensure that their Azure Storage account containing blobs is protected against accidental deletion or corruption. The solution must enable recovery of previous versions up to 30 days. Which TWO features should they enable? (Choose TWO.)

Trap 1: Change feed

The change feed is a transactional log that records create, update, and delete events at the blob level, but it captures only metadata about the operation, not the blob content itself. It enables event-driven processing or analytical pipelines, yet it provides no mechanism to roll back to a prior state or recover data, so it cannot serve as a data protection feature.

Trap 2: Azure Backup for Azure Blobs

Azure Backup for Azure Blobs is a managed, policy-driven backup service that delivers operational backup with point-in-time restore capabilities, but it requires you to provision a Backup Vault, select a policy, and pay separate charges. It also internally depends on native blob versioning and soft delete, so it is not the same as enabling those data protection features directly on the storage account.

Trap 3: Point-in-time restore for Azure Files

Point-in-time restore for Azure Files is a feature scoped exclusively to Azure file shares, relying on file share snapshots to roll back share contents or individual files. Since the scenario pertains to an Azure Storage account containing blobs, this option addresses the wrong storage workload and cannot protect blob data from accidental deletion or modification.

A
Blob versioning
Blob versioning automatically captures the state of a blob each time it is modified, preserving an accessible copy of every previous version in the same storage account. If the current blob is accidentally overwritten or corrupted, you can promote a prior version to restore the blob without relying on a separate backup service.
B
Blob soft delete
Blob soft delete safeguards blobs from accidental deletion by holding them in a recoverable soft-deleted state for a configurable retention period. While versioning preserves the history of changes, soft delete specifically addresses delete operations and permits you to undelete a blob or its versions before the retention window expires.
C
Change feed
Why it fails: The change feed is a transactional log that records create, update, and delete events at the blob level, but it captures only metadata about the operation, not the blob content itself. It enables event-driven processing or analytical pipelines, yet it provides no mechanism to roll back to a prior state or recover data, so it cannot serve as a data protection feature.
D
Azure Backup for Azure Blobs
Why it fails: Azure Backup for Azure Blobs is a managed, policy-driven backup service that delivers operational backup with point-in-time restore capabilities, but it requires you to provision a Backup Vault, select a policy, and pay separate charges. It also internally depends on native blob versioning and soft delete, so it is not the same as enabling those data protection features directly on the storage account.
E
Point-in-time restore for Azure Files
Why it fails: Point-in-time restore for Azure Files is a feature scoped exclusively to Azure file shares, relying on file share snapshots to roll back share contents or individual files. Since the scenario pertains to an Azure Storage account containing blobs, this option addresses the wrong storage workload and cannot protect blob data from accidental deletion or modification.

Question 9mediummultiple choice

A company uses Microsoft Entra ID (Microsoft Entra ID). They need to automate the process of granting users access to a specific application only during business hours and revoking it automatically. The access should be based on a request-approval workflow. Which Microsoft Entra ID feature should they use?

Trap 1: Privileged Identity Management (PIM)

Privileged Identity Management (PIM) is designed for just-in-time privileged access to Microsoft Entra ID roles and Azure resources, such as Global Administrator or Azure RBAC roles. It does not manage or automate assignment of access to standard applications or resources like SharePoint sites or SaaS apps. While PIM supports time-bound activations and approvals, its scope is limited to high-privilege administrative roles, not end-user resource access packages.

Trap 2: Conditional Access

Conditional Access is an evaluation engine that enforces policies at sign-in time based on conditions like user location, device compliance, or risk signals. It can block, require MFA, or restrict session access, but it never grants or removes Entra ID assignments to applications. The requirement is to automate provisioning and deprovisioning of access, which Conditional Access cannot do because it is purely a real-time access enforcement layer.

Trap 3: Access Reviews

Access Reviews provide a recurring workflow for human reviewers to confirm or deny existing access assignments. They are useful for attestation and auditing, but the initial assignment and the automatic revocation are not fully automated by the review process itself. Access Reviews require an administrative or reviewer decision and they do not handle the request-approval lifecycle or scheduled expiration that entitlement management policies provide.

A
Privileged Identity Management (PIM)
Why it fails: Privileged Identity Management (PIM) is designed for just-in-time privileged access to Microsoft Entra ID roles and Azure resources, such as Global Administrator or Azure RBAC roles. It does not manage or automate assignment of access to standard applications or resources like SharePoint sites or SaaS apps. While PIM supports time-bound activations and approvals, its scope is limited to high-privilege administrative roles, not end-user resource access packages.
B
Conditional Access
Why it fails: Conditional Access is an evaluation engine that enforces policies at sign-in time based on conditions like user location, device compliance, or risk signals. It can block, require MFA, or restrict session access, but it never grants or removes Entra ID assignments to applications. The requirement is to automate provisioning and deprovisioning of access, which Conditional Access cannot do because it is purely a real-time access enforcement layer.
C
Access Reviews
Why it fails: Access Reviews provide a recurring workflow for human reviewers to confirm or deny existing access assignments. They are useful for attestation and auditing, but the initial assignment and the automatic revocation are not fully automated by the review process itself. Access Reviews require an administrative or reviewer decision and they do not handle the request-approval lifecycle or scheduled expiration that entitlement management policies provide.
D
Entitlement Management
Entitlement Management is the correct tool because it enables administrators to create access packages that bundle resources like groups, apps, and SharePoint sites with request and approval policies. These policies support time-limited assignments, expiration dates, and automatic revocation of access when the entitlement expires. It also integrates with connected organizations and access reviews, providing a complete automated identity governance lifecycle for internal and external users.