Question 1 of X

CKAD Exam Instructions and Requirements

You must have a working MiniKube cluster, and you must be able to add extra MiniKube nodes.

You must have a working Docker installation on your machine.

You must have Helm installed.

Read all questions carefully. Exercises must be done in the namespace requested.

You can navigate through questions using the buttons at the top of the screen.

The green bar will show you the rough amount of time remaining.

Total time is 2 hours for 18 questions.

Create 3 Pods with names nginx1 📋 Copied! , nginx2 📋 Copied! , and nginx3 📋 Copied! in the namespace 104ab4 📋 Copied! running nginx:latest 📋 Copied! .

• Label nginx1 with app=nginx 📋 Copied! .
• Annotate nginx2 with ingress=enabled 📋 Copied! .
• Completely unlabel the nginx3 Pod.

You are a member of team-blue and must prepare a compute node designed only for team-blue deployments.

• Create the namespace team-blue 📋 Copied! .
• Create a new minikube Node named blue 📋 Copied! and label it with node=dedicated 📋 Copied! . For minikube, you can use the command minikube node add blue 📋 Copied! .
• Add a taint to the blue 📋 Copied! node with node=dedicated 📋 Copied! and the NoSchedule 📋 Copied! effect.
• Create a Deployment named blue-dedicated-node 📋 Copied! , with the image nginx:latest 📋 Copied! in the namespace team-blue 📋 Copied! .
• Ensure the Deployment:
  • Tolerates the taint on the node.
  • Is scheduled only on the node labeled node=dedicated 📋 Copied! .

Team Cr4zy has requested their application to be deployed in a namespace named team-cr4zy 📋 Copied! , which you must create. They use the image webapp-color:v1 📋 Copied! and require a Deployment named cr4zy-app 📋 Copied! . The deployment should update its Pods using the Recreate 📋 Copied! strategy. Every Pod created by the deployment should request 100m 📋 Copied! CPU. As the load on the application can vary drastically during the day, you suggest using horizontal autoscaling.

Configure the cr4zy-app 📋 Copied! Deployment with a horizontal autoscaler. Configure the autoscaler to deploy between 2-5 Pods, with a target CPU utilization of 75%.

A new version of a web application your company is hosting is available. You are tasked with verifying that the new version of the application can reliably serve traffic. You will do this by creating a so-called canary Deployment. Using this method, the new version of the application is spun up and serves traffic next to the old version of the application.

Create a Deployment called application 📋 Copied! with image hashicorp/http-echo:v0.2.2 📋 Copied! , and a Deployment called canary 📋 Copied! with image hashicorp/http-echo:v0.2.3 📋 Copied! both on a new namespace loadbalance 📋 Copied! . Configure a Service that balances the load over the two Deployments. Configure the Deployments in such a way that 75% of the traffic reaches the stable version ( hashicorp/http-echo:v0.2.2 📋 Copied! ) and 25% reaches the canary version ( hashicorp/http-echo:v0.2.3 📋 Copied! ) Deployment.

Optional: you can verify your solution by adding the following configuration to your Deployments:

    args: ["-text", "Hello from Pod $(POD_NAME)"]
    env:
    - name: POD_NAME
      valueFrom:
        fieldRef:
          fieldPath: metadata.name

The image should then respond to API GET Requests with the Pod name that handled the request.

As a member of Team Slyce you are responsible for creating PostgreSQL database backups and cleaning up old log files. Team Slyce operates in the pg-slyce 📋 Copied! namespace, that you must create. Both the backup and cleanup Jobs must happen on a regular schedule. The requirements of the two jobs are as follows:

• A CronJob named db-backup 📋 Copied! must exist in the pg-slyce 📋 Copied! namespace. It should run the image postgres:15.17-trixie 📋 Copied! and schedule a Job every night at 02:00 AM.
• The db-backup 📋 Copied! CronJob must not allow concurrent Jobs to run.

• The db-backup 📋 Copied! CronJob should always keep the last 7 successful, and last 7 failed Jobs.

• A CronJob named db-cleanup 📋 Copied! must exist in the pg-slyce 📋 Copied! namespace. It should also run the image postgres:15.17-trixie 📋 Copied! .
• The db-cleanup 📋 Copied! CronJob must run once per week on Sunday at 05:00 AM.
• The Jobs created by the db-cleanup 📋 Copied! CronJob should have a maximum of 3 retries upon failure. The container itself must never be allowed to Restart.

Create both CronJobs according to the specifications mentioned above.

You received a message from a developer that Kyverno flagged a Pod in the acceptance 📋 Copied! namespace in another Kubernetes cluster for violating some of the security policies. You do not have access to that Kubernetes cluster, but the developer does send you a log of Error messages:

error: resource was rejected by Kyverno: resource Pod/acceptance/insecure-pod failed policy strict-policy: 
- runAsNonRoot: container c1 must not run as root (UID 0).
- seccompProfile: container c1 must have a seccomp profile set to RuntimeDefault.
- allowPrivilegeEscalation: container c1 must not allow privilege escalation.
- readOnlyRootFilesystem: container c1 must have a read-only root filesystem.
- capabilities: container c1 must drop ALL capabilities.

Show the developer how to implement a Pod with the correct security context. Deploy a Pod to the acceptance 📋 Copied! namespace in your cluster that conforms to all the security policies that are mentioned above. You can name the Pod dev-security-demo 📋 Copied! , and for demonstration purposes can use the image nginx:latest 📋 Copied! .

You are investigating Kubernetes credentials inside Pods. You must create a workload and identify the token that this workload uses to talk to the kube-apiserver.

• Create a namespace called ctf 📋 Copied! .
• Create a ServiceAccount named inspector 📋 Copied! in the ctf 📋 Copied! namespace.
• Create a Pod in the ctf 📋 Copied! namespace named app 📋 Copied! with

  • image: busybox:latest 📋 Copied!

  • command: sleep 3600 📋 Copied!

  • with service account: inspector 📋 Copied!

• Identify the ServiceAccount JWT token mounted inside the Pod.
• Save the value of the token inside the file ~/token.txt 📋 Copied! .

You are contacted by a developer from team June-ior requesting help in troubleshooting their Deployment manifest. Identify and fix all issues in the Deployment manifest and then apply it to your Kubernetes cluster on the june-ior 📋 Copied! namespace. You can create the namespace june-ior 📋 Copied! if it doesn’t exist. You must ensure that all Pods reach a Running & Ready state.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: web
        image: nginx:last
        ports:
        - containerPort: "8080"
  restartPolicy: Never
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

For this question create the namespace secure-logs 📋 Copied! .

Create a DaemonSet with the following requirements:

• Runs on all nodes.
• uses the image nginx:1.25-alpine 📋 Copied! .
• Mounts a Secret volume at /etc/tls 📋 Copied! named tls-volume 📋 Copied! inside the container.

You must create a TLS secret in the secure-logs 📋 Copied! namespace with these requirements:

• Secret name must be tls-secret 📋 Copied! .
• Must be of type kubernetes.io/tls 📋 Copied! .
• Contains tls.crt 📋 Copied! and tls.key 📋 Copied! .
• You can generate a certificate and key with openssl:

    openssl req -x509 -nodes -days 365 \
      -newkey rsa:2048 \
      -keyout tls.key \
      -out tls.crt \
      -subj "/CN=localhost"
  

You must mount the secret inside the container at /etc/tls 📋 Copied! , and files must be read-only 📋 Copied! . Ensure that the secret keys appear as files:

• /etc/tls/tls.crt 📋 Copied!

• /etc/tls/tls.key 📋 Copied!

A new development team will deploy workloads into a dedicated Kubernetes namespace. To prevent resource overuse, the cluster administrators want to enforce strict resource boundaries.

Create a namespace called limited 📋 Copied! . Create a ResourceQuota to enforce the below constraints on the limited 📋 Copied! namespace. You don’t need to create any Pods.

• Maximum number of Pods: 5
• Maximum total CPU requests: 200m
• Maximum total CPU limits: 300m
• Maximum total Memory requests: 100Mi
• Maximum total Memory limits: 150Mi

A team is deploying a lightweight internal service that listens for TCP connections on port 80 📋 Copied! . The application does not expose HTTP health endpoints, so health checks must be performed using TCP socket probes.

The platform team wants to ensure:

• The container is restarted if it becomes unresponsive.
• The Pod only receives traffic when it is ready to accept TCP connections.

Create a Pod in the default 📋 Copied! namespace with the name lightweight-app 📋 Copied! , the image nginx:alpine 📋 Copied! , container name app 📋 Copied! , and the container port 80 📋 Copied! .

Configure a TCP Liveness probe with an initial delay of 10 📋 Copied! seconds, and a period of 5 📋 Copied! seconds. Configure a TCP Readiness probe with an initial delay of 2 📋 Copied! seconds, and a period of 3 📋 Copied! seconds, and a failure threshold of 1 📋 Copied! .

The busy-team has been security audited and was told to implement network policies to better control traffic inside their kubernetes cluster. As they are very busy, this task was assigned to you. Their setup is as follows:

• They run a PostgreSQL database (as Pods with label type=database 📋 Copied! ) in the busy-database 📋 Copied! namespace.
• They run two web-api’s (as Deployments, with Pod labels app=green 📋 Copied! for the green 📋 Copied! web-api, and with Pod labels app=blue 📋 Copied! for the blue 📋 Copied! web-api) in the busy-api 📋 Copied! namespace.

As they are truly very busy, all the specifications you obtained are in a hastily scribbled note:

• All ingress and egress traffic must be denied by default unless explicitly allowed via NetworkPolicies.
• Egress traffic from the green 📋 Copied! to the blue 📋 Copied! web-api Pods over port 80 📋 Copied! ALLOWED.
• Egress traffic from the green 📋 Copied! web-api Pods to the database over port 5432 📋 Copied! ALLOWED.
• Ingress traffic to the database from the green 📋 Copied! web-api Pods over port 5432 📋 Copied! ALLOWED.
• Ingress traffic to the database from the blue 📋 Copied! web-api Pods NOT ALLOWED.

Create the namespaces busy-database 📋 Copied! and busy-api 📋 Copied! . Label busy-database 📋 Copied! with namespace=busy-database 📋 Copied! and label busy-api 📋 Copied! with namespace=busy-api 📋 Copied! . Create the network policies required to satisfy the above specifications. You do not need to deploy any databases or api’s.

TODO: Ingress exercise

For this question, you are allowed to use the following url and sub-directories for information: https://github.com/grafana-community/helm-charts/tree/main/charts/grafana 📋 Copied! .

Add the grafana-community 📋 Copied! Helm repository https://grafana-community.github.io/helm-charts 📋 Copied! .

• Create the namespace grafana-dev 📋 Copied! .
• Install Grafana using Helm, and give it the name grafana-dev 📋 Copied! .
• Configure the chart such that the service type is NodePort 📋 Copied! , and the admin password is set to swordfish17 📋 Copied! .

After installation, upgrade the grafana-dev 📋 Copied! Helm chart such that the service type is now ClusterIP 📋 Copied! .

Given the index.html 📋 Copied! file with the contents:

<!DOCTYPE html>
<html>
<head>
    <title>Hello CKAD</title>
</head>
</html>

Create a Dockerfile and the above index.html 📋 Copied! file in the ~/ckad1/q15/docker 📋 Copied! folder. The Dockerfile should use the nginx:latest 📋 Copied! image, and should copy the index.html 📋 Copied! file to /usr/share/nginx/html/index.html 📋 Copied! .

Build a Docker image from the Dockerfile you created, and give it the name dev-app 📋 Copied! and tag it with v0.0.1 📋 Copied! . Save the image as a tar 📋 Copied! archive in the the directory ~/ckad1/q15/image 📋 Copied! with the name dev-app.tar 📋 Copied! .

A GitOps controller (e.g. FluxCD) will be run by the platform team in the iota 📋 Copied! namespace and must only be able to read Pods in that namespace. The controller will use the service account named controller-sa 📋 Copied! .

Create the required ServiceAccount, Role, and RoleBinding on the iota 📋 Copied! namespace.

Create a ConfigMap named app-config 📋 Copied! in the default 📋 Copied! namespace containing the following key-value pairs:

• APP_COLOR=blue
• APP_MODE=test
• APP_DEBUG=true

Create a Deployment named configured-app 📋 Copied! in the default 📋 Copied! namespace running the image nginx:1.25 📋 Copied! and 2 📋 Copied! replicas.

Expose the ConfigMap values as environment variables inside the container. Additional requirement:

• The environment variable names inside the container must match the ConfigMap keys, but with the “APP_” prefix removed. (e.g., APP_COLOR → COLOR).

Create a Deployment named secure-app 📋 Copied! in the capabilities 📋 Copied! namespace, run it with nginx:latest 📋 Copied! for testing purposes.

The application inside the container requires the ability to bind to privileged ports (<1024). Add the NET_BIND_SERVICE 📋 Copied! capability to the container, and no other capabilities.