DEV Community: Nnamdi Felix Ibe

100 Days of DevOps and Cloud (AWS), Day 8: Ansible's 'ping' Isn't a Ping, and the AWS Stop Flag Reads Backwards

Nnamdi Felix Ibe — Sat, 11 Jul 2026 06:59:42 +0000

Ansible's whole pitch is that it manages servers without installing an agent on any of them. That single design choice is most of why it took over, and Day 8 started with getting it running and proving it could actually reach a host.

Two tasks today. Install Ansible on a Linux control node and confirm it can communicate with a managed server, then enable stop protection for an EC2 instance so nobody can accidentally knock it offline. The tasks come from the KodeKloud Engineer platform, as with the rest of this series.

Ansible: install it, then prove it can reach a host

Ansible is a configuration and automation tool. You describe the state you want a server to be in, and it makes the server match. The part that made it win is that it is agentless. There is no daemon to install on the machines you manage, it just needs SSH access and a working Python on the far end. You install it in one place, the control node, and reach everything else from there.

Ansible is written in Python, so Python and pip come first:

# Update packages, then install Python and pip
sudo yum update -y
sudo yum install -y python3 python3-pip

# Confirm what you have
python3 --version
pip3 --version

Then install Ansible itself. In the lab, I pinned an exact version:

# Install a specific Ansible version, system-wide
sudo pip3 install ansible==2.9.27 --prefix /usr/local
ansible --version

Pinning the version is the right instinct. An automation tool that silently upgrades underneath you is how a playbook that worked last week breaks today, so naming the version keeps runs reproducible.

Two honest caveats, because this is where the lab and the real world split.

First, that version is old. Ansible 2.9 is years behind now. On a fresh setup, you would reach for the current release, which ships as a package called ansible-core, the modern engine that the RHEL package manager provides in the 2.16 and up range.

Second, Red Hat does not recommend installing Ansible with sudo pip system-wide, because pip does not respect what the system package manager owns and can quietly clash with it. The supported routes are sudo dnf install ansible-core for a system install, or pip inside a Python virtual environment when you want the newest upstream version without touching system packages. The lab wanted the pip method, so that is what I ran, but on anything real, I would use dnf or a venv.

With Ansible installed, it needs to know what it is managing. That is the inventory file, a plain list of hosts grouped under a label:

# Create an inventory file
vi inventory

# [servers]
# 192.168.1.10
# 192.168.1.11

Then the moment of truth, the ping module:

# Check Ansible can reach every host in the 'servers' group
ansible -i inventory servers -m ping

Here is the trap hiding in the name. Ansible's ping is not an ICMP ping. It does not bounce a packet off the network. It logs into each host over SSH, checks that a usable Python is there, and returns pong only if all of that worked. So a green pong is proof of a full working connection, SSH and Python both, not just that the box is reachable. It is a stronger signal than a normal ping, and it fails for different reasons too, usually broken SSH auth or a missing Python rather than a dropped packet.

EC2 stop protection: a safety switch with a backwards name

Over on AWS, the task was to protect an important instance from being stopped by accident. AWS calls this stop protection, and turning it on is a single command:

# Enable stop protection
aws ec2 modify-instance-attribute \
  --instance-id i-1234567890abcdef0 \
  --disable-api-stop

Read that flag twice, because it catches everyone. --disable-api-stop sounds like it switches stopping off in some harmful way. It is actually the switch that turns protection on. It disables the stop API for that one instance, so the instance cannot be stopped until you remove the protection. To turn it back off later, you use the mirror flag, --no-disable-api-stop.

The note I was working from verified this by trying to stop the instance and watching the call fail. That works, but it is a nervous way to check, because if the protection had not actually applied, you would have just stopped your box. The calmer check is to ask AWS directly:

# Confirm protection is on without risking a stop
aws ec2 describe-instance-attribute \
  --instance-id i-1234567890abcdef0 \
  --attribute disableApiStop

If that returns true, protection is on, and any stop-instances call will now be refused with an error instead of quietly taking the instance down.

A few things worth knowing before you rely on it.

Stop protection and termination protection are two separate switches. Stop uses --disable-api-stop, termination uses --disable-api-termination. Turning on one does nothing for the other, so an instance you want fully locked down needs both.

It also does not apply everywhere. You cannot enable stop protection on an instance with an instance-store root volume or on a Spot Instance. For the standard EBS-backed on-demand instances most people run, you are covered.

The actual lesson

Both tasks were about trust, pointing in opposite directions. Ansible's ping earns your trust by doing more than the name suggests, a real login instead of a network poke. AWS's stop flag tests your trust by being named the opposite of what it does. The habit that carries you through both is the same one: read what a command actually does instead of what its name implies.

So here is Day 8's question. Would you rather assume a command does what it sounds like and find out the hard way in production, or spend the extra minute confirming what it really does before you depend on it?

Day 8 down. Ninety-two to go

100 Days of DevOps and Cloud (AWS), Day 7: Kill the SSH Password, and Resize EC2 the Right Way

Nnamdi Felix Ibe — Wed, 08 Jul 2026 06:01:24 +0000

A password is a secret you type. An SSH key is a secret you never send. That gap is the whole reason key-based login beats passwords, and Day 7 was where I set it up properly instead of halfway.

One Linux task, one AWS task. Configure passwordless SSH with a key pair, and change the type of an existing EC2 instance. Both are routine. Both have one detail that turns routine into broken if you skip it. The tasks come from the KodeKloud Engineer platform, the same as the rest of this series.

SSH keys: log in without ever sending a secret

Key-based SSH uses a pair. A private key that stays on your machine and never leaves it, and a public key you can hand out freely. The server keeps the public key, and when you connect, the two sides prove they match without the private key ever crossing the wire. A password does the opposite, it gets sent to the server on every login, which is one more thing that can be captured, guessed, or brute-forced.

Start by generating the pair on your own machine:

# Generate a key pair (modern OpenSSH defaults to ed25519)
ssh-keygen -t ed25519

A bare ssh-keygen works too. On current OpenSSH, it now defaults to ed25519, a fast modern key type, though older setups defaulted to RSA. I name the type with -t ed25519 so there is no guessing about what I ended up with. Accept the default file location, and add a passphrase if you want a second layer of protection on the key itself. Then push the public half to the server:

# Copy the PUBLIC key to the target server
ssh-copy-id user@hostname

ssh-copy-id handles the fiddly part for you. It appends your public key to ~/.ssh/authorized_keys on the server and sets the permissions correctly, which SSH is famously strict about. Do this by hand, and one wrong permission bit will make the server silently ignore your key while you wonder why it keeps asking for a password. Now test it:

# Should log you straight in, no password prompt
ssh user@hostname

Here is the part the task hints at but most people skip. Setting up a key does not disable passwords. Until you actually turn password login off, the server still accepts the weaker method, and anything on the internet can keep hammering it with guesses. Finish the job on the server side:

# In /etc/ssh/sshd_config, set:
PasswordAuthentication no

# Then reload the SSH daemon
sudo systemctl reload sshd

One warning that has locked plenty of people out of their own servers. Confirm your key login works in a second terminal before you disable passwords. If the key is not actually working and you switch passwords off, you have just removed your only way back in.

Resizing EC2: stop, modify, start, and mind the IP

The AWS task was to change an instance's type, say from a small t2.micro to a heavier t3.medium. You cannot do it live. The instance has to be stopped first because the type is tied to the physical host it runs on, and changing it means the instance gets placed somewhere new. Start by grabbing the ID:

# Get the instance ID by its Name tag
INSTANCE_ID=$(aws ec2 describe-instances \
  --filters "Name=tag:Name,Values=my-instance" \
  --query "Reservations[*].Instances[*].InstanceId" \
  --output text)

Storing the ID in a variable keeps the next few commands clean and stops you from pasting the wrong i-0abc123 halfway through. Then stop it and wait for the stop to finish:

# Stop it, then block until it is fully stopped
aws ec2 stop-instances --instance-ids $INSTANCE_ID
aws ec2 wait instance-stopped --instance-ids $INSTANCE_ID

That wait line is underrated. Instead of running describe-instances over and over to check whether it stopped yet, the waiter blocks until the state is actually stopped, then hands control back to your script. It is the difference between automation that works and automation that races ahead and fails on the next line. Now change the type:

# Change the instance type while it is stopped
aws ec2 modify-instance-attribute \
  --instance-id $INSTANCE_ID \
  --instance-type '{"Value": "t3.medium"}'

The target type has to be compatible with the AMI's architecture. Moving between two x86 types, like t2 to t3, is fine. Jumping to a Graviton (ARM) type would need an image built for that architecture, so those are not interchangeable. Start it back up and confirm the change:

# Start it again and verify the new type
aws ec2 start-instances --instance-ids $INSTANCE_ID
aws ec2 describe-instances \
  --instance-ids $INSTANCE_ID \
  --query "Reservations[*].Instances[*].InstanceType"

Now, the detail that catches people. A stop and start is not a reboot. When you stop an instance and start it again, it usually comes back on a different public IPv4 address, because the old one gets released back into the pool. The private IP inside the VPC stays the same, but any SSH session, DNS record, or firewall rule pinned to the old public IP is now pointing at nothing. If you need a public address that survives a stop and start, that is exactly the problem an Elastic IP solves.

One more worth knowing. If the instance had any instance-store (ephemeral) volumes, stopping it wipes that data. EBS root volumes are safe, which covers most default setups, but check before you stop something that keeps scratch data on local disk.

The actual lesson

Both tasks look finished the moment the command returns success. They are not. SSH is not hardened until passwords are switched off. A resize is not safe until you have accounted for the public IP that just changed underneath you. The command completing and the job being done are two separate moments, and the gap between them is where real operations actually live.

So here is Day 7's question. Would you rather run the command and trust that success means safe, or know exactly what changed the second it returns, so nothing surprises you a week later?

Day 7 down. Ninety-three to go.

100 Days of DevOps and Cloud (AWS), Day 6: Cron's Sneaky OR, and the EC2 Key You Only Get Once

Nnamdi Felix Ibe — Mon, 06 Jul 2026 21:10:28 +0000

Automation is the part of DevOps that actually earns the title. Day 6 was two of the most everyday automation tasks there are, and both had a trap sitting in plain sight.

One Linux task, one AWS task. Schedule a recurring job with cron, and launch an EC2 instance from the AWS CLI. The tasks come from the KodeKloud Engineer platform if you want the same lab to work through.

Cron: five fields, one rule that trips everyone

Cron is the scheduler that has quietly run Linux automation for decades. You hand it a job and a schedule, and its daemon, crond, wakes up every minute to check whether anything is due. If that daemon is not running, nothing fires, so the first move is making sure it is installed and enabled.

# Become root
sudo su -

# Install the cron daemon if it is missing
yum install cronie -y

# Enable it at boot, start it now, and confirm it is alive
systemctl enable crond.service
systemctl start crond.service
systemctl status crond.service

cronie is the package name on RHEL-family distros. enable makes the service survive a reboot, start brings it up right now, and status is how you confirm it is actually running instead of assuming it is. Now edit the crontab:

# Edit the current user's crontab
crontab -e

# minute  hour  day-of-month  month  day-of-week   command
0 2 * * * /path/to/script.sh

# List what is currently scheduled
crontab -l

That line runs the script every day at 2am. The five fields, in order, are minute, hour, day of month, month, and day of week:

minute: 0 to 59
hour: 0 to 23
day of month: 1 to 31
month: 1 to 12
day of week: 0 to 7, where both 0 and 7 mean Sunday

Here is the rule that quietly breaks schedules. When you set both the day-of-month field and the day-of-week field to something other than a star, cron treats them as OR, not AND. So 0 0 13 * 5 does not mean midnight on Friday the 13th. It means midnight on every 13th of the month, and also every Friday, whichever lands first. If you actually want the AND, you restrict one field in cron and check the other one inside your script.

Two more things bite people here.

Cron does not run with your shell environment. It uses a bare, minimal PATH and never reads your .bashrc or profile. A command that runs fine in your terminal can fail silently under cron because it cannot find the binary. Use absolute paths, both to your script and to anything the script calls.

Cron also says nothing when a job fails. By default, it tries to email the output to the local user, which on most boxes goes precisely nowhere. Redirect the output yourself so you have a trail to read:

# Capture normal output and errors so failures are visible
0 2 * * * /path/to/script.sh >> /var/log/myjob.log 2>&1

Launching EC2: gather first, launch once

The AWS task looks like a single run-instances command, but the command is the easy part. It fails the instant you feed it an argument it does not have, so the real work is gathering four things first: an AMI ID, a security group ID, a subnet ID, and a key pair.

# List the 5 newest Amazon-owned AMIs in the region
aws ec2 describe-images \
  --owners amazon \
  --region us-east-1 \
  --query 'reverse(sort_by(Images,&CreationDate))[:5].{id:ImageId,date:CreationDate}' \
  --output table

AMI IDs are region-specific, and they change often as Amazon publishes new images, so never hardcode one you found in a blog post, this one included. Look up a current ID in your own region every time. Next, find a security group and a subnet to launch into:

# The firewall (security group) and the network placement (subnet)
aws ec2 describe-security-groups
aws ec2 describe-subnets

The security group is the instance's firewall, and the subnet decides which VPC and availability zone it lands in. You need one ID from each. Then create the key pair, and this is the step to slow down on:

# Create a key pair and save the private key locally
aws ec2 create-key-pair \
  --key-name my-key \
  --query 'KeyMaterial' \
  --output text > my-key.pem

# Lock the permissions down
chmod 400 my-key.pem

AWS shows you the private key exactly once, at creation. There is no re-download and no recovery. Lose that .pem and the key pair is dead weight, you delete it and generate a new one. The chmod 400 is not optional either, SSH refuses to use a private key that other users on the box could read. Now launch, feeding in everything you gathered:

# Launch the instance
aws ec2 run-instances \
  --image-id ami-xxxxxxxxxxxx \
  --count 1 \
  --instance-type t2.micro \
  --key-name my-key \
  --security-group-ids sg-xxxxxxxxxx \
  --subnet-id subnet-xxxxxxxxxx \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=my-ec2}]'

Swap in the real AMI, security group, and subnet IDs you just looked up. t2.micro is the small, free-tier-friendly size, --count 1 launches a single instance, and the tag block names it so you are not squinting at raw instance IDs later. Then confirm it came up:

# Verify the instance state
aws ec2 describe-instances \
  --filters "Name=tag:Name,Values=my-ec2" \
  --query 'Reservations[*].Instances[*].{Id:InstanceId,State:State.Name}'

Right after launch the state reads pending, then flips to running within a minute or so. That tag filter is exactly why tagging at launch pays off, you query by name instead of digging for an ID.

One thing the task does not mention, but your wallet will. A running instance bills until you stop or terminate it. When the lab is done, terminate it. Learning to launch is only half the skill, cleaning up is the other half.

The actual lesson

Both tasks reward the same habit, and it is not typing speed. Cron punishes you for assuming the schedule means what it looks like. EC2 punishes you for launching before you have gathered what it needs. The people who get burned are the ones who sprint to the final command and skip the boring prep and the fine print.

So the choice for Day 6. Would you rather memorise the run-instances line and hope the environment matches, or understand every argument well enough to fix it yourself when it doesn't?

Day 6 down. Ninety-four to go.

100 Days of DevOps and Cloud (AWS), Day 5: SELinux Isn't Your Enemy, and GP3 Is Your Default

Nnamdi Felix Ibe — Sat, 04 Jul 2026 06:42:59 +0000

Most people meet SELinux for the first time when something breaks, and their first move is to switch it off. I get the reflex. But "disabled" is the laziest of the three options SELinux hands you, and Day 5 of this challenge is where that finally clicked for me.

Two tasks today, one on Linux and one on AWS. Install and configure SELinux on a RHEL-style box, and create a GP3 EBS volume from the AWS CLI. Both look like one-liners. Both hide a second layer that only shows up when you slow down and ask why. The tasks come from the KodeKloud Engineer platform if you want to follow along on the same setup.

SELinux: three modes, and why "off" should be last

SELinux stands for Security-Enhanced Linux, a mandatory access control layer baked straight into the kernel. Regular Linux permissions decide what a user is allowed to do. SELinux determines what a process is allowed to do, even when the user technically has the necessary permissions. That second gate is the entire point.

Picture a web server that gets compromised. With standard permissions alone, the attacker inherits whatever the web server user can touch. With SELinux in enforcing mode, that same hijacked process is boxed into exactly the files and ports its policy allows, so it cannot wander off across the filesystem. That is a security layer worth understanding before you rip it out.

Here are the installation steps. On RHEL, CentOS, Rocky and AlmaLinux, these packages are usually present already, but the task wanted it explicitly:

# Install the SELinux packages
sudo yum install selinux-policy selinux-policy-targeted policycoreutils

policycoreutils is the package that gives you sestatus, setenforce and the rest of the tooling. Next, set the mode permanently by editing the config file:

# Set the mode permanently
sudo vi /etc/selinux/config
# change SELINUX=enforcing to SELINUX=disabled

This file is the source of truth for what the box boots into. The task asked for disabled, so that is what went in. Then confirm the live status:

# Check the current status
sestatus

Now the part the one-liner hides. SELinux has three modes, and they are not interchangeable:

enforcing: rules are applied, violations are blocked and logged. This is what you want in production.
permissive: nothing is blocked, but every violation is logged. This is your debugging mode.
disabled: SELinux is off. No enforcement, no logs, no safety net.

When a service suddenly cannot read a file it clearly owns, the instinct is to jump straight to disabled. Fight it. Flip to permissive instead, reproduce the problem, and read the logs it generates. You get your answer without tearing out the whole security layer. Plenty of quickstart guides tell you to disable SELinux just to remove a variable, and that is fine on a throwaway lab box. It is a bad habit to carry into anything real.

Two things will catch you here.

First, switching to or from disabled needs a reboot. Editing the config file does not change the running mode on its own. Before you reboot, sestatus still reports the old state, which fools a lot of people into thinking the command failed.

Second, going from disabled back to enforcing is not free. The filesystem has to be relabeled so every file gets its SELinux context back. You trigger it like this:

# Relabel the whole filesystem on the next boot, then reboot
sudo touch /.autorelabel
sudo reboot

Skip that step, and you can boot into a machine where half your services refuse to start, which is a miserable way to learn what relabeling actually does.

GP3: the volume type you should default to

Over on AWS, the task was to create a GP3 EBS volume in a specific availability zone and tag it so you can find it later. One command does it:

# Create a 2 GiB GP3 volume in us-east-1a
aws ec2 create-volume \
  --availability-zone us-east-1a \
  --volume-type gp3 \
  --size 2 \
  --tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=my-volume}]'

Reading it left to right:

--availability-zone: a volume lives in exactly one AZ. It cannot cross zones, ever.
--volume-type gp3: the current-generation general-purpose SSD.
--size 2: the size in GiB, not GB. AWS measures and bills EBS in gigabytes, so 2 means 2 GiB.
--tag-specifications: tags the volume at creation time so you are not later hunting for a nameless vol-0a1b2c3d.

That tag block is the fiddly part. The ResourceType=volume prefix is required, and the quoting matters, so copy it carefully. Then verify the volume exists:

# Confirm it was created
aws ec2 describe-volumes --filters "Name=tag:Name,Values=my-volume"

The output shows the volume with a State of available, meaning it is created but not yet attached to anything.

So why default to GP3 over the older GP2? Performance you can actually reason about. GP3 gives every volume a flat baseline of 3,000 IOPS and 125 MiB/s of throughput no matter how small it is, and it lets you dial those numbers up independently when you need more (per the AWS EBS documentation).

GP2 ties performance to size. It gives you 3 IOPS per GiB, so a small GP2 volume is also a slow one, and the only way to speed it up is to make it bigger. GP3 breaks that link and usually costs less per GiB on top of it. For most general workloads, GP3 is the sensible default, which is exactly why AWS made it the default.

One catch, and it rhymes with the SELinux lesson: placement matters. Because this volume is pinned to us-east-1a, you can only attach it to an EC2 instance sitting in that same zone. Get the AZ wrong, and the volume is dead weight until you snapshot it and rebuild it elsewhere. Check your instance's AZ before you create the volume, not after.

Creating the volume is only step one. The real next move is attaching it with aws ec2 attach-volume, then formatting and mounting it on the instance. The task stopped at creation, though, so I will keep this honest and stop there too rather than pretend I did more.

The actual lesson

Both tasks were technically a single command. Both had a second layer that only appears when you ask why instead of copying the line and moving on. SELinux is not a switch to flip off; it is a set of modes with a purpose. GP3 is not a random SSD; it is a deliberate default with numbers behind it. That gap, between running a command and understanding it, is the whole difference between collecting completed tasks and owning the skill.

So here is the choice I would put to you if you are learning this too. Would you rather rack up a hundred green checkmarks you cannot explain, or ten you could rebuild from memory and defend in an interview?

Day 5 down. Ninety-five to go.

100 Days of DevOps and Cloud (AWS), Day 4: Permissions That Actually Matter and Why S3 Versioning Shouldn't Be Optional

Nnamdi Felix Ibe — Mon, 29 Jun 2026 22:04:05 +0000

Not every mistake breaks a system immediately.

Some mistakes just sit there quietly until the wrong person gets access, or someone deletes the wrong file, or a deployment goes sideways. Today's tasks were about putting guardrails in place before those moments happen.

Task 1 (Linux): Set Script Execution Permissions

A script isn't useful if it can't be executed. But making everything executable for everyone isn't the answer either. Linux permissions exist so you can decide exactly who gets to do what.

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

# Navigate to the script location
cd /path/to/script

# Grant execute permission
sudo chmod 755 /path/to/script.sh

# Verify permissions
ls -l /path/to/script.sh

Key points:
chmod 755 means the owner gets read, write, and execute permissions, while the group and everyone else can only read and execute.
Running ls -l should show something like -rwxr-xr-x. The leading simply tells you it's a regular file.
ls -la is useful when you also want to see hidden files in the directory.

One thing I've started appreciating is that Linux permissions aren't just about making something work—they're about limiting what doesn't need to happen. If a script only needs one person to modify it, there's no reason to let everyone else have write access.

Least privilege sounds like a security buzzword until someone accidentally edits a production script.

Task 2 (AWS): Enable Versioning on an S3 Bucket

Deleting the wrong file is inevitable.

Whether it's human error, a faulty deployment, or an application bug, objects eventually disappear or get overwritten. S3 Versioning exists so those mistakes don't automatically become disasters.

# Check current versioning status
aws s3api get-bucket-versioning --bucket my-bucket-name

# Enable versioning
aws s3api put-bucket-versioning \
  --bucket my-bucket-name \
  --versioning-configuration Status=Enabled

# Verify
aws s3api get-bucket-versioning --bucket my-bucket-name

Key points:
Once versioning is enabled, it can't be completely turned off—it can only be suspended.
Every version of every object is stored separately, so storage costs increase over time.
Versioning is required for S3 Replication and is commonly expected in backup and compliance environments.

The interesting thing is that versioning doesn't stop people from making mistakes.

It just gives you a way back.

Recovery is often more valuable than prevention because nobody gets everything right all the time.

What Day 4 Is Really About

Today's tasks looked unrelated.

One was about Linux file permissions.

The other was about object storage.

But they're solving the same problem: reducing the impact of human error.

Permissions stop the wrong people from changing things.

Versioning lets you recover when the right people change the wrong thing.

Neither feature makes a system more exciting.

They just make it far more forgiving.

So here's the question.

If someone accidentally deleted an important file or modified a production script today, how quickly could you recover?

The best time to prepare for mistakes is before anyone makes one.

100 Days of DevOps and Cloud (AWS), Day 3: Disabling Root SSH Login and Carving Out a VPC Subnet

Nnamdi Felix Ibe — Fri, 26 Jun 2026 18:10:36 +0000

A default is a decision someone else made for you.

It's set for convenience, to get you moving fast. That's the opposite of what you want once a system is real and people depend on it. Both of today's tasks change a default on purpose, one in Linux and one in AWS.

Task 1 (Linux): Disable Root Login Over SSH

By default, a lot of Linux images let root log in directly over SSH. That's one weak password, or one leaked key away from someone owning the entire machine. So you turn it off.

# Edit the SSH daemon config
sudo vi /etc/ssh/sshd_config

# Find this line and change it
# PermitRootLogin yes  ->  PermitRootLogin no

# Restart SSH to apply the change
sudo systemctl restart sshd

# Confirm the setting is live, without restarting again
sudo sshd -T | grep permitrootlogin

Key points:

sshd -T prints the effective running config. Use it to confirm the change took, instead of trusting that you edited the right line in the right file.
Make sure a non-root user with sudo exists before you do this. Turn off root login with no other way in, and you've locked yourself out of your own server.

I've never sat in a hardening review where this wasn't on the list. Not because disabling root is clever. Because the attacks that actually work are rarely clever. They're someone trying to root with a common password against a box that should never have accepted the attempt.

Task 2 (AWS): Carve Out a VPC Subnet Without Overlap

Goal: create a subnet inside an existing VPC. What the task is really checking is whether you look at what's already there before you add to it.

# See the VPC you're working in
aws ec2 describe-vpcs

# List existing subnets and their CIDR ranges first
aws ec2 describe-subnets \
  --query 'Subnets[*].{SubnetId:SubnetId, CidrBlock:CidrBlock}' \
  --output table

# Create the subnet with a range that doesn't overlap
aws ec2 create-subnet \
  --vpc-id <VpcId> \
  --cidr-block 10.0.0.0/24 \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-subnet}]'

# Verify it landed
aws ec2 describe-subnets --filters "Name=tag:Name,Values=my-subnet"

Key points:

List existing subnets before you create one. Two subnets with overlapping CIDR ranges are the kind of problem you don't notice now and can't easily explain later, when routing starts behaving in ways that make no sense.
A /24 gives you 256 addresses, 251 usable. AWS reserves 5 in every subnet, so the count never quite matches what you'd expect.
Tag it at creation. Finding a resource by name later beats hunting through a list of subnet IDs.

Subnets look trivial until you're a few environments deep and two of them claim the same range. Address planning is boring on Day 1 and the reason for a war room on Day 200. The check is one command. Run it before, not after.

What Day 3 Is Really About

Both tasks took less than a minute of typing. Neither is hard. The skill isn't the command; it's the habit of not accepting what you were handed just because it works out of the box.

So here's the question for the systems you run right now. How many defaults are still sitting there untouched because nobody stopped to ask whether they should be? Pick one this week and change it on purpose.

100 Days of DevOps and Cloud (AWS), Day 2: Expiring Linux Users and Locking Down Security Groups

Nnamdi Felix Ibe — Tue, 23 Jun 2026 09:48:23 +0000

Day 2. Not Day 1, not Day 50. Day 2 is the day the motivation from starting has worn off, and the finish line isn't in sight yet. This is where most challenges quietly die.

So here's mine.

Same format as yesterday: the Linux task and the AWS task from the session, plus what actually matters about each one once you've done it a few hundred times in production. Today, both tasks come down to the same idea. Controlling access. Who gets in, and from where.

Task 1 (Linux): Create a User That Expires on Its Own

The task: create an account that switches itself off on a set date. This is what you set up for a contractor, an auditor, anyone with temporary access.

# Create the user with an expiry date (format: YYYY-MM-DD)
sudo useradd -e 2026-12-31 username

# Verify the expiry date is set
sudo chage -l username

Key points:

useradd -e sets the expiry at the moment you create the account, so there's no follow-up task to remember.
chage -l lists the account's ageing settings. Confirm Account expires shows the date you set.

The accounts that cause incidents aren't the ones you remember to remove. They're the ones you forget. Setting the expiry at creation means there's nothing to forget. In a regulated environment, a contractor account with no end date is exactly the kind of thing that turns up in an access review with your name next to it.

Task 2 (AWS): Create a Security Group and Open One Port

Goal: create a security group and allow a single port in. Here, that's RDP on 3389.

# Create the security group in the default VPC
aws ec2 create-security-group \
  --group-name my-sg \
  --description "My security group"

# Add an inbound rule. Allow TCP 3389 (RDP) from a specific CIDR
aws ec2 authorize-security-group-ingress \
  --group-id <GroupId> \
  --protocol tcp \
  --port 3389 \
  --cidr x.x.x.x/x

# Verify the rule was added
aws ec2 describe-security-groups --group-ids <GroupId>

Key points:

A new security group blocks all inbound traffic and allows all outbound by default. You only add what you want to let in.
Security groups are stateful. Allow the inbound request and the return traffic is automatic. You don't need a matching outbound rule.
Scope the CIDR. 0.0.0.0/0 on a port like 3389 or 22 means the entire internet can reach it.

Read enough breach write-ups, and a pattern shows up. There's almost always a security group in the story, opened wider than it needed to be, for a reason nobody can remember. 0.0.0.0/0 is convenient on a Friday afternoon and a liability by Monday. Scope it to the address that actually needs it.

What Day 2 Is Really About

Both tasks today limit something. The user expires. The port opens to one address, not the whole internet.

None of it is advanced. All of it is the difference between a system that passes an audit and one that becomes a story other engineers read later.

Day 3 is already done. If you're documenting your own work, here's my question: do you write down the boring controls, the expiry dates and the scoped CIDRs, or only the clever stuff? Because in my experience, the boring controls are the ones that save you.

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

Nnamdi Felix Ibe — Sat, 20 Jun 2026 21:46:34 +0000

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?