A parks dataset mixes public park hours with resident home addresses and phone numbers. Logging currently writes both kinds of fields the same way to CloudWatch. What should developers do first?
Select an answer to reveal the explanation.
Short Explanation
Park hours are the flyer on the community board; home addresses are the locked filing cabinet. Classify first, then treat PII differently in logs — do not dump phones and street numbers beside "sunrise open."
Full Explanation
Applications that mix public park hours with resident home addresses and phone numbers must classify fields before logging. Developers should treat addresses and phones as PII, then redact or omit them from CloudWatch logs rather than writing them the same way as public open-data fields. Classification-first design is foundational for municipal privacy: community-board information can be verbose in logs, while locked-cabinet PII must not become broadly readable log text for operators and integrated log sinks.
Marking every field as public open data because park hours appear in the same JSON document fails because co-location in a payload does not make PII public. Moving all logs to a public-read S3 bucket so classification happens through FOIA requests fails conceptually—it maximizes exposure and is not a classification control. Duplicating PII into every log line for incident response fails because it multiplies sensitive copies outside the source system of record.
Exam caveat: redaction must cover structured fields and free-text that may reintroduce addresses or phones; partial masking that leaves enough digits can still identify residents. Operational check: sample CloudWatch log events after a change window, confirm PII fields are absent or tokenized, and document which roles may access any break-glass unredacted diagnostic path.