PPassTheCertExam

Study guides / CCAO-F / Domain 6

Governance, Risk, and Responsible Use · Lesson 2 of 5

6.2 — Console Roles and Scoped Permissions

Match a person's actual job needs to the Console role that grants exactly that access, and understand why scoped, least-privilege roles are a governance control, not just a convenience.

An Anthropic Console organization supports multiple roles, each granting a different, deliberately scoped set of permissions. Choosing the right role for a person's actual job — rather than defaulting to the broadest available access because it's simpler to hand out once — is a core admin responsibility, and it's also a direct application of a governance principle called least privilege: give each person the minimum access their job actually requires, no more.

This comes up constantly in practice. A new engineer joins for a pilot project. A contractor needs access for eight weeks. A finance stakeholder needs to see spend but has no reason to touch a production integration. Each of these needs a role matched to what the person actually does, not the role that happens to be easiest to remember or hand out by default.

Claude Code User: Scoped for Building, Not Administering

A new engineer who needs to use both the Workbench and the organization's Claude Code workspace for a pilot project, but shouldn't be able to manage API keys or webhook endpoints, fits the Claude Code User role. It grants the access needed to actually build and experiment — using the Workbench, using the org's Claude Code workspace — without granting administrative capabilities like API key management or webhook configuration that a broader role would include.

Billing: A Concrete Example of a Scoped, View-Focused Role

The Billing role is a clean, concrete example of scoping done well. A finance team member using this role can update payment methods and monitor usage and cost data across the organization — exactly what their job requires — but has no access to the Workbench, the Claude Code workspace, API key management, or webhook configuration. They can see how much the organization is spending and on what, but they cannot touch a single production integration, generate a credential, or change what a live application does.

This is deliberate, and it's worth understanding why rather than just memorizing what the role includes. Two governance reasons drive it. First, least privilege: a person's access should match their actual job, and nothing about monitoring spend requires the ability to manage API keys or webhooks. Second, and just as important, limiting blast radius: if a Billing account's credentials were ever compromised, or if the person made an honest mistake while clicking around, the damage they could cause is bounded by what the role can actually do. A compromised Billing-role account can't be used to mint a new API key, redirect a webhook, or touch anything in production — because that access was never granted in the first place. Scoping isn't just about tidiness; it's a real control that shrinks the blast radius of both mistakes and account compromise.

Scoped Roles as a Governance Habit, Not a One-Time Setup Task

It's easy to treat role assignment as something you get right once, at onboarding, and never revisit. Good governance treats it as ongoing: when a contractor's engagement ends, when someone moves from an engineering team to a finance team, or when a pilot project wraps up and an engineer no longer needs Claude Code User access, the role should be revisited and narrowed again, not left at whatever was convenient months ago. An organization that only ever adds access and never removes it slowly accumulates exactly the kind of unnecessary, unreviewed permissions that least privilege is meant to prevent — every one of those stale grants is another account whose compromise would do more damage than it should.

This is also why the exam tends to frame these questions around a specific, described job need rather than a job title alone. Two people with the same title at two different companies can have genuinely different actual needs, and the correct role follows the described need, not the label. Reading the scenario for what the person actually does — not what they're called — is the skill being tested.

Key Concept

Console roles are scoped to what a person actually needs to do. Claude Code User grants building/experimentation access (Workbench, Claude Code workspace) without API key or webhook management. Billing grants payment and usage/cost access without any Workbench, Claude Code workspace, API key, or webhook access. Scoping roles this tightly is a least-privilege governance control: it limits what a mistake or a compromised account can actually do.

Common Exam Distractor

Don't default to a broad Admin-style role just because a person needs some access to the Console, and don't treat scoped roles as merely inconvenient. The exam consistently tests whether you can match the narrowest role that covers the actual described need — over-provisioning access is the wrong answer even when it would technically work, and the governance justification (least privilege, limiting blast radius) is often exactly what a question is testing you to name.

Exam traps

Practice question

A company's finance lead asks why the Billing role can't also include Workbench access, arguing it would be 'more convenient' for the one person who handles both budgeting and the occasional Console question. From a governance standpoint, what is the strongest reason to keep the Billing role scoped as-is rather than broadening it?

  • A Broadening the role would violate least privilege and increase the blast radius if that account were ever compromised or misused, without adding any capability the person's actual job requires Correct

    This is the governance rationale directly from the lesson: scoped roles limit what a mistake or compromised account can do, and access should match actual job need, not convenience for edge-case questions.

  • B The Console doesn't technically allow combining permissions from two different roles under any circumstances

    This isn't the governance reason being tested, and framing it as a pure technical limitation misses the actual least-privilege rationale the exam is testing.

  • C Finance team members are generally not capable of using the Workbench safely

    This is a patronizing, unsupported claim, not the actual governance reasoning — the point is scoping to job need and limiting blast radius, not a judgment about capability.

  • D Billing and Workbench access are stored in different databases, so combining them isn't possible

    This isn't the governance reasoning at all — it invents a technical explanation instead of citing least privilege and blast-radius limitation, which is what the scenario is actually testing.

Build exercise: Match Console Roles to Job Needs and Justify with Governance Reasoning

Beginner · 20 minutes

You'll practice:

  1. In the Anthropic Console (or its documentation if you don't have admin access), review the list of available organization roles and write down, for each, what it grants and what it explicitly excludes — pay particular attention to Claude Code User and Billing.

    This builds a concrete reference you can match specific job needs against, rather than guessing from memory, and surfaces exactly which capabilities each role deliberately withholds.

    You should see: A short written list of roles with their granted and excluded capabilities noted, including at minimum that Billing excludes Workbench, Claude Code workspace, API key, and webhook access.

    Hints 
    1. Look specifically for roles that separate 'building' access from 'administering' access.
    2. Note which roles include API key or webhook management and which explicitly don't.
    3. If you don't have Console admin access, use the Console's role documentation page instead.

  2. Write two short scenarios of your own describing a person's job need — one clearly technical/building-focused and one clearly financial — and assign the correct role to each, with a one-sentence governance justification for why the narrower role, not a broader one, is correct.

    This exercises the actual matching-and-justifying skill the exam tests, forcing you to name the governance reason (least privilege, blast radius) rather than just picking a role that 'sounds right.'

    You should see: Two scenarios, each with a role assignment and a justification that explicitly references what the role excludes and why that exclusion matters.

    Hints 
    1. Make sure your justification names a capability the role deliberately excludes, not just what it includes.
    2. Try swapping the roles between your two scenarios and confirm the assignment would now be wrong — this checks you're reasoning, not guessing.
    3. For at least one scenario, add a sentence about what a compromised account with that role could and couldn't do.

  3. Imagine the Billing-role account from the practice question is compromised by a phishing attack. Write down, in a short list, what an attacker with that account's access could and could not do inside the Console.

    This makes the abstract 'blast radius' concept concrete by walking through a specific compromise scenario and its actual bounded consequences.

    You should see: A short list showing the attacker could view usage/cost data and payment methods, but could not generate an API key, alter a webhook, or touch the Workbench or Claude Code workspace.

    Hints 
    1. Refer back to your role-capability list from the first step while building this.
    2. Notice how the 'could not do' list is what actually protects the organization — that's the point of scoping.
    3. Compare this to what the blast radius would look like if the account instead had a broad Admin role.

Sources