When would you use a DeploymentConfig versus a Deployment in OpenShift?

• A. Use DeploymentConfig for OpenShift-specific features like image-change triggers.
• B. Use DeploymentConfig for Kubernetes-native workloads and portability.
• C. Use DeploymentConfig for testing only.
• D. Use DeploymentConfig to manage SSL certificates.

Answer: (A)

OpenShift provides two deployment approaches, and the one labeled DeploymentConfig is designed to expose OpenShift-specific features. The key capability here is image-change triggers: the deployment can automatically redeploy when a new image appears in an ImageStreamTag, tying the image updates directly to the rollout within OpenShift. This makes DeploymentConfig particularly useful when you want an automatic, image-driven release process that integrates with OpenShift’s image streams and build pipeline.

A Deployment, by contrast, is the standard Kubernetes workload resource. It handles rolling updates in a Kubernetes-native way and is portable across Kubernetes clusters, but it doesn’t include the OpenShift-specific image-change triggers out of the box. If you’re aiming for Kubernetes-native workloads or cross-cluster portability, Deployment is the better fit.

SSL certificates and related routing configurations are managed separately from the deployment object, so they don’t drive the choice between these two resources.