A Lakehouse holding culturally restricted oral-history transcripts carries a sensitivity label indicating restricted donor content. Compliance is surprised to find that an analyst with edit permission on the item was still able to modify the transcript data despite the label. What explains this?
Select an answer to reveal the explanation.
Short Explanation
A sensitivity label is a classification tag, not a lock on the door — it tells you and downstream systems 'handle with care,' but stopping someone from editing still comes down to the actual permissions granted on the item, which the label doesn't touch by itself.
Full Explanation
A sensitivity label's job is to classify an item and, where configured, trigger protections such as encryption when data is exported — it is not an access-control mechanism that restricts editing, and it doesn't override or interact with the item's existing edit permissions. So an analyst who already holds edit permission on the Lakehouse retains that ability regardless of any label applied, which is exactly the surprising-but-expected behavior compliance observed; nothing was misconfigured. The label being 'applied incorrectly' is a plausible-sounding but wrong diagnosis, since labels aren't designed to gate edit rights in the first place — reissuing it would change nothing. The claim that labels automatically revoke edit permission describes a capability sensitivity labels don't have; permissions and labels are separate systems that must each be configured deliberately. OneLake data access roles govern data-level read access through OneLake and have no special relationship that lets them 'override' labels for editing — the two features don't interact that way. The correct remediation, if editing should be restricted, is to adjust the item's own item-level or object-level permissions for that analyst, independent of the label.