What Does a Cloud Engineer Do on a Normal Work Day?

#!/usr/bin/env bash
# Quick morning look at CloudWatch alarms and running instances
set -euo pipefail
REGION=${AWS_REGION:-ap-south-1}
echo "== Alarms in ALARM state =="
aws cloudwatch describe-alarms --region "$REGION" --state-value ALARM \
  --query 'MetricAlarms[].{name:AlarmName,reason:StateReason}' --output table
echo "== Running instances =="
aws ec2 describe-instances --region "$REGION" \
  --filters Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].{id:InstanceId,type:InstanceType}' --output table

Stand-up (example format):

Yesterday: finished Terraform module for the staging database
Today:     review two PRs; handle access request ticket; start S3 lifecycle rules
Blockers:  waiting for approval on the new VPC peering change

Keep it short: what you did, what you will do, what is blocking you.

# Ticket: create a private, encrypted bucket for report files
resource "aws_s3_bucket" "reports" {
  bucket = "example-team-reports-staging"
  tags   = { team = "analytics", env = "staging", ticket = "OPS-123" }
}

resource "aws_s3_bucket_public_access_block" "reports" {
  bucket                  = aws_s3_bucket.reports.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "reports" {
  bucket = aws_s3_bucket.reports.id
  rule {
    apply_server_side_encryption_by_default { sse_algorithm = "AES256" }
  }
}

#!/usr/bin/env bash
# Typical flow for an infrastructure change
set -euo pipefail
git switch -c ops-123-reports-bucket
terraform fmt -recursive
terraform validate
terraform plan -out=plan.tfplan     # read the plan carefully
git add . && git commit -m "OPS-123: private encrypted reports bucket"
git push -u origin ops-123-reports-bucket
# Open a pull request; apply only after review and approval

# pip install boto3   Lists EBS volumes not attached to any instance
import boto3

ec2 = boto3.client("ec2", region_name="ap-south-1")
resp = ec2.describe_volumes(Filters=[{"Name": "status", "Values": ["available"]}])
for v in resp["Volumes"]:
    tags = {t["Key"]: t["Value"] for t in v.get("Tags", [])}
    print(v["VolumeId"], f"{v['Size']} GiB", v["CreateTime"].date(), tags.get("team", "untagged"))
print("Review with owners before deleting anything.")

Pull request review checklist:

[ ] Plan output attached and matches the description
[ ] No public access unless clearly required and approved
[ ] Security group rules are narrow (no open SSH)
[ ] IAM permissions follow least privilege
[ ] Encryption enabled for storage and databases
[ ] Tags include team, env and ticket
[ ] Rollback approach is clear

Day 1  Build a dashboard and one alarm for a small app
Day 2  Write a morning check script
Day 3  Handle a mock ticket: private encrypted bucket via Terraform
Day 4  Review your own PR with the checklist
Day 5  Find and tag (or delete) leftover practice resources
Day 6  Write a runbook for one alert
Day 7  Do a mock on-call drill: break something, then fix it

Alert: High 5xx error rate on web service

What it means: users are seeing errors
First checks:
  1. Recent deployments or infrastructure changes?
  2. Target health on the load balancer
  3. Application logs for the error
  4. Database connections and CPU
Mitigation: roll back the last change if related
Escalate to: application team if code-related
After: write a short incident note

Situation: practice environment had untagged leftover resources
Task: find waste safely
Action:
  - script listing unattached volumes and idle instances
  - tagging policy added in Terraform
  - budget alert configured
Result: clean account, clear ownership; I can explain the process