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.
Top comments (0)