# ViktorUJ/cks: Kubernetes and AWS EKS lab preparation > ViktorUJ/cks is a Terraform and Terragrunt learning environment for hands-on Kubernetes, AWS EKS, and certification practice. It fits engineers who want disposable infrastructure, but its AWS permissions, version-specific modules, and undocumented cleanup details require careful review. **ViktorUJ/cks** — Open-source Platform for learning kubernetes and aws eks and preparation for for Certified Kubernetes exams (CKA ,CKS , CKAD, ICA) - Repository: https://github.com/ViktorUJ/cks - Website: https://www.youtube.com/@aws-guru - Stars: 1,635 · Forks: 311 - Language: HCL - License: Apache-2.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/viktoruj-cks ## Why ViktorUJ/cks exists beyond a list of exam topics ViktorUJ/cks addresses a practical gap in Kubernetes exam preparation: candidates need a cluster in which to change settings, diagnose failures, deploy workloads, and apply security controls. The repository presents that work as hands-on labs and mock exams rather than as a passive question bank. Its intended users are IT engineers preparing for CKA, CKS, CKAD, ICA, KCNA, KCSA, LFCS, and AWS Certified AI Practitioner study, with AWS EKS practice as a separate focus. The CKA and CKS portions have distinct areas in the repository. Each certification directory contains `labs` and `mock` subdirectories, while the `Makefile` selects between a mock environment and a lab environment. This is useful for engineers who know Kubernetes objects but need a system on which to execute administrative tasks. It does not, based on the documentation, explain how closely each lab maps to every current exam objective, so that alignment should be checked lesson by lesson rather than inferred from the repository title. The platform is centered on infrastructure creation. According to the README, scenarios can create a VPC, subnets, security groups, EC2 Spot instances, and S3 resources before giving access to Kubernetes clusters. That makes it more suitable for learners who are comfortable working with cloud networking, remote hosts, IAM credentials, and infrastructure state. It is less convenient for someone seeking a local cluster that starts with a single command. ## How Make, Terragrunt, and the k8s_self_managment module fit together The `Makefile` is the control surface for labs and mocks. Its internal Terragrunt helper resolves a family and environment path under `terraform/environments`, then dispatches `run`, `delete`, or `output`. For a run operation, the underlying command is `terragrunt run-all apply`; deletion uses `terragrunt run-all destroy`. This separation gives the learner named scenarios while allowing Terraform modules to remain reusable infrastructure components. Cluster creation is delegated to the `terraform/modules/k8s_self_managment` module. The spelling is part of the repository path and must be preserved when navigating the code. The README states that this module creates clusters with `kubeadm`, while the top-level environments and scenarios are organized through Terragrunt. Based on the documented layout, the data flow is a Make target, followed by a Terragrunt environment, followed by Terraform resources and reusable modules. The module does not treat Kubernetes, container runtime, operating system, and CNI as one unconstrained setting. The README lists Kubernetes versions from 1.21 through 1.34, Docker for 1.21 through 1.23, CRI-O for 1.21 through 1.29, and containerd or `containerd_gvizor` through 1.33. Ubuntu 20.04 LTS and 22.04 LTS are listed, with CKS defaulting to Ubuntu 22.04 LTS. Calico and Cilium are named as CNI options. These combinations make version selection part of the exercise, but they also mean that an unsupported runtime pairing is a valid failure boundary rather than something the README promises to resolve automatically. ## AWS configuration and the first documented Make use The README does not provide a repository acquisition command or a complete installation script. It points users either to `docs/run_from_docker.MD` and an associated video, or to the local prerequisites. Those prerequisites are GNU Make 4.2.1 or newer, Terraform 1.6.6 or newer, Terragrunt 0.54.8 or newer, jq 1.6 or newer, AWS CLI 2.2.30 or newer, and an AWS profile. Because the linked Docker guide is not reproduced here, its exact image name, build process, and run flags cannot be confirmed. Before any local scenario, configure `backend_bucket` in `terraform/environments/terragrunt.hcl`. The README also identifies `region` and `backend_region` as optional configuration there. The `Makefile` reads those fields to derive the backend bucket and region, and it appends `-lock` to the bucket name when defining `dynamodb_table`. Do not substitute a guessed bucket name or state table name for the values maintained in that file. The clearest first documented command is a read-only CMDB listing. Run it from the repository root: ```bash make cmdb_get_env_all ``` The README says this returns a list of all resources in CMDB. For resource information attributed to a particular user and environment, the documented form is: ```bash USER_ID='myuser' ENV_ID='01' make cmdb_get_user_env_data ``` The expected output is described as the resources created for `myuser` in environment `01`. A similar command is documented for lock resources, although the README repeats the lock command and does not explain its output in enough detail to infer the exact record format. ## Infrastructure cost, permissions, and upgrade responsibility ViktorUJ/cks operates in an AWS account, so its operating cost is not limited to studying locally. The README requires an IAM user or role with administrative privileges for VPC, EC2, IAM, and EKS. That is a broad permission requirement for what is presented as a learning environment. The documentation does not explain whether the scenarios can use narrower permissions, so restricting the identity is not something a reader can assume will work. The project also creates billable or potentially billable cloud resources, including EC2 Spot instances, S3 storage, VPC components, and EKS-related infrastructure. The repository documentation does not state expected costs, Spot interruption handling, or cleanup guarantees. The generic delete mechanism shown in the `Makefile` is `terragrunt run-all destroy`, but the truncated command list does not expose every scenario-specific deletion target. Resource cleanup should therefore be verified through the repository's Makefile and Terragrunt output rather than assumed from the existence of a delete path. Maintenance is recent but not release-driven. The last push was on 2026-10-01, and the repository is not archived. However, there are no GitHub releases to provide a stable installation version or upgrade boundary. Users must track the default branch and module changes themselves. The Apache-2.0 license permits broad use and modification under its terms, but operators remain responsible for checking dependency compatibility and the cloud-security implications of the credentials used by each scenario. ## Where the learning platform stops being the right tool The clearest limitation is the dependency on an AWS account and administrative access. ViktorUJ/cks is not presented as an offline Kubernetes simulator, a replacement for a managed training cluster, or a lightweight command-line exam environment. A learner without AWS credentials, permission to create networking and compute resources, or a willingness to manage remote infrastructure cannot use the documented scenario path as written. The supported matrix also creates a version-boundary problem. A learner targeting a newer runtime combination, a Kubernetes release outside the stated range, or a CNI and operating system pair not listed in the README may need to modify the Terraform module. The documentation does not claim compatibility with every release in that range across every runtime, so the matrix should be read as an upper and lower boundary rather than proof that every combination is tested. There is also no documented release history, formal support policy, or guarantee that mock scenarios match the current certification exams. That makes the repository a useful practice repository, not a complete substitute for official objectives and exam documentation. Engineers who need versioned course progress, local-only execution, or a guaranteed cleanup contract would need another approach. ## ViktorUJ/cks compared with local Kubernetes study workflows A real alternative is a local Kubernetes workflow such as using Docker with a local cluster tool or managing a cluster directly on a workstation. The difference is architectural. ViktorUJ/cks provisions AWS network and compute resources through Terraform and Terragrunt, then uses `kubeadm` to create the cluster. A local workflow keeps the control plane and nodes on the user's machine, so it removes much of the AWS IAM, VPC, remote access, and cloud teardown surface. That alternative is usually a better fit for repetitive Kubernetes object practice because startup and networking are simpler. ViktorUJ/cks is more relevant when the exercise itself needs EC2 nodes, VPC and subnet behavior, IAM, S3, EKS exposure, or infrastructure visibility. The AWS platform can therefore teach cloud context that a local cluster cannot reproduce, but it also exposes the learner to more configuration and failure modes. The trade-off is not performance or capability, because the repository does not document benchmarks. It is operational scope. ViktorUJ/cks asks the learner to operate an infrastructure repository; a local workflow asks the learner mainly to operate Kubernetes. Choose based on whether the cloud architecture is part of the learning objective, not on an unsupported claim that one environment is faster or more realistic. ## Conclusion Engineers preparing for CKA, CKS, CKAD, or AWS EKS practice should adopt ViktorUJ/cks when they can create and destroy AWS infrastructure through the documented Make targets. It is a poor fit for local-only study, tightly restricted cloud accounts, or users who need a packaged, versioned curriculum. Before the first scenario, verify the backend bucket setting, AWS identity permissions, supported runtime and Kubernetes version pair, generated cluster access details, and the exact deletion target recorded by Terragrunt. ## FAQ ### What is ViktorUJ/cks used for? ViktorUJ/cks provides hands-on labs and mock exam scenarios for Kubernetes certifications and practical AWS EKS study. Its repository is organized around CKA and CKS materials, with Make-driven Terraform and Terragrunt environments. ### Does ViktorUJ/cks require AWS credentials? Yes. The documented local path requires an AWS profile and an IAM user or role with Admin privilege for VPC, EC2, IAM, and EKS. The Docker route is presented as an alternative in the README, but its detailed setup is in a separate guide. ### How do I start a ViktorUJ/cks environment? The README says to configure `backend_bucket` in `terraform/environments/terragrunt.hcl`, then use the Makefile from the repository root. For a first read-only check, `make cmdb_get_env_all` lists all resources in CMDB; scenario-specific commands are exposed through the Make targets. ## Sources - [Issues](https://github.com/ViktorUJ/cks/issues) - [License: Apache-2.0](https://github.com/ViktorUJ/cks/blob/master/LICENSE) - [Project website](https://www.youtube.com/@aws-guru) - [README](https://github.com/ViktorUJ/cks/blob/master/README.md) - [ViktorUJ/cks on GitHub](https://github.com/ViktorUJ/cks) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/viktoruj-cks