A platform team offers a validated custom API for provisioning caches, while another team only needs a few key/value settings for one app. When is a CRD the better fit than a ConfigMap?
Select an answer to reveal the explanation.
Short Explanation
ConfigMaps are sticky notes of settings; CRDs are formal forms backed by an Operator’s brains. Use the CRD when the platform exposes that structured API. Keep ordinary app kv config in ConfigMaps.
Full Explanation
A CRD is the better fit when an Operator defines a structured extended API you should create and consume—for example a validated cache provisioning API—rather than stuffing orchestration into a ConfigMap. ConfigMaps remain appropriate for a few key/value settings one app reads as files or environment variables. Choose CRDs for platform capabilities with schema, status, and reconciliation; choose ConfigMaps for plain application configuration in civic services that simply need settings.
Using a CRD whenever any string exceeds sixteen characters fails—value length is irrelevant to whether you need an extended API. Limiting CRDs to clusters with fewer than three nodes invents a topology rule that does not drive API design. Always preferring ConfigMaps for databases and CRDs only for static HTML inverts real practice: databases are classic Operator/CRD territory, while static HTML config is often ConfigMap or image content.
Exam caveat: inventing CRDs for every tiny setting adds operational weight—prefer ConfigMaps unless the platform provides an Operator API with real lifecycle behavior. Operational check: if the platform published a Cache CRD, create that CR and read status; if you only need CACHE_TTL=60, use a ConfigMap and env or volume injection for the app.