Choosing a runtime configuration and secret delivery model
Last updated: 10/13/2026
Use this topic to choose how runtime configuration, secrets, and mounted data are
delivered to workloads in Dynamic Engine
environments.
Choose the delivery mechanism
| Use case | Recommended topic |
|---|---|
| You need non-sensitive configuration values as environment variables. | Injecting environment variables from ConfigMap |
| You need sensitive values as environment variables. | Injecting environment variables from Kubernetes Secret |
| You need secrets exposed as files, for example certificate or key material. | Mounting Kubernetes Secret as volumes in Dynamic Engine containers |
| You need persistent data mounted through Kubernetes storage claims. | Mounting Kubernetes PersistentVolumeClaims for persistent storage in Dynamic Engine |
Scope impact and guardrails
- Choose one primary model per workload concern to avoid overlapping injections that are difficult to troubleshoot.
- For security-sensitive scenarios, prefer Kubernetes Secret-based delivery and pair it with container security controls.
Verify and recover
Validate runtime values inside running pods after configuration changes. If workloads fail to start or mount correctly, use Troubleshooting Kubernetes resource mounting in Dynamic Engine environments to identify mount and injection issues.