A company stores application logs as JSON documents in a cloud log service. Email addresses can appear in nested fields whose names differ from one microservice to the next. Which discovery technique is best suited to finding personal data in these logs?
Select an answer to reveal the explanation.
Short Explanation
JSON logs sit halfway between a spreadsheet and a novel: there's structure, but it bends from one service to the next. You walk the keys and values, however deep they're nested, and pattern-match what you find. Don't treat it like a fixed database table, and definitely don't OCR text you can already parse.
Full Explanation
Semi-structured data, such as JSON, XML and many log formats, carries its own structure through tags or key/value pairs but does not conform to a fixed, enforced schema. Fields can be nested, optional or named differently by each producer. Effective discovery parses that self-describing structure, traverses every level of nesting, and applies content inspection such as pattern matching for email address formats to the values, while using key names as hints rather than as the only signal. This combines the efficiency of structure-aware processing with the robustness of content analysis. Reading a relational schema assumes predefined, fixed columns, which is exactly what semi-structured logs lack; differing field names across microservices would be missed. Optical character recognition converts images of text into text; JSON is already machine-readable text and parsers handle nesting routinely, so OCR adds error and cost without benefit. Log services do not automatically tag every record containing personal data, and retention labels govern how long data is kept, not what it contains. Exam caveat: the outline lists structured, unstructured and semi-structured data separately because each needs a different discovery approach. Operational check: run discovery against sample logs from each microservice and confirm nested email fields are detected.