AWS Cloud Engineer

# CLI and SDK workflows ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Automate repeatable operations with profiles, roles, JSON output, and safe scripts. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools AWS CLI, Python ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[AWS Cloud Engineering] App --> Control[AWS CLI] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: CLI and SDK workflows
TOOLS: AWS CLI, Python

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# VPC networking ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Design CIDR ranges, subnets, routes, gateways, endpoints, and controlled egress. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools VPC, DNS ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[AWS Cloud Engineering] App --> Control[VPC] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: VPC networking
TOOLS: VPC, DNS

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Security groups and NACLs ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Apply stateful and stateless network boundaries with observable intent. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools VPC, Flow Logs ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[AWS Cloud Engineering] App --> Control[VPC] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Security groups and NACLs
TOOLS: VPC, Flow Logs

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# EC2 operations ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Choose instances, images, user data, patching, metadata, and lifecycle controls. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools EC2, SSM ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[AWS Cloud Engineering] App --> Control[EC2] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: EC2 operations
TOOLS: EC2, SSM

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# S3 storage ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Apply object lifecycle, versioning, encryption, policies, and data protection. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools S3, KMS ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[AWS Cloud Engineering] App --> Control[S3] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: S3 storage
TOOLS: S3, KMS

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# RDS data services ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Design backups, replicas, maintenance, connection limits, and failover. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools RDS, PostgreSQL ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[AWS Cloud Engineering] App --> Control[RDS] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: RDS data services
TOOLS: RDS, PostgreSQL

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# DynamoDB modeling ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Choose partition keys, access patterns, indexes, consistency, and capacity. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools DynamoDB ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[AWS Cloud Engineering] App --> Control[DynamoDB] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: DynamoDB modeling
TOOLS: DynamoDB

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Lambda and events ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Build event-driven functions with idempotency, retries, and dead letters. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Lambda, EventBridge ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[AWS Cloud Engineering] App --> Control[Lambda] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Lambda and events
TOOLS: Lambda, EventBridge

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Terraform on AWS ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Compose modules, remote state, provider configuration, and safe plans. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Terraform, S3 ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[AWS Cloud Engineering] App --> Control[Terraform] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Terraform on AWS
TOOLS: Terraform, S3

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Observability ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Create metrics, structured logs, alarms, dashboards, and trace context. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools CloudWatch, X-Ray ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[AWS Cloud Engineering] App --> Control[CloudWatch] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Observability
TOOLS: CloudWatch, X-Ray

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Encryption and key management ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Protect data at rest and in transit with key policy and rotation. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools KMS, ACM ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[AWS Cloud Engineering] App --> Control[KMS] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Encryption and key management
TOOLS: KMS, ACM

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Cloud cost control ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Use budgets, tags, rightsizing, lifecycle policies, and savings decisions. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Cost Explorer ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[AWS Cloud Engineering] App --> Control[Cost Explorer] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Cloud cost control
TOOLS: Cost Explorer

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Production architecture review ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Evaluate reliability, security, performance, cost, and operations together. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Well-Architected Tool ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[AWS Cloud Engineering] App --> Control[Well-Architected Tool] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Production architecture review
TOOLS: Well-Architected Tool

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# AWS capstone ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Design and deploy a secure, observable, resilient web platform. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools VPC, ALB, RDS, S3 ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[AWS Cloud Engineering] App --> Control[VPC] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: AWS capstone
TOOLS: VPC, ALB, RDS, S3

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off