How should I use these Application Design and Build practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

Can I practise just Application Design and Build questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Application Design and Build domain.

CKAD · topic practice

Application Design and Build practice questions

Practise Certified Kubernetes Application Developer CKAD Application Design and Build practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Reviewed byJohnson Ajibi· MSc IT Security

20 questionsDomain: Application Design and Build

Practice 10 questions Browse domain →

What the exam tests

What to know about Application Design and Build

Application Design and Build questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Watch out for

Common Application Design and Build exam traps

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Practice set

Application Design and Build questions

20 questions · select your answer, then reveal the explanation

Question 1hardmultiple choice

Read the full Application Design and Build explanation →

A team is deploying a microservice that requires initialization of a database schema before the main application starts. The init container must run a script that writes to a shared volume. Which configuration correctly ensures the init container completes before the main container runs?

Trap 1: Run the script as a sidecar container that shares the volume with…

Sidecar containers run concurrently, so the script may not finish before the main app starts.

Trap 2: Use a postStart lifecycle hook on the main container to run the…

postStart runs after the container starts, not before, and may not complete before the app begins.

Trap 3: Add a readiness probe to the main container that checks the shared…

Readiness probes check container readiness but do not guarantee init container completion.

Study all Application Design and Build common traps →

A
Run the script as a sidecar container that shares the volume with the main container.
Why wrong: Sidecar containers run concurrently, so the script may not finish before the main app starts.
B
Use a postStart lifecycle hook on the main container to run the script.
Why wrong: postStart runs after the container starts, not before, and may not complete before the app begins.
C
Define an init container with the script and mount the shared volume to both init and main containers.
Init containers run to completion before app containers start, and shared volumes persist data.
D
Add a readiness probe to the main container that checks the shared volume.
Why wrong: Readiness probes check container readiness but do not guarantee init container completion.

Full breakdown with real-world context →

Question 2mediummultiple choice

Read the full Application Design and Build explanation →

A developer needs to expose a deployment named 'web-app' running on port 8080 to external traffic. The cluster is on-premises with no cloud load balancer. Which service type should be used?

Trap 1: ExternalName

ExternalName maps to an external DNS name, not a service port.

Trap 2: ClusterIP

ClusterIP is only reachable within the cluster.

Trap 3: LoadBalancer

LoadBalancer requires a cloud provider; on-premises it behaves like NodePort but may not work.

Study all Application Design and Build common traps →

A
ExternalName
Why wrong: ExternalName maps to an external DNS name, not a service port.
B
ClusterIP
Why wrong: ClusterIP is only reachable within the cluster.
C
LoadBalancer
Why wrong: LoadBalancer requires a cloud provider; on-premises it behaves like NodePort but may not work.
D
NodePort
NodePort exposes a port on each node's IP address for external access.

Full breakdown with real-world context →

Question 3easymultiple choice

Read the full Application Design and Build explanation →

A developer is creating a ConfigMap from a file named 'app.properties'. The file contains key-value pairs. Which command correctly creates the ConfigMap with keys matching the file content?

Trap 1: kubectl create configmap my-config --from-literal=app.properties

--from-literal expects key=value, not a file.

Trap 2: cat app.properties | kubectl create configmap my-config…

kubectl create configmap does not accept stdin with --from-file=-.

Trap 3: kubectl create configmap my-config --from-env-file=app.properties

--from-env-file is not a valid flag; correct is --from-env-file (but that's for env-style files).

Study all Application Design and Build common traps →

A
kubectl create configmap my-config --from-file=app.properties
--from-file creates a configmap with a key named 'app.properties' containing file content.
B
kubectl create configmap my-config --from-literal=app.properties
Why wrong: --from-literal expects key=value, not a file.
C
cat app.properties | kubectl create configmap my-config --from-file=-
Why wrong: kubectl create configmap does not accept stdin with --from-file=-.
D
kubectl create configmap my-config --from-env-file=app.properties
Why wrong: --from-env-file is not a valid flag; correct is --from-env-file (but that's for env-style files).

Full breakdown with real-world context →

Question 4mediummulti select

Read the full Application Design and Build explanation →

Which TWO statements are true about Kubernetes Secrets?

Trap 1: Secrets cannot be used as environment variables.

Secrets can be exposed as environment variables via envFrom or valueFrom.

Trap 2: Secrets are always encrypted at rest by default.

Not encrypted by default; requires encryption configuration.

Trap 3: Secrets are limited to 1KB in size.

Secret size limit is 1MB.

Study all Application Design and Build common traps →

A
Secret data is base64 encoded in YAML manifests.
Secret values are base64 encoded, not plaintext.
B
Secrets cannot be used as environment variables.
Why wrong: Secrets can be exposed as environment variables via envFrom or valueFrom.
C
Secrets are always encrypted at rest by default.
Why wrong: Not encrypted by default; requires encryption configuration.
D
Secrets can be mounted as volumes in a Pod.
Secrets can be mounted as files using volumes.
E
Secrets are limited to 1KB in size.
Why wrong: Secret size limit is 1MB.

Full breakdown with real-world context →

Question 5hardmulti select

Read the full Application Design and Build explanation →

Which THREE are valid reasons to use a StatefulSet instead of a Deployment?

Trap 1: The application requires rolling updates.

Both Deployments and StatefulSets support rolling updates.

Trap 2: The application cannot be scaled down.

StatefulSets can be scaled down; pods are terminated in reverse order.

Study all Application Design and Build common traps →

A
The application requires rolling updates.
Why wrong: Both Deployments and StatefulSets support rolling updates.
B
Each pod requires a stable, unique network identity.
StatefulSets assign stable hostnames based on ordinal index.
C
Each pod needs its own persistent volume that persists across rescheduling.
StatefulSets can use volumeClaimTemplates to give each pod a unique PVC.
D
The application cannot be scaled down.
Why wrong: StatefulSets can be scaled down; pods are terminated in reverse order.
E
Pods must be terminated in reverse order during shutdown.
StatefulSets terminate pods from highest to lowest ordinal.

Full breakdown with real-world context →

Question 6easymultiple choice

Read the full Application Design and Build explanation →

A developer is designing a Job that should run exactly once and then stop. The Job runs a batch process that is expected to complete within one hour. Which restartPolicy and backoffLimit are appropriate?

Trap 1: restartPolicy: Always, backoffLimit: 6

Always is not allowed for Jobs.

Trap 2: restartPolicy: Never, backoffLimit: 0

Never means no retries; backoffLimit 0 is default but no retries.

Trap 3: restartPolicy: Always, backoffLimit: 0

Always is not valid for Jobs; it's for Deployments.

Study all Application Design and Build common traps →

A
restartPolicy: Always, backoffLimit: 6
Why wrong: Always is not allowed for Jobs.
B
restartPolicy: OnFailure, backoffLimit: 4
OnFailure retries within the backoff limit; Job completes when pod succeeds.
C
restartPolicy: Never, backoffLimit: 0
Why wrong: Never means no retries; backoffLimit 0 is default but no retries.
D
restartPolicy: Always, backoffLimit: 0
Why wrong: Always is not valid for Jobs; it's for Deployments.

Full breakdown with real-world context →

Question 7mediummultiple choice

Read the full Application Design and Build explanation →

A developer creates a Deployment with 3 replicas that uses a ConfigMap mounted as a volume. After updating the ConfigMap, the developer expects the pods to pick up the new configuration immediately, but the old configuration is still in use. What is the most likely reason?

Trap 1: ConfigMap updates are not propagated to mounted volumes.

Updates are propagated, but not instantly.

Trap 2: The pods must be recreated after a ConfigMap update to see the…

Mounted ConfigMaps are updated without pod restart, but with a delay.

Trap 3: ConfigMaps are immutable and cannot be updated.

ConfigMaps can be updated; immutability is optional.

Study all Application Design and Build common traps →

A
ConfigMap updates are not propagated to mounted volumes.
Why wrong: Updates are propagated, but not instantly.
B
The kubelet sync interval delays the propagation of ConfigMap changes to pods.
The kubelet periodically syncs ConfigMap data; changes may take up to the sync period to appear.
C
The pods must be recreated after a ConfigMap update to see the changes.
Why wrong: Mounted ConfigMaps are updated without pod restart, but with a delay.
D
ConfigMaps are immutable and cannot be updated.
Why wrong: ConfigMaps can be updated; immutability is optional.

Full breakdown with real-world context →

Question 8mediummultiple choice

Read the full Application Design and Build explanation →

You are tasked with deploying a stateless web application on a Kubernetes cluster. The application is containerized and listens on port 8080. You have created a Deployment named 'webapp' with 3 replicas, and a ClusterIP Service named 'webapp-svc' exposing port 80 targeting the application's port 8080. During testing, you notice that some requests to the service return errors while others succeed. You have verified that all Pods are running and ready. The application logs show no errors. What is the most likely cause of the intermittent failures?

Trap 1: The ClusterIP Service type does not support load balancing.

Incorrect; ClusterIP Services do provide internal load balancing.

Trap 2: The Service is not configured with enough endpoints.

Incorrect; Kubernetes Services dynamically manage endpoints based on Pod labels and readiness.

Trap 3: The Service's targetPort is set incorrectly, causing traffic to be…

Incorrect; the targetPort is correctly set to 8080, so this would not cause intermittent failures.

Study all Application Design and Build common traps →

A
The ClusterIP Service type does not support load balancing.
Why wrong: Incorrect; ClusterIP Services do provide internal load balancing.
B
The Service is not configured with enough endpoints.
Why wrong: Incorrect; Kubernetes Services dynamically manage endpoints based on Pod labels and readiness.
C
The Service's targetPort is set incorrectly, causing traffic to be misrouted.
Why wrong: Incorrect; the targetPort is correctly set to 8080, so this would not cause intermittent failures.
D
The Deployment lacks a readiness probe, causing the Service to route traffic to Pods that are not ready.
Correct; without a readiness probe, the Service may send traffic to Pods that are not ready, leading to intermittent failures.

Full breakdown with real-world context →

Question 9mediumdrag order

Read the full Application Design and Build explanation →

Arrange the steps to create a Kubernetes Deployment with a rolling update strategy.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Question 10mediumdrag order

Read the full Application Design and Build explanation →

Sequence the steps to expose a Kubernetes Service using a NodePort for external access.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Question 11mediummatching

Read the full Application Design and Build explanation →

Match each Kubernetes resource to its primary purpose.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Smallest deployable unit running containers

Stable network endpoint for a set of pods

Store non-sensitive configuration data

Request for storage resources

HTTP and HTTPS routing to services

Question 12mediummatching

Read the full Application Design and Build explanation →

Match each Kubernetes Service type to its behavior.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Exposes service on a cluster-internal IP

Exposes service on each node's IP at a static port

Exposes service externally using a cloud load balancer

Maps service to a DNS name

No cluster IP; used for stateful workloads

Question 13mediummultiple choice

Read the full Application Design and Build explanation →

A developer has a Dockerfile that builds a Go application. The final image size is 800MB. Which improvement would MOST reduce the image size?

Trap 1: Combine all RUN commands into a single layer

Combining RUN commands reduces layers but does not eliminate build-time dependencies.

Trap 2: Add a .dockerignore file to exclude unnecessary files

.dockerignore reduces build context size but the largest contributor is often the base image and build deps.

Trap 3: Use a smaller base image like alpine:3.19

Using a smaller base image helps but multi-stage builds are more effective when the build requires many dependencies.

Study all Application Design and Build common traps →

A
Combine all RUN commands into a single layer
Why wrong: Combining RUN commands reduces layers but does not eliminate build-time dependencies.
B
Add a .dockerignore file to exclude unnecessary files
Why wrong: .dockerignore reduces build context size but the largest contributor is often the base image and build deps.
C
Use a smaller base image like alpine:3.19
Why wrong: Using a smaller base image helps but multi-stage builds are more effective when the build requires many dependencies.
D
Use multi-stage builds with a scratch final stage
Multi-stage builds allow copying only the compiled binary to a minimal final image, removing all build tools.

Full breakdown with real-world context →

Question 14easymultiple choice

Read the full Application Design and Build explanation →

What is the primary purpose of an Init Container in a Pod?

Trap 1: Run a sidecar proxy alongside the main container

That describes a sidecar container, not an init container.

Trap 2: Provide a health check endpoint for the main container

Health checks are defined in the main container spec (liveness/readiness probes), not init containers.

Trap 3: Collect logs and metrics from the main container

That is a common sidecar pattern, not an init container.

Study all Application Design and Build common traps →

A
Perform initialization tasks such as waiting for a database to be ready
Init containers handle prerequisites before the application starts.
B
Run a sidecar proxy alongside the main container
Why wrong: That describes a sidecar container, not an init container.
C
Provide a health check endpoint for the main container
Why wrong: Health checks are defined in the main container spec (liveness/readiness probes), not init containers.
D
Collect logs and metrics from the main container
Why wrong: That is a common sidecar pattern, not an init container.

Full breakdown with real-world context →

Question 15mediummultiple choice

Read the full Application Design and Build explanation →

A user runs: kubectl run my-pod --image=nginx --restart=Never --dry-run=client -o yaml. Which apiVersion is used in the generated YAML?

Trap 1: apps/v1

apps/v1 is for Deployments, but '--restart=Never' creates a Pod, which uses v1.

Trap 2: batch/v1

batch/v1 is for Jobs and CronJobs.

Trap 3: networking.k8s.io/v1

networking.k8s.io/v1 is for NetworkPolicy and Ingress.

Study all Application Design and Build common traps →

A
apps/v1
Why wrong: apps/v1 is for Deployments, but '--restart=Never' creates a Pod, which uses v1.
B
batch/v1
Why wrong: batch/v1 is for Jobs and CronJobs.
C
networking.k8s.io/v1
Why wrong: networking.k8s.io/v1 is for NetworkPolicy and Ingress.
D
v1
The command creates a Pod, and Pods are in the core v1 API group.

Full breakdown with real-world context →

Question 16hardmultiple choice

Read the full Application Design and Build explanation →

A CronJob is configured with concurrencyPolicy: Replace and a job execution takes 10 minutes. The schedule is /5 * * *. Which statement is true about job executions?

Trap 1: Jobs will never overlap because the schedule is too frequent

The schedule is more frequent than job duration, so overlap would occur without Replace.

Trap 2: The job will be skipped if the previous one hasn't finished

That describes Forbid policy, not Replace.

Trap 3: Jobs will overlap, with up to two jobs running concurrently

Replace policy kills the existing job, so no overlap occurs.

Study all Application Design and Build common traps →

A
Jobs will never overlap because the schedule is too frequent
Why wrong: The schedule is more frequent than job duration, so overlap would occur without Replace.
B
Every 5 minutes, a new job is created, and if the previous job is still running, it is killed
Replace policy terminates the running job and starts a new one at each scheduled time.
C
The job will be skipped if the previous one hasn't finished
Why wrong: That describes Forbid policy, not Replace.
D
Jobs will overlap, with up to two jobs running concurrently
Why wrong: Replace policy kills the existing job, so no overlap occurs.

Full breakdown with real-world context →

Question 17mediummultiple choice

Read the full Application Design and Build explanation →

A DevOps engineer wants to deploy a logging sidecar container that reads log files from the main application container. Which volume type should be used to share files between the two containers?

Trap 1: persistentVolumeClaim

PVC is for persistent storage, not needed for ephemeral sidecar log sharing.

Trap 2: configMap

ConfigMap is for configuration data, not for sharing dynamic log files.

Trap 3: hostPath

hostPath mounts a file from the node filesystem, not suitable for sharing between containers in a pod without node dependency.

Study all Application Design and Build common traps →

A
emptyDir
emptyDir is created empty and shared across all containers in the Pod, ideal for sidecar log collection.
B
persistentVolumeClaim
Why wrong: PVC is for persistent storage, not needed for ephemeral sidecar log sharing.
C
configMap
Why wrong: ConfigMap is for configuration data, not for sharing dynamic log files.
D
hostPath
Why wrong: hostPath mounts a file from the node filesystem, not suitable for sharing between containers in a pod without node dependency.

Full breakdown with real-world context →

Question 18hardmultiple choice

Read the full Application Design and Build explanation →

A Pod has two containers: one with a liveness probe that fails after 30 seconds. The restartPolicy is 'Never'. What state will the Pod be in after the liveness probe fails?

Trap 1: Running

The container is not running after the probe failure.

Trap 2: Unknown

Unknown is a temporary state when the node is unreachable.

Trap 3: CrashLoopBackOff

CrashLoopBackOff only occurs when restartPolicy is Always or OnFailure and the container keeps crashing.

Study all Application Design and Build common traps →

A
Running
Why wrong: The container is not running after the probe failure.
B
Failed
With restartPolicy: Never, the Pod enters Failed state when a container exits with non-zero or is killed.
C
Unknown
Why wrong: Unknown is a temporary state when the node is unreachable.
D
CrashLoopBackOff
Why wrong: CrashLoopBackOff only occurs when restartPolicy is Always or OnFailure and the container keeps crashing.

Full breakdown with real-world context →

Question 19easymultiple choice

Read the full Application Design and Build explanation →

Which command builds a Docker image from the current directory and tags it as 'myapp:v1'?

Trap 1: docker image build --name myapp:v1 .

There is no --name flag for docker build.

Trap 2: docker build myapp:v1 .

Missing -t flag.

Trap 3: docker tag myapp:v1 .

docker tag requires an existing image and a new tag, not a build command.

Study all Application Design and Build common traps →

A
docker image build --name myapp:v1 .
Why wrong: There is no --name flag for docker build.
B
docker build -t myapp:v1 .
Correct syntax: -t for tag, . for build context.
C
docker build myapp:v1 .
Why wrong: Missing -t flag.
D
docker tag myapp:v1 .
Why wrong: docker tag requires an existing image and a new tag, not a build command.

Full breakdown with real-world context →

Question 20mediummultiple choice

Read the full Application Design and Build explanation →

A developer wants to create a Job that runs exactly 3 pods in parallel. Which field should be set in the Job spec?

Trap 1: spec.ttlSecondsAfterFinished: 3

ttlSecondsAfterFinished controls automatic cleanup after completion.

Trap 2: spec.backoffLimit: 3

backoffLimit sets the number of retries before marking the Job as failed.

Trap 3: spec.completions: 3

completions sets the number of successful completions needed, not parallelism.

Study all Application Design and Build common traps →

A
spec.ttlSecondsAfterFinished: 3
Why wrong: ttlSecondsAfterFinished controls automatic cleanup after completion.
B
spec.backoffLimit: 3
Why wrong: backoffLimit sets the number of retries before marking the Job as failed.
C
spec.parallelism: 3
parallelism sets the maximum number of pods running in parallel.
D
spec.completions: 3
Why wrong: completions sets the number of successful completions needed, not parallelism.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Application Design and Build sessions

Start a Application Design and Build only practice session

Every question in these sessions is drawn from the Application Design and Build domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Application Design and Build questions →Mixed CKAD session

Frequently asked questions

What does the CKAD exam test about Application Design and Build?: Application Design and Build questions test whether you can apply the concept in context, not just recognise a definition.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Application Design and Build questions in a focused session?: Yes — the session launcher on this page draws every question from the Application Design and Build domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other CKAD topics?: Use the topic links above to move to related areas, or go back to the CKAD question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the CKAD exam covers. They are not copied from any real exam or dump site.

Application Design and Build only

10 questions 20 questions 30 questions 50 questions

Mixed CKAD session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All CKAD questions Application Design and Build domain overview CKAD exam guide

Exam traps to avoid

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Application Design and Build practice questions

What to know about Application Design and Build

Common Application Design and Build exam traps

Application Design and Build questions

A team is deploying a microservice that requires initialization of a database schema before the main application starts. The init container must run a script that writes to a shared volume. Which configuration correctly ensures the init container completes before the main container runs?

A developer needs to expose a deployment named 'web-app' running on port 8080 to external traffic. The cluster is on-premises with no cloud load balancer. Which service type should be used?

A developer is creating a ConfigMap from a file named 'app.properties'. The file contains key-value pairs. Which command correctly creates the ConfigMap with keys matching the file content?

Which TWO statements are true about Kubernetes Secrets?

Which THREE are valid reasons to use a StatefulSet instead of a Deployment?

A developer is designing a Job that should run exactly once and then stop. The Job runs a batch process that is expected to complete within one hour. Which restartPolicy and backoffLimit are appropriate?

A developer creates a Deployment with 3 replicas that uses a ConfigMap mounted as a volume. After updating the ConfigMap, the developer expects the pods to pick up the new configuration immediately, but the old configuration is still in use. What is the most likely reason?

Arrange the steps to create a Kubernetes Deployment with a rolling update strategy.

Sequence the steps to expose a Kubernetes Service using a NodePort for external access.

Match each Kubernetes resource to its primary purpose.

Match each Kubernetes Service type to its behavior.

A developer has a Dockerfile that builds a Go application. The final image size is 800MB. Which improvement would MOST reduce the image size?

What is the primary purpose of an Init Container in a Pod?

A user runs: kubectl run my-pod --image=nginx --restart=Never --dry-run=client -o yaml. Which apiVersion is used in the generated YAML?

A CronJob is configured with concurrencyPolicy: Replace and a job execution takes 10 minutes. The schedule is /5 * * *. Which statement is true about job executions?

A DevOps engineer wants to deploy a logging sidecar container that reads log files from the main application container. Which volume type should be used to share files between the two containers?

A Pod has two containers: one with a liveness probe that fails after 30 seconds. The restartPolicy is 'Never'. What state will the Pod be in after the liveness probe fails?

Which command builds a Docker image from the current directory and tags it as 'myapp:v1'?

A developer wants to create a Job that runs exactly 3 pods in parallel. Which field should be set in the Job spec?

Track your progress over time

Start a Application Design and Build only practice session

Related CKAD topic practice pages