A user named 'DATA LOADER is responsible for loading data into a table named 'ORDERS' in the 'PUBLIC' schema of the 'SALES DB' database. Initially, 'DATA LOADER had the 'INSERT' privilege on the 'ORDE

Question

Options

• ARevoke the 'SELECT privilege from 'DATA_LOADER on the 'ORDERS' table.
• BRevoke the 'INSERT privilege from and grant the ` APPLY MASKING POLICY privilege instead.
• CNo change is required, as 'INSERT privilege alone does not grant access to view existing data.
• DCreate a view on the "ORDERS' table that excludes all columns, grant 'SELECT on the view to
• ERevoke the 'INSERT privilege from 'DATA LOADER and grant the 'WRITE privilege instead.

• A
  13% (5)
• B
  5% (2)
• C
  77% (30)
• D
  3% (1)
• E
  3% (1)

Explanation

Option C is correct because the INSERT privilege is narrowly scoped - it grants only the ability to add new rows to a table, not to read or query existing data. Since DATA_LOADER never had SELECT privilege, the audit requirement is already satisfied by the current configuration, and no change is needed.

Why the distractors fail:

• A is wrong because you cannot revoke a privilege the user never had - SELECT was never granted to DATA_LOADER, so revoking it accomplishes nothing.
• B is wrong because APPLY MASKING POLICY controls how data is displayed to users who already have SELECT; it has no relevance to controlling insert-only access.
• D is a needlessly complex workaround - creating a view with no columns and granting SELECT on it solves a problem that doesn't exist.
• E is wrong because WRITE is not a standard SQL or Snowflake privilege; INSERT is already the correct and specific privilege for loading data.

Memory tip: Think of SQL privileges as separate keys on a keyring - INSERT is the "drop-box" key (put things in) and SELECT is the "reading room" key (take things out). Having one does not give you the other. If the audit only finds the drop-box key, there's nothing to fix.

No community discussion yet for this question.