Day 5 - Week 3 Synthesis — Core Services 2 Review

If last week was the skeleton of "servers, storage, and networking," this week we learned the "operations layer" on top of it — handling data, letting services communicate, and monitoring and automating the whole. Databases, application integration (messaging), management and monitoring tools, and IaC for building infrastructure as code. Today, with no new concepts, we review by tying these pieces together with comparison tables and selection criteria.

The core is still "when to choose what." The answer depends on the shape of the data, the form of the communication, and the kind of information you want to see.

How to Use Today's Review

This is less an article to read from start to finish than a checklist for finding the places where you are likely to slip. Look at the map below and check whether a one-line definition comes to mind from the name alone, mark the pairs that still feel ambiguous, and finally work through the "This situation, this service" table at the end with the answers covered.

CLF-C02 asks in a consistent way. It does not ask about internal structure or how to configure things; it asks "Here is a situation. Which service would you use?" So what to memorize is not the definition but "the situation this service was born to solve."

Core Services 2 Map at a Glance

The common keyword for this week's services is "Managed." AWS takes on operational burdens like patching, backups, and scaling, while users focus on data and logic. This shifts things in the direction where AWS's share of the shared responsibility model grows larger.

Database Review: RDS vs. DynamoDB vs. Aurora vs. Redshift

All four are for "storing data," but the shape and purpose of the data differ.

🎯 Scenario: "I need to read and write millions of users' shopping carts in milliseconds" → DynamoDB, the auto-scaling NoSQL. "I want to move an existing MySQL app somewhere faster and more reliable" → Aurora. "I run complex aggregate analysis over years of sales data" → Redshift.

⚠️ Pitfall: Distinguish "relational vs. NoSQL" from "transactional vs. analytical." RDS/Aurora are for relational transactions, DynamoDB is NoSQL, and Redshift is for analytics (OLAP). Choosing Redshift for "fast key lookups" or DynamoDB for "complex analysis" is a wrong answer.

Aurora is one kind of product within the RDS family — an engine that is compatible with MySQL and PostgreSQL while being redesigned by AWS for the cloud. Remember RDS as "the managed relational DB bundle" and Aurora as "the high-performance option among them."

Database Wrong-Answer Notes

In practice, the places where people slip are almost always one of the four below.

First, lumping "relational or not" and "transactional or analytical" onto a single axis. These are different axes, so you have to ask the questions separately.

Question 1: Is the data shaped like tables, and do relationships matter?
   Yes → RDS / Aurora / Redshift family
   No  → DynamoDB

Question 2: Is the work "reading and writing quickly, record by record," or "gathering what has piled up and analyzing it"?
   Record by record → RDS / Aurora / DynamoDB
   Gather and analyze → Redshift

Second, reflexively picking DynamoDB whenever you see the word "scale." If "complex joins and transactions are needed" appears alongside it, relational is the answer.

Third, forgetting the cache. If the wording is something like "put it in front of the DB to speed up repeated reads," ElastiCache (an in-memory cache) may be the answer. A place that stores data and a place that holds it briefly have different roles.

Fourth, over-interpreting "managed." It means AWS carries operational burdens such as backup, patching, and recovery; it does not mean AWS takes care of schema design or query performance for you.

Integration Review: SQS vs. SNS vs. EventBridge

These are tools for connecting services loosely (decoupling) instead of binding them together directly.

🎯 Scenario: "Even when orders surge, I want to digest payment processing one at a time, reliably" → SQS, which piles them in a queue for sequential processing. "When a single order comes in, I want to notify the notification, inventory, and shipping systems at once" → SNS, which publishes once and fans out to multiple subscribers.

SQS is a "pull" queue, and SNS is "push" publish/subscribe. The "fan-out pattern" — combining the two so SNS fans out and each SQS queue receives — is also common. EventBridge is a higher-level tool that adds "rule-based routing by event content" on top of this.

Integration Wrong-Answer Notes

The trap in this area is that "sending a message" applies to all three. The decisive distinction is "how many receivers there are and how they receive."

Another important concept is decoupling (loose coupling). Here is a picture of why a queue is placed in the middle.

[Direct connection]  Order service ──direct call──► Payment service
                     If payment stalls, ordering stalls with it

[Via a queue]        Order service ──► [SQS queue] ──► Payment service
                     Even if payment pauses briefly, orders keep being accepted and piled up

The point is "keeping a failure on one side from spreading to the other." When you see phrases like "reduce coupling between services," "keep the failure of one component from affecting the whole," or "absorb traffic spikes (buffering)," the queue/messaging family is the answer.

⚠️ Pitfall: If you remember SNS only as "a service that sends email," you will get it wrong. The essence of SNS is a structure where one publish is delivered to multiple subscribers at the same time, and email and text messages are just some of those delivery targets. Conversely, do not mistake SQS for a "notification service." SQS is a queue that the receiving side pulls from when it is ready.

Management & Monitoring Review: CloudWatch vs. CloudTrail vs. Config

All three "observe," but what they watch is different. Distinguishing these three is easy to get confused on the exam.

Pitfall: "Alarm when CPU utilization is high" = CloudWatch, "trace who deleted this S3 bucket" = CloudTrail, "check whether every EBS volume is encrypted" = Config. All three "observe," which is confusing, but their roles split into performance, auditing, and configuration compliance.

CloudTrail records nearly all API activity within the account, making it the primary evidence for security incident investigation and auditing. It's easy to tell them apart with the analogy: CloudWatch is a "health monitor," CloudTrail is an "entry/exit log," and Config is a "compliance checklist."

Management & Monitoring Wrong-Answer Notes

On top of the three services, we also sort out Systems Manager from this week, along with Trusted Advisor and Health Dashboard, which often appear alongside them.

Pitfall: Do not pick CloudTrail every time just because you see the phrase "incident investigation." If the subject of the investigation is a person's action, it is CloudTrail; if it is the state or performance of a system, it is CloudWatch; if it is whether a setting matched a rule, it is Config. Even for a single incident, each of the three tells a different piece — CloudWatch shows the symptom, CloudTrail the culprit, and Config whether a rule was violated.

IaC Review: CloudFormation

CloudFormation is an IaC (Infrastructure as Code) service that defines infrastructure as templates (code) to automatically create and manage it rather than clicking by hand. It can reproduce the same environment repeatedly without mistakes.

🎯 Scenario: "I need to build three identical environments for dev, test, and prod." → Building each by clicking invites mistakes, so you repeatedly create stacks from a single CloudFormation template. Deletion is also cleaned up in one go, per stack.

With CloudFormation, you declare "the final state I want," and AWS creates and changes resources to reach that state. Thanks to this declarative approach, the same template produces the same result whenever you run it.

Deployment & Compute Wrong-Answer Notes

This area becomes easy to sort out if you line the services up on a single axis: "how much do you hand over to AWS."

I manage more                                       AWS manages more
─────────────────────────────────────────────────────────►
EC2 directly  →  CloudFormation  →  Beanstalk  →  Fargate  →  Lambda
(more control)                                    (less operational burden)

Pitfall: Do not compare CloudFormation and Elastic Beanstalk by asking "which is better." Beanstalk uses CloudFormation internally, and the fork between them is "do you need to define the entire infrastructure in fine detail (CloudFormation)" versus "is the goal to get a web app up quickly (Beanstalk)." Likewise, ECS and EKS are separated not by performance but by the AWS-native way versus standard Kubernetes.

This Situation, This Service — 20 Comprehensive Cases

Cover the answers with your hand, read only the left column, and recall the service name.

Self-Check List

If you can answer "yes" to this list the night before the exam, you are through Week 3.

• I can explain the difference between RDS and DynamoDB in terms of data shape
• I know why Redshift is "for analytics" and how Aurora relates to RDS
• I can explain the difference between SQS and SNS in terms of "number of receivers"
• I can give an example of why decoupling is needed
• I know the question each of CloudWatch, CloudTrail, and Config answers
• I know how a CloudWatch alarm connects to Auto Scaling and SNS
• I can name two operational burdens that Systems Manager reduces
• I know the difference between a template and a stack, and the difference in focus between CloudFormation and Beanstalk
• I know the one-line difference among ECS, EKS, and Fargate
• I know which direction the phrase "minimize operational burden" points

Confusing Concept Pairs at a Glance

Decision Flow for When You Get Stuck

This is the order to use when all four options look plausible.

1) What does this situation deal with?
   Storing data → DB family
   Passing between services → Integration family
   Reporting and watching → Management family
   Building and deploying → IaC and compute family

2) Within that, look for the decisive word
   DB          : Relational? Analytics? Ultra-fast key lookups?
   Integration : One receiver? Many? By condition?
   Management  : Performance? Who? Rules?
   Deployment  : Repeatable reproduction? Fast deployment? No server management?

3) If options still remain, choose "the least operational burden"
   CLF often puts managed and serverless options as the correct answer

Step 3 is not a cure-all, but because the questions are meant to check "what becomes easier when you use AWS," it works as a useful default.

Let us tie together how this week's services are used as one scene. A delivery app piles incoming orders into SQS so the payment service processes them in order, and sends the results out through SNS to the notification, settlement, and dispatch systems at the same time. Order data goes into DynamoDB, and aggregates for settlement go into Redshift. The overall state is watched with CloudWatch, and when load rises, an alarm wakes Auto Scaling. CloudTrail catches who changed a setting, and Config catches rule violations. And this whole setup can be rebuilt from a single CloudFormation template. Rather than memorizing individual services, remembering each one's place within a scene like this lasts longer.

Wrap-Up

To re-etch Core Services 2: Databases split by data shape into RDS/Aurora (relational), DynamoDB (NoSQL), and Redshift (analytics); integration loosely connects services with SQS (queue), SNS (fan-out), and EventBridge (event routing); management differs by what it watches with CloudWatch (performance), CloudTrail (auditing), and Config (configuration compliance); and IaC reproduces infrastructure as code with CloudFormation.

Remember again that the exam asks "situation → most appropriate service." In particular, the CloudWatch/CloudTrail/Config distinction and the SQS/SNS difference are within the exam scope. Next week we move on to the operations and governance area — security, pricing, support, and more.

📝 Practice Questions

Click a choice to reveal the answer and explanation.

Question 1

You must read and write the session information of millions of users quickly, in milliseconds, and it must scale automatically even during traffic spikes. Which database is most appropriate?

• AAmazon Redshift
• BAmazon DynamoDB
• CAmazon RDS for MySQL
• DAWS CloudFormation

Question 2

When a single order occurs, you want to send the same message simultaneously to the notification system, the inventory system, and the shipping system. Which service is most appropriate?

• AAmazon SQS
• BAmazon SNS
• CAmazon RDS
• DAmazon CloudWatch

Question 3

You want to trace after the fact when a specific user called which AWS API to delete a resource, for a security audit. Which service is most appropriate?

• AAmazon CloudWatch
• BAWS CloudTrail
• CAWS Config
• DAmazon EventBridge

Question 4

You want to continuously check compliance with resource configuration rules — such as "whether every EBS volume is encrypted" — and track change history. Which service is most appropriate?

• AAWS Config
• BAmazon CloudWatch
• CAmazon SQS
• DAmazon Aurora

Question 5

You want to repeatedly create a completely identical infrastructure environment for dev, test, and prod without mistakes, and delete it all at once when it's no longer needed. Which service is most appropriate?

• AAmazon CloudWatch
• BAWS CloudFormation
• CAmazon DynamoDB
• DAmazon SNS