AWS + Git + EC2 + Linux — Day 1–4 Study Guide

Generated on 2025-08-31 19:13

Day 1 AWS Account, IAM, MFA, Billing, AWS CLI

Day 2 Git Basics, Branching, PRs, Protection

Day 3 EC2 & SSH Essentials

Day 4 Linux Commands & Administration

Day 1 — AWS Account, IAM, MFA, Billing Alerts, AWS CLI

1) Why use IAM users instead of the root account?
• Root = Unlimited power: it can close the account, change billing, and delete everything.
• No guardrails: you can't easily limit root. With IAM you can restrict, require MFA, and audit.
• Best practice: Enable MFA on root, create an Admin role/user, and lock root away for rare tasks.

2) IAM Users vs Groups vs Roles

• User: Long■lived identity (person/app) with sign■in and optional access keys.
• Group: Attach policies once and apply to many users (e.g., Developers, BillingViewers).
• Role: Temporary identity assumed via STS (short■lived credentials). Ideal for EC2/CI/CD/cross■account.

3) Enforce MFA for all users

Attach a Deny policy that blocks actions when MFA is not present; in Organizations, use an SCP. Ask
users to set up virtual MFA (e.g., Authy, Google Authenticator).
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DenyAllIfNoMFA",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}
}
}]
}

4) Principle of Least Privilege (PoLP)

• Give only the permissions needed, nothing more.
• Start narrow → observe usage (Access Advisor / CloudTrail) → add only what's required.
• Scope by resource ARN, conditions (tags, IP, MFA), and time.
• Use permission boundaries, SCPs, and session policies for guardrails.

5) Billing alerts (important for Free Tier)

• Create an AWS Cost Budget with actual and forecast alerts sent to Email/SNS.
• Watch pitfalls: EBS size, NAT Gateway, data transfer, wrong instance types.
• Consider Cost Anomaly Detection for spikes.

6) Access keys vs IAM roles (for CLI)

• Access keys: Long■lived on your machine; risky if leaked; you must rotate.
• IAM roles: Short■lived tokens via SSO/STS; safer and preferred for humans and workloads.

7) Configure AWS CLI (step by step)

• Install CLI v2 → verify with aws --version.
• Option A (keys): aws configure --profile dev → enter key, region, output.
• Option B (SSO): aws configure sso → choose account/role; profile is saved.
• Test: aws sts get-caller-identity --profile dev.
• Profiles live in ~/.aws/credentials and ~/.aws/config.

8) If an access key leaked on GitHub

• Immediate: Deactivate/delete key; rotate only if necessary; purge from Git history (BFG or git filter■repo);
force■push.
• Audit via CloudTrail; remove anything malicious created.
• Enable secret scanning and pre■commit hooks; prefer roles/SSO over long■lived keys.

9) Inline policies vs Managed policies

• Inline: Lives on one user/role/group; hard to reuse/audit.
• Managed: Reusable standalone policies (AWS■managed or customer■managed); versionable and
governed.
• Rule: prefer customer■managed policies for your org.

Day■to■day: Monitor unapproved new IAM users

Use CloudTrail + EventBridge rules for IAM events like CreateUser/CreateAccessKey/AddUserToGroup,
then notify via SNS/Slack (or open a ticket).
# EventBridge pattern for CreateUser
{
"source": ["aws.iam"],
"detail-type": ["AWS API Call via CloudTrail"],
"detail": {
"eventSource": ["iam.amazonaws.com"],
"eventName": ["CreateUser"]
}
}
 Day 2 — Git Basics, Branching, Pull Requests, Protection
1) git init vs git clone
• git init: start a new, empty repo in the current folder.
• git clone <url>: copy an existing remote repo (code + history).

2) Staging area & git add

• Staging is your 'basket' of changes for the next commit.
• git add fileA adds only that file; git add . adds everything.
• Undo staging: git restore --staged fileA. Use git add -p to stage parts.

3) git commit vs git push

• git commit -m: saves a snapshot locally.
• git push origin branch: sends your commits to the remote (GitHub).

4) Resolve conflicts when two people change same lines

• Update: git pull --rebase origin <branch>.
• Edit conflict markers, keep correct lines, then git add.
• Continue: git rebase --continue; then push (maybe --force-with-lease for your feature branch).
• Avoid with small PRs and frequent pulls.

5) Purpose of a Pull Request (PR)

• Safe proposal to merge changes.
• Enables code review, CI checks, discussion, and documented history.

6) Branch protection rules (and why)

• In GitHub → Settings → Branches → Add rule for main/develop.
• Require PR reviews, passing status checks, and disallow direct/force pushes.
• Use Code Owners for critical paths; prevents broken code entering main.

7) Committed a secret by mistake

• Remove it and rotate the secret (invalidate old).
• Rewrite history (BFG or git filter■repo) and force push.
• Enable secret scanning; add pre■commit hooks; store secrets in a vault/CI store.

8) git fetch vs git pull

• git fetch: downloads remote updates without changing your branch.
• git pull: fetch + merge/rebase into current branch (prefer --rebase).

9) Simple branching strategy

• main: always deployable (production).
• feature/<task>: short■lived branches; open PR into main when done.
• hotfix/<issue>: quick fix from main; merge back and deploy immediately.

Day■to■day: Broken code pushed to main

• Fix now: git revert <bad-sha> to undo safely; redeploy a known good build.
• Prevent: protect main, require PRs + green CI, add smoke tests/linters, and use Code Owners.
 Day 3 — EC2 & SSH
1) Key pair vs password login
• Key pairs (.pem) are default and more secure; no passwords to guess.
• Passwords are weaker and often disabled; consider SSM Session Manager to avoid SSH entirely.

2) Security Group vs NACL

• Security Group: Stateful, instance■level firewall—return traffic auto■allowed.
• NACL: Stateless, subnet■level—must allow both directions explicitly.
• Use SGs for most scenarios; touch NACLs sparingly.

3) .pem file permissions too open

# Linux/macOS
chmod 400 mykey.pem

# Windows PowerShell (limit to your user)

icacls .\mykey.pem /inheritance:r
icacls .\mykey.pem /grant:r "$($env:USERNAME):R"

# SSH
ssh -i mykey.pem ec2-user@PUBLIC_IP

4) Can't SSH — what to check first

• Instance running; correct username (ec2-user for Amazon Linux, ubuntu for Ubuntu).
• Public IP/Elastic IP present; in public subnet with route to an Internet Gateway.
• SG: inbound TCP 22 allowed from your IP; NACL allows 22 + ephemeral return ports.
• Local/VPN/office firewall not blocking; consider Bastion or SSM if private.
• On■instance: sshd running? cloud■init done? Use EC2 serial console/SSM for repair.

5) t2.micro vs t3.micro
• Both burstable; t3 is newer (Nitro), more efficient, better baseline price/perf.
• Unlimited mode allows longer bursts (may incur cost if over credits).

6) Install/update packages (Amazon Linux)

# Amazon Linux 2
sudo yum update -y
sudo yum install -y git docker nginx
sudo usermod -aG docker ec2-user
sudo systemctl enable --now docker nginx

# Amazon Linux 2023

sudo dnf update -y
sudo dnf install -y git docker nginx
sudo usermod -aG docker ec2-user
sudo systemctl enable --now docker nginx

7) Transfer files to/from EC2

# SCP
 scp -i mykey.pem file.txt ec2-user@IP:~/
scp -i mykey.pem ec2-user@IP:~/file.txt .

# rsync (efficient for folders)

rsync -avz -e "ssh -i mykey.pem" ./dir ec2-user@IP:~/dir

# S3 (alternative path)
aws s3 cp s3://bucket/file .

8) Instance terminated — data?

• Instance Store: data is gone on stop/terminate; use only for cache/temp.
• EBS: can persist. If DeleteOnTermination=false, volume survives and can be reattached.
• Always keep snapshots/AMIs; use DLM to automate EBS snapshots.

9) EBS vs Instance Store

• EBS: Network■attached, persistent, snapshot■able; survives stop/start.
• Instance Store: Local NVMe, very fast, ephemeral (data lost on stop/terminate).

10) Auto■install at boot (User Data)

#cloud-config
package_update: true
packages: [nginx, docker]
runcmd:
- usermod -aG docker ec2-user
- systemctl enable --now docker nginx

#!/bin/bash
yum update -y
yum install -y docker nginx
usermod -aG docker ec2-user
systemctl enable --now docker nginx

Add in: Launch EC2 → Advanced details → User data. Logs: /var/log/cloud-init-output.log
 Day 4 — Linux Commands & Administration
1) Create, move, delete files/directories
# files
touch a.txt
cp a.txt b.txt
mv b.txt c.txt
rm c.txt

# directories
mkdir dir1
cp -r dir1 dir2
mv dir2 /tmp/
rm -r /tmp/dir2

2) Absolute vs Relative path

• Absolute: Full path from root '/', e.g., /var/log/messages
• Relative: From current directory, e.g., ../logs/messages
• Show current directory: pwd

3) Permissions: rwxr-xr-- and how to change

• Owner: rwx (7), Group: r-x (5), Others: r-- (4).
• Change: chmod 754 file or chmod u=rwx,g=rx,o=r file.
• Add/remove specific bits: chmod u+x, chmod g-w.

4) chmod vs chown vs chgrp

• chmod: change permissions (e.g., chmod 640 file).
• chown: change owner (e.g., sudo chown alice file).
• chgrp: change group (e.g., sudo chgrp devs file).

5) Find which process uses port 80

sudo ss -lntp | grep :80
# or
sudo lsof -i :80
# then
ps -fp <PID>

6) kill -15 vs kill -9

• -15 (TERM): ask to exit cleanly (preferred).
• -9 (KILL): force exit immediately (last resort).
• For services, prefer systemctl stop <service>.

7) Check running services & logs

systemctl list-units --type=service --state=running
systemctl status nginx
journalctl -u nginx --no-pager | tail -n 50
 8) yum/dnf vs apt-get
• RHEL/CentOS/Amazon Linux: yum (older) or dnf (newer).
• Debian/Ubuntu: apt-get/apt.
• Updates: sudo dnf update -y / sudo yum update -y / sudo apt update && sudo apt upgrade -y.

9) Check memory, CPU, disk usage

free -h # memory
top # CPU/processes (q to quit)
df -h # disk space per filesystem
du -sh * # per-folder usage in current dir

10) IP address & routing table

ip addr show # or: ip a
ip route # or: ip r
hostname -I # quick IP(s)

Tip: Convert this into your team runbook and keep it in your wiki.