Select Two (Multi-Select) Questions

A Service can expose only one container port

Why it fails: A Service can expose multiple ports with different names.

A Service can only route traffic to pods on the same node as the Service

Why it fails: Services route to any pod matching the selector, regardless of node.

A Service of type NodePort exposes the service only on the node where the pod is running

Why it fails: NodePort exposes the service on every node in the cluster.

Deployments are the recommended controller for stateful applications.

Why it fails: Deployments suit stateless workloads with interchangeable replicas; StatefulSets provide stable network identities, ordered rollout and per-pod PersistentVolumeClaims. StatefulSets are correct for databases and clustered systems needing persistent storage and ordinal naming, which Deployments cannot guarantee.

Deployments can expose applications externally via a built-in load balancer.

Why it fails: Deployments only manage pod replicas and ReplicaSets; external exposure requires a Service of type LoadBalancer or an Ingress resource, which cloud controllers provision. A LoadBalancer Service is the right choice when publishing a workload outside the cluster, not the Deployment itself.

Deployments are used to run a pod on every node in the cluster.

Why it fails: Deployments manage replicated, stateless pods with a desired replica count; running one pod per node is the job of a DaemonSet, which schedules via node affinity and tolerations. DaemonSets suit log shippers, node exporters and CNI agents, so this describes that controller rather than Deployments.

Use a single centralized logging solution to aggregate logs from all components.

Why it fails: Single point of failure; prefer highly available solutions.

Store all debug logs for a minimum of 90 days for compliance.

Why it fails: Debug logs are verbose; store selectively.

Disable leader election for monitoring components to reduce complexity.

Why it fails: Leader election prevents duplicate metrics in HA setups.

env

Why it fails: The env field is optional; environment variables may be supplied at runtime or omitted entirely, so a container spec validates without it. It tempts because most real containers do set environment variables, but the only required container field is name (plus image).

resources

Why it fails: The Pod spec's required fields are only containers[].name and containers[].image; resources is optional, defaulting to unlimited if omitted. It is tempting because resource requests and limits are best practise for scheduling and stability, and would be the right answer to a question about production readiness or quality of service.

ports

Why it fails: The ports field is optional; omitting it leaves the container's listening ports unspecified, which is valid for Pods that need no declared ports. It tempts because exposing ports feels essential, yet Kubernetes requires only name and image in a container definition.

Manual infrastructure provisioning

Why it fails: Cloud native emphasizes automation.

Monolithic application design

Why it fails: Monolithic design is the opposite of cloud native.

Tight coupling between services

Why it fails: Coupling is avoided in cloud native.

Single monolithic codebase

Why it fails: Monolithic is the opposite of microservices.

Shared database schema across services

Why it fails: Microservices often use separate databases per service.

kubelet

Why it fails: The kubelet is a node agent that runs on each worker node and manages pod lifecycle there; it is not a controller inside the kube-controller-manager. It is tempting because it is a core Kubernetes component, but its placement on nodes, not in the control-plane controller manager, rules it out.

etcd

Why it fails: etcd is the distributed key-value store holding cluster state, running as its own process rather than as a controller within the kube-controller-manager. It is tempting because it is a control-plane component, but it provides storage, not the reconciliation loops the question asks about.

kube-scheduler

Why it fails: The kube-scheduler is a separate control-plane process that binds pods to nodes; it does not run inside the kube-controller-manager. It is tempting because it is a control-plane component, but its distinct binary and scheduling role place it outside the controller manager's embedded controllers.

Tight coupling between services to ensure performance

Why it fails: Tight coupling contradicts the independent deployability and scaling that orchestration platforms like Kubernetes provide; each microservice must be separately releasable and scalable. It is tempting because coupling services can reduce network latency in monolithic or performance-critical designs, where shared in-process calls genuinely outperform inter-service communication.

Monolithic codebase with centralized deployment

Why it fails: A monolithic codebase with centralised deployment contradicts the independent, per-service deployability that container orchestration exists to support; orchestrators schedule discrete containers, not one coupled artefact. It is tempting because centralised deployment genuinely suits single-unit applications, where one build-and-release pipeline is the intended model rather than a limitation.

Use of a single, shared database for all services

Why it fails: A shared database couples services through a common schema, so independent deployment and scaling break. It is tempting because it simplifies transactions and reporting; it would suit a monolith, not the decentralised data ownership container orchestration supports.

More human-readable than plain text

Why it fails: Structured logs are machine-parseable key-value records, typically less readable for humans than free-text lines. It is tempting because JSON can be pretty-printed and some viewers render fields clearly, but the format's purpose is automated querying and correlation, not human consumption.

Reduced storage requirements

Why it fails: Structured formats such as JSON add field names and delimiters, usually increasing log volume rather than reducing it. It is tempting because indexed fields allow faster filtering and shorter retention of raw data, but the encoding itself does not shrink storage; compression and sampling achieve that.

Monitoring CPU and memory usage of each service instance

Why it fails: CPU and memory metrics come from resource monitoring tools such as Prometheus or cAdvisor, not distributed tracing, which records request paths across services via spans and trace IDs. It is tempting because tracing data is often displayed alongside resource dashboards, but tracing captures latency and call relationships, not host resource consumption.

Capturing detailed error messages and stack traces

Why it fails: Distributed tracing focuses on propagating trace context across service boundaries to reconstruct end-to-end request flows, not on capturing the payload of individual errors. Detailed error messages and stack traces belong to structured logging or exception-handling frameworks, which record local failure details without the cross-service correlation identifiers that tracing requires. This option is tempting because observability tools often bundle tracing with logging, but the specific mechanism of trace propagation—span IDs and parent-child relationships—is absent from raw error capture.

Storing cluster state

Why it fails: Cluster state is persisted in etcd, the distributed key-value store; the kube-controller-manager runs control loops that reconcile desired state, never storing it. It is tempting because the controller-manager reads and writes objects through the API server, so its constant interaction with state can be mistaken for ownership of the storage layer.

Exposing the Kubernetes API

Why it fails: The Kubernetes API is exposed by kube-apiserver, which serves REST requests and validates objects; the kube-controller-manager only watches and reconciles resources via that API. It is tempting because controller-manager activity is visible through API objects, so its reliance on the API server can be confused with providing the API itself.

Assigning pods to nodes

Why it fails: Assigning pods to nodes is the responsibility of the kube-scheduler, which uses resource requests and constraints to select a node for each unscheduled pod. The kube-controller-manager runs controller loops (e.g., ReplicaSet, Node Lifecycle) but does not perform node assignment. This option is tempting because the controller-manager oversees node health and can evict pods from unhealthy nodes, but it never decides which node a new pod lands on.

Simplified application development by eliminating the need for code changes

Why it fails: Orchestration manages deployment, scaling and scheduling of existing images; it cannot alter application source code, so development effort continues. It is tempting because declarative manifests and rolling updates remove manual deployment toil, which in a stable, already-containerised application can feel like development work has been eliminated.

Elimination of the need for monitoring and logging

Why it fails: Orchestration schedules and restarts containers but exposes no telemetry itself; monitoring and logging remain essential and are typically integrated alongside it. It is tempting because Kubernetes does surface basic liveness and readiness states, which in a minimal single-container test setup can appear to replace dedicated observability tooling.

Store config in codebase for traceability

Why it fails: Factor III requires configuration in environment variables, keeping credentials and per-deploy values out of the codebase so the same artefact promotes across environments. Storing config in code is tempting for traceability, but it couples builds to environments and leaks secrets into version control.

Tight coupling to backing services

Why it fails: Twelve-Factor requires backing services to be treated as attached resources, swappable via configuration without code changes; tight coupling directly violates that. It tempts because some legacy designs do bind services closely for latency or simplicity, but the methodology explicitly mandates loose coupling through externalised config.

All services share the same database

Why it fails: Microservices often have their own databases to avoid tight coupling.

The entire application is deployed as a single unit

Why it fails: That describes a monolithic architecture, not microservices.

Services are tightly coupled

Why it fails: Microservices are loosely coupled, meaning they can change independently without affecting others.

Specify 'resources.guarantees.cpu' for CPU guarantees

Why it fails: Kubernetes Pod specs define resources under 'resources.requests' and 'resources.limits'; no 'guarantees' field exists. It is tempting because guarantees conceptually resemble requests, so the term sounds plausible, yet the API would reject this unknown field during validation.

Specify 'resources.min.memory' for minimum memory

Why it fails: Resource constraints use 'resources.requests' and 'resources.limits'; 'resources.min.memory' is not a valid field. It is tempting because a minimum memory concept mirrors requests, but Kubernetes expresses that through requests.memory, and an unrecognised key fails schema validation.

Specify 'resources.max.cpu' for CPU limits

Why it fails: Kubernetes nests limits under resources.limits.cpu; resources.max.cpu is not a recognised field and the API server rejects the manifest. It tempts because 'max' intuitively suggests an upper bound, and a schema using resources.max would be valid in some other orchestrators' resource models.

OCI requires the use of containerd

Why it fails: OCI standards are runtime-agnostic; any compliant runtime can be used.

OCI defines the Dockerfile format

Why it fails: Dockerfile is a Docker-specific format, not part of OCI.

OCI defines the Container Runtime Interface (CRI)

Why it fails: CRI is a Kubernetes-specific interface, not part of OCI.

Containers require hypervisor software to run

Why it fails: Containers run directly on the host OS using the kernel's container features, no hypervisor required.

Containers include a full guest operating system

Why it fails: Containers share the host OS kernel and do not include a full guest OS, unlike VMs.

Containers provide stronger isolation than VMs

Why it fails: VMs provide stronger isolation because each VM has its own kernel. Containers share the host kernel.

Manual deployment of containers to servers

Why it fails: Manual placement is what orchestration replaces; Kubernetes schedules pods automatically onto nodes based on resource requests, taints and affinity rules. It is tempting because manual deployment gives operators direct control, and would be correct for a small, static set of long-lived services where automation overhead is not justified.

Requirement for a hypervisor on every node

Why it fails: Kubernetes runs containers directly on a shared host kernel via a container runtime such as containerd, so no hypervisor layer is required per node. It is tempting because hypervisors do isolate VMs, and would be the right choice when running heterogeneous operating systems or requiring hardware-level separation between tenants.

Static infrastructure that never changes

Why it fails: Kubernetes exists precisely to abstract and reschedule workloads across changing node pools, so immutable infrastructure contradicts its scheduling and self-healing model. It is tempting because stability sounds desirable, and static infrastructure would be the correct design for fixed-purpose appliances where no orchestration or dynamic placement is needed.

kubectl describe pod my-pod

Why it fails: kubectl describe pod reports metadata, events and container status, not the container's stdout/stderr log stream. Describe suits diagnosing scheduling, image-pull or restart failures; reading application output requires kubectl logs, which queries the kubelet's log endpoint.

kubectl run my-pod -- logs

Why it fails: kubectl run creates a new pod from an image; the trailing arguments become that container's command, so no existing pod's logs are read. Run suits launching throwaway workloads, whereas viewing an existing pod's output requires kubectl logs against 'my-pod'.

kubectl attach my-pod

Why it fails: kubectl attach connects to a running container's stdin/stdout for interactive input; it does not read the container log file. Attaching suits debugging a live process expecting terminal input, whereas log retrieval requires kubectl logs, which streams the container runtime's recorded output.

Containers include a full guest operating system

Why it fails: Containers do not include a guest OS; they share the host kernel.

Containers provide stronger isolation than VMs

Why it fails: VMs provide stronger isolation due to separate kernels.

Containers require a hypervisor to run

Why it fails: Containers run directly on the host OS using the kernel's namespace features, no hypervisor needed.