CKA Practice Question: Cluster Architecture, Installation and Configuration

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Role and RoleBinding

  Why this is correct

  This combination is the correct and most granular approach for granting permissions within a specific namespace. A `Role` defines a set of permissions (e.g., create pods, list deployments) that are strictly confined to the namespace where the `Role` is created. Subsequently, a `RoleBinding` links this namespace-scoped `Role` to a specific subject, such as a service account used by a CI/CD pipeline, thereby granting those defined permissions exclusively within that particular namespace. This adheres to the principle of least privilege by preventing unintended access to other parts of the cluster.

• ✗

  ClusterRole and RoleBinding

  Why it's wrong here

  This option fails because a `ClusterRole` grants permissions cluster-wide, which is too broad for the requirement of restricting pod creation/deletion solely to the 'ci' namespace. While a `RoleBinding` correctly scopes permissions to a namespace, the `ClusterRole` itself lacks the necessary namespace-specific restriction. This combination is tempting because it's the standard approach for granting cluster-level permissions to a specific namespace, but it's incorrect here due to the strict namespace boundary specified in the question.

• ✗

  ClusterRole and ClusterRoleBinding

  Why it's wrong here

  Using a `ClusterRole` paired with a `ClusterRoleBinding` grants permissions that are effective across the entire Kubernetes cluster, not just within a single namespace. A `ClusterRole` defines permissions for cluster-scoped resources (like nodes) or for namespaced resources *across all namespaces*. Binding this `ClusterRole` via a `ClusterRoleBinding` would provide the CI/CD pipeline with broad, cluster-wide access, which is excessive and insecure if the pipeline only needs to operate within a designated namespace.

• ✗

  Role and ClusterRoleBinding

  Why it's wrong here

  This combination is fundamentally incorrect and will not function as intended within Kubernetes RBAC. A `Role` is a namespace-scoped resource, meaning its permissions are defined and applicable only within a single namespace. Conversely, a `ClusterRoleBinding` is designed exclusively to grant *cluster-scoped* permissions, which are defined by a `ClusterRole`, to a subject across the entire cluster. You cannot bind a namespace-scoped `Role` using a `ClusterRoleBinding`; such an attempt would result in a validation error because a `ClusterRoleBinding`'s `roleRef` field must point to a `ClusterRole`.