DEBUG if the environment variable DJANGO_DEBUG is not set?import os DEBUG = os.getenv('DJANGO_DEBUG', 'False') == 'True'
The os.getenv function returns the default string 'False' when DJANGO_DEBUG is not set. Comparing the string 'False' to 'True' results in False. So, DEBUG will be False.
SECRET_KEY from an environment variable named DJANGO_SECRET_KEY and raises an error if it is missing.Option B uses os.environ['DJANGO_SECRET_KEY'] which raises a KeyError if the environment variable is missing, ensuring the app fails fast. Option B and C do not raise errors if missing. Option B is invalid syntax in Python.
DATABASES['default']['PORT'] after running this Django settings code?import os DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql', 'NAME': os.getenv('DB_NAME', 'mydb'), 'USER': os.getenv('DB_USER', 'user'), 'PASSWORD': os.getenv('DB_PASS', 'pass'), 'HOST': os.getenv('DB_HOST', 'localhost'), 'PORT': int(os.getenv('DB_PORT', '5432')) } }
The environment variable DB_PORT is not set, so os.getenv('DB_PORT', '5432') returns the string '5432'. The int() function converts it to the integer 5432. So, PORT is 5432.
ALLOWED_HOSTS is not set?import os ALLOWED_HOSTS = os.getenv('ALLOWED_HOSTS').split(',')
Option D calls split() on None if ALLOWED_HOSTS is not set, causing an AttributeError. Other options provide a default empty string or check for None before splitting.
SECRET_KEY and database credentials secure and configurable per environment. Which approach below is the best practice?Option C is best practice: environment variables keep secrets out of code, and using a secrets manager or vault in production adds security. .env files are convenient for local development but should not be used in production.