A select policy in Supabase controls who can read data from a table. It defines rules to allow or deny read access.
Click to reveal answer
beginner
Why do we need select policies for read access?
Select policies protect your data by ensuring only authorized users can see it, keeping sensitive information safe.
Click to reveal answer
intermediate
How do you write a simple select policy to allow all authenticated users to read data?
You create a policy with a condition like: auth.role() = 'authenticated'. This means only logged-in users can read.
Click to reveal answer
beginner
What happens if no select policy is defined on a table in Supabase?
By default, no one can read data from the table until a select policy is created and enabled.
Click to reveal answer
intermediate
Can select policies be based on row-level conditions?
Yes, select policies can include conditions that check specific row values, allowing fine-grained read access.
Click to reveal answer
What does a select policy in Supabase control?
AWho can delete a table
BWho can read data from a table
CWho can write data to a table
DWho can create new tables
✗ Incorrect
Select policies specifically control read access to data in tables.
If no select policy exists on a table, who can read its data?
AEveryone
BOnly admins
CNo one
DOnly the table owner
✗ Incorrect
Without a select policy, Supabase denies all read access by default.
Which condition allows only logged-in users to read data?
Aauth.role() = 'authenticated'
Bauth.role() = 'anonymous'
Ctrue
Dfalse
✗ Incorrect
The condition auth.role() = 'authenticated' restricts access to logged-in users.
Can select policies restrict access based on specific row data?
AYes, using row-level conditions
BNo, policies apply to whole tables only
COnly for write access
DOnly for delete access
✗ Incorrect
Select policies can include conditions that check row values for fine-grained control.
What is the main purpose of select policies?
ATo speed up queries
BTo create new tables
CTo backup data
DTo secure read access to data
✗ Incorrect
Select policies secure who can read data from your database.
Explain how select policies control read access in Supabase.
Think about who can see data and how rules decide that.
You got /4 concepts.
Describe how you would create a select policy to allow only users to read their own data.
Consider how to match data rows to the logged-in user.
You got /4 concepts.
Practice
(1/5)
1. What is the main purpose of a SELECT policy in Supabase?
easy
A. To control who can read data from a table
B. To control who can write data to a table
C. To create new tables in the database
D. To delete data from a table
Solution
Step 1: Understand the role of SELECT policies
SELECT policies define rules for reading data from tables.
Step 2: Differentiate from other policies
Write policies control data insertion or updates, not reading.
Final Answer:
To control who can read data from a table -> Option A
Quick Check:
SELECT policy = read access control [OK]
Hint: SELECT policies = rules for reading data only [OK]
Common Mistakes:
Confusing SELECT with INSERT or UPDATE policies
Thinking SELECT policies create or delete tables
Assuming SELECT policies control write access
2. Which of the following is the correct syntax to create a read policy allowing all users to select from a table named profiles?
easy
A. CREATE POLICY "Allow all" ON profiles FOR UPDATE USING (true);
B. CREATE POLICY "Allow all" ON profiles FOR INSERT USING (true);
C. CREATE POLICY "Allow all" ON profiles FOR SELECT USING (true);
D. CREATE POLICY "Allow all" ON profiles FOR DELETE USING (true);
Solution
Step 1: Identify the correct command for read access
FOR SELECT is used to allow read (select) operations.
Step 2: Confirm the condition for allowing all users
USING (true) means no restriction, so all users can read.
Final Answer:
CREATE POLICY "Allow all" ON profiles FOR SELECT USING (true); -> Option C
Quick Check:
FOR SELECT + USING (true) = allow all read [OK]
Hint: FOR SELECT + USING (true) allows all reads [OK]
Common Mistakes:
Using FOR INSERT instead of FOR SELECT
Forgetting the USING clause
Using FOR DELETE or UPDATE for read access
3. Given the policy:
CREATE POLICY "User can read own profile" ON profiles FOR SELECT USING (auth.uid() = user_id);
What will happen if a user tries to select a profile where user_id is different from their auth.uid()?
medium
A. The user will be able to read the profile
B. The user will get an empty result (no rows)
C. The query will cause a syntax error
D. The user will be able to update the profile
Solution
Step 1: Understand the policy condition
The policy allows reading only if auth.uid() equals user_id.
Step 2: Analyze the case when user_id differs
If user_id is different, the condition fails, so no rows are returned.
Final Answer:
The user will get an empty result (no rows) -> Option B
Quick Check:
Condition false = no rows returned [OK]
Hint: Read allowed only if auth.uid() matches user_id [OK]
Common Mistakes:
Assuming user can read all profiles
Expecting an error instead of empty result
Confusing read with update permissions
4. You wrote this policy:
CREATE POLICY "Allow read" ON orders FOR SELECT USING (user_id = auth.uid);
But users cannot read their orders. What is the problem?
medium
A. USING clause should be omitted
B. The policy should use FOR UPDATE instead of FOR SELECT
C. The table name is incorrect
D. auth.uid should be called as a function: auth.uid()
Solution
Step 1: Check the usage of auth.uid
auth.uid is a function and must be called with parentheses: auth.uid()
Step 2: Understand impact of missing parentheses
Without (), the condition is invalid and blocks access.
Final Answer:
auth.uid should be called as a function: auth.uid() -> Option D
Quick Check:
auth.uid() is required for correct condition [OK]
Hint: Always call auth.uid() with parentheses [OK]
Common Mistakes:
Using auth.uid without parentheses
Confusing FOR SELECT with FOR UPDATE
Removing USING clause mistakenly
5. You want to allow users to read only their own messages from a messages table. The table has columns id, content, and owner_id. Which policy correctly enforces this read access?
hard
A. CREATE POLICY "Read own messages" ON messages FOR SELECT USING (owner_id = auth.uid());
B. CREATE POLICY "Read own messages" ON messages FOR SELECT USING (owner_id != auth.uid());
C. CREATE POLICY "Read own messages" ON messages FOR SELECT USING (true);
D. CREATE POLICY "Read own messages" ON messages FOR UPDATE USING (owner_id = auth.uid());
Solution
Step 1: Identify correct condition for own data
Users should read rows where owner_id equals their auth.uid()
Step 2: Confirm correct policy type and condition
FOR SELECT with USING (owner_id = auth.uid()) restricts reads properly.
Final Answer:
CREATE POLICY "Read own messages" ON messages FOR SELECT USING (owner_id = auth.uid()); -> Option A
Quick Check:
owner_id = auth.uid() restricts read to own rows [OK]
Hint: Use owner_id = auth.uid() in USING for own read access [OK]
Common Mistakes:
Using != instead of = in condition
Allowing all reads with USING (true)
Using FOR UPDATE instead of FOR SELECT
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.