ADA-C01 Question 512
Single answerAnalyze the impact of replication on access controlsA global company uses Snowflake account replication to maintain a secondary account for disaster recovery in another region. In the primary account, the SECURITYADMIN role grants a custom role named ANALYST_READ to several users. ANALYST_READ has SELECT on schemas and tables in a replicated database. After a failover to the secondary account, users report that they can see the replicated database but some of them cannot query objects as expected. The administrator needs to determine how replication affected access control and what must be done to restore the intended access. Which statement best explains the behavior?
- A
Database replication includes all user-to-role grants automatically, so the issue must be caused by warehouse privileges not being replicated with the database.
- B
Privileges granted on objects in the replicated database are replicated, but account-level principals such as users and their role assignments are not replicated as part of database replication, so access must be re-established in the target account.
- C
Failover changes all replicated object ownership to ACCOUNTADMIN in the target account, so custom roles lose their privileges until ownership is transferred back.
- D
Because the database was failed over, all future grants defined in the primary account are removed in the secondary account and must be recreated before any existing object privileges work.
Show answer and explanation
Correct answer: B
Explanation
The practical lesson is that administrators must distinguish between object-level privileges within replicated databases and account-level access control constructs. In Snowflake, database replication/failover is designed to replicate the database and supported metadata, including relevant privileges on replicated objects, but it does not automatically make the target account identical to the source account in terms of users, warehouses, or all account-level grants. As a result, after failover, a user may be able to see a database or a role may still exist conceptually in the access design, yet the user cannot query data unless the target account has the necessary principal configuration and role assignments. This is why disaster recovery planning should include validating roles, user mappings, and required warehouse access in the secondary account. This aligns with Snowflake documentation on replication and failover, which distinguishes replicated database metadata from account-level objects and grants.
- A. Incorrect.
Incorrect. A common misconception is that database replication carries over the entire access model, including users and user-role mappings. In Snowflake, object grants associated with replicated objects can replicate with the database, but account-level entities such as users are not part of database replication. Warehouse privileges are also account-level, but the key issue in this scenario is that user-to-role relationships are not automatically restored by replicating the database alone.
- B. Correct.
Correct. This is the key distinction administrators must understand when analyzing replication and access controls. Replication of a database can include the securable objects and their object-level grants, but users, virtual warehouses, and many account-level grants are outside the scope of database replication. After failover, roles or grants on replicated objects may exist, but users in the secondary account still need the appropriate role assignments there to query data. The administrator must ensure the target account has the necessary principals and grants configured.
- C. Incorrect.
Incorrect. Failover does not broadly reset ownership of all replicated objects to ACCOUNTADMIN. Ownership and privileges on replicated database objects are handled according to Snowflake replication and failover behavior, not by blanket reassignment to ACCOUNTADMIN. This distractor reflects a misunderstanding of how ownership metadata is preserved for replicated objects.
- D. Incorrect.
Incorrect. Future grants are not the reason existing privileges stop working for users after failover. Even if future grants require separate consideration depending on replication scope and subsequent administrative changes, the scenario describes users being unable to query existing replicated objects they can see. That points to missing account-level access control configuration, especially user-to-role grants in the secondary account, not to a blanket removal of future grants.