Environment variables and secrets in Supabase - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

How does Supabase handle environment variables in serverless functions?

Supabase allows you to set environment variables for your serverless functions. What happens if you try to access an environment variable that is not set?

A The function returns undefined or null for the missing variable.

B The function throws a runtime error and stops execution.

C The function returns an empty string for the missing variable.

D The function uses a default value defined in the Supabase dashboard.

💡 Hint

Think about how environment variables behave in Node.js when not set.

If an environment variable is not set, accessing it returns undefined (or null in some contexts). Supabase serverless functions behave similarly, so no error is thrown automatically.

❓ security

intermediate

What is the safest way to store API keys in Supabase projects?

You want to use a third-party API key in your Supabase project. Which method ensures the key is kept secret and not exposed to users?

A Save the API key in a public table in the Supabase database.

B Hardcode the API key directly in the client-side JavaScript code.

C Store the API key in Supabase environment variables and access it only in serverless functions.

D Include the API key in the URL query parameters of client requests.

💡 Hint

Consider where client-side code can be seen by users.

Environment variables in serverless functions keep secrets safe because they are not exposed to the client. Hardcoding or storing keys in public places risks exposure.

❓ Configuration

advanced

What is the correct way to access a secret environment variable in a Supabase Edge Function?

Given you have set an environment variable named MY_SECRET in your Supabase project, how do you access it inside an Edge Function?

Supabase

export default async function handler(req) {
  // Access the secret here
  const secret = Deno.env.get('MY_SECRET');
  return new Response(secret);
}

A const secret = window.env.MY_SECRET;

B const secret = Deno.env.get('MY_SECRET');

C const secret = supabase.env.MY_SECRET;

D const secret = process.env.MY_SECRET;

💡 Hint

Supabase Edge Functions run on Deno runtime, not Node.js.

Supabase Edge Functions use Deno, so environment variables are accessed with Deno.env.get(). process.env is Node.js specific and will not work.

❓ Architecture

advanced

How should you architect a Supabase project to securely use multiple environment variables for different deployment stages?

You have development, staging, and production environments. How do you manage environment variables securely and efficiently across these stages in Supabase?

A Create separate Supabase projects for each stage, each with its own environment variables.

B Use the same environment variables for all stages and rely on code to switch behavior.

C Store all variables in one project and prefix variable names with the stage name.

D Keep environment variables in a shared public database table with stage tags.

💡 Hint

Think about isolation and risk of leaking secrets between stages.

Separate projects per stage isolate environment variables and resources, reducing risk of accidental leaks or interference. Sharing variables or projects risks mixing secrets.

✅ Best Practice

expert

What is the recommended practice to rotate secrets stored as environment variables in Supabase without downtime?

You need to update a secret API key stored in Supabase environment variables used by Edge Functions. How do you rotate the secret safely without causing downtime or errors?

A Store both old and new secrets in the same variable separated by a comma and parse them in code.

B Delete the old secret variable first, then add the new one and redeploy functions.

C Update the environment variable directly and redeploy all functions immediately.

D Deploy new functions that read the new secret variable while old functions still use the old one, then switch traffic gradually.

💡 Hint

Consider how to avoid breaking running functions during secret updates.

Gradual rollout with new functions using the new secret while old ones still run avoids downtime. Direct replacement risks breaking running functions that rely on the old secret.