Exam Professional Data Engineer topic 1 question 179 discussion

D is the answer. https://cloud.google.com/dlp/docs/pseudonymization#supported-methods Format preserving encryption: An input value is replaced with a value that has been encrypted using the FPE-FFX encryption algorithm with a cryptographic key, and then prepended with a surrogate annotation, if specified. By design, both the character set and the length of the input value are preserved in the output value. Encrypted values can be re-identified using the original cryptographic key and the entire output value, including surrogate annotation.

Why other options are not as suitable: A (Cryptogenic tokens and locked-down bucket): While this provides some protection, storing the non-tokenized data in a separate bucket adds complexity and risk. B (Redaction and locked-down bucket): Redaction removes sensitive data entirely, which might limit its usefulness for analysis and other purposes. C (Scanning and masking in BigQuery): This approach might be less efficient than masking the data during the streaming process before it reaches BigQuery.

I would like to go with D. If the data could be deindentified later by the token, why should we store the data in a locked-down bucket?

D> Looks more suitable as it will handle Referential integrity. https://cloud.google.com/dlp/docs/pseudonymization

answer A https://cloud.google.com/dlp/docs/transformations-reference Replaces an input value with a token, or surrogate value, of the same length using AES in Synthetic Initialization Vector mode (AES-SIV). This transformation method, unlike format-preserving tokenization, has no limitation on supported string character sets, generates identical tokens for each instance of an identical input value, and uses surrogates to enable re-identification given the original encryption key.

D is correct.

I've also asked to GPT but I had to remind the hard condition "names and emails are often used as join keys". It changed the answer to "B" after 3rd iteration. masking all PII data may not satisfy the requirement of using names and emails as join keys, as the data is obfuscated and cannot be used for accurate join operations. In this approach, you would redact or remove the sensitive PII data, such as names and emails, from the dataset that will be used for real-time processing and analysis. The redacted data would be stored in the primary dataset to ensure that sensitive information is not accessible. Additionally, you would create a copy of the original dataset with the PII data still intact, but this copy would be stored in a locked-down bucket with restricted access. This ensures that authorized individuals who need access to the unredacted data for specific purposes, such as join operations, can retrieve it from the secured location.

gpt: The recommended approach for using the Cloud Data Loss Prevention API (DLP API) to protect sensitive PII data while maintaining referential integrity is to create pseudonyms by replacing the PII data with cryptographic format-preserving tokens. This approach ensures that sensitive data is not accessible by unauthorized individuals, while still preserving the format and length of the original data, which is essential for maintaining referential integrity. Replacing PII data with cryptogenic tokens, as mentioned in option A, is not recommended because cryptogenic tokens are not necessarily format-preserving, and this could affect the accuracy of data joins. Therefore, option D is the best approach for using the DLP API to ensure that PII data is not accessible by unauthorized individuals while still maintaining referential integrity.

here catch is "cryptographic" key

Answer D, key word - "referential integrity" use format preserve option, it keeps same length of the value and last four digits of your value in column

The answer is D

I believe "Format preserving token" in option D makes it easier choice for me

D looks right

Question is super tricky, B and C are not the answers since they do not maintain referential integrity. For D, it does preserve the length of input. But since we are only concerned with referencing during joins, there is no point of maintaining the length anyway. Also, characters must be encoded as ASCII, this means that the name and email must be within the 256 character set. which is further limited to the alphabet characters, i.e. 94 characters. (https://cloud.google.com/dlp/docs/transformations-reference#crypto) Names nowadays do not just have ASCII characters but unicode as well, so D will not necessarily work all the time.

D is the answer Pseudonymization is a de-identification technique that replaces sensitive data values with cryptographically generated tokens. Keywords: You want to ensure that the sensitive data is masked but still maintains referential integrity Part1- data is masked-Create a pseudonym by replacing PII data with a cryptographic token Part 2 still maintains referential integrity- with a cryptographic format-preserving token A Not an answer because the locked-down button does not seem to google cloud word

Though both option A nad D maintains referential integrity,question is why you wnat to keep untokenize data in GCS,best way is option D which even support Reversible feature which is not supported by option A refer chart in reference document. reference:- https://cloud.google.com/dlp/docs/pseudonymization

It's D. "You want to ensure that the sensitive data is masked but still maintains referential integrity." They don't ask you to also keep the original data (which answer A relates to). Also, format-preservation is important in this case.