100 Days of DevOps, Day 1: Linux User Management and AWS Key Pairs

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.

# SSH into the private server via the jump server
ssh user@hostname

# Switch to root
sudo su -

# Create the user with a non-interactive shell
useradd username -s /sbin/nologin

# Verify the user was added
cat /etc/passwd | grep username

Key points:

• /sbin/nologin prevents the user from getting a shell session — they can own processes but cannot log in.
• Always verify by grepping /etc/passwd — the last field confirms the 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

Goal: Generate and register an RSA key pair in AWS EC2 for SSH access to instances.

# Create the key pair and save the private key locally
aws ec2 create-key-pair \
  --key-name my-key-pair \
  --key-type rsa \
  --key-format pem \
  --query "KeyMaterial" \
  --output text > my-key-pair.pem

# Verify the key pair exists in AWS
aws ec2 describe-key-pairs --key-names my-key-pair

Key points:

• The private key is returned only once at creation — save it immediately, AWS does not store it.
• Set correct permissions before use: chmod 400 my-key-pair.pem 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?