Files
kodekloud-engineer/aws-31-34.md

317 lines
11 KiB
Markdown

## Task 31
As a member of the Nautilus DevOps Team, your task is to perform the following:
Provision a Private RDS Instance: Create a new private RDS instance named devops-rds using the Full configuration database creation method, and select the Free tier template. Further, it must be a db.t3.micro type instance.
Engine Configuration: Use the MySQL engine with version 8.4.x.
Enable Storage Autoscaling: Enable storage autoscaling and set the threshold value to 50GB. Keep the rest of the configurations as default.
Instance Availability: Ensure the instance is in the available state before submitting this task.
```bash
REGION=us-east-1
aws rds create-db-instance \
--db-instance-identifier devops-rds \
--engine mysql \
--engine-version 8.4.10 \
--db-instance-class db.t3.micro \
--allocated-storage 20 \
--max-allocated-storage 50 \
--master-username admin \
--master-user-password 'ChangeMe_Str0ng!23' \
--no-publicly-accessible \
--no-multi-az \
--backup-retention-period 7 \
--region $REGION
# waiter
aws rds wait db-instance-available \
--db-instance-identifier devops-rds \
--region $REGION
# status poller
watch -n 10 'aws rds describe-db-instances \
--db-instance-identifier devops-rds \
--query "DBInstances[0].DBInstanceStatus" --output text'
# validation
aws rds describe-db-instances \
--db-instance-identifier devops-rds \
--region $REGION \
--query 'DBInstances[0].{Status:DBInstanceStatus,Engine:Engine,Version:EngineVersion,Class:DBInstanceClass,Alloc:AllocatedStorage,MaxAlloc:MaxAllocatedStorage,Public:PubliclyAccessible,MultiAZ:MultiAZ}'
```
## Task 32
As a member of the Nautilus DevOps Team, your task is to perform the following:
Take a Snapshot: Take a snapshot of the xfusion-rds RDS instance and name it xfusion-snapshot (please wait xfusion-rds instance to be in available state).
Restore the Snapshot: Restore the snapshot to a new RDS instance named xfusion-snapshot-restore.
Configure the New RDS Instance: Ensure that the new RDS instance has a class of db.t3.micro.
Verify the New RDS Instance: The new RDS instance must be in the Available state upon completion of the restoration process.
```bash
REGION=us-east-1
# ── 0. Wait for the source to be available before snapshotting ──
# `aws rds wait db-instance-available` blocks silently for up to ~40 min
# with zero feedback, so swap in a polling loop that prints the state
# on every check (original waiter kept below for reference):
# aws rds wait db-instance-available \
# --db-instance-identifier xfusion-rds --region $REGION
until [ "$STATUS" = "available" ]; do
STATUS=$(aws rds describe-db-instances \
--db-instance-identifier xfusion-rds --region $REGION \
--query 'DBInstances[0].DBInstanceStatus' --output text)
echo "xfusion-rds: $STATUS"
[ "$STATUS" = "available" ] || sleep 10
done
# ── 1. Take the snapshot ──
aws rds create-db-snapshot \
--db-instance-identifier xfusion-rds \
--db-snapshot-identifier xfusion-snapshot \
--region $REGION
# Wait for the snapshot to finish (creating -> available)
# aws rds wait db-snapshot-available \
# --db-snapshot-identifier xfusion-snapshot --region $REGION
unset STATUS
until [ "$STATUS" = "available" ]; do
STATUS=$(aws rds describe-db-snapshots \
--db-snapshot-identifier xfusion-snapshot --region $REGION \
--query 'DBSnapshots[0].Status' --output text)
echo "xfusion-snapshot: $STATUS"
[ "$STATUS" = "available" ] || sleep 10
done
# ── 2 + 3. Restore into a NEW instance, force db.t3.micro ──
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier xfusion-snapshot-restore \
--db-snapshot-identifier xfusion-snapshot \
--db-instance-class db.t3.micro \
--region $REGION
# ── 4. Wait for the restored instance to be available ──
# aws rds wait db-instance-available \
# --db-instance-identifier xfusion-snapshot-restore --region $REGION
unset STATUS
until [ "$STATUS" = "available" ]; do
STATUS=$(aws rds describe-db-instances \
--db-instance-identifier xfusion-snapshot-restore --region $REGION \
--query 'DBInstances[0].DBInstanceStatus' --output text)
echo "xfusion-snapshot-restore: $STATUS"
[ "$STATUS" = "available" ] || sleep 10
done
# verify
REGION=us-east-1
aws rds describe-db-instances \
--db-instance-identifier xfusion-snapshot-restore \
--region $REGION \
--query 'DBInstances[0].{Status:DBInstanceStatus,Class:DBInstanceClass,Engine:Engine,Version:EngineVersion}'
aws rds describe-db-snapshots \
--db-snapshot-identifier xfusion-snapshot \
--region $REGION \
--query 'DBSnapshots[0].{Id:DBSnapshotIdentifier,Status:Status,Source:DBInstanceIdentifier}'
```
## Task 33
The Nautilus DevOps team is embracing serverless architecture by integrating AWS Lambda into their operational tasks. They have decided to deploy a simple Lambda function that will return a custom greeting to demonstrate serverless capabilities effectively. This function is crucial for showcasing rapid deployment and easy scalability features of AWS Lambda to the team.
Create Lambda Function: Create a Lambda function named xfusion-lambda.
Runtime: Use the Runtime Python.
Deploy: The function should print the body Welcome to KKE AWS Labs!.
Status Code: Ensure the status code is 200.
IAM Role: Create and use the IAM role named lambda_execution_role.
Use the AWS Console to complete this task.
# AWS Lambda Task — `xfusion-lambda`
Runtime pinned: latest is **Python 3.14** (Lambda added it Nov 18, 2025 as the latest LTS release). Use `python3.14` — or 3.13 if the grader's env lags; both are current. Avoid 3.10/3.11 (on the AL2 deprecation track tied to the June 30, 2026 EOL).
Task says use the console, so here's the click-path — with the CLI equivalent after, for reproducibility.
## Console steps
First the IAM role (Lambda needs it to exist before/at function creation):
1. **IAM → Roles → Create role.** Trusted entity type: **AWS service**. Use case: **Lambda**. Next.
2. Attach **`AWSLambdaBasicExecutionRole`** (managed policy — grants CloudWatch Logs write, the minimum a Lambda needs). Next.
3. Role name: **`lambda_execution_role`**. Create role.
Then the function:
4. **Lambda → Create function → Author from scratch.**
5. Function name: **`xfusion-lambda`**. Runtime: **Python 3.14**. Architecture: leave x86_64.
6. Expand **Change default execution role → Use an existing role →** pick **`lambda_execution_role`**. Create function.
7. In the code editor, replace `lambda_function.py` with the handler below, then **Deploy** (Ctrl+S / Deploy button).
8. **Test** → create a test event (any name, default empty `{}` payload) → Run. Confirm the result shows `statusCode: 200` and the body string.
The handler:
```python
def lambda_handler(event, context):
return {
'statusCode': 200,
'body': 'Welcome to KKE AWS Labs!'
}
```
That's the whole function — returns the exact body and a 200. The task's "print the body" maps to the returned `body` field (what an invocation/API-Gateway-style response surfaces), not a `print()` to stdout. Returning the dict with `statusCode: 200` satisfies both requirements 3 and 4.
## CLI equivalent
In case you'd rather, or to verify:
```bash
REGION=us-east-1
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
# 1. Trust policy + role
cat > /tmp/lambda-trust.json << 'EOF'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"lambda.amazonaws.com"},"Action":"sts:AssumeRole"}]}
EOF
aws iam create-role \
--role-name lambda_execution_role \
--assume-role-policy-document file:///tmp/lambda-trust.json
aws iam attach-role-policy \
--role-name lambda_execution_role \
--policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
# 2. Package the handler
mkdir -p /tmp/fn && cat > /tmp/fn/lambda_function.py << 'EOF'
def lambda_handler(event, context):
return {'statusCode': 200, 'body': 'Welcome to KKE AWS Labs!'}
EOF
(cd /tmp/fn && zip -q function.zip lambda_function.py)
# 3. Create the function (IAM role propagation lags ~10s; retry if it errors)
aws lambda create-function \
--function-name xfusion-lambda \
--runtime python3.14 \
--role "arn:aws:iam::${ACCOUNT_ID}:role/lambda_execution_role" \
--handler lambda_function.lambda_handler \
--zip-file fileb:///tmp/fn/function.zip \
--region $REGION
```
## Things worth knowing (either path)
- **`--handler lambda_function.lambda_handler`** = `<filename without .py>.<function name>`. The file must be `lambda_function.py` and the function `lambda_handler`, or Lambda can't find the entry point. This is the #1 "works in console, breaks on deploy" mismatch.
- **IAM role propagation is eventually consistent** — a freshly-created role sometimes isn't visible to Lambda for a few seconds, so CLI `create-function` can throw `The role defined for the function cannot be assumed`. Just re-run; it settles. The console usually masks this because you click through slower than the propagation.
## Verify
```bash
aws lambda invoke --function-name xfusion-lambda --region $REGION /tmp/out.json \
&& cat /tmp/out.json
```
Want `{"statusCode": 200, "body": "Welcome to KKE AWS Labs!"}`. That's the invocation returning the exact body with a 200. Done.
## Task 34
The Nautilus DevOps team continues to explore serverless architecture by setting up another Lambda function. This time, the task must be completed using the AWS Console to familiarize the team with the web interface. The function will return a custom greeting and demonstrate the capabilities of AWS Lambda effectively.
Create Python Script: Create a Python script named lambda_function.py with a function that returns the body Welcome to KKE AWS Labs! and status code 200.
Zip the Python Script: Zip the script into a file named function.zip.
Create Lambda Function: Create a Lambda function named xfusion-lambda-cli using the zipped file and specify Python as the runtime.
IAM Role: Use the IAM role named lambda_execution_role.
```bash
REGION=us-east-1
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
# --- script + zip ---
mkdir -p ~/xfusion-lambda-cli && cd ~/xfusion-lambda-cli
cat > lambda_function.py << 'EOF'
def lambda_handler(event, context):
return {'statusCode': 200, 'body': 'Welcome to KKE AWS Labs!'}
EOF
zip function.zip lambda_function.py
# --- IAM role ---
cat > /tmp/lambda-trust.json << 'EOF'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"lambda.amazonaws.com"},"Action":"sts:AssumeRole"}]}
EOF
aws iam create-role \
--role-name lambda_execution_role \
--assume-role-policy-document file:///tmp/lambda-trust.json
aws iam attach-role-policy \
--role-name lambda_execution_role \
--policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
# --- give IAM a moment to propagate, then create the function ---
sleep 10
aws lambda create-function \
--function-name xfusion-lambda-cli \
--runtime python3.14 \
--role "arn:aws:iam::${ACCOUNT_ID}:role/lambda_execution_role" \
--handler lambda_function.lambda_handler \
--zip-file fileb://function.zip \
--region $REGION
# Verify
aws lambda invoke --function-name xfusion-lambda-cli --region $REGION /tmp/out.json \
&& cat /tmp/out.json
```
## Task 36
```bash
```
## Task 37
```bash
```
## Task 38
```bash
```
## Task 39
```bash
```
## Task 40
```bash
```