Development teams frequently raise support tickets for short-term access to staging clusters, creating a growing burden on the platform team. What's…

Using GitOps to manage Kubernetes RBAC (Role-Based Access Control) provides the best long-term balance. This approach treats access control configurations as code, stored in a Git repository. Developers request access via pull requests (PRs), creating a transparent and auditable trail. Automating the PR approval and merge process for non-sensitive environments, like staging, eliminates the manual burden on the platform team. This empowers developers with a self-service workflow they are already familiar with, improving efficiency and experience while maintaining strict, version-controlled governance over cluster access.

B. Dedicating an engineer creates a single point of failure and a bottleneck. This approach does not scale and institutionalizes manual toil rather than solving the underlying process inefficiency.

C. Batching requests into scheduled windows severely hinders developer productivity and agility by forcing them to wait, which is contrary to creating a good developer experience.

D. Distributing static, pre-approved kubeconfigs is a significant security risk. It lacks granular control, an audit trail, and a straightforward mechanism for revocation, violating the principle of least privilege.

1. Kubernetes Official Documentation

"Using RBAC Authorization": This document details the Kubernetes RBAC API

which allows for configuring granular access policies. The GitOps approach in option A declaratively manages these Role and RoleBinding objects.

Source: Kubernetes Authors. (n.d.). Using RBAC Authorization. Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/reference/access-authn-authz/rbac/ (Specifically

the sections on Role and RoleBinding objects).

2. The Cloud Native Computing Foundation (CNCF)

Argo Project Documentation: The Argo CD documentation

a leading GitOps tool and CNCF graduated project

describes managing all cluster resources

including RBAC

declaratively from Git. This is a practical implementation of the proposed solution.

Source: Argo Project. (n.d.). Declarative Setup. Argo CD Documentation. Retrieved from https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/ (This section explains how all resources

which would include RBAC policies

are defined in Git).

3. The OpenGitOps Project

"GitOps Principles": This resource

from a CNCF Sandbox project

defines the core principles of GitOps. The correct answer aligns with these principles: declarative configuration

version control via Git

automated pull-based deployment

and continuous reconciliation.

Source: The OpenGitOps Authors. (n.d.). The GitOps Principles. OpenGitOps. Retrieved from https://opengitops.dev/principles/ (Principle 1: "A system managed by GitOps must have its state expressed declaratively" and Principle 2: "A Git repository is the canonical source of truth").