Which of the following is a primary benefit of using Kubernetes Custom Resource Definitions (CRDs) in a self-service platform model?

The primary benefit of Custom Resource Definitions (CRDs) is that they provide a native mechanism to extend the Kubernetes API. In a self-service platform model, this allows a platform team to define their own custom API objects (e.g., Database, MessageQueue, Tenant) that represent managed services. Application developers can then interact with these high-level abstractions using standard Kubernetes tools (kubectl, GitOps) and declarative manifests, without needing to understand the underlying implementation details. This is accomplished without modifying or forking the core Kubernetes API server code, ensuring the platform remains maintainable and aligned with the upstream Kubernetes project.

A. CRDs only define the resource's API schema. The operational logic for scaling and failover must be implemented in a separate custom controller (Operator), which is not an automatic feature of the CRD itself.
B. CRDs do not eliminate the need for RBAC; they integrate with it. Access to custom resources is controlled by RBAC rules (Roles/ClusterRoles and Bindings) just like any built-in Kubernetes resource.
D. CRDs are a feature within a single Kubernetes cluster. While a controller associated with a CRD could be programmed to interact with multiple clouds, this is not a built-in capability of CRDs and requires significant additional tooling and logic.

1. Official Kubernetes Documentation

"Custom Resources": "A custom resource is an extension of the Kubernetes API... The CustomResourceDefinition API resource allows you to define custom resources. Defining a CRD object creates a new custom resource with a name and schema that you specify. The Kubernetes API serves and handles the storage of your custom resource." This directly supports that CRDs extend the API without modifying its code.

Source: Kubernetes Authors. (n.d.). Custom Resources. Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/

2. Official Kubernetes Documentation

"Operator pattern": "Operators are software extensions to Kubernetes that make use of custom resources to manage applications and their components. Operators follow Kubernetes principles

notably the control loop." This clarifies that the logic (refuting option A) is in the Operator

which uses the CRD as its API.

Source: Kubernetes Authors. (n.d.). Operator pattern. Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/concepts/extend-kubernetes/operator/

3. University of California

Berkeley

EECS Course CS 162

Lecture 19: Course materials on cloud computing explain that a key design principle of Kubernetes is its extensibility. The lecture notes describe CRDs as the mechanism to "add new types of resources to the API server" enabling custom controllers to manage them

reinforcing that CRDs are for API extension.

Source: Stoica

I.

& Kubiatowicz

J. (2020). CS 162: Operating Systems and System Programming

Lecture 19: Cloud Computing (continued). University of California

Berkeley. (Specific lecture slides on Kubernetes architecture).

4. Red Hat OpenShift Documentation

"Understanding Operators": "An Operator is a method of packaging

deploying

and managing a Kubernetes application. A Kubernetes application is an application that is both deployed on Kubernetes and managed using the Kubernetes APIs and kubectl tooling. You can think of Operators as the runtime that manages this type of application. Conceptually

an Operator takes a Custom Resource Definition (CRD) and combines it with a controller." This vendor documentation confirms CRDs are the API definition component used to build higher-level platform services.

Source: Red Hat. (n.d.). About Operators. OpenShift Container Platform 4.14 Documentation. Section: "What is an Operator?".