Knowledge Check - Containers and CI/CD
Test your understanding of the key concepts from Module 3. Select the best answer for each question, then submit to see your results. You need to score at least 60% to pass.
A team wants to give one CI pipeline permission to push only to the taskboard/api repository and a separate pipeline permission to push only to taskboard/web, both inside the same IONOS Container Registry. They plan to create one token per pipeline with a per-repository push ACL. Why will this approach not work as intended?
IONOS Container Registry uses token-based docker login only with no RBAC. Tokens carry a Registry or Repository scope type, but fine-grained per-repository push/pull/delete ACLs are not available, so you cannot restrict a token to write to exactly one repository. Tokens are created through the IONOS API or DCD, not invented by the Docker CLI, which rules out the first option.
A developer pushed the TaskBoard API image to tue1608es.cr.es-vit.ionos.com/taskboard/api:abc123 and wrote a Deployment manifest referencing it. The pods fail with ImagePullBackOff. The image exists and the tag is correct. Which configuration is most likely missing?
The IONOS Container Registry is private and requires authentication for every pull, so the kubelet needs credentials supplied through imagePullSecrets referencing a docker-registry Secret created from a registry token. Without it, anonymous pulls are rejected and the pods loop in ImagePullBackOff. A NodeSelector, Ingress, or ConfigMap does not provide pull credentials.
A developer creates a Kubernetes Service of type LoadBalancer on IONOS Managed Kubernetes expecting a dedicated external load balancer to be provisioned in front of the cluster. They later notice all traffic flows through a single worker node and throughput plateaus. What is the correct understanding of this behavior?
On IONOS Managed Kubernetes a LoadBalancer Service does not deploy an external load balancer. IONOS reserves a static public IP and attaches it as a secondary IP to a single worker node, which routes traffic into the cluster, so throughput is bounded by that one ingress node. To scale or to put a true managed load balancer in front, you provision an IONOS ALB or NLB separately, since these are not auto-created from Kubernetes manifests.
A GitHub Actions workflow builds the TaskBoard image, pushes it to Container Registry, and runs kubectl apply against Managed Kubernetes. The pipeline currently hardcodes the IONOS_TOKEN, the registry token, and the kubeconfig directly in the workflow YAML. What is the correct way to supply these credentials?
Pipeline credentials such as IONOS_TOKEN, the Container Registry token, and the kubeconfig must be stored as encrypted CI secrets and injected at runtime, never committed to source or baked into images. Committing to a private branch still places secrets in Git history, and embedding them in the image exposes them to anyone who can pull it. Minting credentials from an account password over Basic auth defeats least-privilege, per-service token scoping.
A bad image was rolled out to the TaskBoard API Deployment on Managed Kubernetes and pods are crash-looping. The previous image worked. The developer needs the fastest safe way to return the running workload to the prior version. Which command should they use?
A Deployment keeps a revision history of its ReplicaSets, so kubectl rollout undo reverts to the previous working revision with a controlled rolling replacement and minimal disruption. Deleting the Deployment causes downtime and discards rollout state, while terraform destroy tears down the entire cluster. Scaling to zero replicas removes all pods without restoring any prior version, since the Deployment spec still references the bad image.