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?