A library attendance analytics job finds null values in a resident identifier that resembles an SSN under municipal privacy rules. What is the most appropriate next step?
Select an answer to reveal the explanation.
Short Explanation
Null SSN-like IDs are a privacy tripwire, not a reason to invent identifiers or publish rows unchanged. Flag and quarantine the affected rows for governance review, preserving the quality issue while keeping the rows from unsafe use. You can then follow municipal rules; silently dropping rows hides the defect.
Full Explanation
Under municipal privacy and governance rules, null values in an SSN-like resident identifier are a data-quality and compliance event, not a license to fabricate identifiers or publish data. Flag and quarantine the null-ID rows for governance review rather than silently dropping them. Quarantine preserves evidence of the defect, blocks unsafe downstream use, and lets privacy officers decide whether repair, suppression, or an approved transformation is permitted under policy. Replacing missing identifiers with fabricated SSNs creates false personal identifiers, poisons record linkage, and may manufacture unlawful synthetic PII; it does not resolve the missingness or avoid governance review. Publishing the raw null-ID rows unchanged can still expose adjacent attributes, while also putting unreviewed data and quality failures on the public portal. Deleting the entire attendance table destroys the analytic asset and the audit trail needed for legitimate, policy-compliant reporting, rather than addressing the specific issue. Exam caveat: quarantine requires process and technical isolation, such as a separate table, flags, and access controls; a TODO comment in a notebook is not governance. Practical check: flag null IDs, route those rows to a restricted quarantine set, verify they are absent from the public extract, and document the review decision before applying any imputation or drop.