In Kubernetes, resources like Pods and Services are represented as API objects that you create, read, update, delete, and watch via the Kubernetes RESTful API. That makes D (REST) the correct answer.
Kubernetes is fundamentally API-driven: the API server exposes endpoints for each resource type (for example, /api/v1/namespaces/{ns}/pods and /api/v1/namespaces/{ns}/services). Clients such as kubectl, controllers, operators, and external systems interact with these resources by making REST-style calls using HTTP verbs (GET, POST, PUT/PATCH, DELETE) and using watch streams for event-driven updates. This API-first design is what enables Kubernetes’ declarative model—users submit desired state to the API server, and controllers reconcile the cluster to that desired state.
Options A and B (JSON and YAML) are common serialization formats used to represent Kubernetes objects, but they are not what the objects “are.” Kubernetes objects are logical API resources; they can be encoded as JSON (what the API uses) and often authored as YAML for human convenience. YAML is effectively a superset-friendly format that can be converted to JSON. The underlying API object model remains the same regardless of whether you wrote YAML or JSON. Option C (Java) is unrelated; Java is a programming language that can interact with Kubernetes via client libraries, but Kubernetes objects are not “Java objects” in the platform’s definition.
So the accurate statement is: Pods and Services are Kubernetes REST API objects (resources) exposed and managed through the Kubernetes API server, which is why REST is the correct fill-in.
=========
