Management & Governance
Provisioning, monitoring, auditing, and policy enforcement across your accounts and resources.
Amazon CloudWatch
Monitoring and observability service that collects metrics, logs, and events from AWS resources and applications.
- Three pillars: Metrics (numbers over time), Logs (text streams), Alarms (act on thresholds)
- Metrics retention rolls up: 1-min data kept 15 days, 5-min for 63 days, 1-hr for 15 months — old detail is gone forever
- EC2 basic monitoring is 5-min intervals free; detailed monitoring is 1-min and costs extra
- Alarms have three states: OK, ALARM, INSUFFICIENT_DATA — and can trigger SNS, Auto Scaling, or EC2 actions
- Memory and disk usage on EC2 are NOT default metrics — need the CloudWatch Agent (classic exam trap)
- Logs never expire by default — retention is configurable per log group from 1 day to 10 years
Exam triggers
Phrases and scenarios that point here.
- "Monitor", "metric", "threshold", "alert when CPU exceeds" → CloudWatch Alarms
- "Scale when..." → CloudWatch Alarm triggering an Auto Scaling policy
- Track memory/disk on EC2 → CloudWatch Agent, not default metrics
- Centralize application logs across instances → CloudWatch Logs
- "Search logs with a query language" → CloudWatch Logs Insights
- Custom app metric (queue depth, active users) → PutMetricData custom metric
Not this service
- Who did what — API call audit trail → CloudTrail
- Resource configuration history and compliance → AWS Config
- Distributed request tracing across microservices → X-Ray
- React to resource state changes and route events → EventBridge
Use cases
- Alarm on a payment API's p99 latency so the on-call engineer hears about slowness before customers tweet about it
- Auto Scaling a fleet of web servers off CPU utilization during a ticket-sale launch, then scaling back in overnight
- Shipping application logs from 40 ECS tasks into one log group, then using Logs Insights to find every 5xx in the last hour
- Publishing a custom 'orders stuck in pending' metric and alarming when it climbs — a business signal AWS metrics can't see
- Billing alarm on estimated charges so a forgotten sandbox NAT Gateway doesn't quietly eat the month's budget
Commonly confused with
Verified against AWS documentation · 2026-08-27
AWS CloudFormation
Infrastructure as code — declare AWS resources in a template, CloudFormation provisions them as a stack.
- Templates are declarative JSON/YAML — you describe the end state, CloudFormation figures out create/update/delete order
- A stack is the unit of deployment — all resources succeed together or roll back together
- Change sets preview exactly what an update will modify before you commit — the safety net for prod stacks
- Drift detection reports when someone hand-edited resources outside the template
- StackSets deploy one template across multiple accounts and Regions in a single operation
- Limits: 500 resources per template, 51,200 bytes inline / 1 MB via S3, 2,000 stacks per account
Exam triggers
Phrases and scenarios that point here.
- "Infrastructure as code", "repeatable deployments", "provision identical environments" → CloudFormation
- "Deploy the same baseline to every account in the Organization" → StackSets
- "Preview changes before applying" → change set
- "Resources were modified manually, how to detect it" → drift detection
- Failed deployment must not leave half-built infrastructure → automatic rollback
Not this service
- Prefer writing infrastructure in Python/TypeScript instead of templates → CDK (which compiles down to CloudFormation)
- Configuration inside the OS — packages, patches, app config → Systems Manager / OpsWorks
- Pre-approved template catalog for end users to self-serve → Service Catalog
- Audit resource configuration history over time → AWS Config
Use cases
- Spinning up an identical staging copy of production for a load test, then deleting the whole stack afterward — no orphaned resources leaking cost
- New-Region disaster recovery: the same template that built us-east-1 rebuilds everything in ap-southeast-1 in one deploy
- Onboarding a new team account — StackSets pushes the standard VPC, IAM roles, and logging baseline automatically
- Catching the engineer who 'temporarily' opened a security group in the console — drift detection flags the stack as drifted
- Reviewing a change set before a template update, and spotting that an innocent-looking property change would replace the RDS instance
Commonly confused with
Verified against AWS documentation · 2026-08-27
AWS CloudTrail
Records API calls and account activity across AWS — the audit log of who did what, when, and from where.
- Logs API activity: every console click, CLI command, and SDK call becomes an event with identity, time, source IP, and parameters
- Management events (control plane: create/modify/delete resources) are on by default; data events (S3 object reads, Lambda invokes) are opt-in and high-volume
- Event history gives 90 days of management events free in the console — no setup; a trail delivers events to S3 for retention beyond 90 days
- One trail can cover all Regions and, via Organizations, all accounts (organization trail)
- Not real-time — events are delivered on a delay (typically within ~15 minutes), so it's for audit and investigation, not live alerting
Exam triggers
Phrases and scenarios that point here.
- "Who deleted / modified / accessed this resource?" → CloudTrail, always
- "Audit", "compliance", "track user activity", "record API calls" → CloudTrail
- Retain activity logs beyond 90 days → create a trail to S3
- Detect unusual API activity (spike in calls or errors) → CloudTrail Insights
- Prove logs weren't tampered with → log file integrity validation
Not this service
- Metrics, application logs, alarms → CloudWatch
- Resource configuration history and compliance rules ("what did this resource look like?") → AWS Config
- Threat detection that analyzes the logs for you → GuardDuty
Use cases
- Post-incident forensics: a production security group was opened to 0.0.0.0/0 overnight — CloudTrail shows which IAM principal made the call, from what IP, at what time
- Compliance retention: shipping an organization trail to a locked-down S3 bucket in a dedicated audit account, satisfying the auditor's 7-year requirement
- Catching leaked credentials: Insights flags an abnormal burst of RunInstances calls from an access key that normally only reads S3
- Attribution during cost spikes: matching a surprise NAT Gateway or EC2 bill to the exact API calls (and person) that created the resources
Commonly confused with
Verified against AWS documentation · 2026-08-27
AWS Compute Optimizer
ML-powered rightsizing service that analyzes utilization metrics and recommends optimal resource configurations.
- Opt-in service — analyzes CloudWatch metrics over a 14-day default lookback (32-day configurable, 93-day with paid enhanced infrastructure metrics)
- Covers EC2, Auto Scaling groups, EBS volumes, Lambda, ECS on Fargate, RDS/Aurora, and commercial licenses — plus idle-resource detection
- Findings labeled: under-provisioned, over-provisioned, optimized (EC2) — recommendations refresh daily
- Organization-wide view when opted in from the management account; preferences settable at org, account, or resource level
Exam triggers
Phrases and scenarios that point here.
- "Rightsizing recommendations", "identify over-provisioned instances", "optimal instance type based on utilization" → Compute Optimizer
- Uses machine learning on CloudWatch metrics → Compute Optimizer, not Trusted Advisor
- "Analyze memory utilization for rightsizing" → needs CloudWatch agent installed; CPU works out of the box
- Recommendations across an entire AWS Organization → opt in from the management account
Not this service
- Broad best-practice checks (security, limits, fault tolerance) → Trusted Advisor
- Visualizing and analyzing what you've already spent → Cost Explorer
- Reserved Instance / Savings Plans purchase recommendations → Cost Explorer, not Compute Optimizer
Use cases
- Quarterly rightsizing sweep: a team inherits 200 EC2 instances sized by guesswork years ago — Compute Optimizer flags the m5.2xlarges idling at 8% CPU and names the cheaper replacement
- Catching the opposite mistake: a t3.medium API server that's been throttling under load shows up as under-provisioned before customers start complaining
- Lambda memory tuning — finding functions where dropping (or raising) the memory setting cuts cost or duration without trial-and-error redeploys
- Idle-resource cleanup: surfacing unattached EBS volumes and forgotten dev instances that quietly bill every month
- Workloads with monthly patterns (payroll runs, month-end reporting) — 14 days of data misleads, so extend the lookback before trusting the recommendation
Commonly confused with
Verified against AWS documentation · 2026-08-27
AWS Config
Resource configuration recorder — tracks what your resources looked like, when they changed, and whether they comply with your rules.
- Records every configuration change as a configuration item — a point-in-time snapshot with full history and resource relationships
- Config = *what* changed and what it changed to; CloudTrail = *who* made the API call. Exams love this pairing
- Rules (AWS managed, or custom via Lambda/Guard) mark resources compliant/non-compliant continuously; auto-remediation via SSM Automation documents
- Aggregators roll up compliance across accounts and Regions; conformance packs bundle rules for frameworks like CIS or PCI-DSS
- Regional service — you enable the recorder per Region; limit of 1,000 rules per Region per account
Exam triggers
Phrases and scenarios that point here.
- "Track/audit configuration changes over time", "configuration history", "what did this resource look like last Tuesday" → Config
- "Ensure all buckets are encrypted" / "no security groups open to 0.0.0.0/0" as a continuous check → Config rules
- "Automatically fix non-compliant resources" → Config rule + SSM Automation remediation
- "Single compliance view across the whole organization" → Config aggregator
Not this service
- Who called which API, from where → CloudTrail
- Performance metrics, logs, alarms → CloudWatch
- Cost/security best-practice suggestions → Trusted Advisor
Use cases
- Post-incident forensics: a security group suddenly allows 0.0.0.0/0 — Config shows the exact before/after state and the timestamp, then CloudTrail tells you who did it
- Continuous compliance instead of quarterly audits: an encryption rule flags any new unencrypted EBS volume within minutes of creation
- Self-healing guardrails: someone disables S3 Block Public Access, the rule goes non-compliant, SSM Automation flips it back before anyone notices
- One dashboard for the auditor: aggregator pulls compliance status from 40 accounts across 3 Regions into a single pane
- Drift detection: resources modified by hand in the console stand out against the state your IaC pipeline actually deployed
Commonly confused with
Verified against AWS documentation · 2026-08-26
AWS Control Tower
Managed service that sets up and governs a secure multi-account AWS environment (landing zone) based on best practices.
- Landing zone = the whole governed environment: management account, log archive account, audit account, OUs, and baseline config
- Controls (exam may still say "guardrails") come in three types — preventive (SCPs, block the action), detective (Config rules, flag it), proactive (CloudFormation Hooks, catch it before deploy)
- Account Factory provisions new accounts pre-baked with your baselines — no hand-configuring each one
- Orchestrates other services, it doesn't replace them: Organizations, IAM Identity Center, Config, CloudTrail, CloudFormation StackSets under the hood
- Dashboard shows compliance and drift across all enrolled accounts from one place
Exam triggers
Phrases and scenarios that point here.
- "Easiest way to set up and govern a new multi-account environment" → Control Tower
- "Guardrails", "landing zone", "account vending/provisioning at scale" → Control Tower
- Prevent actions across accounts → preventive control; detect non-compliance → detective control
- Restrict which Regions accounts can deploy into → Region deny control
Not this service
- Just need OUs, consolidated billing, and hand-rolled SCPs → AWS Organizations alone
- Curated catalog of approved products for teams to self-serve deploy → Service Catalog
- Rule-level compliance checks in a single account → AWS Config directly
Use cases
- A startup graduating from one shared account to per-team accounts — Control Tower stamps out dev, staging, and prod accounts with logging and guardrails already in place
- An enterprise where every new project used to mean a week of manual account setup — Account Factory turns it into a self-service vending machine
- Compliance teams that need one dashboard answering "which accounts drifted from policy" instead of auditing accounts one by one
- Blocking an entire org from launching resources in non-approved Regions (data residency) with one Region deny control
- Enrolling messy pre-existing accounts under a single governance baseline instead of retrofitting each by hand
Commonly confused with
Verified against AWS documentation · 2026-08-28
AWS Organizations
Central management of multiple AWS accounts — grouping, governance policies, and one consolidated bill.
- One management account owns the org; everything else is a member account — the management account can never be restricted by SCPs
- Accounts are grouped into OUs under a single root, nested up to 5 levels deep; policies attached higher up flow down to everything beneath
- SCPs are guardrails, not grants — they set the maximum possible permissions but never give anyone access; IAM still has to allow the action
- Consolidated billing: one bill for all accounts, usage pooled for volume discounts, and Reserved Instances / Savings Plans shared across accounts by default
- Two modes: consolidated billing only, or all features (required for SCPs and most governance) — all features is the exam default assumption
Exam triggers
Phrases and scenarios that point here.
- "Multiple accounts", "centrally manage", "single bill", "volume discounts across accounts"
- Restrict what member accounts can do, even their root users → SCP
- New accounts created automatically with guardrails already applied → Organizations + OUs
- Share Reserved Instance or Savings Plans discounts across accounts → consolidated billing
- An SCP denies it → nothing in that account can do it, not even an admin with full IAM permissions
Not this service
- Prescriptive multi-account setup with a landing zone and pre-built guardrails → AWS Control Tower (built on top of Organizations)
- Permissions for users and roles within one account → IAM
- Sharing resources (subnets, Transit Gateways) between accounts → AWS RAM
Use cases
- Separate accounts for dev, staging, and prod under one org — a blast radius boundary, so a leaked dev credential can't touch production
- Sandbox OU with an SCP denying expensive services, so an intern can experiment without accidentally launching a p5 instance
- Deny-region SCP pinning workloads to approved Regions for data residency — think of it as a fence the whole org lives inside
- One finance team paying a single bill while fifty engineering teams each own their account, with pooled usage unlocking volume discount tiers nobody hits alone
- Org-wide CloudTrail trail from the management account, so member account admins can't switch off their own audit logging
Commonly confused with
Verified against AWS documentation · 2026-08-28
AWS Service Catalog
Curated self-service portal of pre-approved infrastructure templates that end users can launch without touching the underlying services.
- Admins publish products (CloudFormation or Terraform templates) into portfolios; end users launch them from a catalog view
- Launch constraints attach an IAM role to the product — users provision EC2/RDS/etc. without ever holding those permissions themselves
- Template constraints restrict what users can input at launch (e.g. instance types capped at t3.medium)
- Portfolios can be shared across accounts and AWS Organizations — one governance team, many consumer accounts
- Versioned products: push an updated template, users see and can update to the new version
Exam triggers
Phrases and scenarios that point here.
- "Pre-approved", "standardized", "self-service provisioning", "without granting direct access to underlying services"
- Non-technical teams need to launch compliant infrastructure → Service Catalog, not IAM permissions
- Central IT wants to control what gets deployed while devs deploy it themselves
- Enforce governance/compliance on what users can provision → constraints
Not this service
- Buying third-party software/AMIs → AWS Marketplace
- Writing/deploying the templates themselves → CloudFormation
- Full landing zone with guardrails across accounts → Control Tower (which uses Service Catalog under the hood)
Use cases
- Data science team self-serves pre-hardened SageMaker notebooks without anyone granting them SageMaker admin rights
- New-hire dev environments: one-click launch of a standard VPC + EC2 + RDS stack that security already signed off on
- Marketing spins up approved campaign microsites from a template — capped instance sizes, mandatory cost-allocation tags baked in
- Enterprise shares one portfolio from a hub account to 50 spoke accounts so every business unit deploys the same vetted stacks
Commonly confused with
Verified against AWS documentation · 2026-08-27
AWS Systems Manager
Operations hub for viewing, managing, and automating actions on your fleet — EC2, on-prem, and multicloud nodes — at scale.
- One service, many tools: Session Manager (shell access), Run Command (execute at scale), Patch Manager, Parameter Store, Automation, Inventory, State Manager
- Requires the SSM Agent on the node plus an instance profile/IAM role — no agent or no role is the classic 'instance not showing up' cause
- Session Manager: browser/CLI shell with no SSH keys, no bastion, no inbound ports open — auditable via CloudTrail and session logs
- Parameter Store: Standard tier free (10,000 params, 4 KB), Advanced paid (100,000 params, 8 KB, parameter policies like expiry/rotation reminders)
Exam triggers
Phrases and scenarios that point here.
- "Access instances without opening port 22 / without SSH keys / without a bastion" → Session Manager
- "Run a command/script across hundreds of instances" → Run Command
- "Automate OS patching on a schedule" → Patch Manager + Maintenance Windows
- "Store configuration values or license keys centrally, free" → Parameter Store
- "Manage on-premises servers alongside EC2" → hybrid activation with SSM Agent
Not this service
- Secrets needing automatic rotation or cross-account sharing → Secrets Manager
- Provisioning infrastructure from templates → CloudFormation
- Recording resource configuration history and compliance rules → AWS Config
Use cases
- Killing the bastion host: a team replaces its jump box and SSH key spreadsheet with Session Manager, and every shell session is now logged to S3 for the auditors
- Friday-night hotfix across a 300-instance fleet — one Run Command invocation instead of a for-loop over SSH
- Monthly patching of dev on week 1 and prod on week 2, fully hands-off, via Patch Manager baselines and Maintenance Windows
- An app reads its DB endpoint and feature flags from Parameter Store at boot, so promoting a build from staging to prod changes zero code
- Automation runbook that snapshots a volume, swaps an AMI, and notifies the team — the 3 a.m. manual checklist turned into one document
Commonly confused with
Verified against AWS documentation · 2026-08-27
AWS Trusted Advisor
Automated best-practice inspector that scans your account and flags cost, security, performance, fault tolerance, and quota issues.
- Checks your account against AWS best practices across five exam pillars: cost optimization, performance, security, fault tolerance, service limits
- Findings are color-coded: red = act now, yellow = investigate, green = fine
- All accounts get a core set of checks (service limits + select security); the full check library requires a paid support plan
- It recommends, it doesn't fix — remediation is on you (or automation you wire up via EventBridge)
- Organizational View aggregates findings across all accounts in an AWS Organization from the management account
Exam triggers
Phrases and scenarios that point here.
- "Best practice recommendations" or "identify idle/underutilized resources" → Trusted Advisor
- "Check if security groups allow unrestricted access" or "MFA on root" as an automated account-wide scan → Trusted Advisor
- "Approaching service limits/quotas" and want alerts → Trusted Advisor (limit checks are free-tier)
- "Which support plan is needed for all Trusted Advisor checks" → Business-level support or higher
Not this service
- Continuous resource config compliance against your own rules → AWS Config
- Detailed cost analysis and spend breakdowns → Cost Explorer
- Threat detection from logs and network activity → GuardDuty
- Architecture review of a specific workload against the framework → Well-Architected Tool
Use cases
- Monthly hygiene sweep — catching the Elastic IP someone allocated for a demo and never released, still billing quietly
- Pre-launch check that no security group has port 22 open to 0.0.0.0/0 before an audit
- Wiring limit checks to EventBridge so you get a Slack ping before you hit the EC2 instance quota during a scaling event, not after
- Central cloud team using Organizational View to spot which of 40 member accounts have public S3 buckets without logging into each one
Commonly confused with
Verified against AWS documentation · 2026-08-27