A developer proposes storing a 50Mi proprietary binary installer inside a ConfigMap for a batch Job. What guidance best matches ConfigMap purpose and practical limits?
Select an answer to reveal the explanation.
Short Explanation
ConfigMaps are sticky notes and short settings files — not a freight elevator for fat binaries. Park large artifacts in the image or object storage. etcd-backed objects have real size limits and the wrong shape for installers.
Full Explanation
A developer proposing to store a 50Mi proprietary binary installer inside a ConfigMap for a batch Job should instead keep ConfigMaps for small non-sensitive configuration data and store large binaries elsewhere—such as an image layer or object storage. etcd and API practical size limits make large binary ConfigMaps fragile for municipal batch platforms and expensive to distribute to every kubelet that mounts them.
Claiming ConfigMaps are preferred over container images for any binary larger than 1Mi because etcd compresses them fails operational guidance and understates size and performance risks. Putting the binary in a ConfigMap and also copying it into a Secret so RBAC allows exec misunderstands both object purposes and still leaves an oversized object in the API. Claiming immutable ConfigMaps specifically let binaries over 10Mi bypass API size constraints fails—immutability does not raise etcd or API size ceilings.
Exam caveat: even below hard cluster limits, large ConfigMaps hurt control-plane performance and widen exposure of proprietary binaries via get permissions. Operational check: move the installer into the Job image or fetch it from object storage at runtime, keep ConfigMaps to small settings, and delete oversized ConfigMap experiments.