A new partner feed combines public product catalog data with customer names, email addresses and order histories. The feed is about to be loaded into a shared analytics area that many analysts can query. What should the DBA do first?
Select an answer to reveal the explanation.
Short Explanation
Think of data classification as sorting the mail before it hits the shared inbox. If you don't flag the personal letters first, everybody reads them. The tempting shortcut is "load now, sort later," and that's exactly how PII ends up in front of people who should never see it.
Full Explanation
Data classification assigns each data element a sensitivity level, such as public, internal, confidential or regulated, based on its content and the obligations attached to it. Performing classification at acquisition time is what allows the right handling to be applied before data is exposed: names, email addresses and order histories tied to individuals are personally identifiable information, so they can be tagged, then masked, tokenized, encrypted or restricted to authorized roles, while the public catalog fields flow to the shared area without extra controls. Loading everything first and classifying later exposes the PII to every analyst in the meantime, which is the exact risk classification is meant to prevent and may breach privacy obligations. Compression is a storage and transfer optimization, not an access control; anyone with ordinary tools can decompress the archive, and analysts still need usable data. Converting JSON to CSV changes the file format only; it does not identify which fields are personal or separate them, and the PII would still be loaded. Exam caveat: classification drives later decisions such as retention, residency, encryption and masking, so it belongs at the start of the integration pipeline, not after loading. Operational check: confirm every column in the feed has a recorded classification in the data dictionary and that PII columns are masked when queried by a non-privileged analyst account.