Exam Certified Data Engineer Professional topic 1 question 46 discussion

suretly E

Secret redaction Storing credentials as Databricks secrets makes it easy to protect your credentials when you run notebooks and jobs. However, it is easy to accidentally print a secret to standard output buffers or display the value during variable assignment.

Answer D. dbutils.secrets.get(scope="myScope", key="myKey") retrieves the plain text value of a secret, which is then available for use in code. Limitation: Once the secret is retrieved, if improperly handled (e.g., logged or iterated), its plain text value can be exposed. Option E: The REST API can list secrets in plain text if proper credentials (e.g., a personal access token) are provided. This is unrelated to dbutils.secrets.get but is a valid limitation of the overall secrets management framework in Databricks. Note that the difference between Option D or E is if it is a limitation related to Databricks Utilities Secret (dbutils.secrets), in this case option D is the correct option.

Cannot be option E as it justs lists the Secret value. It does not print the content therein

value = dbutils.secrets.get(scope="myScope", key="myKey") for char in value: print(char, end=" ") Out: y o u r _ v a l u e

Only through REST API or CLI you can fetch the secret if you have valid token

E: https://docs.databricks.com/api/azure/workspace/secrets/listsecrets GET /api/2.0/secrets/list won’t list secrets in plain text. D: if print it without iterating it in a for loop the output is kind of encrypted where it is showing [REDACTED]. But, if I do it as shown in the screenshot, I'm able to see the value of the secret key. https://community.databricks.com/t5/data-engineering/how-to-avoid-databricks-secret-scope-from-exposing-the-value-of/td-p/12254 https://docs.databricks.com/en/security/secrets/redaction.html Secret redaction for notebook cell output applies only to literals. The secret redaction functionality does not prevent deliberate and arbitrary transformations of a secret literal.

Both D and E seems correct. They are poorly written thought because for D just printing the characters (not separated by spaces, newlines or something) would not work, while E if launched inside databricks workspace would not work neither.

D is correct

D is for sure correct (tried it several times on a Databricks environment).

D is correct

D is correct

At least E is a correct answer. B: You can't see secrets in Admin console. Only via REST API, CLI etc. C: Secrets are. not stored in Hive Metastore. D: I am not sure if iterating through secret character by character would work? E: This is at least correct. Using this.

B and E both seems to be correct: https://community.databricks.com/t5/data-engineering/how-to-avoid-databricks-secret-scope-from-exposing-the-value-of/td-p/12254/page/2

For sure it's D

Answer is E: /api/2.0/secrets/get { "key": "string", "value": "string" } The REST API can potentially expose secrets in plain text if a user with appropriate permissions (including access to both secrets/list and secrets/get) uses a personal access token.

Iterating through the secrets provides a way to see the secret's password.