SnowPro Advanced: Security Engineer Question 207
Single answerDefine and secure ownership of replication and failover group objectsA global security team uses Snowflake Business Critical accounts in AWS across two regions. They have created a failover group named FG_SEC to protect security-related databases and account objects. The team wants to ensure that only a tightly controlled role can modify the failover group definition, add or remove objects from it, or initiate failover-related administrative changes. At the same time, they want to avoid relying on ACCOUNTADMIN for routine operations. Which approach best meets these requirements?
- A
Create a custom role such as FAILOVER_GRP_OWNER, transfer OWNERSHIP of FG_SEC to that role, and grant that role only to the small set of administrators responsible for replication and failover operations.
- B
Grant USAGE on the databases included in FG_SEC to a custom role, because database-level privileges are sufficient to control who can administer the failover group object.
- C
Grant MONITOR and OPERATE on FG_SEC to a custom role, because these privileges allow the role to change the failover group membership and ownership without needing OWNERSHIP.
- D
Keep FG_SEC owned by ACCOUNTADMIN and grant imported privileges on the SNOWFLAKE database to the security administrators, because imported privileges allow delegated management of failover group objects.
Show answer and explanation
Correct answer: A
Explanation
The key security design principle is that replication groups and failover groups are securable objects whose administration is governed primarily through OWNERSHIP. To define and secure ownership properly, organizations should avoid leaving these objects under broad built-in roles such as ACCOUNTADMIN for normal operations. Instead, transfer OWNERSHIP to a dedicated custom role designed specifically for replication/failover administration, and restrict assignment of that role to a small number of trusted administrators. This aligns with Snowflake best practices around least privilege, separation of duties, and minimizing use of highly privileged system roles. Snowflake documentation on access control and replication/failover group management emphasizes that ownership is the controlling privilege for object administration, while lower-level privileges such as USAGE, MONITOR, or OPERATE do not provide equivalent authority to redefine or secure the object.
- A. Correct.
Correct. In Snowflake, the role with OWNERSHIP on a replication group or failover group controls the object and can manage its definition and administrative lifecycle. Using a dedicated custom owner role follows least-privilege principles and avoids using ACCOUNTADMIN for day-to-day administration. This is the recommended pattern for securing high-impact objects: assign ownership to a narrowly scoped administrative role and grant that role only to authorized personnel.
- B. Incorrect.
Incorrect. Privileges on databases that are included in a failover group do not make a role the administrator of the failover group object itself. A failover group is a separate securable object with its own ownership and privilege model. Granting USAGE on member databases may be necessary for other tasks, but it does not confer the ability to manage the failover group definition.
- C. Incorrect.
Incorrect. MONITOR and OPERATE do not replace OWNERSHIP for object administration. These privileges may allow visibility into status or execution of certain operational actions, but they do not grant full control over the failover group object, such as redefining protected objects or transferring ownership. A common misconception is that operational privileges are equivalent to administrative control; in Snowflake they are not.
- D. Incorrect.
Incorrect. Imported privileges on the SNOWFLAKE database are unrelated to ownership or administration of failover group objects. They are used for accessing shared system data exposed through the SNOWFLAKE database, not for delegated control of securable objects like failover groups. Keeping the object under ACCOUNTADMIN also violates the goal of minimizing routine reliance on powerful built-in roles.