Issue description

Hi Red Hat Training Team,

I’d like to share some feedback on the GitOps for Cluster Administration section of the course.

To be honest, I think the example using the Compliance Operator may not be the best choice—especially from a learning perspective. In most real-world environments, compliance management (including planning, scanning, and remediation) is typically handled by senior or specialized engineers. Junior or mid-level engineers may only assist in a limited way.

In this exercise, we're only installing the Compliance Operator. There’s no step where we actually configure compliance scans, implement remediations, or understand what changes are happening in the cluster. It feels like a black box—we run some commands, something gets deployed, but we don't get to see how GitOps is helping or why it matters unless we're already familiar with the Compliance Operator or compliance hardening on kubernetes clusters in general

On top of that, GitOps itself—and tools like ArgoCD—are already new territory for many system administrators. Most of us coming from a Linux/sysadmin background don’t work with Git on a daily basis like developers do. Introducing Git, ArgoCD, and a niche compliance tool all at once makes this section significantly steeper in terms of the learning curve.

A more relatable use case could go a long way. Maybe something like:

1. Configuring SSH ciphers or KEX algorithms
2. Setting ulimits or hugepages
3 Managing log forwarding
4. Deploying app versions
5. Automating backup or alerting tasks
6. Implementing simple alerts

These are things many Linux engineers already deal with and likely have worked. Examples like these will tremendously help someone with such a sysadmin background; show the power of GitOps in a way that’s easier to grasp and appreciate.

Alternatively, if the intention is to showcase operator management via GitOps, maybe it would be better to focus on managing the GitLab instance of the GitOps Operator itself. For example, deploying and managing a GitLab instance using GitOps would make a lot of sense. GitLab typically includes components like NGINX, Redis, and PostgreSQL, and it would be great to see how we can configure and scale those through GitOps workflows.

Lastly, just a quick note: compliance hardening isn’t something to be done lightly. It can significantly impact application behavior, and running it blindly—especially without understanding what’s being applied—can lead to real problems in production. That’s another reason why a black-box-style example may do more harm than good here.

Thanks again for the effort that’s gone into this course. I’m enjoying it overall and just wanted to offer this suggestion in the hope it might improve the learning experience for future students like me.