TL;DR: Design namespace-first: teams hold RoleBindings inside their own namespaces and almost nothing at cluster scope. The recurring failures are cluster-admin granted to unblock someone, wildcard rules, workloads sharing one service account, and nobody noticing who can escalate to anything.
How to approach it
Ask who shares the cluster: team count, environments, whether a platform group exists. Then present the design in layers: identity mapping, per-namespace roles, minimal cluster scope, and enforcement of the boundary itself. The misconfiguration list is where you demonstrate scar tissue, so keep design brief and specifics long.
A strong answer
Identity first: users authenticate through OIDC from the corporate identity provider and RBAC binds to groups, never individuals. Bindings to named people rot the moment anyone changes team, and nobody audits them; groups are already governed by joiner-mover-leaver process.
The design itself is boring on purpose. Every team gets namespaces, ideally split by environment, and inside each one a small set of Roles covering the workload lifecycle: deployments, pods, configmaps, secrets if they must have them, jobs. RoleBindings attach those Roles to the team's group. Cluster scope holds almost nothing: a view ClusterRole for platform observability, targeted admin for the platform group, system components left untouched. Identities that must cross namespaces, a CI deployer for instance, get explicit RoleBindings generated from a list of destination namespaces, so "where can this identity deploy" stays answerable with grep.
Give the default service account special mention: set automountServiceAccountToken: false unless the pod talks to the API server, and never bind permissions to it. Workloads sharing an identity is how blast radius stops being containable.
The misconfigurations I see repeatedly, roughly by frequency: cluster-admin bound broadly to unblock delivery, which quietly becomes permanent; wildcard verbs or resources copied from a forum answer; get and list secrets granted namespace-wide, handing out every credential in that namespace at once; escalation paths, where pod creation can expose service-account permissions in that namespace, or excess bind/escalate permissions permit stronger grants.
That last one deserves explaining because it decides whether your design holds. Creating a pod lets you choose a service account in the same namespace, so whoever can run pods as identity X effectively holds X's permissions. RBAC is additive only, there are no deny rules, so you cannot patch around it. You prevent it structurally: only the platform group holds roles, rolebindings and pod-create rights where it matters, and admission policy backs the boundary by rejecting self-service ClusterRoleBindings regardless of what RBAC would allow.
Verification closes the loop: kubectl auth can-i get secrets -n ns --as=system:serviceaccount:ns:sa for spot checks, rbac-lookup or kubectl-who-can to answer who can touch a given resource, and audit-log alerts on any grant of cluster-admin, because grants are rarer and louder than uses.
What interviewers probe next
"Why is listing secrets equivalent to owning the namespace?" Secrets can contain TLS keys, database passwords and manually created or legacy service-account tokens. Modern projected tokens are not automatically Secret objects. Access compromises the credentials actually present, not necessarily every workload identity.
"RBAC has no deny. A team must be blocked from one action. How?" Restructure instead of fighting: move the workload into its own namespace and narrow the role. Where structure cannot express it, an admission policy handles the negative case.
"How do you stop someone granting themselves cluster-admin?" RBAC checks that a role author already holds its permissions unless explicitly granted escalate, and that a binding author can grant the referenced role unless granted bind. Restrict those verbs and cluster-scope bindings; admission can add organizational rules. RBAC escalation checks. Defence in depth on the exact rule that matters most.
Common mistakes
Binding to named users because it is faster this sprint, then inheriting an unauditable sprawl at review time.
Granting cluster-admin as a debugging step with intent to revoke later, and neither revoking nor logging it.
Confusing NetworkPolicy with RBAC: network reachability and API permissions are independent axes and both need deliberate design.