Front-line ticketing analysts at a national museum need to review visitor payment records but should see donor and visitor credit-card numbers only as a partially obscured value, such as the last four digits, while the finance team continues to see full numbers. Which feature should the team apply to the card-number column?

Dynamic data masking lets an engineer apply a masking function — full, partial, or a custom pattern — to a specific column so that most querying principals see an obscured value while a designated group (typically granted the UNMASK permission or belonging to an exempted role) continues to see the real data. Applying a partial mask to the card-number column satisfies exactly this: analysts get enough of the number to do their job (like confirming the last four digits against a receipt) without exposure to the full value, while finance keeps full visibility. Column-level security via DENY would block the column outright for analysts, which is stricter than the requirement — they need a partial view, not zero view. A sensitivity label classifies the item and can drive downstream protections like encryption on export, but it doesn't itself transform what a query returns. Object-level security operates on the whole table, not a single column, so it can't selectively obscure just the card-number field. Operationally, the team should query the table as both an analyst and a finance account and confirm the analyst sees a masked pattern while finance sees the unmasked value.