A developer’s kubeconfig user receives Forbidden when applying a Deployment in the permits namespace. What is the most likely authorization issue?
Select an answer to reveal the explanation.
Short Explanation
Forbidden on apply is the bouncer saying your badge lacks “create Deployments” for that floor. Fix the Role/RoleBinding verbs and resources. DNS and TLS ciphers are not RBAC.
Full Explanation
Forbidden when applying a Deployment in the permits namespace is an authorization failure after successful authentication: the API knows who the developer is, but RBAC denies create on deployments in that namespace. The most likely issue is that their Role or RoleBinding lacks permission to create Deployments in permits. For municipal self-service platforms, the fix is a least-privilege Role granting the needed Deployment verbs and a RoleBinding to the user or group—scoped to permits—rather than chasing unrelated pod fields.
Omitting preferred CPU architecture in pod affinity fails as an explanation for Forbidden; affinity mistakes may affect scheduling after admission, not RBAC denial of the create call. Claiming CoreDNS lacks a stub domain for the developer's email address fails conceptually because DNS configuration does not evaluate Deployment create authorization. Asserting that an Ingress TLS Secret cipher suite drives RBAC evaluation fails because TLS settings on Ingress objects are unrelated to whether a user may create Deployments.
Exam caveat: a ClusterRoleBinding might be wrong-sized for a namespace-only need, and a RoleBinding in the wrong namespace will not authorize creates in permits. Operational check: run kubectl auth can-i create deployments -n permits as that user, inspect Role and RoleBinding subjects and rules, add create (and related verbs as required), re-apply the Deployment, and confirm it is stored without Forbidden.