Who are you, may you do this, and does policy allow this exact object?

Authentication, authorization and admission run in strict order. Only a request that passes all three is written to etcd.

1 Authentication

Who are you?

Client certificate, bearer token, OIDC identity, or a ServiceAccount token. Failure: 401.

2 Authorization

Are you allowed?

Usually RBAC: may this identity create a Deployment in shop? Failure: 403.

3 Admission

Is this object acceptable?

Looks at the content: defaults, quotas, Pod Security, webhooks. Can mutate or reject.

4 Persist

Written to etcd

Only now is the desired state stored. Controllers see it through a watch.

Built-in admission controllers worth knowing

LimitRanger	fills default requests and limits
ResourceQuota	rejects objects that exceed the namespace quota
PodSecurity	enforces privileged, baseline or restricted
DefaultStorageClass	assigns a class to a PVC that names none

what each failure looks like

$ kubectl get pods --token=bad
error: You must be logged in (401)
$ kubectl create deploy x --image=nginx
forbidden: cannot create resource "deployments" (403)
$ kubectl apply -f big-pod.yaml
exceeded quota: shop-quota, requested: cpu=40

Every request passes three gates before it is stored

Every request to the API server goes through three distinct stages, always in this order. Authentication establishes identity: a client certificate, a bearer token, an OIDC token from your identity provider, or a ServiceAccount token for in-cluster workloads. If this fails you get a 401.

Authorization decides whether that identity may perform this verb on this resource in this namespace. RBAC is the standard mechanism: Roles and ClusterRoles list permissions, bindings attach them to users, groups or ServiceAccounts. A failure here is a 403. The Node authorizer additionally limits a kubelet to objects related to its own node, which limits the damage if one node is compromised.

Admission is different in kind. By now the caller is known and allowed in principle; admission asks content questions about this specific object. Built-in controllers fill defaults (LimitRanger), enforce quotas (ResourceQuota) and apply Pod Security Standards, and webhooks let you add your own rules. Only after all three does the API server persist the object.

Practical consequence for debugging: a 401 means fix your credentials, a 403 means fix RBAC, and an admission rejection names the policy that refused it. A pod that simply never appears while its quota is exceeded was refused at admission and never created, which looks different from a Pending Pod.