Lab download.Starter is the tree you edit. Worked answer is a separate file; open it after the starter passes. Rust 1.85 or newer (the lesson was tested with Rust 1.98; cargo vendor was checked on Rust 1.99) and tar. One online command, cargo vendor vendor, from inside starter/ or reference/. The zip has no vendor directory, so it is not offline-ready until that command finishes. The checker then builds with cargo build --offline. DEPLOY_LOG_KEY in the checker is the demo string lab-only-key-0123456789abcdef0123456789. All lab requirements.
Q1 · DOP-C02 task 5.3, CodeDeploy alarm rollback
A team deploys an edge API to Amazon ECS with AWS CodeDeploy. The deployment group has a CloudWatch alarm attached and automatic rollback enabled for the case where an alarm threshold is met. Partway through the rollout the alarm goes to the ALARM state. What does CodeDeploy do?
Answer: C. With automatic rollback enabled for alarm thresholds, CodeDeploy stops the deployment when the attached alarm fires and rolls back to the last known good revision. CodeDeploy does not wait for a manual redeploy, does not limit itself to notification, and does not continue the rollout once the configured alarm condition triggers the rollback. Source: Redeploy and roll back a deployment with CodeDeploy - https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html
Q2 · DOP-C02 task 5.3, CodePipeline failed action
A CodePipeline pipeline for the edge service stops at a failed Deploy stage. Before retrying, the team must first identify which action failed and read its logs, without changing the pipeline definition. What should they do?
Answer: A. A failed CodePipeline action is diagnosed from the pipeline execution details, where each action links to the action provider's logs so the failure can be inspected before a retry. Deleting the pipeline, forcing a new revision, or disabling the stage all skip the required diagnosis of the failed action and either discard history or hide the failure. Source: View pipeline details and history in CodePipeline (console) - https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-view-console.html
Q3 · CKA workloads and scheduling, rollout undo
Deployment edge-api rolled out an image that fails in production, and its previous ReplicaSet is still retained. The team must return to the previous revision using the Deployment's own revision history, not by editing the Pod template by hand. Which command does that?
Answer: D.kubectl rollout undo rolls the Deployment back to the previous revision recorded in its rollout history. Deleting Pods or scaling to zero and back recreates Pods from the current (bad) Pod template, and setting the tag to latest is a manual template edit that does not select a prior digest. Source: Deployments, Rolling Back a Deployment - https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-back-a-deployment
Q4 · CKA workloads and scheduling, readiness vs traffic
A model-serving container in a Pod starts successfully but begins returning wrong answers after a bad config mount. The team must stop sending Service traffic to that Pod while keeping its container running, so no kill or restart is allowed. What should they configure?
Answer: B. A failing readiness probe marks the Pod not ready, so it receives no traffic through Services while its container keeps running. A failing liveness probe makes the kubelet kill and restart the container, deleting the Pod kills it, and restartPolicy: Never neither stops traffic nor is valid for a Deployment's Pod template. Source: Configure Liveness, Readiness and Startup Probes - https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
Q5 · CKA workloads and scheduling, rolling update halt
A team updates Deployment edge-api using the default RollingUpdate strategy, with maxUnavailable left at its default of 25%. The new image is broken, so the new Pods never become Ready. What does the Deployment controller do about scaling up the new ReplicaSet?
Answer: A. The Deployments docs state the controller stops the bad rollout automatically by not scaling up the new ReplicaSet, depending on the rolling update parameters such as maxUnavailable. The controller does not ignore readiness, does not delete the old ReplicaSet while the rollout is stalled, and does not roll back by itself. Source: Deployments, Rolling Back a Deployment - https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-back-a-deployment
Q6 · CKA workloads and scheduling, progress deadline
Deployment edge-api exceeds its .spec.progressDeadlineSeconds and the status condition shows reason ProgressDeadlineExceeded. The team expects Kubernetes itself to roll the Deployment back to the previous revision. According to the Deployments docs, what actually happens?
Answer: C. The Deployments docs say Kubernetes takes no action on a stalled Deployment other than reporting the condition, and higher-level orchestrators may act on it. Kubernetes does not roll back, delete Pods and pause, or rewrite Service selectors when the progress deadline is exceeded. Source: Deployments, Failed Deployment - https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#failed-deployment
Q7 · CKA servicing and networking, Service endpoints
A ClusterIP Service named edge-api selects five Pods by label. Two of the five Pods have failing readiness probes, and all five are otherwise running. What traffic behaviour should the team expect from the Service?
Answer: B. Service endpoints include only Ready Pods, so clients of a ClusterIP Service reach Ready backends and not Pods whose readiness probes are failing. Failing readiness does not keep Pods in the endpoints, Kubernetes does not scale the Deployment to zero for readiness failures, and readiness affects ClusterIP Services without requiring NodePort. Source: Pod Lifecycle, Container probes - https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
Q8 · CKA servicing and networking, NetworkPolicy
Namespace edge has a NetworkPolicy that selects the model-serving Pods. Ingress must be allowed only from Pods labelled role=client that run in namespaces labelled tier=frontend, and from nothing else. Which ingress.from shape does that?
Answer: D. Putting namespaceSelector and podSelector in the same from entry selects only the matching Pods in the matching namespaces (a logical AND). Separate entries are ORed and admit all Pods in tier=frontend namespaces plus all role=client Pods in the policy namespace, a lone podSelector only matches the policy's own namespace, and an ipBlock does not select Pods by label. Source: Network Policies, Behavior of to and from selectors - https://kubernetes.io/docs/concepts/services-networking/network-policies/#behavior-of-to-and-from-selectors
Q9 · CKS supply chain security, image digest
CI scanned registry.example.com/edge/model-svc:2.1 and the build passed, but the registry owner can later push different bytes to the same tag. The Pod must run exactly the scanned content on every node, even if the tag is re-pushed. What should the Pod spec do?
Answer: A. An image digest identifies one exact image content, so every node runs the same bytes regardless of what the tag later points to. A tag is mutable, so Always pulls whatever the tag points to now, latest is just another mutable tag, and IfNotPresent keeps any different image already cached under that tag on a node. Source: Images, Image names - https://kubernetes.io/docs/concepts/containers/images/#image-names
Cluster policy must ensure Pods only pull images from an approved registry and that image content is validated before the Pod is admitted. The team already pins digests in Pod specs, and the control must be enforced at admission in the API server request path. Which additional control fits?
Answer: D. The ImagePolicyWebhook admission controller lets a backend webhook decide at admission time whether the images in a Pod are allowed. A pull policy of Never breaks first pulls and validates nothing, a ConfigMap is not a registry control, and disabling kubelet pulls is not an admission-time check of registry or content. Source: Admission Controllers Reference, ImagePolicyWebhook - https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook
An Amazon ECS service update failed. The service uses a rolling update deployment with the deployment circuit breaker enabled and its rollback option turned on. The console now shows the deployment as failed and the previous task definition is again the one running. Which documented behaviour explains this?
Answer: B. When the circuit breaker is enabled with rollback, ECS rolls a failed deployment back to the last deployment that completed successfully. ECS can roll back automatically with the circuit breaker, the breaker does not simply leave the failed revision serving, and Container Insights is a monitoring feature that does not perform rollbacks. Source: How the Amazon ECS deployment circuit breaker detects failures - https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-circuit-breaker.html
Q12 · CKA workloads and scheduling, self-healing primitives
The team wants a self-healing workload so that when a Pod is deleted or its node fails, a replacement Pod appears without anyone recreating it by hand. The service is long-running and must keep a fixed number of replicas. Which primitive is the documented path for this?
Answer: C. A Deployment manages a ReplicaSet, and the ReplicaSet controller creates replacement Pods to match its replica count when Pods are deleted or lost. A bare Pod is not replaced elsewhere after node failure (restartPolicy only restarts containers), a Job runs to completion with a backoff limit and is not meant for long-running services, and a CronJob only creates Jobs on a schedule. Source: ReplicaSet, Alternatives to ReplicaSet (Bare Pods) - https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/