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.

• ✗

  apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: dev ... subjects: - kind: ServiceAccount name: dev-user roleRef: kind: Role name: pod-reader

  Why it's wrong here

  This manifest declares a RoleBinding in the dev namespace, but the subject is a ServiceAccount named dev-user. ServiceAccounts are identities for Pods and automated workloads, not for human users, so the bind would grant the pod-reader Role to the service account, leaving the actual user without any permissions. To grant a human user access, the subject kind must be 'User' (or 'Group' if referring to a group), and the service account would need to exist and be referenced with its own namespace. Therefore, this option fails because it targets the wrong principal type.

• ✗

  apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding ... subjects: - kind: User name: dev-user roleRef: kind: ClusterRole name: pod-reader

  Why it's wrong here

  Using ClusterRole in a RoleBinding is valid only if the ClusterRole is scoped to the namespace, but the question asks for a RoleBinding. However, the RoleBinding itself is correct for namespace scoping, but the roleRef uses ClusterRole, which may not be restricted to the namespace. The correct approach is to use a Role.

• ✗

  apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding ... subjects: - kind: User name: dev-user roleRef: kind: ClusterRole name: pod-reader

  Why it's wrong here

  This option uses a ClusterRoleBinding, which is a cluster-scoped resource that grants permissions across all namespaces (or on cluster-level resources). The requirement is to grant access only in the 'dev' namespace, so the binding must be a RoleBinding, which is namespace-scoped. Even though the ClusterRole 'pod-reader' might exist, binding it via ClusterRoleBinding makes the user effective cluster-wide, violating the namespace isolation the question demands. The correct construct is a RoleBinding in the 'dev' namespace referencing a Role or a ClusterRole (the latter scoped to the namespace), but not a ClusterRoleBinding.

• ✓

  apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: dev ... subjects: - kind: User name: dev-user roleRef: kind: Role name: pod-reader

  Why this is correct

  This is the correct answer. The RoleBinding is defined with 'namespace: dev', which confines the authorization to the dev namespace. The subject uses 'kind: User' and 'name: dev-user', correctly identifying the human user who needs access. The roleRef points to a Role named 'pod-reader' in the same namespace, which is the appropriate binding structure for granting namespace-scoped permissions to a named user. This combination satisfies the requirement of granting the user access to pod-reader only in the dev namespace.