Although the Databricks Utilities Secrets module provides tools to store sensitive credentials and avoid accidentally displaying them in plain text users should still be careful with which credentials are stored here and which users have access to using these secrets.
Which statement describes a limitation of Databricks Secrets?
The Databricks REST API can indeed be used to list secrets in plain text if the personal access token has proper credentials. This means that the security of the secrets is dependent not only on how they are stored but also on the security of the access tokens and the permissions assigned to them. This presents a potential security risk if a personal access token is compromised, which aligns with the limitations described in the question.
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.
D is correct
could be E reference: https://docs.databricks.com/api/workspace/secrets
Answer is D based on Udemy practice test
E is the correct answer because it describes a limitation of Databricks Secrets. Databricks Secrets is a module that provides tools to store sensitive credentials and avoid accidentally displaying them in plain text. Databricks Secrets allows creating secret scopes, which are collections of secrets that can be accessed by users or groups. Databricks Secrets also allows creating and managing secrets using the Databricks CLI or the Databricks REST API. However, a limitation of Databricks Secrets is that the Databricks REST API can be used to list secrets in plain text if the personal access token has proper credentials. Therefore, users should still be careful with which credentials are stored in Databricks Secrets and which users have access to using these secrets.
While Databricks Secrets are designed to secure sensitive information such as passwords and tokens, one limitation is that if a user's personal access token is compromised, and that token has the necessary permissions, the REST API could potentially be used to retrieve secrets. This means that the security of secrets is also dependent on the security of personal access tokens and the permissions assigned to them.
Iterating through the secrets provides a way to see the secret's password.
For sure it's D
D is correct
D is for sure correct (tried it several times on a Databricks environment).
Regarding E, it can list secrets (with scopes) but I am not sure it can list secret contents.
D is correct
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.
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.
D is correct, see https://community.databricks.com/t5/data-engineering/how-to-avoid-databricks-secret-scope-from-exposing-the-value-of/td-p/12254/page/2
you didn't read the entire document, they are also using the get api to print the secret.
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
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.
Only through REST API or CLI you can fetch the secret if you have valid token