When Does Content Expiry Apply After a Sensitivity Label Change?
Short answer
B Doc1 expires January 24 because Label1's 21-day content expiry is fixed at label application on January 3; the later change to 28 days is not retroactive.
Question
On January 1, you create the sensitivity label shown in the following table.
On January 2, you publish Label1 to User.
On January 3, User1 creates a Microsoft Word document named Doc1 and applies Label1 to the document.
On January 4, User2 edits Doc1.
On January 15, you increase the content expiry period for Label1 to 28 days.
When will access to Doc1 expire for User2?
Key Takeaways
The exam tests whether content expiry is calculated from label application or from a user's first access; the trap is resetting the clock when User2 edits Doc1 on January 4 or applying the January 15 policy change retroactively.
This SC-401 scenario tests how a sensitivity label's content-expiry setting is fixed when Label1 is applied to Doc1. Because Label1 was applied on January 3 with a 21-day expiry, Doc1 expires for User2 on January 24; the later change to 28 days does not retroactively update the existing document.
Common mistake: The most common wrong choice is C (January 25), because candidates start the 21-day period when User2 first edits Doc1 on January 4. That treats expiry as per-user first-access time, but Label1's content expiry is fixed at application on January 3 and yields January 24.
Expert Analysis
Why the Answer Is Correct
The exhibit's Label1 sets content expiry to 21 days after the label is applied, not after first access. User1 applied Label1 to Doc1 on January 3, so the expiry date baked into Doc1 is January 24 (January 3 plus 21 days). User2's January 4 edit does not restart that clock because content expiry belongs to the protected document, not to each user's first opening. The January 15 increase to 28 days applies to newly labeled or re-labeled content; it does not retroactively rewrite Doc1's existing expiry, so B is the answer.
Why the Other Options Are Wrong
A (January 23) is an off-by-one date that would come from counting from publication on January 2 or mishandling the application date. C (January 25) incorrectly starts the 21-day period at User2's first edit on January 4, even though the label's content-expiry rule is anchored to when the label was applied. D (January 31) wrongly applies the new 28-day value to Doc1 as if the January 15 policy change recalculated existing protection from January 3. The document would need to be re-labeled or re-protected under the updated label setting for the 28-day value to govern.
Community Comment Notes
gabbinu captures the core rule: the expiry period is "stamped into the document at the time the label is applied," and changing the label later does not retroactively update protected content. Eltooth reaches the same January 24 result by counting from Doc1's creation/labeling on January 3 with the original 21-day setting. kollyp2000 notes that label changes can be picked up during authentication after a use license expires, but that does not move this document's content-expiry date for the scenario. MultiCloudIronMan's January 25 rationale treats the RMS license issued at first access as resetting expiry, which conflates use-license issuance with the content-expiry value set when Label1 was applied.
Official Reference
https://learn.microsoft.com/en-us/purview/encryption-sensitivity-labels
This link opens the official vendor documentation in a new tab.
Exam Strategy
For content-expiry questions, anchor the calculation to the date the sensitivity label was applied and use the setting in force at that moment. Don't let a later label-policy edit or another user's first access pull you into recalculating an existing document's expiry.
Frequently Asked Questions
Why doesn't the January 15 change to 28 days extend Doc1's expiry to January 31?
Why isn't User2's first edit on January 4 the start of the 21-day expiry?
Discussion 5 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 5
-
gabbinu 👍 8 Answered BThe expiry period is stamped into the document at the time the label is applied. • Changing the label later does not retroactively update already protected content. • To take effect, the document must be re-labeled. So for Doc1, applied on Jan 3 with a 21-day expiry, the countdown is fixed → expiry = Jan 24.
-
Eltooth 👍 2 Answered BB is correct answer - retention label applies from doc creation I.e. 3rd Jan. plus 21 days =3 weeks Jan 24th.
-
MultiCloudIronMan 👍 1 Answered CThe RMS license is issued at first access, and its expiry is fixed at that moment. If you later change the label’s expiry setting, it does not retroactively update existing RMS licenses. For example: Label1 says “access expires after 21 days.” User2 opens Doc1 on January 4 → RMS license expires January 25. You change Label1 to 28 days on January 15 → User2’s license still expires January 25. Only new accesses or reprotected content will reflect the updated expiry.
-
kollyp2000 👍 1 Answered Bthe clock starts when the label is applied. For labels using “assign permissions now,” changes “will be applied for existing items when users authenticate with the encryption service... However, if users have already opened an encrypted document or email, they won’t get the new settings until their use license has expired and they must reauthenticate.”
-
deeptha92 👍 1 Answered BDocuments already labelled with a sensitivity label will retain the original expiry settings until they reconnect to the service and synchronise with the updated label configuration 1. This would only happen it a user opens the doc.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.