A company is going to use an Amazon Aurora PostgreSQL DB cluster for an application backend. The DB cluster contains some tables with sensitive data. A Database Specialist needs to control the…

Question

Options

• AUse AWS IAM database authentication and restrict access to the tables using an IAM policy.
• BConfigure the rules in a NACL to restrict outbound traffic from the Aurora DB cluster.
• CExecute GRANT and REVOKE commands that restrict access to the tables containing sensitive
• DDefine access privileges to the tables containing sensitive data in the pg_hba.conf file.

• B
  4% (1)
• C
  87% (20)
• D
  9% (2)

Explanation

Explanation

Controlling table-level access in PostgreSQL is achieved through native SQL commands - specifically GRANT (to assign privileges) and REVOKE (to remove privileges) - which allow a Database Specialist to precisely define which users or roles can perform operations (SELECT, INSERT, UPDATE, DELETE) on specific tables containing sensitive data. This is the standard PostgreSQL approach for granular, object-level access control within the database engine itself.

Why the distractors are wrong:

• Option A is incorrect because AWS IAM database authentication handles connection-level authentication (who can connect to the database), not table-level authorization within the database schema.
• Option B is incorrect because NACLs are network-layer controls that manage traffic in/out of subnets - they have no awareness of database objects like tables.
• Option D is incorrect because pg_hba.conf (Host-Based Authentication) controls which hosts and users can connect to the PostgreSQL instance, not what they can access once connected.

Memory Tip: Think of it in layers - NACLs and pg_hba.conf guard the door (network/connection), IAM holds the key (authentication), but GRANT/REVOKE controls what's inside each room (table-level authorization). For object-level permissions, always go native SQL.

No community discussion yet for this question.