AWS SOA-C03Trap Reference

Commonly Confused Services on SOA-C03

SysOps Administrator confusions cluster around services that all sound like "operations and compliance" — the distinguishing factor is whether the scenario involves detecting, enforcing, auditing, or responding.

Each section below gives you the deciding signal, a quick check to run when you encounter the confusion, and why the wrong answer keeps looking right.

Amazon CloudWatchAWS CloudTrailAWS Config
#1

Operational metrics vs. API audit trail vs. configuration compliance

All three monitor AWS environments, so candidates apply whichever they studied most recently.

Deciding signal

CloudWatch collects operational metrics (CPU, memory, error rates), ingests logs, triggers alarms, and drives dashboards — it answers "how is this resource performing right now?" CloudTrail records every API call: who made it, when, from where, and what changed — it answers "who did what to this account?" Config continuously evaluates resource configurations against defined rules and maintains a configuration history — it answers "is this resource configured correctly and has it always been?" When a scenario asks about detecting configuration drift or proving that an S3 bucket was always encrypted, Config. When it asks about API-level activity for a specific user or role, CloudTrail.

Quick check

Is this about resource performance metrics (CloudWatch), API-level account activity (CloudTrail), or configuration state and compliance rules (Config)?

Why it looks right

CloudWatch is the broadest monitoring service and candidates apply it to Config and CloudTrail scenarios. "Monitoring" in a compliance context points to Config, not CloudWatch.

AWS Systems ManagerAWS OpsWorks
#2

Modern unified operations platform vs. managed Chef/Puppet

Both manage EC2 instance configuration and patching, so candidates treat them as equivalent options.

Deciding signal

Systems Manager is AWS-native operations tooling: Run Command for ad-hoc script execution, Patch Manager for automated patching, Session Manager for browser-based shell access, Parameter Store for config, and Automation for runbook-based workflows. It requires no additional agents beyond the SSM Agent and integrates directly with IAM. OpsWorks manages Chef and Puppet environments. OpsWorks Stacks lets you define application layers and run Chef recipes; OpsWorks for Chef Automate and Puppet Enterprise are fully managed versions of those platforms. When a scenario describes using Chef recipes or Puppet manifests for configuration management, OpsWorks. When the scenario describes patching, run command, session access, or AWS-native automation, Systems Manager.

Quick check

Is the scenario using existing Chef or Puppet configuration management (OpsWorks), or does it need AWS-native patching, session access, or automation (Systems Manager)?

Why it looks right

Systems Manager is the current AWS-recommended approach for EC2 fleet management, so candidates apply it universally. OpsWorks is the correct answer in questions that explicitly involve Chef or Puppet as the configuration management toolchain.

Amazon InspectorAmazon GuardDutyAWS Security Hub
#3

Vulnerability scanning vs. threat detection vs. findings aggregation

All three are AWS security services that appear in "improve security posture" questions.

Deciding signal

Inspector scans EC2 instances and container images for software vulnerabilities and unintended network exposure. It runs assessments on a schedule or event-driven basis and produces findings with CVE details. GuardDuty continuously analyzes CloudTrail, VPC Flow Logs, and DNS logs for behavioral anomalies and known threat indicators — it detects threats but does not scan for vulnerabilities. Security Hub is an aggregation layer: it collects findings from Inspector, GuardDuty, Macie, and other services, normalizes them, and runs CIS and PCI benchmark checks. Security Hub does not detect threats itself. When the scenario asks "which service detected that an EC2 instance has an unpatched vulnerability," Inspector. When it asks "which service detected unusual API call patterns," GuardDuty. When it asks "which service gives a single view of findings across security services," Security Hub.

Quick check

Is this about scanning for software vulnerabilities (Inspector), detecting anomalous behavior in logs and network traffic (GuardDuty), or aggregating findings from multiple security services (Security Hub)?

Why it looks right

GuardDuty is the most prominent threat detection service and candidates apply it to vulnerability-scanning scenarios. Inspector is specifically about CVEs and software weaknesses on running compute resources.

AWS Organizations SCPsIAM Policies
#4

Account-level permission guardrails vs. identity-level permission grants

Both control what actions are allowed in AWS, so candidates treat them as alternative solutions to the same access control problem.

Deciding signal

IAM policies grant permissions to identities — users, roles, groups — within an account. They define what a principal can do. Service Control Policies (SCPs) are applied to AWS Organizations OUs or accounts and define the maximum available permissions — they do not grant anything on their own. If an SCP denies an action, no IAM policy in that account can permit it, even for the root user. SCPs are account-level guardrails. When a scenario asks "how do you prevent any user in a member account from disabling CloudTrail," SCPs. When it asks "how do you allow an EC2 instance to access S3," IAM policies.

Quick check

Is the requirement to restrict what any identity in an entire account can do regardless of their IAM permissions (SCPs), or to grant specific permissions to a specific identity (IAM policies)?

Why it looks right

IAM policies are the default answer for access control. Candidates miss that SCPs are the correct answer when the scope is an entire account or OU — because IAM policies can always be overridden by an administrator within the account, while SCPs cannot.

AWS Trusted AdvisorAWS Config Rules
#5

Periodic advisory checks vs. continuous configuration evaluation

Both identify resources that do not meet best practices, so candidates treat them as equivalent compliance tools.

Deciding signal

Trusted Advisor runs periodic, account-wide advisory checks across five categories: cost, performance, security, fault tolerance, and service limits. It flags issues like security groups open to the world or underutilized resources. The checks are static and run on AWS-defined schedules. Config Rules continuously evaluate resource configurations in near real-time as resources change. You define rules (or use AWS managed rules) that check specific properties — encryption, public access settings, tag compliance — and Config generates findings each time a resource changes. When the scenario requires continuous, event-driven compliance evaluation of specific resource properties, Config Rules. When it describes a periodic review of broad account health and best practices, Trusted Advisor.

Quick check

Does the requirement involve continuous, real-time evaluation of specific configuration properties (Config Rules), or periodic advisory checks across broad categories (Trusted Advisor)?

Why it looks right

Trusted Advisor is familiar from the AWS console and is associated with "security checks." Config Rules is the correct answer when the scenario involves detecting configuration drift or enforcing compliance on resource changes.

AWS BackupNative Service Snapshots (EBS, RDS, DynamoDB)
#6

Centralized cross-service backup policy vs. per-service snapshot management

Both create backups of AWS resources, so candidates treat them as equivalent options without considering policy management.

Deciding signal

Native snapshots (EBS snapshots, RDS automated backups, DynamoDB on-demand backups) are managed per-service with their own retention policies and scheduling interfaces. AWS Backup is a centralized service that creates backup plans with unified retention schedules, lifecycle rules, and cross-region and cross-account copy capabilities across EBS, RDS, DynamoDB, EFS, FSx, and other services. When the scenario describes managing backups for multiple services from a single location, enforcing organizational backup policies, or copying backups cross-account for compliance, AWS Backup. When the scenario involves a single service and no cross-service policy requirement, native snapshots are a valid simpler answer.

Quick check

Does the scenario involve coordinating backups across multiple services or accounts under a unified policy (AWS Backup), or managing backups for a single service (native snapshots)?

Why it looks right

Native snapshots are the first tool candidates think of for backup. AWS Backup is correct when centralization, compliance, or cross-service policy enforcement is the stated requirement.

AWS CloudFormationAWS Service Catalog
#7

Infrastructure as code vs. approved product catalog for self-service provisioning

Both use CloudFormation templates under the hood, so candidates treat Service Catalog as a UI wrapper around CloudFormation.

Deciding signal

CloudFormation is an IaC service: you write templates describing infrastructure and CloudFormation provisions it. It requires the user to have IAM permissions to create the resources in the template. Service Catalog lets administrators define approved products (backed by CloudFormation templates) and publish them so that end users can provision them through a self-service catalog — without needing direct IAM permissions for the underlying resources. Service Catalog assumes an IAM role during provisioning, so users get approved products without broader IAM access. When the scenario describes enabling developers to provision pre-approved infrastructure without direct IAM access to the underlying services, Service Catalog.

Quick check

Is the requirement to define and provision infrastructure as code by an admin with full permissions (CloudFormation), or to let end users provision approved products without needing direct IAM permissions (Service Catalog)?

Why it looks right

Service Catalog is less familiar and appears to be just a CloudFormation wrapper. The key distinction — users provisioning resources without direct IAM access to those resources — is what the exam tests.

AWS Systems Manager Parameter StoreAWS Secrets Manager
#8

Configuration and non-rotating secrets vs. credentials with automatic rotation

Both store sensitive values securely, so candidates pick one without checking the rotation requirement.

Deciding signal

Parameter Store stores strings, string lists, and secure strings (encrypted via KMS). Standard parameters are free. It does not rotate values automatically. Secrets Manager is built for credentials that need lifecycle management: it integrates natively with RDS, Redshift, and DocumentDB to rotate passwords automatically on a schedule, and supports custom rotation Lambda for other services. It has a per-secret monthly cost. When the scenario involves a database password that must be rotated automatically, Secrets Manager. When the scenario involves storing API keys, environment configuration, or secrets that do not require rotation, Parameter Store is the more cost-effective answer.

Quick check

Does the secret require automatic rotation on a defined schedule (Secrets Manager), or is it a non-rotating value that needs secure centralized storage (Parameter Store)?

Why it looks right

Both services are described as "secrets management," and Secrets Manager sounds more authoritative. Parameter Store is the correct answer for non-rotating secrets because it avoids the per-secret cost of Secrets Manager.

Auto Scaling Lifecycle HooksAmazon EventBridge
#9

Pausing instance launch/terminate for custom logic vs. reacting to state change events

Both trigger custom actions when Auto Scaling events occur, so candidates conflate the mechanisms.

Deciding signal

Lifecycle Hooks pause an Auto Scaling instance in a pending or terminating state so that custom logic can complete before the instance enters service or is terminated — for example, draining connections, installing software, or running configuration checks before an instance is considered healthy. EventBridge can receive Auto Scaling events (like instance launch or termination notifications) after the fact, but it does not pause the scaling action. When the scenario requires the instance to wait in a pending state while an action completes, Lifecycle Hooks. When the scenario requires reacting to an event after it occurs, EventBridge is the right mechanism.

Quick check

Does the workload need to pause instance transitions until a task completes (Lifecycle Hooks), or react asynchronously to an Auto Scaling event that already happened (EventBridge)?

Why it looks right

EventBridge is the more prominent event-routing service. Candidates apply it to scenarios where the requirement is actually to block the instance state transition — which only Lifecycle Hooks can do.

CloudWatch Logs InsightsAmazon Athena
#10

Interactive log query within CloudWatch vs. SQL query over S3-stored data

Both allow you to query log data with query syntax, so candidates treat them as interchangeable for log analysis.

Deciding signal

CloudWatch Logs Insights is a query engine built directly into CloudWatch Logs. It uses a custom query language, requires no data movement, and is the right answer when the logs are already in CloudWatch and the requirement is interactive ad-hoc queries on recent log data. Athena queries data stored in S3 using standard SQL. It is the right answer when logs have been exported to S3 (for cost reasons or long-term retention) and the requirement involves complex SQL analysis, joining log data with other datasets, or querying historical data beyond CloudWatch retention limits. The deciding factor is where the data lives: CloudWatch (Logs Insights) or S3 (Athena).

Quick check

Are the logs in CloudWatch Log Groups and the requirement is rapid interactive query (Logs Insights), or have logs been exported to S3 for long-term analysis with SQL (Athena)?

Why it looks right

Athena is familiar and "query logs" sounds like an S3 use case. CloudWatch Logs Insights is the correct answer when logs remain in CloudWatch and ad-hoc querying is the requirement — no S3 export needed.

Train these confusions, not just read them

10 SOA-C03 questions. Pattern-tagged with trap analysis. Free, no signup required.

Start SOA-C03 Mini-Trainer →