Overview
This domain covers everything around a container that is not the image itself. You create ConfigMaps and Secrets from literals and files and inject them as environment variables or mounted files. You set resource requests and limits, then work within a namespace ResourceQuota and the defaults a LimitRange applies. You create ServiceAccounts, attach them to Pods and bind Roles so an application can call the API with only the rights it needs. Security contexts set the user and group a container runs as, block privilege escalation, make the root filesystem read-only and add or drop Linux capabilities.
Two competencies look outward. Authentication, authorization and admission control explain why a request is accepted or rejected, including Pod Security Admission labels on namespaces. Custom Resource Definitions and Operators show how Kubernetes is extended with new kinds that you can list, describe and create like built-in objects.
How it's tested
Configuration and security tasks often combine several objects. One task may ask you to create a ConfigMap and a Secret, inject both into a Deployment, run it as a specific user and fit it under a quota. The grader checks each field, so names, keys and mount paths must match the task exactly.
-
Inject configuration
Create a ConfigMap or Secret with given keys, then expose it as environment variables, a single variable or files under a mount path.
-
Identity and permissions
Create a ServiceAccount, bind a Role allowing specific verbs, assign it to a Deployment and confirm with kubectl auth can-i.
-
Constrained namespace
A ResourceQuota, LimitRange or Pod Security level blocks a workload, and you adjust requests, limits or securityContext until it is admitted.
A Deployment in namespace team-a stays at zero ready Pods, and its ReplicaSet events say the Pods must specify requests and limits for cpu and memory. A ResourceQuota on compute resources requires every new Pod to declare them. Adding requests and limits within the remaining quota to the container fixes it. Raising replicas or deleting Pods does nothing, because the API server rejects each Pod at admission.
Competencies 8
Official competencies from the CNCF / The Linux Foundation outline, in outline order.
4.1 Discover and use resources that extend Kubernetes (CRD, Operators)Finding and using CustomResourceDefinitions and Operator-managed resources.
- What it means
- A CustomResourceDefinition adds a new resource kind to the API. An Operator is a controller that watches those custom resources and acts on them, packaging operational knowledge for an application.
- What to understand
- List extensions with kubectl get crd and kubectl api-resources, which shows the group, kind and short names. kubectl explain kind.spec reveals the schema when the CRD publishes one. Create instances with YAML that uses the CRD's group/version as apiVersion and its kind. A custom resource does nothing unless a controller watches it, so check that the Operator's Pods are running when objects are not reconciled.
- How it shows up
- Expect to find a custom resource kind in the cluster and create or modify an instance of it.
- Common confusion
- Using the CRD's plural name as kind instead of the singular kind in apiVersion and kind fields.
4.2 Understand authentication, authorization and admission controlHow API requests are authenticated, authorized with RBAC and admitted.
- What it means
- Every API request passes three stages: authentication identifies the user or ServiceAccount, authorization decides whether the action is allowed, and admission controllers can modify or reject the object before it is stored.
- What to understand
- RBAC Roles and ClusterRoles list verbs on resources; RoleBindings and ClusterRoleBindings grant them to users, groups or ServiceAccounts. Check access with kubectl auth can-i verb resource --as=system:serviceaccount:ns:name -n ns. Admission controllers include LimitRanger, ResourceQuota and Pod Security Admission, which enforces privileged, baseline or restricted levels set by namespace labels such as pod-security.kubernetes.io/enforce. A Forbidden error means authorization; a policy violation message means admission.
- How it shows up
- You may grant a ServiceAccount specific rights or explain why a Pod is rejected by a Pod Security level.
- Common confusion
- Treating a Pod Security rejection as an RBAC problem and adding more permissions.
4.3 Understand requests, limits, quotasResourceQuota and LimitRange in a namespace.
- What it means
- Requests and limits are per container. ResourceQuota caps the totals a namespace may consume and the number of objects it may hold, while LimitRange sets defaults, minimums and maximums for individual containers.
- What to understand
- A quota can limit requests.cpu, requests.memory, limits.cpu, limits.memory, pods, services and other counts. When a quota covers a compute resource, every new Pod must specify it unless a LimitRange provides a default. Check usage with kubectl describe quota. LimitRange default sets limits, defaultRequest sets requests, and max or min reject containers outside the range. Both apply only to Pods created after they exist.
- How it shows up
- Expect to create a quota with given values or fix a Deployment that a quota rejects.
- Common confusion
- Expecting a new quota or LimitRange to change Pods that are already running.
4.4 Define resource requirementsSetting container CPU and memory requests and limits.
- What it means
- Resource requirements tell the scheduler how much a container needs and tell the kubelet the most it may use. Requests drive placement; limits drive throttling and termination.
- What to understand
- Write resources.requests and resources.limits per container using millicores such as 250m and binary units such as 128Mi. A container over its CPU limit is throttled; over its memory limit it is OOMKilled. Equal requests and limits for CPU and memory in every container put the Pod in the top QoS class, any request gives Burstable, and none gives BestEffort. Pods stay Pending when no node has enough unrequested capacity. kubectl set resources edits a Deployment quickly.
- How it shows up
- A task gives exact request and limit values to add to a Deployment's containers.
- Common confusion
- Writing 128M when 128Mi is required, or 0.5 CPU in a field expecting 500m; both are valid but not equal.
4.5 Understand ConfigMapsCreating ConfigMaps and consuming them as variables or files.
- What it means
- A ConfigMap stores non-sensitive configuration as key-value pairs so the same image can run in different environments without rebuilding.
- What to understand
- Create with kubectl create configmap name --from-literal, --from-file or --from-env-file. Consume a key with env valueFrom.configMapKeyRef, all keys with envFrom.configMapRef, or files through a configMap volume, optionally choosing keys with items. Mounted files update after a delay when the ConfigMap changes, but environment variables and subPath mounts do not. Setting immutable: true prevents edits.
- How it shows up
- Expect to create a ConfigMap from a file and mount it at a given directory in a Deployment.
- Common confusion
- Expecting environment variables to change after editing the ConfigMap without restarting Pods.
4.6 Create & consume SecretsGeneric, TLS and registry Secrets and how Pods use them.
- What it means
- Secrets hold sensitive data such as passwords, tokens and keys. Values are base64-encoded in the API, which is encoding, not encryption, so access should be restricted with RBAC.
- What to understand
- Create with kubectl create secret generic name --from-literal or --from-file, secret tls with --cert and --key, or secret docker-registry for image pulls. Use stringData in YAML to avoid manual encoding. Consume with env valueFrom.secretKeyRef, envFrom.secretRef, a secret volume with optional defaultMode, or imagePullSecrets on the Pod. Decode a value with jsonpath and base64 -d.
- How it shows up
- You may create a Secret and expose one key as an environment variable with a different name.
- Common confusion
- Putting plain text under data instead of stringData, which fails or stores the wrong value.
4.7 Understand ServiceAccountsPod identities for API access and token mounting.
- What it means
- A ServiceAccount is the identity a Pod uses when it talks to the Kubernetes API. Each namespace has a default ServiceAccount, and Pods use it unless the spec names another.
- What to understand
- Create one with kubectl create serviceaccount name and set spec.serviceAccountName in the Pod template. Grant rights through a RoleBinding whose subject is the ServiceAccount. Pods receive a short-lived token through a projected volume; set automountServiceAccountToken: false when the app never calls the API. kubectl create token name issues a token on demand. A running Pod's ServiceAccount cannot be changed, but editing a Deployment template rolls new Pods.
- How it shows up
- Expect to create a ServiceAccount, bind it to a Role and assign it to a Deployment.
- Common confusion
- Using the deprecated serviceAccount field or editing a bare Pod's ServiceAccount in place.
4.8 Understand Application Security (SecurityContexts, Capabilities, etc.)Pod and container securityContext settings.
- What it means
- A securityContext sets privilege and access controls for a Pod or container: which user and group run the process, whether it may gain privileges, and which kernel capabilities it holds.
- What to understand
- Pod-level fields include runAsUser, runAsGroup, fsGroup, runAsNonRoot and seccompProfile; container-level fields override them and add allowPrivilegeEscalation, readOnlyRootFilesystem, privileged and capabilities with add and drop lists. Capabilities are container-only. Drop ALL and add back only what is needed, such as NET_BIND_SERVICE. The restricted Pod Security level requires runAsNonRoot, no privilege escalation, dropped capabilities and a RuntimeDefault seccomp profile.
- How it shows up
- Expect to set a user ID, drop capabilities or make the root filesystem read-only for one container.
- Common confusion
- Placing capabilities in the Pod-level securityContext, where the field does not exist.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
envFrom vs valueFrom
envFrom imports every key; valueFrom picks one key into one variable.
- Remember
- valueFrom lets you rename the variable.
- Tested as
- Tasks often specify a variable name different from the key.
- Trap
- Using envFrom when only one key with a new name is wanted.
-
ConfigMap volume updates
Mounted ConfigMap files refresh after the kubelet sync period.
- Remember
- subPath mounts and environment variables never refresh.
- Tested as
- Explains why config changes seem ignored.
- Trap
- Expecting env vars to update without a rollout restart.
-
Secret encoding
data holds base64 values; stringData accepts plain text.
- Remember
- base64 is reversible and not encryption.
- Tested as
- Secret creation and decoding tasks.
- Trap
- Double-encoding values that were already base64.
-
Requests and limits
Requests reserve capacity for scheduling; limits cap use.
- Remember
- CPU over limit throttles; memory over limit kills.
- Tested as
- Most config tasks include resource values.
- Trap
- Swapping requests and limits in the YAML.
-
QoS classes
Three classes, from highest to lowest eviction protection, follow from requests and limits; the lower two are Burstable and BestEffort.
- Remember
- The highest class needs requests equal to limits for CPU and memory in every container.
- Tested as
- Asked about in eviction and design reasoning.
- Trap
- Forgetting that a container with limits but no requests gets requests copied from its limits.
-
ResourceQuota enforcement
Rejects Pods that would exceed namespace totals or omit required fields.
- Remember
- Errors appear on the ReplicaSet events, not on a Pod.
- Tested as
- Common cause of Deployments with zero Pods.
- Trap
- Looking for a failing Pod that was never created.
-
LimitRange defaults
Supplies default requests and limits to containers that omit them.
- Remember
- Applies at admission, only to new Pods.
- Tested as
- Lets workloads fit a quota without editing them.
- Trap
- Assuming it limits namespace totals.
-
kubectl auth can-i
Answers whether a subject may perform an action.
- Remember
- --as=system:serviceaccount:ns:name tests a ServiceAccount.
- Tested as
- Verifies RBAC tasks quickly.
- Trap
- Forgetting the namespace flag and testing the wrong scope.
-
Pod Security Admission
Enforces privileged, baseline or restricted standards per namespace.
- Remember
- Set with labels such as pod-security.kubernetes.io/enforce=restricted.
- Tested as
- Explains rejections of otherwise valid Pods.
- Trap
- Trying to fix the rejection with RBAC.
-
Capabilities
Fine-grained Linux privileges added or dropped per container.
- Remember
- Only in container securityContext; names omit the CAP_ prefix.
- Tested as
- Common security task detail.
- Trap
- Writing CAP_NET_ADMIN or placing capabilities at Pod level.
-
runAsNonRoot
Blocks the container if it would run as UID 0.
- Remember
- Combine with runAsUser or an image USER that is not root.
- Tested as
- Required by the restricted level.
- Trap
- Setting it on an image that runs as root and wondering why the Pod fails.
-
Custom resources
New kinds served by the API after a CRD is installed.
- Remember
- kubectl api-resources shows group, version and kind.
- Tested as
- Extension tasks start by discovering the kind.
- Trap
- Writing an apiVersion without the CRD's group.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Ways to consume configuration
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| env with valueFrom | One key into one named variable | Can rename; fixed at container start | Expecting live updates |
| envFrom | All keys as variables | Key names become variable names | Expecting keys added to the ConfigMap later to appear without a Pod restart |
| Volume mount | Each key becomes a file | Updates propagate unless subPath is used | Mounting over a directory the app needs |
Resource controls
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Container requests/limits | Per-container needs and caps | Set in the Pod spec | Leaving them out under a compute quota |
| LimitRange | Per-container defaults and bounds in a namespace | Fills in or rejects individual containers | Thinking it caps the namespace total |
| ResourceQuota | Namespace-wide totals and object counts | Rejects Pods that would exceed totals | Expecting it to affect running Pods |
Why a request is refused
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Authentication failure | Credentials missing or invalid | Returns 401 Unauthorized | Adding RBAC rules for an unknown user |
| Authorization failure | RBAC does not allow the verb | Returns 403 Forbidden naming the user and verb | Binding the Role in the wrong namespace |
| Admission rejection | A controller such as quota or Pod Security refused the object | Message names the policy that was violated | Granting more RBAC permissions |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Quota error hidden from view
- What candidates pick
- Looking for a failing Pod with kubectl get pods.
- Why it looks right
- Most failures show on a Pod.
- Why it's wrong
- Pods rejected at admission are never created, so the error appears only in the ReplicaSet events.
Clue to watch for A Deployment showing 0 of N ready and no Pods listed.
-
Capability at the wrong level
- What candidates pick
- spec.securityContext.capabilities.
- Why it looks right
- Other security fields work at Pod level.
- Why it's wrong
- capabilities exists only on the container securityContext, so the setting is rejected or ignored.
Clue to watch for Any task mentioning add or drop of a capability.
-
Secret value encoded twice
- What candidates pick
- Running base64 and then using --from-literal.
- Why it looks right
- Secrets are known to be base64.
- Why it's wrong
- kubectl create secret encodes values itself, so the stored value becomes the encoded string, not the password.
Clue to watch for A plain password given in the task.
-
Variable name mismatch
- What candidates pick
- envFrom for a single renamed key.
- Why it looks right
- envFrom is shorter to write.
- Why it's wrong
- envFrom keeps the original key names, so the variable the task names never exists.
Clue to watch for A task stating both a key name and a different variable name.
-
RBAC subject typo
- What candidates pick
- Subject kind User with the ServiceAccount name.
- Why it looks right
- Both are names in the same list.
- Why it's wrong
- A ServiceAccount subject needs kind ServiceAccount and its namespace; a User of that name is a different identity.
Clue to watch for kubectl create rolebinding with --user instead of --serviceaccount=ns:name.
-
Pod Security blamed on RBAC
- What candidates pick
- Granting more permissions after a Pod is refused.
- Why it looks right
- The error comes from the API server.
- Why it's wrong
- A violation of the namespace's Pod Security level is an admission decision that RBAC cannot override.
Clue to watch for An error naming the restricted or baseline policy.
-
CRD kind written as plural
- What candidates pick
- kind: databases in the custom resource YAML.
- Why it looks right
- kubectl get databases works.
- Why it's wrong
- The plural is for URLs and kubectl; the kind field needs the singular CamelCase kind defined in the CRD.
Clue to watch for kubectl api-resources showing both NAME and KIND columns.
Answer framework
Use these steps whenever a task attaches configuration, identity, resources or security settings to a workload.
- List every object the task needs, such as ConfigMap, Secret, ServiceAccount, Role or quota, with exact names and keys.
- Create supporting objects first with kubectl create commands so the workload can reference them immediately and Pods do not fail on missing keys.
- Edit the Pod template: env or volumes for configuration, serviceAccountName, resources, and securityContext at the correct level.
- Check namespace constraints with kubectl describe quota and limitrange, and read the namespace labels to see which Pod Security level is enforced.
- Verify with kubectl exec env, file listings, kubectl auth can-i and ReplicaSet events that everything was admitted and applied.
Practice question
Want more like this? The CKAD practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Give this domain the most practice time, since it has the largest weight and eight competencies. Start with configuration objects. Create ConfigMaps and Secrets in every supported way, then consume each through valueFrom, envFrom and a volume. Exec into the Pod and print env and the mounted files so you see exactly what each method produces.
Move on to resources and namespace limits. Create a namespace with a ResourceQuota and LimitRange, deploy a workload without resources, read the ReplicaSet events, then fix it two ways: by adding resources and by relying on LimitRange defaults. Check describe quota after each change.
Then cover identity and security. Create a ServiceAccount, bind a Role and confirm access with kubectl auth can-i. Label a namespace with the restricted Pod Security level and keep editing a Pod until it is admitted, which teaches the required securityContext fields. Finally, install a simple CRD from the Kubernetes documentation example, explore it with api-resources and explain, and create an instance of it.
FAQ
How much of the CKAD exam is Application Environment, Configuration and Security?
Application Environment, Configuration and Security is the largest CKAD domain at 25% of the score. It has eight competencies, so expect four or five tasks.
Do I need to write a Custom Resource Definition?
The competency is to discover and use resources that extend Kubernetes. Focus on finding CRDs, reading their schema with kubectl explain and creating or editing instances.
Are Secrets encrypted in Kubernetes?
Secret values are only base64-encoded in the API. Encryption at rest is a cluster setting outside CKAD scope, so access control with RBAC is the developer's main protection.
What is the difference between ResourceQuota and LimitRange?
ResourceQuota limits totals for the whole namespace. LimitRange sets defaults and bounds for each container or Pod. Both apply only when objects are created.
How deep does CKAD go into RBAC?
Expect Roles, RoleBindings and ServiceAccounts within a namespace, plus checking access with kubectl auth can-i. Cluster administration of RBAC belongs more to the CKA.
Which securityContext fields are container-only?
capabilities, allowPrivilegeEscalation, privileged and readOnlyRootFilesystem exist only on containers. runAsUser, runAsGroup and runAsNonRoot can be set at either level, with the container value winning.
How do I check what a Secret contains?
Run kubectl get secret name -o jsonpath='{.data.key}' and pipe the output to base64 -d to read the decoded value.
Other DevOps & Containers certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 4 knowledge
Test yourself on ConfigMaps, Secrets, quotas, ServiceAccounts, RBAC, custom resources and securityContext in the largest CKAD domain, worth 25%.