SY0-701 Security Program Management and Oversight Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Export the full tickets because the developers need realistic records.

  Why it's wrong here

  Exporting unmodified tickets violates data minimization and least privilege, because full customer records typically contain direct identifiers (names, emails, phone numbers) and possibly financial or health data. Developers only need the ticket structure and the values that trigger the bug, not every personal attribute. Realistic behavior can be preserved using synthetic records or masked fields that retain formatting and relationships while concealing PII. Sharing raw data—even internally—substantially increases breach impact if the copy is lost or accessed by unauthorized staff.

• ✓

  Mask or tokenize the personal data and restrict access to approved testers only.

  Why this is correct

  Masking or tokenizing personal data follows privacy-by-design principles by reducing exposure while preserving enough structure for testing. Limiting access further reduces the chance of improper handling. This approach allows developers to reproduce issues without using unnecessary real customer information, which supports data minimization and secure sharing requirements.

• ✗

  Copy the tickets to a shared cloud drive and protect it with a simple password.

  Why it's wrong here

  Protecting a cloud drive with a simple password provides a single-factor, low-entropy barrier that is vulnerable to brute-force, dictionary, or phishing attacks, and it offers no protection if the drive link is shared or leaked. Such a solution lacks enterprise security controls: no per-user access management, no multi-factor authentication, no data-loss prevention, and often no at-rest encryption with proper key management. It also fails the data minimization requirement because the underlying tickets remain unchanged and fully sensitive in the shared copy, creating a standing data-exposure risk that is not addressed by the password alone.

• ✗

  Remove the account numbers only and leave the rest of the ticket untouched.

  Why it's wrong here

  Removing account numbers only is an incomplete de-identification effort because names, email addresses, phone numbers, and free-text ticket comments still constitute personal data that can directly or indirectly identify customers. Even if those explicit identifiers were redacted, quasi-identifiers such as zip code, service tier, and complaint details can be combined with external datasets to re-identify individuals. Defensible privacy preservation requires tokenization or pseudonymization of all direct and indirect identifiers, plus a restricted access policy, rather than ad hoc redaction of a single field. Partial redaction also fails to address unstructured data where sensitive values like SSNs or medical details may appear in notes.