ADA-C01 Question 455
Single answerManage data providers and consumersA company publishes a secure data share from its Snowflake account to several external customers. One customer reports that after creating a database from the share, they can query shared tables but a dashboard that depends on a secure view in the share fails with an error indicating the underlying objects cannot be resolved. The provider account recently reorganized schemas and moved some base tables used by the secure view. The provider wants to restore access for all consumers without granting direct access to the base tables. What should the administrator do?
- A
Recreate or replace the secure view so that its definition references the current fully qualified base objects, then ensure the share includes the database and schema that contain the secure view
- B
Grant IMPORTED PRIVILEGES on the consumer database to the provider role so the secure view can resolve the moved tables across accounts
- C
Convert the secure view to a regular view and add the underlying base table schemas directly to the share so consumers can resolve dependencies
- D
Ask each consumer to recreate their database from the share because view definitions are cached when the shared database is first created
Show answer and explanation
Correct answer: A
Explanation
This scenario tests provider-side management of Snowflake Secure Data Sharing. When a provider shares a secure view, consumers access that view through a database created from the share, but the object dependencies are still maintained in the provider account. If the provider moves or renames underlying objects, the secure view definition can become invalid and must be updated by the provider. Best practice is to share secure views rather than underlying tables when the provider needs to mask implementation details or restrict direct access. IMPORTED PRIVILEGES applies to consumer roles using a shared database, not to repairing provider-side dependencies. Snowflake documentation on secure data sharing and secure views emphasizes that secure views are supported for sharing and that providers manage the shared object definitions in their own account.
- A. Correct.
Correct. In a data sharing scenario, consumers can query secure views exposed through a share, but the secure view definition in the provider account must remain valid. If base tables were moved or renamed, the secure view can break because its referenced objects no longer resolve. The fix is to update or recreate the secure view so it points to the current objects. The provider can continue exposing only the secure view through the share, preserving abstraction and limiting access to underlying tables.
- B. Incorrect.
Incorrect. IMPORTED PRIVILEGES is granted in the consumer account to roles that need to use objects in a database created from a share. It is not a mechanism for the provider to resolve broken object references in a secure view, and it does not grant cross-account object resolution back to the provider.
- C. Incorrect.
Incorrect. Regular views are not the recommended mechanism for securely exposing derived shared data because secure views are specifically designed to protect underlying logic and support secure data sharing patterns. Adding base table schemas to the share would also expose more than the provider wants, violating the requirement to avoid direct access to the underlying tables.
- D. Incorrect.
Incorrect. A consumer does not need to recreate the database from the share to pick up a corrected secure view definition. Shares expose live metadata and data from the provider. Once the provider fixes the secure view in the shared objects, consumers can use the updated object without rebuilding the shared database.