Doing the work and being able to explain the work are two different skills.
I've had the first one for 8 years. I'm building the second one now.
I'm a Cloud Platform Engineer. AWS, Kubernetes, Terraform, Linux. Regulated
environments, healthcare, production systems. Real experience. Almost zero
public documentation of it. That's the gap I'm closing, starting from Day 1.
The platform is KodeKloud. Each session gives you tasks across multiple tools.
I'm posting the Linux and AWS tasks here. Here's what I built and what
actually matters about each one.
Task 1 (Linux): Create a User with a Non-Interactive Shell
The task was to create a system user that can own processes but cannot log in
interactively. This is what you do for service accounts.
bash
ssh user@hostname
sudo su -
useradd username -s /sbin/nologin
cat /etc/passwd | grep username
The /sbin/nologin shell is the important part. The user exists in the
system, can own files and run processes, but cannot open a shell session. You
verify by checking /etc/passwd because the last field in each line is the
assigned shell.
I've been doing this in production environments for years. I still verify
every time. Not because I'm unsure. Because in a regulated environment, you
don't assume, you confirm.
Task 2 (AWS): Create an EC2 Key Pair via CLI
aws ec2 create-key-pair \
--key-name my-key-pair \
--key-type rsa \
--key-format pem \
--query "KeyMaterial" \
--output text > my-key-pair.pem
aws ec2 describe-key-pairs --key-names my-key-pair
The private key is returned exactly once at creation. AWS does not store it.
If you lose it, you generate a new one and replace it everywhere it was used.
I've seen this cause real problems in production environments where the key
wasn't backed up properly.
Always run chmod 400 my-key-pair.pem after saving it. SSH will refuse to
use a key file with open permissions. It won't tell you that's the reason
straight away.
What Day 1 Taught Me That 8 Years Didn't
Nothing here was technically new to me. That's not the point.
The point is that explaining something clearly, step by step, with the
reasoning, is a skill completely separate from being able to do it. Most
engineers build the doing skill and ignore the explaining skill. I was one
of them.
Day 2 is already done. If you're running your own DevOps challenge or thinking
about starting one, I'd ask you this: would you rather keep building experience
silently and have nothing to show for it at the end, or build it loudly and
have 100 posts that prove you did the work?