Multi-environment deployment (dev, staging, prod) in Apache Airflow - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why use separate Airflow environments for dev, staging, and prod?

Which of the following is the main reason to maintain separate Airflow environments for development, staging, and production?

A To increase the number of users who can access Airflow UI simultaneously

B To isolate changes and test workflows safely before affecting production data

C To reduce the number of DAGs that can be deployed

D To save disk space by sharing logs across environments

💡 Hint

Think about why testing in a safe place before production is important.

Separate environments allow developers to test changes without risking production stability or data integrity.

💻 Command Output

intermediate

Output of Airflow environment variable check

Given the following command run in the staging Airflow environment, what is the output?

echo $AIRFLOW_ENV

A staging

B production

C development

D undefined

💡 Hint

Check which environment variable is set for staging.

The AIRFLOW_ENV variable is set to 'staging' in the staging environment to distinguish it from dev and prod.

❓ Configuration

advanced

Correct Airflow config for environment-specific database URI

Which Airflow configuration snippet correctly sets the database URI for the production environment using environment variables?

A

[database]
sql_alchemy_conn = $PROD_DB_URI

B

[database]
sql_alchemy_conn = PROD_DB_URI

C

[database]
sql_alchemy_conn = ${PROD_DB_URI}

D

[database]
dsql_alchemy_conn = ${PROD_DB_URI}

💡 Hint

Check the correct config key spelling and environment variable syntax.

The correct key is 'sql_alchemy_conn' and environment variables are referenced with ${VAR} or $VAR in some shells, but Airflow config uses ${VAR} syntax inside the config file.

🔀 Workflow

advanced

Best practice for deploying DAGs across environments

Which deployment workflow ensures safe promotion of DAGs from development to production in Airflow?

A Directly commit DAGs to the production repository branch and deploy

B Use a single branch for all environments and toggle environment variables manually

C Deploy DAGs only in production and fix bugs live

D Develop DAGs locally, push to a dev branch, test in dev environment, merge to staging branch for further testing, then merge to production branch for deployment

💡 Hint

Think about how to test changes progressively before production.

This workflow uses branches and environments to test changes step-by-step, reducing risk of errors in production.

❓ Troubleshoot

expert

Why does the production Airflow environment fail to connect to the database?

The production Airflow environment suddenly fails to connect to its database. The error log shows: sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) could not connect to server. The sql_alchemy_conn in airflow.cfg is set to ${PROD_DB_URI}. What is the most likely cause?

A The environment variable PROD_DB_URI is not set or empty in the production environment

B The Airflow scheduler is not running

C The DAGs folder is empty

D The Airflow webserver port is blocked by firewall

💡 Hint

Check if the environment variable used in the config is properly set.

If PROD_DB_URI is missing or empty, Airflow cannot connect to the database, causing the OperationalError.