Study Confluent CCAC API Keys and RBAC: key concepts, common traps, and exam decision cues.
On this page
This lesson matters because CCAC access questions are often simple once you split them into three parts: who is acting, how it authenticates, and what it is allowed to do.
Access model chooser
If the scenario is asking…
Strongest first object
which workload is acting
service account
how that workload proves identity
API key or other credential
what that workload is allowed to do
RBAC role binding and scope
Keep these layers separate
Layer
Real job
Common confusion
user
human identity
treating it like an application principal
service account
workload identity
sharing one across unrelated systems
API key
credential used for authentication
assuming it defines authorization
role binding
permission scope
forgetting it must match the resource boundary
What the exam is really testing
If the scenario shows…
Strong reading
one connector and one app using the same identity
accountability and blast-radius weakness
successful authentication but denied action
authorization scope issue
pressure to simplify by sharing credentials
operator discipline is under test
Decision order that usually wins
Name the acting principal first.
Separate authentication from authorization before changing anything.
Check whether the role binding scope matches the actual resource boundary.
Keep identities narrow when ownership and blast radius differ.
Escalate access only after proving the smaller scope is insufficient.
CCAC access questions get easier once you stop treating “identity” as one blur. Service account, credential, and role binding each solve a different problem.
Scenario triage
Scenario
Better first move
connector and app share one identity for convenience
split principals
request authenticates but still fails
inspect RBAC scope
team wants broad access to avoid triage
keep least privilege and test narrow scope first
one workload acts on behalf of an app
use service-account design, not user credentials
Common traps
Trap
Better rule
“One key per team is enough.”
separate principals where ownership and blast radius differ
“The API key already proves the app should write.”
authentication and authorization are different
“Broad admin access is faster.”
least privilege is safer and usually clearer operationally