Exercise 1: Role vs. ClusterRole, RoleBinding vs. ClusterRoleBinding — Scope — Possible Solution
====================================================================

ROLE vs. CLUSTERROLE:

A Role is scoped to ONE NAMESPACE -- per the chapter, its permissions
only apply within the specific namespace it's created in, and it can
only grant access to resources that live within that namespace
(matching `k8s1-10`'s own namespace-scoped resource material).

A ClusterRole is scoped CLUSTER-WIDE. Per the chapter, this is needed
for two distinct reasons: either the permission is for a genuinely
CLUSTER-SCOPED resource (like Nodes, which per `k8s1-10` don't belong
to any namespace at all, so a namespace-scoped Role couldn't grant
access to them even in principle), OR because the SAME set of
permissions needs to be reused/granted across MULTIPLE namespaces
without duplicating an identical Role in each one separately.

ROLEBINDING vs. CLUSTERROLEBINDING:

A RoleBinding grants a Role's permissions to a specific
user/group/ServiceAccount, but the GRANT ITSELF is scoped to one
namespace -- the subject only receives those permissions within that
one namespace, even if the exact same Role name happens to exist as a
completely separate object in a different namespace.

A ClusterRoleBinding grants permissions CLUSTER-WIDE -- the subject
receives the referenced permissions across the entire cluster, not
limited to any single namespace.

Note a subtlety directly from the chapter: a ClusterRole can actually
be used in EITHER a RoleBinding (making its permissions apply only
within one specific namespace, even though the ClusterRole itself is
defined cluster-wide) OR a ClusterRoleBinding (making it apply
everywhere) -- the BINDING is what ultimately determines the effective
scope of the grant, not just which kind of Role object was referenced.

WHY THIS WORKS AS AN ANSWER
------------------------------
This distinguishes all four objects along the SAME dimension (scope:
one namespace vs. cluster-wide) and explicitly notes the chapter's own
"be careful" point that identically-named Roles in different
namespaces are entirely separate objects -- directly addressing the
specific nuance the chapter calls out as worth being careful about.