Section 3 of 3 · 7 minutes
Test allowed, denied, and recovery access
Your goal
What you will be able to do
Prove the application can do its job, forbidden actions fail, and operators retain recovery access.
Why this matters at work
The practical reason
A grant list is only an intention; connection and query tests show what PostgreSQL will actually allow.
Learn
The idea in plain English
Test as the application role, not as the owner who created the grants. Run one required operation and one operation that must be denied. Record both results.
Before changing authentication or ownership, confirm an operator can still connect through a separate recovery path. Keep that session open until the new access is tested.
Remember these points
- Test using the same role and connection path as the application.
- A denied test is part of the evidence.
- Keep a verified operator route before access changes.
See it in SQL
Inspect object ownership before revoking access
Find the owner who can still control the table after grants change.
SELECT
table_schema,
table_name,
tableowner AS owner_role
FROM pg_tables
WHERE table_schema = 'reports'
ORDER BY table_name;Ownership can allow changes even when ordinary privileges are revoked. Include it in the access review.
Do not transfer ownership as a shortcut unless the new owner and recovery process are explicitly approved.
The owner of each table in the reports schema, ordered by table name.
Useful words
Important terms
- Recovery access
- A tested operator connection kept available while access rules are changed.
Quick check · Not graded
Check your understanding
What is the strongest proof that a least-privilege change is correct?
Your progress is saved to your signed-in account.