Night Before the Exam

Domain Weights

Essential Services

Critical Differences

• SQS vs SNS vs EventBridge
• Step Functions vs SQS/EventBridge Orchestration
• Lambda vs ECS/Fargate vs EC2
• Secrets Manager vs Parameter Store
• CloudWatch vs CloudTrail vs AWS Config

Security Concepts

• Roles over long-lived keys where possible.
• Encryption does not replace authorization.
• Resource policies and identity policies can both participate in access decisions.
• CloudTrail answers API activity; Config answers configuration state.

Cost Concepts

• Match capacity model to usage pattern.
• Watch storage access frequency and lifecycle.
• Data transfer and NAT can dominate architecture cost.
• Managed services reduce operations but are not automatically cheapest.

Decision Words

• Least operational overhead: Prefer managed and serverless services when they satisfy the requirement. Exceptions appear when the scenario needs host control, unsupported runtimes, specialized network behavior, or exact migration compatibility.
• Highly available: Identify the failure boundary. One instance is not HA. Multiple instances in one AZ help capacity but not AZ failure. Multi-AZ handles regional AZ faults. Multi-Region handles regional events but adds complexity and cost.
• Durable: Durability is about preserving data. Use replication, versioning, backups, point-in-time recovery, and tested restore plans. A durable backup does not guarantee a low RTO.
• Decouple the application: Use SQS for buffering work, SNS for fanout, EventBridge for event routing, and Step Functions for visible workflow state. Add retries, DLQs, and idempotent consumers.
• Least privilege: Prefer roles and temporary credentials, scope actions/resources/conditions, watch explicit denies, and remember that resource policies may also be required.
• Most cost-effective: Read usage pattern, duration, access frequency, scaling behavior, data transfer, and operations. Cheapest unit price is not always lowest total cost.
• Lowest latency: Move content or compute closer to users, cache aggressively, choose the right database access pattern, and avoid unnecessary cross-Region or NAT paths.
• Private connectivity: Use private subnets, VPC endpoints, PrivateLink, VPN, Direct Connect, Transit Gateway, and tight DNS/routing design instead of public exposure.
• Minimum downtime: Separate deployment downtime, failure recovery, and data restore time. Use blue/green, canary, Multi-AZ, replication, and tested rollback where appropriate.
• Automatic remediation: Pair a reliable signal with EventBridge or CloudWatch, a scoped Systems Manager Automation or Lambda action, and a validation step.
• RPO and RTO: RPO is acceptable data loss. RTO is acceptable recovery time. Backups, replication, failover, and architecture all affect them differently.
• Ordered processing: Use FIFO queues or ordered stream partition keys where ordering really matters. Otherwise preserve throughput and idempotency with standard queues/events.
• Encryption and key management: Encryption protects data confidentiality. KMS key policies and IAM decide who can use keys. Authorization still needs separate design.
• Centralized governance: Use Organizations, SCPs, delegated admin, organization trails, Config aggregators, Security Hub, and account vending for multi-account control.

Common Traps

• Putting secrets in environment variables without a secrets-management plan.
• Ignoring Lambda concurrency and retry behavior.
• Using synchronous calls where queues or events are required to decouple failures.
• Troubleshooting only the code while missing IAM deny, throttling, or missing log permissions.

Worth Memorizing

• Development with AWS Services: 32%
• Security: 26%
• Deployment: 24%
• Troubleshooting and Optimization: 18%

Understand, Do Not Memorize

• Whether application code uses AWS services safely, especially identity, secrets, retries, and errors.
• Whether Lambda, API Gateway, DynamoDB, SQS, EventBridge, and deployment services are integrated correctly.
• Whether CI/CD choices preserve deployment safety and repeatability.
• Whether you can use logs, metrics, traces, and errors to find the application failure.

Sources and Review Metadata