Home CKAD Exam Tips
Post
Cancel

CKAD Exam Tips

I recently took and passed the CKAD Exam and now the proud owner of the CKAD Certification issued by The Linux Foundation. Like so many others who have accomplished this, I decided to share some tips that I found most helpful when I took my exam. This is not a complete list and there are many great tips out there that you may find more valuable. These were just some top-of-mind thoughts I captured shortly after taking the exam. If you are preparing for the CKAD exam, I hope these tips help you be successful.

The CKAD exam will test more than just your kubernetes knowledge. It will also test your ability to complete tasks fast. Speed and efficiency is critical to getting past this exam.

  1. Spend 1 minute (or less) setting up the following aliases and environment variable. The ROI on these 3 is very high.

    1
    2
    3
    4
    5
    6
    
     # Aliases
     alias k=kubectl
     alias kn='kubectl config set-context --current --namespace '
        
     # Env Variable
     export dro='--dry-run=client -o yaml'
    

    Below are a few examples using these:

    1
    2
    3
    4
    5
    
     # Set the namespace in the current context to dev3201
     kn dev3201
    
     # Create a pod definition file
     k run frontend --image=nginx $dro > frontend.yaml
    

    If you search the internet, you will find some pretty nifty aliases that people suggest using. But, if you spend more than a minute at the start of the exam setting up various aliases, then it’s my opinon you probably won’t get the ROI in time savings.

  2. Make sure to run the command that they give you at the beginning of every question to set your context. Watch this video from The Linux Foundation demonstrating this. Then, if the question instructs you to work in a particular namespace, use your kn alias to set your namespace so you can skip the namespace parameter in your commands. If it doesn’t specify a namespace, run kn default to insure you’re in the default namespace.

  3. Get used to using abbreviations for resources. For example, po instead of pods, deploy instead of deployment, svc instead of service, cm instead of configmap. You can find all the abbreviations by running k api-resources.

  4. Get used to using shorthand for command switches/parameters. For example, -A instead of --all-namespaces, -l instead of --selector.

  5. Get really good at editing in vi(m) or nano so you don’t lose valuable time on trivial editor stuff. When you take your practice tests ( you get 2 ), try to identify situation where you are not efficient in the editor. Then, get really good at being efficient in those situations.

  6. Get really good at using grep to find stuff in files, command help, etc. Switches that I used a lot were the -i, -A, and -B. See next tip for an example.

  7. When you need schema for a resource, use k explain with the --recursive switch and then pipe it into grep with the -B and -A switches. For example, suppose you’re asked to configure a rolling update strategy for a deployment and instructed to set the maximum surge property to a given value. You may not recall the exact schema you need to add to your deployment, but you recall there is a property that contains the word “surge” in it. You can find the property and schema it is part of using the following command:

    1
    
     k explain deploy.spec --recursive | grep -i -B5 -A3 surge
    

    This command will return the following output. For the search string “surge”, it found the maxSurge property and returned 5 lines before and 3 lines after this instance. This is enough to give you the full schema you need as highlighted in the box. Now, you can cut/paste this into your deployment configuration and fill out the values.

    Schema for pod.spec.strategy

  8. Don’t waste time formatting yaml. You don’t get points for making your code pretty! Just make sure it’s syntactically correct. Below are equivalent and valid pod definitions. Notice the differences at pod.spec.containers.volumeMounts and pod.spec.volumes.

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    
     apiVersion: v1
     kind: Pod
     metadata:
       name: mypod
     spec:
       containers:
       - name: myfrontend
         image: nginx
         volumeMounts:
         - mountPath: "/var/www/html"
           name: mypd
       volumes:
       - name: mypd
         persistentVolumeClaim:
           claimName: myclaim
    
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    
     apiVersion: v1
     kind: Pod
     metadata:
       name: mypod
     spec:
       containers:
       - name: myfrontend
         image: nginx
         volumeMounts:
                 - mountPath: "/var/www/html"
                   name: mypd
       volumes:
             - name: mypd
               persistentVolumeClaim:
                 claimName: myclaim
    

    It is my belief that if you are comfortable with your yaml editing, then you can ignore tips relating to configuring the vi(m) editor.

  9. I did a time check at about an hour into the exam. Took a minute to explore the weight of the remaining questions. Then, prioritized the order of remaining questions based on their weight.

  10. Don’t rathole on a question. If you’re not making progress or stuck on a question for more than 5 mins, flag it and come back to it later.

This post is licensed under CC BY 4.0 by the author.

Add a custom device to the Azure IoT Suite Remote Monitoring solution

Developer Laptop Setup on Ubuntu

Comments powered by Disqus.

Trending Tags