Question 29
Domain 2: Cluster HardeningA Kubernetes administrator wants to grant a team read-only access across many resources without manually listing rules in a new ClusterRole. Which approach best aligns with the built-in default ClusterRole intended for that level of access?
Correct answer: C
Explanation
In Kubernetes, the built-in default ClusterRoles map to broad access levels: cluster-admin for full control, edit for modifying most resources, and view for read-only access. When the requirement is read-only visibility, the default role designed for that purpose is view. — cks_syllabus.txt
Why each option is right or wrong
A. Bind the team to the cluster-admin ClusterRole
cluster-admin is the default ClusterRole for full administrative access, not read-only visibility.
B. Bind the team to the edit ClusterRole
edit is the default ClusterRole for modifying resources, not limiting access to read-only operations.
C. Bind the team to the view ClusterRole
The requirement is read-only access across resources. Among the default ClusterRoles named in the source material, view is the built-in role intended for read-only access, whereas edit allows changes and cluster-admin grants full administrative control.
D. Create a binding to an aggregated ClusterRole named edit-view
Aggregated ClusterRoles are a separate concept; the source material identifies view as the default read-only ClusterRole.