RBAC Interview Questions & Answers

Q: How do you audit and troubleshoot effective permissions for a user?

Inspect the user's token claims (groups/email), match them against g bindings and p rules, account for policy.default and deny-by-default, and use API-server debug logs showing policy decisions. Tools/UI can display a user's roles. This pinpoints why an action is allowed or denied.

Q: What is the difference between ArgoCD RBAC and Kubernetes RBAC?

ArgoCD RBAC governs actions within ArgoCD (who can view/sync/delete apps, manage clusters/repos). Kubernetes RBAC governs access to cluster API resources. A user might sync an app in ArgoCD (ArgoCD RBAC) while ArgoCD's service account applies the resources using its Kubernetes permissions.

Q: How do you restrict which repositories a project can use?

Set sourceRepos on the AppProject to an allow-list (with wildcards) of permitted repo URLs. Apps in that project can only pull from those repos, preventing teams from deploying arbitrary or untrusted sources.

Q: How do you implement break-glass emergency access safely?

Provide a tightly controlled admin path (a local admin account or a rarely-used group binding) whose use is logged and alerted, with credentials stored securely and rotated after use. It grants elevated access during incidents when SSO/normal roles are insufficient, while keeping the action auditable.

Q: How do you prevent a team from deploying to namespaces they don't own?

Constrain the AppProject's destinations to the team's clusters/namespaces (with patterns like team-a-*). Even with sync rights, apps in that project can't target other namespaces, because the project rejects disallowed destinations at validation.

Q: How do you separate duties between who can create apps and who can sync them?

Grant create/delete on applications to platform admins and only get/sync to developers, via distinct roles. This separation means developers can deploy approved apps but not create arbitrary ones or remove them, enforcing change control and least privilege.

Q: How do you bind a user (not a group) to a role?

Use a g line with the username: `g, alice, role:dev`. This is common for local accounts or when not using group claims. For SSO, binding groups scales better than individual users.

Q: What permissions are needed to manage ApplicationSets?

The applicationsets resource in RBAC controls who can create/update/delete ApplicationSets. Because an ApplicationSet can generate many apps, this is a powerful permission usually reserved for platform admins, separate from ordinary application sync rights.

Q: How do you enforce that only signed/approved commits get deployed?

Combine Git signature verification (ArgoCD can require signed commits via configured GPG keys on the Project) with branch protection requiring reviews. Only commits signed by trusted keys and merged through review are deployed, adding supply-chain integrity to RBAC and process controls.

How do you audit and troubleshoot effective permissions for a user?

Advanced

Inspect the user's token claims (groups/email), match them against g bindings and p rules, account for policy.default and deny-by-default, and use API-server debug logs showing policy decisions. Tools/UI can display a user's roles. This pinpoints why an action is allowed or denied.

Real-world example Debug logs reveal a denied sync stemmed from a group claim not listed in scopes, which is then corrected.

Common follow-ups: What do you check first for a denial? | How do debug logs help?

Multi-cluster Applications RBAC

What is the difference between ArgoCD RBAC and Kubernetes RBAC?

Beginner

ArgoCD RBAC governs actions within ArgoCD (who can view/sync/delete apps, manage clusters/repos). Kubernetes RBAC governs access to cluster API resources. A user might sync an app in ArgoCD (ArgoCD RBAC) while ArgoCD's service account applies the resources using its Kubernetes permissions.

Real-world example A developer with ArgoCD sync rights triggers deploys, but the actual apply uses ArgoCD's own Kubernetes permissions.

Common follow-ups: Who actually applies resources to the cluster? | Which RBAC governs app sync?

Applications Multi-cluster RBAC

How do you restrict which repositories a project can use?

Intermediate

Set sourceRepos on the AppProject to an allow-list (with wildcards) of permitted repo URLs. Apps in that project can only pull from those repos, preventing teams from deploying arbitrary or untrusted sources.

spec:
  sourceRepos: [ 'https://github.com/org/team-a-*' ]

Real-world example Team A's project only permits its own repos, so it can't deploy manifests from an unapproved source.

Common follow-ups: Where is the repo allow-list set? | Why restrict source repos?

Applications Multi-cluster RBAC

How do you implement break-glass emergency access safely?

Advanced

Provide a tightly controlled admin path (a local admin account or a rarely-used group binding) whose use is logged and alerted, with credentials stored securely and rotated after use. It grants elevated access during incidents when SSO/normal roles are insufficient, while keeping the action auditable.

Real-world example During an SSO outage, an on-call lead uses a monitored break-glass account to restore service, triggering an audit alert.

Common follow-ups: Why log break-glass use? | When is break-glass justified?

Applications Multi-cluster RBAC

How do you prevent a team from deploying to namespaces they don't own?

Intermediate

Constrain the AppProject's destinations to the team's clusters/namespaces (with patterns like team-a-*). Even with sync rights, apps in that project can't target other namespaces, because the project rejects disallowed destinations at validation.

destinations:
  - server: '*'
    namespace: 'team-a-*'

Real-world example Team A's apps can only deploy into team-a-* namespaces; a manifest targeting kube-system is rejected.

Common follow-ups: What enforces the namespace limit? | Do sync rights override project destinations?

Applications Multi-cluster RBAC

How do you separate duties between who can create apps and who can sync them?

Advanced

Grant create/delete on applications to platform admins and only get/sync to developers, via distinct roles. This separation means developers can deploy approved apps but not create arbitrary ones or remove them, enforcing change control and least privilege.

p, role:dev, applications, sync, '*/*', allow
p, role:platform, applications, create, '*/*', allow

Real-world example Developers sync existing apps while only the platform team can create or delete Application definitions.

Common follow-ups: How does omitting create limit developers? | Why separate these duties?

Applications Sync & Health RBAC

How do you bind a user (not a group) to a role?

Beginner

Use a g line with the username: `g, alice, role:dev`. This is common for local accounts or when not using group claims. For SSO, binding groups scales better than individual users.

policy.csv: |
  g, alice, role:dev

Real-world example A specific automation user 'alice' is bound directly to the dev role.

Common follow-ups: User vs group bindings? | Why prefer groups for SSO?

Applications Multi-cluster RBAC

What permissions are needed to manage ApplicationSets?

Intermediate

The applicationsets resource in RBAC controls who can create/update/delete ApplicationSets. Because an ApplicationSet can generate many apps, this is a powerful permission usually reserved for platform admins, separate from ordinary application sync rights.

p, role:platform, applicationsets, *, '*/*', allow

Real-world example Only platform admins can edit ApplicationSets, since one change can spawn or remove many Applications.

Common follow-ups: Why guard ApplicationSet permissions tightly? | Which resource governs them?

Applications Multi-cluster RBAC

How do you enforce that only signed/approved commits get deployed?

Advanced

Combine Git signature verification (ArgoCD can require signed commits via configured GPG keys on the Project) with branch protection requiring reviews. Only commits signed by trusted keys and merged through review are deployed, adding supply-chain integrity to RBAC and process controls.

spec:
  signatureKeys:
    - keyID: ABCDEF1234567890

Real-world example The project only syncs commits signed by approved GPG keys, blocking unsigned or tampered changes.

Common follow-ups: How does ArgoCD verify commit signatures? | How does this complement RBAC?

GitOps Principles Applications RBAC