COF-C03 Data Collaboration Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Run ALTER SHARE ... ADD ACCOUNTS = <consumer_account> with a REVOKE keyword to flip the account's access off.

  Why it's wrong here

  The ADD ACCOUNTS clause only adds consumers; it has no revoke modifier. There is no syntax that adds an account and simultaneously denies it. Removing access for an existing consumer is done with the REMOVE ACCOUNTS clause, which performs the opposite operation on the share's account list.

• ✗

  Run REVOKE USAGE ON DATABASE <shared_db> FROM SHARE <share_name> to detach the consumer account.

  Why it's wrong here

  USAGE grants on the shared database are made to the share, not to individual consumer accounts, so revoking from a share name in that form does not target a consumer. Removing one consumer from a multi-consumer share requires altering the share's account list, not revoking database privileges that other consumers depend on.

• ✗

  Run DROP SHARE <share_name> and recreate it immediately, re-adding every consumer except the one to be excluded.

  Why it's wrong here

  Dropping the share destroys the share object and its grants, disrupting all consumers and requiring full reconstruction. The requirement is to remove a single consumer while preserving the share and grants for others, so a drop-and-recreate approach causes needless outage and risk of misconfiguration.

• ✓

  Run ALTER SHARE ... REMOVE ACCOUNTS = <consumer_account> so only that account loses access while the share and its grants remain unchanged.

  Why this is correct

  REMOVE ACCOUNTS deletes the account-to-share association for the named consumer only. The share object and all grants on its objects persist, so other consumers are unaffected. The removed account can no longer create a database from the share, and its existing shared database loses access on the next access attempt.