What is the purpose of the Downward API in Kubernetes/OpenShift?

• A. It secures secrets with encryption at rest.
• B. It exposes pod metadata to containers via environment variables or files in a volume.
• C. It scales pods automatically based on resource usage.
• D. It enables network policy enforcement for pods.

Answer: (B)

The Downward API lets a pod share information about itself with the containers running inside it. This means metadata about the pod—such as its name, namespace, IP address, and labels or annotations—can be made available inside the container without needing to query the Kubernetes API at run time. You can expose this data either as environment variables or as files in a mounted volume, giving the container runtime convenient, read-only access to its own context.

This capability is useful for apps that need to adapt based on where they’re running, for example by using the pod name or namespace for logging, configuring behavior according to labels, or including the IP address in a service request. You configure it in the pod spec by defining a downward API volume or by setting environment variables that reference fields like metadata.name or metadata.namespace, which will populate those values inside the container.

Other options don’t fit because the Downward API isn’t about encrypting secrets, automatic scaling, or enforcing network policies. Its purpose is specifically to surface pod metadata inside the container for runtime use.