Kubernetes Quiz

Kubernetes orchestration concepts — pods, deployments, services, and how the platform manages containers at scale.

This category currently has 100 questions in the SERVBG quiz bank. Below are a few sample questions — the full interactive quiz shuffles through the whole set with instant scoring.

Sample questions

A developer needs to list and get Pods in the 'staging' namespace but must not be able to delete them. Which RBAC construct is the minimum required to grant this?

A ClusterRole with verbs ["get","list"] on 'pods' is required because namespace-scoped Roles cannot grant Pod access.
A ClusterRoleBinding to the built-in 'view' ClusterRole, which grants read-only access across all namespaces including staging.
A Role with verbs ["get","list","watch","create"] is mandatory because the API server requires create permission before allowing list.
A Role with verbs ["get","list","watch"] on resource 'pods' bound to the user via a RoleBinding in the 'staging' namespace.
A RoleBinding alone is sufficient; no Role or ClusterRole resource is needed when binding to a user by name.

A ServiceAccount 'app-sa' in namespace 'prod' is bound to a ClusterRole that includes 'impersonate' verb on 'users'. What is the primary security risk and mitigation?

The ServiceAccount can impersonate any user including cluster-admin, bypassing all RBAC controls. Revoke the impersonate verb and use dedicated service accounts with minimal permissions.
The ServiceAccount can only impersonate users listed in the same ClusterRole's resourceNames field, limiting blast radius.
Impersonation only affects audit log attribution; there is no privilege escalation risk because the impersonated user's tokens are not issued.
The risk is limited to the 'prod' namespace because ClusterRoles are scoped to the binding namespace when used with RoleBindings.
The risk is theoretical; Kubernetes API server validates that the impersonating principal has equal or higher privileges than the target user.

You run 'kubectl auth can-i create pods --as=system:serviceaccount:dev:ci-runner --namespace=prod' and it returns 'yes'. The ci-runner ServiceAccount has no RoleBindings in prod. Explain the most likely cause.

The system:authenticated group grants pod creation in all namespaces by default in standard Kubernetes installations.
A ClusterRoleBinding grants the ci-runner ServiceAccount (or a Group it belongs to) cluster-wide pod creation rights, which supersedes namespace-level restrictions.
Kubernetes RBAC caches permission decisions for 60 seconds; the 'yes' response is a stale cache hit from a recently deleted binding.
The --namespace flag in kubectl auth can-i is ignored when using --as; the check always evaluates against the default namespace.
The ci-runner ServiceAccount inherits permissions from the default ServiceAccount in the prod namespace via automatic token mounting.

Which built-in RBAC aggregation label must a ClusterRole carry for its rules to be automatically merged into the 'edit' ClusterRole?

rbac.authorization.k8s.io/merge-into-edit: "true"
rbac.authorization.k8s.io/aggregate-to-view: "true"
rbac.authorization.k8s.io/aggregate-to-admin: "true"
rbac.authorization.k8s.io/aggregate-to-edit: "true"
rbac.authorization.k8s.io/extends-edit: "true"

A Pod's ServiceAccount token is projected with 'expirationSeconds: 3600'. An attacker exfiltrates the token at T+0. At T+3601, can the attacker still use the token, and why?

Possibly yes. The token may remain valid beyond 3601 seconds because the kubelet renews tokens before expiry and the API server accepts tokens up to the configured --service-account-max-token-expiration value, which defaults to 1 year.
No. The ServiceAccount controller rotates the secret and issues a new CA bundle at expiry, making old tokens unverifiable.
Yes, but only because the attacker can use the refresh endpoint at /api/v1/serviceaccounts/token to extend it without re-authentication.
Yes unconditionally. Projected service account tokens never expire in practice because expirationSeconds is advisory only and not enforced by the API server.
No. The token is cryptographically invalidated at exactly T+3600 by the kube-apiserver token review webhook.

Start the full quiz ›