DEV Community

ExamCert.App
ExamCert.App

Posted on

5 SOA-C03 Traps That Fail Otherwise-Ready SysOps Candidates

AWS Certified SysOps Administrator – Associate (SOA-C03)

The SysOps Associate is the one AWS Associate exam that punishes people who studied like it was the Solutions Architect exam. SAA rewards you for knowing which service to pick. SOA-C03 rewards you for knowing how the service actually behaves in production — the flag that only takes effect after a reboot, the metric that isn't published unless you install an agent, the replication that's async by default. Same service list, completely different failure mode.

SOA-C03 is the current version (it replaced SOA-C02, and notably it dropped the hands-on "exam labs" that SOA-C02 was infamous for — it's now 65 multiple-choice / multiple-response questions, 130 minutes, 720/1000 to pass, USD 150). No labs doesn't mean easier. It means every operational gotcha that used to live in the labs is now baked into the scenario questions. If you're deep in prep, run a set of free SOA-C03 practice questions before you read on — you'll recognize at least two of these traps from questions you got wrong and couldn't explain why.

Here are the five that catch operationally-competent people.

1. CloudWatch doesn't see inside the instance by default

This is the single most common source of "but I set up the alarm" failures. Out of the box, EC2 publishes hypervisor-level metrics: CPUUtilization, NetworkIn/Out, DiskReadOps on the instance store. It does not publish memory utilization or disk space used on an EBS volume's filesystem. Those live inside the guest OS, and the hypervisor can't see them.

If a question says "you need to alarm on memory pressure" or "trigger when the root volume is 90% full," the answer always involves the CloudWatch agent (the unified agent, not the retired legacy scripts), pushing custom metrics.

# The agent config that actually collects memory + disk
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config -m ec2 -s \
  -c file:/opt/aws/amazon-cloudwatch-agent/etc/config.json
Enter fullscreen mode Exit fullscreen mode

Distractor answers will offer "create a CloudWatch alarm on the MemoryUtilization metric" as if it exists natively. It doesn't. If you didn't install the agent, there's no metric to alarm on.

Also know detailed monitoring (1-minute granularity, paid) vs basic (5-minute, free) — and that detailed monitoring changes frequency, not which metrics exist. It will not conjure memory metrics.

2. "Reboot" vs "stop/start" — which config changes actually apply

SOA-C03 loves the difference between a reboot and a stop/start because operationally they are worlds apart:

  • Reboot: same physical host, same instance store data, same public IP (if not using EIP), same private IP. Kernel-level changes may apply.
  • Stop/start: instance moves to a new physical host. Instance store data is lost. You get a new public IP (again, unless you attached an Elastic IP). Enhanced networking / instance type changes take effect here.

The classic trap: "Users report the public IP keeps changing after maintenance." The fix isn't a script — it's an Elastic IP, because stop/start reassigns the auto-assigned public IPv4. Another: "We changed the instance type but it's still the old size" — instance type changes require a stop/start, not a reboot.

Bonus reliability gotcha in the same family: EC2 auto recovery. It works via a CloudWatch alarm on StatusCheckFailed_System, recovers the instance on new hardware with the same private IP, EIP, and instance ID — but it does not recover from StatusCheckFailed_Instance (that's your OS/app problem, not AWS hardware).

3. RDS Multi-AZ is for failover, read replicas are for scaling — don't swap them

Deployment/reliability questions bait you into using the wrong RDS feature:

  • Multi-AZ = synchronous standby in another AZ, automatic failover via DNS CNAME swap. It is a durability/availability feature. You cannot read from the standby. It does nothing for read throughput.
  • Read replicas = asynchronous replication, you can read from them, they can span regions. They are a scaling feature. Failover to a read replica is manual (promotion) and can lose in-flight data because it's async.

The trap question: "Read-heavy workload is overloading the primary — what do you do?" If you answer "enable Multi-AZ," you're wrong; Multi-AZ adds zero read capacity. Conversely: "We need automatic failover with no data loss." Read replicas can't guarantee that (async lag); Multi-AZ can (sync). Memorize which knob is sync and which is async — half the reliability domain hinges on it.

4. S3 encryption, bucket policies, and Block Public Access all fight each other

The security domain on SOA-C03 is where "I clicked the right checkbox" candidates get humbled. Three overlapping controls, and the exam tests the interaction:

  1. Block Public Access (BPA) overrides bucket policies and ACLs. If a bucket "won't go public" despite a permissive policy, BPA is on — at the account or bucket level. Account-level BPA wins over bucket-level.
  2. Default encryption: SSE-S3 vs SSE-KMS. If objects need encryption and you need an audit trail of who decrypted, it's SSE-KMS (CloudTrail logs the KMS calls). A trap asks "prove which principal accessed the key" — SSE-S3 gives you no key-level audit, so it's KMS.
  3. A bucket policy with "aws:SecureTransport": false deny is how you force HTTPS. If a question says "reject any non-TLS request to the bucket," that's the condition key. 
{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": { "Bool": { "aws:SecureTransport": "false" } }
}
Enter fullscreen mode Exit fullscreen mode

Know that a KMS key policy can also block access independent of the IAM policy — "user has s3:GetObject but still gets AccessDenied" usually means the KMS key policy doesn't grant them kms:Decrypt.

5. Systems Manager is the answer more often than SSH

If your instinct on any "I need to run a command / patch / gather inventory across the fleet" question is to reach for a bastion host and SSH keys, retrain it. The SOA-C03 answer is almost always AWS Systems Manager:

  • Session Manager → shell access with no open port 22, no bastion, no SSH keys, fully logged to CloudTrail/S3. Any question that says "reduce attack surface, no inbound SSH" is Session Manager.
  • Patch Manager → scheduled patching with patch baselines and maintenance windows.
  • Run Command → run a script on N instances without logging in.
  • Parameter Store → config and secrets (SecureString via KMS) instead of hardcoding.

The prerequisite everyone forgets: the SSM Agent must be running (it's preinstalled on Amazon Linux 2/2023 and current Ubuntu/Windows AMIs) and the instance needs an IAM role with AmazonSSMManagedInstanceCore. "Instance doesn't show up in Fleet Manager / Session Manager" is nearly always a missing instance-profile role or no route to the SSM endpoints (needs NAT or VPC endpoints in a private subnet).

How to actually prep for these

Reading service docs won't inoculate you — these traps only stick after you've been burned by them in a question and had to reason through why the obvious answer was wrong. Work through scenario sets, and every time you miss one, write the one-line rule (sync vs async, agent vs native metric, reboot vs stop/start) on a card.

Full domain breakdown, cost, and format details are on the SOA-C03 exam page, and you can pressure-test all five of these patterns with the free SOA-C03 practice test before you book the real thing. Get comfortable being wrong in practice so you're right on exam day.

Top comments (0)