A city data team needs managed Postgres for an application. A Postgres Operator is installed and exposes a custom Postgres resource. What should the app team create to consume that capability?
Select an answer to reveal the explanation.
Short Explanation
Operators put a custom “order form” in the cluster API—you fill out the Postgres CR and the Operator builds the machinery. Skip hand-rolled StatefulSets when that CR exists. Let the Operator reconcile the database.
Full Explanation
When a city data team needs managed Postgres and a Postgres Operator is already installed exposing a custom Postgres kind, the application team should create an instance of that custom resource rather than hand-rolling StatefulSets, Services, and backup Jobs. The Operator watches Postgres objects and reconciles them into the concrete Kubernetes objects and lifecycle automation the platform intends. For municipal data workloads, consuming the Operator’s CR keeps provisioning consistent with platform standards—storage classes, credentials, and health checks—without each app team reinventing database controllers.
Writing a raw kubeadm configuration that installs etcd beside the app Deployment fails because kubeadm/etcd are control-plane concerns, not an application pattern for consuming managed Postgres. Running PostgreSQL on every node via DaemonSet with hostPath fails portability, durability, and operational safety compared with Operator-managed instances and proper storage. Expecting a LimitRange to provision database Pods when CPU requests appear fails conceptually: LimitRanges constrain or default resource fields; they do not act as database Operators.
Exam caveat: creating the CR still requires RBAC to that custom API and a healthy Operator deployment—Unknown kind means the CRD is missing. Operational check: kubectl get crd | grep -i postgres, apply a Postgres CR in the app namespace, watch the Operator create Secret/Service/Pods, then point the civic app at the generated connection Secret.