ADA-C01 Question 513
Single answerAnalyze the impact of replication on access controlsA global company uses Snowflake database replication to maintain a secondary account in another region for disaster recovery. The primary account contains a production database with several schemas, tables, and secure views. Access to these objects is managed through database roles that are granted to account roles in the primary account. During a failover test, administrators notice that users in the secondary account cannot access the replicated database objects even though the objects themselves are present. Which action should the administrators take to ensure the replicated access model works as expected after failover?
- A
Recreate the database roles in the secondary account and grant them directly to users after each refresh or failover.
- B
Grant the replicated database roles to appropriate account roles in the secondary account, because database roles can replicate with the database but account-level role grants do not.
- C
Enable replication for the SECURITYADMIN role so that all grants to users and roles are included with the database replication.
- D
Convert all database roles to account roles before replication, because only account roles are preserved consistently across replicated databases.
Show answer and explanation
Correct answer: B
Explanation
This scenario tests the distinction between database-scoped access controls and account-scoped access controls during replication and failover. In Snowflake, database roles belong to the database and can replicate with that database. However, account roles, users, and grants that connect database roles to account-level principals are not automatically solved by database replication alone. As a result, after failover, the replicated objects may exist but remain inaccessible until the replicated database roles are granted to appropriate account roles in the secondary account.
This aligns with Snowflake best practices for cross-region/cross-account replication and failover planning: design object privileges with database roles when possible, and explicitly plan how those database roles will be mapped to account roles in each participating account. Candidates should recognize that replication preserves certain database-contained security metadata, but not the entire account-level access control framework.
- A. Incorrect.
Incorrect. Database roles are contained within the database and can be replicated with the database. Recreating them manually in the secondary account is unnecessary and error-prone. The real issue is typically that account-level grants, such as grants of database roles to account roles, users, or other account principals, are not automatically established in the target account by database replication alone.
- B. Correct.
Correct. In Snowflake, database roles are database objects and can be included as part of database replication/failover groups, but account roles and user mappings are account-level constructs. After replication or failover, administrators must ensure the replicated database roles are granted to the correct account roles in the secondary account so users inherit the expected privileges. This is a key consideration when analyzing replication's impact on access controls.
- C. Incorrect.
Incorrect. Snowflake does not support replicating an account role such as SECURITYADMIN in the way described to carry all user/role grants with a replicated database. Account-level security objects and relationships are managed separately from database replication. Choosing this option reflects a common misconception that database replication includes the full account security model.
- D. Incorrect.
Incorrect. Database roles are specifically designed to encapsulate privileges within a database and are useful for replicated databases. Converting them to account roles is not required and would reduce the portability of the access model. Account roles themselves are not part of the replicated database object set in the manner implied here.