Grading Rubric

Criterion	Strong (3)	Adequate (2)	Weak (1)
Identified misleading symptom	Recognized force-unlock failure as a DynamoDB issue; checked CloudWatch throttle metrics	Tried force-unlock, then AWS CLI delete, then noticed the throughput error	Spent extended time on Terraform state file, lock IDs, or CI runner configuration
Found root cause in cloud domain	Traced to load test consuming DynamoDB WCUs via CloudTrail	Found the throttling but not the specific consumer	Assumed DynamoDB was broken or the table needed more capacity
Remediated in observability domain	Added DynamoDB throttle alarms, moved load test to separate table, switched to on-demand	Separated the tables but did not add monitoring	Just increased the provisioned capacity (does not prevent recurrence)
Cross-domain thinking	Explained the shared resource contention pattern; proposed IAM-level isolation and monitoring	Acknowledged the load test conflict but missed the monitoring gap	Treated it as a Terraform or DynamoDB configuration problem

Prerequisite Topic Packs

• terraform — needed for Domain A investigation (state locking, force-unlock, backend configuration)
• terraform-deep-dive — needed for Domain A (state management, DynamoDB locking mechanism)
• cloud-deep-dive — needed for Domain B root cause (DynamoDB provisioned throughput, CloudTrail)
• aws-troubleshooting — needed for Domain B (CloudWatch metrics, DynamoDB throttling)
• monitoring-fundamentals — needed for Domain C remediation (CloudWatch alarms, resource monitoring)

Pages that link here

• Aws Troubleshooting
• Monitoring Fundamentals
• Symptoms: Terraform Apply Fails, State Lock Stuck, Root Cause Is DynamoDB Throttle
• Terraform / IaC
• Terraform Deep Dive