Day 30: Hard Reset Forgets on Purpose, and NAT Needs a Guardrail Switched Off

Thirty days after starting, two specific tasks were tackled that required voluntarily turning off safeguards designed to protect users. Git refused to permit overwriting shared history, while EC2 would not forward packets not destined for it. Both decisions were justified as correct, and the tasks in question were to undo a branch through a hard reset followed by forcing a push, and building a NAT instance to enable a private EC2 instance to access S3.

These tasks were sourced from the KodeKloud Engineer platform. The hard reset involved rewriting history without leaving a trace, a practice generally discouraged. The process involved changing the directory, listing the current branch, displaying the commit history, resetting the branch to a specific commit, and verifying the log and status.

Resetting with the "hard" mode moved the branch pointer back and discarded any uncommitted work, with no possible undo. Pushing the changes was rejected because the branch was no longer a fast-forward, and the push was terminated. It was advised to use the "--force-with-lease" option, which checks if the remote remains unchanged and refuses if anyone has pushed updates.

The NAT instance task aimed to resolve a situation where a private EC2 instance, running a cron job to upload files to S3, was failing due to lack of internet access. The first step involved discovering that no internet gateway was attached to the VPC. Adding a NAT instance in a public subnet, and configuring the NAT instance to allow outbound internet access was the solution.

This involved installing necessary packages, modifying iptables rules to enable source/destination forwarding, and configuring the ENI (Elastic Network Interface) for routing. This NAT instance approach was cheaper than a NAT Gateway and provided a hands-on learning experience.