Developers need a copy of the payments database with realistic-looking data for testing. Card numbers must keep their length and format so validation code still works, but developers must not see real card numbers. Which technique best fits this need?
Select an answer to reveal the explanation.
Short Explanation
Masking is like a stunt double: same build, same costume, but not the real star. The test data looks and behaves like card numbers, so your validation code still runs, yet nobody sees the real ones. Suppression and hashing protect the data too, but they break the format your developers need.
Full Explanation
Data masking replaces sensitive values with fictitious but realistic substitutes that preserve format, length and sometimes check-digit validity, so applications and tests behave as they would with real data while the original values are hidden. Static masking is typically applied when creating a non-production copy, so the real card numbers never reach the test environment at all. Transparent data encryption protects files at rest, but anyone querying the test database through the engine sees decrypted real card numbers, which violates the requirement. Suppression withholds or removes the values entirely, so validation code and any feature that depends on the column cannot be exercised. One-way hashing hides the original value, but it produces a digest of a fixed length and character set unlike a card number, breaking format-dependent validation and tests. Exam caveat: some masking methods, such as tokenization with a stored mapping, are reversible by design; for test data, a non-reversible substitution is usually preferred, and masked copies still need access control. Operational check: after refreshing the test copy, run a query comparing a sample of masked values against production to confirm none match, and run the application's card validation tests to confirm the format still passes.