Senior questions

Scenario

An internal serverless API is needed for order management. Orders must be stored in a DynamoDB table with all access routed through a Lambda function — never direct database access. The Lambda execution role should follow least-privilege principles, limiting permissions to only what's necessary.

Task

1. Create a DynamoDB table named orders with orderId as the partition key
2. Create an IAM role called lambda-orders-role that assumes Lambda permissions
3. Create a orders-handler Lambda function using Python 3.12 with environment variable TABLE_NAME=orders (code provided at /tmp/handler.py)
4. Create a REST API named orders-api with an /orders endpoint supporting GET and POST methods
5. Deploy to a dev stage for public access

---

📹 Video Solution

Scenario

You need to deploy a web application accessible only within a VPC. EC2 instances run in private subnets behind an Application Load Balancer in public subnets. A startup script at /tmp/userdata.sh runs a simple HTTP server with a /health endpoint on port 80.

Task

1. Create a VPC named app-vpc using CIDR 10.0.0.0/16 with public and private subnets across two availability zones
2. Establish two security groups: alb-sg allowing HTTP from internal networks, and ec2-sg allowing HTTP only from the load balancer
3. Launch two EC2 instances in private subnets using Amazon Linux 2 AMI with the provided startup script
4. Configure an ALB named app-alb with target group app-tg, health checks at /health, and HTTP listener on port 80
5. Create a private Route 53 hosted zone for internal.example.com and add a CNAME record app.internal.example.com pointing to the ALB

---

Solution

Scenario:

You have created a macvlan network called mymacvlan to give containers their own MAC addresses on the physical network. However, containers mac1 and mac2 started on this network cannot ping the host or the gateway at 192.168.50.1.

Task:

Correct the macvlan network configuration so that both mac1 and mac2 can successfully ping the gateway at 192.168.50.1 .

---

📹 Video Solution

Scenario

You manage a CustomResourceDefinition (CRD) for "Widgets". Currently, the API allows users to create widgets with missing or invalid configuration, which causes the controller to crash.

Task

Modify the existing widgets.mycompany.io CRD to enforce a schema. Require the field spec.size to be present. Restrict spec.size to be an integer with a minimum value of 1. Attempt to create a custom resource named bad-widget (provided in the file bad-widget.yaml) that is missing the size field. Verify that the creation fails and the resource is not created.

---

📹 Video Solution

Scenario

Configuration files in /etc are at risk of being lost due to accidental changes or deletions, and there's currently no automated backup process in place.

Task

Write a shell script at /usr/local/bin/backup_etc.sh that accepts a target backup path (where files will be saved at) as a command-line argument, creates a compressed archive of /etc with the naming format etc-backup-YYYY-MM-DD.tar.gz, automatically removes backups older than 7 days, and exits with an error if no path is provided. Make the script executable and create a cron job to run it daily at 02:00 AM, storing backups in /backups/etc/ using crontab command. You can use https://crontab.guru for cronjob format.

Once script is created execute it /usr/local/bin/backup_etc.sh /backups/etc/

Example

# Before (no automated backups)

No backup script exists
/etc directory unprotected
Manual backups required

# After (automated backup system configured)

Backup script created and executable
Running without argument:
  Error: Backup directory path required

Running with argument creates timestamped backup:
  /backups/etc/etc-backup-2025-11-06.tar.gz

After 7 days of daily backups:
  etc-backup-2025-11-01.tar.gz (deleted - older than 7 days)
  etc-backup-2025-11-02.tar.gz (deleted - older than 7 days)
  etc-backup-2025-11-03.tar.gz
  etc-backup-2025-11-04.tar.gz
  etc-backup-2025-11-05.tar.gz
  etc-backup-2025-11-06.tar.gz
  etc-backup-2025-11-07.tar.gz
  etc-backup-2025-11-08.tar.gz
  etc-backup-2025-11-09.tar.gz

Cron job configured: runs daily at 02:00 AM

---

📹 Video Solution

Scenario

You have a shell script at /usr/local/bin/check_app.sh that runs periodically and exits with a non-zero code. The script is currently failing due to a simulated error condition.

Task

Create a systemd service named check_app.service that automatically restarts the script when it fails, but stops retrying after 3 restart attempts within 60 seconds. Configure the service to start on boot with a 5-second delay between restart attempts, then start the service and verify it hits the restart limit.

---

📹 Video Solution

Scenario

Disk usage on the /var partition is at 92% and increasing rapidly. You need to identify the largest files consuming space and determine if they're actively used by processes or need log rotation.

Task

Find the 10 largest files under /var and save them to /home/devops/largest_var_files.txt, check which processes are using these files and save results to /home/devops/file_processes.txt, and verify log rotation configuration for any log files found, saving results to /home/devops/logrotate_status.txt.

Example

# File: /home/devops/largest_var_files.txt
2.3G    /var/log/mysql/mysql-slow.log
1.8G    /var/lib/docker/overlay2/abc123/diff/app/data.db
1.3G    /var/log/nginx/access.log
891M    /var/cache/apt/archives/linux-image-generic.deb
655M    /var/log/syslog.1
450M    /var/log/myapp/app.log
...

# File: /home/devops/file_processes.txt
tail     44 root    3r   ... /var/log/mysql/sorted.log
tail     45 root    3r   ... /var/log/nginx/test.log
tail     46 root    3r   ... /var/log/hello.1
...

# File: /home/devops/logrotate_status.txt
/etc/logrotate.d/test:/var/log/test.log
/etc/logrotate.d/test:/var/log/hello.log
...

---

📹 Video Solution

Scenario

A process is consuming excessive resources, but its origin is unclear.

Task

Create a utility script at /home/devops/trace_service.sh that accepts a PID argument and outputs its managing systemd service name, full status, and the last 20 log entries.

trace_service.sh Example:

#!/bin/bash

PID=$1
echo "PID: $PID"

# Extract service name managing this PID using systemd
# Hint: systemd can resolve a PID back to its unit
SERVICE=""

echo "SERVICE: $SERVICE"

echo "---- STATUS ----"
# Hint: show full systemd status for the identified service with --no-pager flag

echo "---- LOGS ----"
# Hint: show the last 20 log entries for the service from journald with --no-pager flag

Example

Running the script should produce a structured report similar to this:

root@server:~# ./trace_service.sh 4567

Service Identified: nginx.service

--- Status ---
● nginx.service - A high performance web server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
   Active: active (running) since Fri 2025-12-19 14:00:00 UTC; 1h ago
 Main PID: 4567 (nginx)

--- Last 20 Logs ---
Dec 19 14:00:01 server nginx[4567]: Starting web server...
Dec 19 14:00:02 server nginx[4567]: Configuration loaded successfully.
...

---

📹 Video Solution

Scenario

Your Nginx web server has recently experienced performance issues caused by excessive traffic from a few aggressive clients. You've decided to enable rate limiting based on the recent traffic pattern. To determine the proper limit, you first need to analyze request frequency.

Task

Find the top 3 client IPs by number of requests from /var/log/nginx/access.log, calculate the rate limit using the formula (sum of top 3 IP request counts / 3) * 0.8, write this value into /etc/nginx/nginx.conf as limit_req_zone $binary_remote_addr zone=app_limit:10m rate=<rate_limit>r/s;, and verify the configuration with nginx -t.

Example

# Before (no rate limiting configured)

Access log contains thousands of requests from various IPs
No rate limit configured in nginx.conf
Need to analyze traffic and set appropriate limit

# After (rate limit calculated and configured)

Top 3 IPs analyzed: 4523, 3891, 3456 requests
Rate limit calculated: 7896 r/s
Configuration updated and validated successfully
nginx -t: syntax ok, test successful

---

📹 Video Solution