# Knowledge Check: ServiceAccounts & RBAC

---

**1. A Pod is created with no ServiceAccount specified. What identity does it actually run as,
and what can that identity do by default?**

*Answer:* The `default` ServiceAccount in its Namespace, which by default has essentially no
permissions — it can authenticate to the API but is granted nothing until an RBAC binding says
otherwise.

---

**2. You create a Role granting `get`/`list` on Pods, but a workload still can't read Pods.
What's the most likely missing piece?**

*Answer:* A RoleBinding (or ClusterRoleBinding) connecting that Role to the workload's actual
ServiceAccount. A Role by itself grants nothing to anyone — it has to be bound to an identity.

---

**3. True or false: a ClusterRole can only ever be applied cluster-wide.**

*Answer:* False. A ClusterRole can be bound via a RoleBinding to apply within just ONE
Namespace (reusing a cluster-wide-DEFINED permission set in a namespace-SCOPED way), or via a
ClusterRoleBinding to apply cluster-wide. The Role-type and Binding-type are independent
choices.

---

**4. Why would a security review flag a Role granting `verbs: ["*"]` on `resources: ["*"]`
even if the workload "seems to work fine"?**

*Answer:* That grant is root-equivalent API access — it violates least privilege regardless of
whether the workload happens to only use a small subset of it today. "Works fine" doesn't mean
"correctly scoped" — an over-broad grant is a real risk the moment that workload (or its
credentials) is compromised, whether or not it's ever exploited in practice.

## Instructor Notes

**Facilitation:** Question 4 is worth discussing even if everyone answers correctly — the "it
works, so what's the problem" instinct is exactly what least-privilege review exists to counter.

**Approximate timing:** 5 minutes.