AWS CloudOps Engineer (SOA-C03) common mistakes
AWS CloudOps Engineer (SOA-C03) · Understand the traps and how to avoid them.
When asked to detect an EC2 instance that has stopped reporting metrics, the candidate enables detailed monitoring or builds a CloudWatch alarm on CPUUtilization instead of using the instance status check (StatusCheckFailed) or a metric-math missing-data alarm.
Detailed monitoring and CPU alarms are the most familiar CloudWatch features, so they are reached for reflexively; candidates conflate 'is the instance healthy' with 'is the instance busy', and overlook that a stopped or hung instance stops emitting metrics entirely.
What to do instead
Map the failure to the right signal: host/instance health is StatusCheckFailed (instance and system status checks), agent/OS health is the CloudWatch agent's mem/disk metrics with a missing-data treatment, and application health is a custom metric or synthetic canary. Configure alarm actions with treatMissingData set to breaching for availability alarms so silence is treated as failure.
When configuring a CloudWatch alarm to trigger remediation, the candidate sets the alarm action to an SNS topic and stops there, or attaches the action to the wrong alarm state (for example ALARM instead of INSUFFICIENT_DATA), and the automated recovery never runs.
Candidates learn alarms and SNS together and assume notification equals remediation; they also forget that alarm actions fire only for the states they are configured on, and that an SNS subscription needs a consumer (Lambda, etc.) to actually act.
What to do instead
Design the chain explicitly: metric -> alarm -> action. Use EC2 auto-recovery (recover action) for instance-level failures, Systems Manager Automation runbooks or Lambda via SNS/EventBridge for application remediation, and set alarm actions on every state that matters. Verify the subscription exists and the execution role has permission to call the target API.
The candidate sends all logs to a single CloudWatch log group with no retention policy and searches them with ad hoc filter patterns, rather than using CloudWatch Logs Insights queries and structured (JSON) log events with defined retention.
Filter patterns are the first log-search feature encountered, and default log groups retain logs indefinitely, so the cost and query limitations are invisible until the question probes operational efficiency or cost.
What to do instead
Use structured JSON logging, Logs Insights for querying across log groups, metric filters only for turning specific patterns into metrics, and an explicit retention period per log group (or export to S3 with lifecycle rules for long-term retention). Recognize that metric filters create metrics; they do not store or query logs.
When asked to design for a Regional outage, the candidate proposes a Multi-AZ deployment (or an RDS Multi-AZ standby) as the disaster-recovery answer.
Multi-AZ is repeatedly taught as the high-availability answer, so candidates apply it to every resilience question without distinguishing availability within a Region from continuity across Regions.
What to do instead
Separate the two: Multi-AZ (or Multi-AZ DB cluster) protects against AZ failure and is the HA answer; cross-Region strategies (backup and restore, pilot light, warm standby, active-active) are the DR answers, chosen by RTO/RPO. Read the RTO/RPO figures in the stem and select the strategy that meets them at lowest cost.
The candidate describes backups as sufficient for recovery without verifying restorability, or assumes an RDS automated backup or EBS snapshot alone satisfies a compliance requirement for cross-Region or long-term retention.
Automated backups are enabled by default and feel like a complete backup solution; candidates miss that they are retained for a limited window, live in the same Region, and are deleted with the DB instance unless copied.
What to do instead
Layer the strategy: automated backups for point-in-time recovery, manual snapshots copied cross-Region for DR, AWS Backup with vault lock and cross-Region/cross-account copies for compliance, and periodic restore tests to validate RTO. Match retention and isolation requirements to the specific service feature.
The candidate treats a launch template change as automatically affecting an existing Auto Scaling group, or assumes a new launch template version is used without updating the group, and expects instances to be replaced.
Infrastructure-as-code habits suggest that editing the template is the deployment; candidates forget that an Auto Scaling group pins a specific launch template version and that existing instances are not recycled by a template edit.
What to do instead
Update the Auto Scaling group to the new launch template version (or set it to $Latest/$Default deliberately) and trigger an instance refresh with a defined minimum healthy percentage. For immutable deployments, use CodeDeploy or a new group with weighted target-group shifting.
When automating cross-account or cross-service actions, the candidate grants broad permissions (for example AdministratorAccess or wildcard actions) to the execution role instead of scoping the policy to the exact API calls and resources required.
Broad policies are the fastest way to make a demo work, and troubleshooting an AccessDenied by widening permissions is a common reflex; least privilege takes more effort to enumerate.
What to do instead
Derive the policy from the actual API calls the automation makes (CloudTrail or IAM Access Analyzer policy generation), scope Resource ARNs, use conditions where relevant (aws:SourceAccount, aws:SourceArn for confused-deputy protection), and use separate roles per automation with a trust policy limited to the invoking service.
The candidate selects a security group or NACL change that is directionally wrong: opening an outbound rule on a security group to allow inbound traffic, or using a NACL to allow traffic between instances in the same subnet.
Security groups and NACLs are taught together and their scoping differs (stateful vs stateless, instance vs subnet), so candidates apply the wrong control to the wrong layer.
What to do instead
Remember: security groups are stateful and instance-level (return traffic is automatic; only allow rules), NACLs are stateless and subnet-level (need both directions, allow and deny, evaluated by rule number). Same-subnet traffic never traverses the NACL for that subnet's boundary in the way candidates assume; use security group references for instance-to-instance rules.
The candidate diagnoses a connectivity failure by inspecting only one component (for example the route table) and declares the cause, without walking the full path: subnet route table, internet/NAT gateway, security group, NACL, and endpoint policy.
Troubleshooting questions present one salient clue, and candidates anchor on it; the full packet path is tedious to enumerate under time pressure.
What to do instead
Use a checklist in order: DNS resolution, subnet association and route table (including local vs igw/nat/endpoint routes), security group egress/ingress, NACL both directions, then service-level policy (VPC endpoint policy, bucket policy). For private-subnet access to AWS APIs, verify the gateway or interface endpoint exists and the route/policy permits it.
The candidate recommends a larger instance type or Provisioned IOPS as the fix for a performance problem without first checking whether the workload is CPU-, memory-, disk-, or network-bound, or whether a cost-optimization lever (Savings Plans, Spot, Graviton, right-sizing from CloudWatch data) already addresses it.
'Scale up' is the intuitive answer and instance families are easy to name; reading CloudWatch metrics to identify the bottleneck and then matching the lever to the constraint takes more analysis than the question seems to invite.
What to do instead
Identify the bottleneck from metrics first (CPUUtilization, EBSVolumeQueueLength/BurstBalance, NetworkIn/Out, memory via the agent), then choose the matching lever: right-size or change family for the constrained resource, EBS volume type/IOPS for disk, Savings Plans/Reserved for steady state, Spot for fault-tolerant batch, and Graviton for compatible workloads. Justify the choice against the cost or performance objective stated in the stem.