RBAC Interview Questions & Answers

Q: How do you troubleshoot 'permission denied' errors in ArgoCD?

Check the user's group claims (via the token/SSO), confirm matching `g` bindings and `p` rules in policy.csv, verify the object scope (project/app) matches, and remember deny-by-default. The scopes setting must reference the correct claim (e.g., groups). Enabling debug logging on the API server shows which policy decision was made.

Q: What actions can be controlled for the applications resource?

For applications you can control get (view), create, update, delete, sync, override (override a running operation), and action/* (run resource actions like restart). Fine-grained control lets you, for example, allow developers to view and sync but reserve create/delete for platform admins.

Q: What is the policy.default setting?

policy.default sets the role applied to any authenticated user who has no explicit grant. Setting it to role:readonly gives safe view-only default access; leaving it empty denies by default. It's the fallback that determines baseline permissions.

Q: How do you give a group admin access via RBAC?

Add a g line binding the group to role:admin in the policy: `g, , role:admin`. The group name must match the claim from SSO (per the scopes setting). This grants that group full ArgoCD access.

Q: What resources can ArgoCD RBAC control besides applications?

RBAC covers applications, applicationsets, clusters, repositories, projects, accounts, certificates, gpgkeys, logs, and exec. This lets you separately govern who can register clusters, add repos, manage projects, view logs, or open pod shells—not just act on apps.

Q: How do you create a read-only role scoped to one project?

Define policy lines granting only get on that project's apps: `p, role:viewer-a, applications, get, team-a/*, allow`, then bind users/groups with a g line. They can view team-a apps but not sync or modify them, and nothing outside the project.

Q: How does the scopes setting affect group mapping?

The scopes field in argocd-rbac-cm tells ArgoCD which token claims to read for subject matching (commonly groups, sometimes email). If it doesn't reference the claim your IdP sends, g bindings won't match and users fall to the default role. Correct scopes are essential for SSO group RBAC to work.

Q: What is a local account and when would you use one?

Local accounts are ArgoCD-managed users (defined in argocd-cm) with passwords or tokens, used for automation or break-glass access when SSO is unavailable. They should be limited and carefully permissioned; SSO is preferred for humans, local accounts for specific service/automation needs.

Q: How do project roles and tokens enable least-privilege automation?

AppProject roles define scoped policies for that project, and you generate JWT tokens bound to a role. CI uses such a token to, say, sync only that project's apps—no admin account needed. This confines automation to exactly the actions and objects it requires.

Q: How do you manage RBAC declaratively under GitOps?

Store the argocd-rbac-cm ConfigMap (policy.csv, policy.default, scopes) in Git and let ArgoCD (or the install) apply it, so access-control changes go through pull requests and review. This versions permissions and provides an audit trail of who changed access and when.

How do you troubleshoot 'permission denied' errors in ArgoCD?

Advanced

Check the user's group claims (via the token/SSO), confirm matching `g` bindings and `p` rules in policy.csv, verify the object scope (project/app) matches, and remember deny-by-default. The scopes setting must reference the correct claim (e.g., groups). Enabling debug logging on the API server shows which policy decision was made.

Real-world example A user denied sync is fixed by correcting the scopes setting so their SSO group claim is read and mapped to a role.

Common follow-ups: What does the scopes setting control? | Why check the object scope?

RBAC Multi-cluster Applications

What actions can be controlled for the applications resource?

Intermediate

For applications you can control get (view), create, update, delete, sync, override (override a running operation), and action/* (run resource actions like restart). Fine-grained control lets you, for example, allow developers to view and sync but reserve create/delete for platform admins.

p, role:dev, applications, action/apps/Deployment/restart, '*/*', allow

Real-world example Developers are allowed to restart Deployments via ArgoCD actions but not to delete applications.

Common follow-ups: What does the override action do? | How do resource actions fit RBAC?

Applications Sync & Health RBAC

What is the policy.default setting?

Beginner

policy.default sets the role applied to any authenticated user who has no explicit grant. Setting it to role:readonly gives safe view-only default access; leaving it empty denies by default. It's the fallback that determines baseline permissions.

data:
  policy.default: role:readonly

Real-world example Unmapped SSO users get read-only access because policy.default is role:readonly.

Common follow-ups: What does an empty default do? | Why set a readonly default?

Applications Multi-cluster RBAC

How do you give a group admin access via RBAC?

Beginner

Add a g line binding the group to role:admin in the policy: `g, <group>, role:admin`. The group name must match the claim from SSO (per the scopes setting). This grants that group full ArgoCD access.

policy.csv: |
  g, platform-admins, role:admin

Real-world example The platform-admins SSO group is bound to role:admin so its members manage all of ArgoCD.

Common follow-ups: Where does the group name come from? | What does role:admin allow?

Multi-cluster Applications RBAC

What resources can ArgoCD RBAC control besides applications?

Intermediate

RBAC covers applications, applicationsets, clusters, repositories, projects, accounts, certificates, gpgkeys, logs, and exec. This lets you separately govern who can register clusters, add repos, manage projects, view logs, or open pod shells—not just act on apps.

p, role:repo-admin, repositories, *, *, allow

Real-world example A role can manage repository connections but has no permission over clusters or app deletion.

Common follow-ups: Why separate cluster and repo permissions? | What does the logs resource control?

Multi-cluster Applications RBAC

How do you create a read-only role scoped to one project?

Intermediate

Define policy lines granting only get on that project's apps: `p, role:viewer-a, applications, get, team-a/*, allow`, then bind users/groups with a g line. They can view team-a apps but not sync or modify them, and nothing outside the project.

p, role:viewer-a, applications, get, team-a/*, allow
g, team-a-viewers, role:viewer-a

Real-world example Auditors get read-only visibility into team A's apps without any change rights.

Common follow-ups: What action gives view-only? | How do you scope to one project?

Applications Multi-cluster RBAC

How does the scopes setting affect group mapping?

Advanced

The scopes field in argocd-rbac-cm tells ArgoCD which token claims to read for subject matching (commonly groups, sometimes email). If it doesn't reference the claim your IdP sends, g bindings won't match and users fall to the default role. Correct scopes are essential for SSO group RBAC to work.

data:
  scopes: '[groups, email]'

Real-world example Adding groups to scopes fixes users landing on readonly because their group claim wasn't being read.

Common follow-ups: Why might group bindings silently fail? | What claims can scopes reference?

Multi-cluster Applications RBAC

What is a local account and when would you use one?

Intermediate

Local accounts are ArgoCD-managed users (defined in argocd-cm) with passwords or tokens, used for automation or break-glass access when SSO is unavailable. They should be limited and carefully permissioned; SSO is preferred for humans, local accounts for specific service/automation needs.

# argocd-cm
data:
  accounts.ci-bot: apiKey

Real-world example A ci-bot local account issues an API token for the pipeline, separate from human SSO logins.

Common follow-ups: When are local accounts appropriate? | Why prefer SSO for humans?

Applications Multi-cluster RBAC

How do project roles and tokens enable least-privilege automation?

Advanced

AppProject roles define scoped policies for that project, and you generate JWT tokens bound to a role. CI uses such a token to, say, sync only that project's apps—no admin account needed. This confines automation to exactly the actions and objects it requires.

roles:
  - name: deployer
    policies: [ 'p, proj:team-a:deployer, applications, sync, team-a/*, allow' ]

Real-world example The pipeline's project-scoped token can sync team-a apps only, never affecting other projects.

Common follow-ups: How is a project token scoped? | Why not use an admin token for CI?

Applications Multi-cluster RBAC

How do you manage RBAC declaratively under GitOps?

Intermediate

Store the argocd-rbac-cm ConfigMap (policy.csv, policy.default, scopes) in Git and let ArgoCD (or the install) apply it, so access-control changes go through pull requests and review. This versions permissions and provides an audit trail of who changed access and when.

Real-world example Granting a new team access is a reviewed PR to the argocd-rbac-cm manifest, not a manual console change.

Common follow-ups: What's the benefit of RBAC in Git? | Do changes need a restart?

GitOps Principles Applications RBAC