Compact AWS SOA-C03 Cheat sheet for service selection, monitoring, automation, security, networking, reliability, and troubleshooting.
Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.
Scope and study context
This page supports IT Mastery exam prep with original practice questions. It is not affiliated with AWS.
Exam-use orientation
This independent Cheat Sheet supports preparation for the AWS Certified CloudOps Engineer – Associate (SOA-C03) exam from AWS. Use it as a scenario decision guide: the exam often tests which AWS service, operational control, or troubleshooting step best fits a production operations problem.
Systems Manager is frequently the most operationally correct answer when the scenario asks for controlled fleet management without opening inbound administrative ports.
Systems Manager feature
Use it for
Session Manager
Browser/CLI shell access without SSH/RDP inbound exposure.
Run Command
Execute commands across managed nodes.
Patch Manager
Patch baselines, patch groups, and maintenance windows.
State Manager
Maintain desired configuration over time.
Automation
Multi-step operational runbooks and remediation.
Inventory
Collect software and configuration inventory.
Parameter Store
Store configuration and secrets-like values.
OpsCenter
Track and manage operational issues.
Distributor
Package and distribute software agents.
Maintenance Windows
Schedule disruptive or controlled operations.
SSM managed-node checklist
If an instance is not showing as a managed node, check:
SSM Agent installed and running.
IAM role attached with required Systems Manager permissions.
Network path to Systems Manager endpoints through internet, NAT, or VPC interface endpoints.
Correct AWS Region.
Supported operating system and instance state.
No restrictive proxy, DNS, endpoint policy, or security control blocking communication.
Compute, scaling, and load balancing
EC2 operational troubleshooting
Symptom
Check first
Likely direction
Instance unreachable
Security group, NACL, route table, public/private IP, SSM status
Separate network path problem from OS problem
System status check failed
AWS host/network issue
Stop/start, recover, or allow AWS remediation depending scenario
Instance status check failed
Guest OS/app issue
Check boot logs, CPU, disk, networking config
User data did not work
Cloud-init logs, script syntax, IAM role, network access
User data normally runs at first boot unless configured otherwise
Cannot access S3 from private subnet
Route/NAT or S3 VPC endpoint policy
Prefer gateway endpoint for private S3 access where appropriate
App lost AWS permissions
Instance profile, role policy, SCP/permission boundary, STS credentials
Temporary credentials come from role metadata
Memory/disk alarm missing
CloudWatch Agent/custom metrics
Default EC2 metrics do not include all OS-level metrics
Replacement instance not configured
AMI, launch template, user data, SSM State Manager
Avoid snowflake instances
Notes and examples
Auto Scaling decisions
Need
Feature
Notes
Maintain fixed capacity
Desired/min/max capacity
Health checks replace failed instances
Scale around target metric
Target tracking policy
Common for CPU, request count, custom utilization metric
Scale by thresholds/steps
Step scaling
Useful when response should vary by severity
Scale on schedule
Scheduled scaling
Good for predictable business hours
Prepare for future demand
Predictive scaling
Use when historical patterns are reliable
Let instances finish work before termination
Lifecycle hooks
Pair with Lambda/SNS/SQS/Systems Manager
Use load balancer health
ELB health checks in Auto Scaling
Replaces instances failing app-level checks
Safely roll new launch template
Instance refresh
Combine with health checks and warmup
Keep scale-in from killing special node
Instance protection
Useful for stateful/critical instances, but avoid permanent snowflakes
Load balancer selection
Load balancer
Choose for
Key features
Avoid when…
Application Load Balancer
HTTP/HTTPS apps
Host/path routing, redirects, header rules, WebSocket, target groups
Need static IP at L4
Network Load Balancer
TCP/UDP/TLS, high performance, static IP needs
Low latency, source IP preservation patterns, TLS passthrough/termination
Snapshot, test, maintenance window, blue/green where available
Avoid untested production upgrades
Encrypt database
KMS-backed encryption at creation/restore as supported
Plan key permissions and snapshot sharing behavior
Need
DynamoDB feature
Key distinction
Automatic capacity adjustment
Auto scaling or on-demand capacity mode
Choose based on predictability
Recover table to prior time
Point-in-time recovery
Operational recovery, not analytics
Global low-latency writes/reads
Global tables
Multi-Region active-active pattern
React to item changes
DynamoDB Streams
Feed Lambda/consumers
Expire old items
TTL
Deletion is asynchronous
Protect accidental deletion
Backups, PITR, IAM controls
CloudFormation deletion policy may also matter
S3 operational review
Feature
Use it for
Trap
Versioning
Recover from overwrite/delete scenarios
Delete markers can make objects appear deleted.
Lifecycle policies
Transition or expire objects
Understand access pattern before moving to archival classes.
Replication
Same-Region or cross-Region object replication
Versioning is required; existing objects need special handling.
S3 Block Public Access
Prevent public exposure
Can override bucket policies or ACL-based public access.
Object Ownership
Control ownership and ACL behavior
Bucket owner enforced disables ACLs.
Object Lock
WORM retention patterns
Governance and compliance modes differ.
Event notifications
Trigger processing from object events
Watch destination permissions and event-loop risks.
Storage Lens
Organization-wide storage visibility
Useful for usage, activity, and optimization insights.
Access logs / CloudTrail data events
Audit S3 access
Data events can be high volume; scope carefully.
EBS, EFS, and FSx
Storage type
Best fit
Key operational point
EBS
Block storage for EC2
AZ-scoped; use snapshots for backup and migration.
EFS
Shared NFS file system
Regional service with mount targets in subnets/AZs.
FSx for Windows File Server
Managed Windows file shares
SMB and Windows integration.
FSx for Lustre
High-performance file system for compute workloads
Often paired with HPC or data processing.
Instance store
Temporary local storage
Fast but ephemeral.
RDS and database operations
Feature
Purpose
Exam distinction
Automated backups
Point-in-time recovery within retention
Operational recovery feature, not read scaling.
Manual snapshots
User-initiated backups retained until deleted
Useful before risky changes.
Multi-AZ
High availability / failover
Not the same as read scaling for traditional RDS deployments.
Read replicas
Read scaling and some DR patterns
Promotion is a separate action.
Performance Insights
Database performance analysis
Helps identify waits, SQL load, and bottlenecks.
Enhanced Monitoring
OS-level DB instance metrics
More granular than standard CloudWatch DB metrics.
Parameter groups
Engine configuration
Static parameters may require reboot.
Option groups
Engine-specific features
Common in certain RDS engines.
Networking and content delivery
VPC connectivity decision table
Need
Choose
High-yield notes
Public IPv4 internet access for instance
Public subnet route to internet gateway + public IP
Security group/NACL must allow traffic
Private subnet outbound IPv4 internet
NAT gateway or NAT instance
NAT does not allow unsolicited inbound from internet
Private IPv6 outbound internet
Egress-only internet gateway
IPv6 does not use NAT in the same way
Private access to S3/DynamoDB
Gateway VPC endpoint
Route table association and endpoint policy matter
Private access to many AWS services
Interface VPC endpoint
ENI-based, security groups, private DNS option
Connect VPCs at scale
Transit Gateway
Hub-and-spoke routing; route tables still matter
Simple direct VPC-to-VPC connectivity
VPC peering
Non-transitive; CIDR overlap is a blocker
Hybrid encrypted connection
Site-to-Site VPN
Faster to establish than physical private connectivity
Dedicated private network
AWS Direct Connect
Often paired with VPN for encryption/backup design
DNS routing and failover
Route 53
Health checks and routing policies are central
Global static entry and acceleration
AWS Global Accelerator
Routes to healthy regional endpoints over AWS network
Cache static/dynamic content at edge
CloudFront
Cache behavior, origin, TTL, invalidation, TLS
Notes and examples
Security group vs NACL
Control
Security group
Network ACL
Scope
Elastic network interface/resource
Subnet
State
Stateful
Stateless
Rules
Allow rules only
Allow and deny rules
Evaluation
All applicable rules
Ordered rule evaluation
Common use
Instance/app firewall
Subnet guardrail or explicit deny
Exam trap
Return traffic automatically allowed
Return traffic must be explicitly allowed
Route 53 routing policies
Policy
Use when…
Simple
Single basic answer
Weighted
Split traffic by assigned proportions
Latency-based
Send users to lowest-latency Region
Failover
Active/passive with health checks
Geolocation
Route by user geographic location
Geoproximity
Route by location with optional bias
Multivalue answer
Return multiple healthy records
Alias
Point DNS to supported AWS resources without hard-coding IPs
VPC troubleshooting quick path
flowchart TD
A[Connectivity failure] --> B{DNS resolves?}
B -- No --> C[Check Route 53/private hosted zone/resolver/DHCP options]
B -- Yes --> D{Route exists?}
D -- No --> E[Check route table, TGW, peering, IGW, NAT, endpoint]
D -- Yes --> F{Firewall allows?}
F -- No --> G[Check security groups and NACLs both directions]
F -- Yes --> H{Target healthy/listening?}
H -- No --> I[Check OS firewall, app port, ELB health check, instance status]
H -- Yes --> J[Check asymmetric routing, TLS, proxy, endpoint policy, IAM]
Security, identity, and compliance operations
IAM policy evaluation reference
Concept
Exam meaning
Default deny
No permission unless allowed
Explicit deny
Overrides any allow
Identity-based policy
Attached to users, groups, or roles
Resource-based policy
Attached to resource, such as S3 bucket, KMS key, Lambda function
Permissions boundary
Maximum permissions an identity can receive
SCP
Maximum permissions for accounts/OUs in AWS Organizations; does not grant access
Session policy
Further restricts temporary session permissions
Role
Assumed for temporary credentials; preferred for AWS services and cross-account access
Instance profile
Delivers IAM role credentials to EC2
Trust policy
Defines who can assume a role
Access Analyzer
Detects unintended external access and validates policies
Can allow KMS actions only if key policy permits/delegates
Grants
Common for AWS services needing temporary/delegated key use
AWS managed key
Managed by AWS for a service/account
Customer managed key
More control over policy, rotation settings, auditing, deletion scheduling
Multi-Region key
Useful for client-side or service patterns needing related keys across Regions
Encryption context
Additional authenticated data used by some integrations/policies
S3 SSE-KMS failure
Check both S3 permission and KMS key permission
IAM policy evaluation shortcuts
For SOA-C03 scenarios, remember:
Explicit deny wins.
If there is no applicable allow, the result is implicit deny.
Identity policies, resource policies, permissions boundaries, session policies, and SCPs can all affect the final result.
SCPs do not grant permissions. They set maximum available permissions for accounts or organizational units.
Permission boundaries do not grant permissions. They cap what an identity can do.
Resource policies can allow cross-account access, but the trusted principal may still need identity-side permission depending on the service and action.
Use roles for AWS services and temporary access. Avoid long-term access keys where a role is possible.
IAM scenario table
Scenario
Preferred answer pattern
EC2 instance needs S3 access
Attach an IAM role through an instance profile; do not store access keys on the instance.
Lambda needs to call DynamoDB
Add permissions to the Lambda execution role.
External account needs access to a bucket
Use a bucket policy and/or cross-account role with least privilege.
Team needs temporary elevated access
Use IAM Identity Center or role assumption with controlled permissions and audit logging.
Need to limit maximum permissions for developers
Use permissions boundaries and appropriate identity policies.
Need guardrails across accounts
Use AWS Organizations SCPs.
Need to detect unintended public or cross-account access
Use IAM Access Analyzer.
KMS and secrets
Need
Better fit
Key exam note
Encrypt data with customer-managed access control
AWS KMS customer managed key
Key policy matters; IAM permission alone may not be enough.
Encrypt S3 objects
SSE-S3, SSE-KMS, or client-side encryption
SSE-KMS adds KMS permissions and possible request-cost considerations.
Store database passwords with rotation
AWS Secrets Manager
Built-in rotation support is a common differentiator.
Store configuration values
Systems Manager Parameter Store
SecureString can use KMS; advanced features vary by parameter tier.
Temporary credentials
AWS STS
Prefer temporary credentials over long-term access keys.
Security monitoring services
Service
Use it for
Amazon GuardDuty
Threat detection from logs and signals such as CloudTrail, VPC flow logs, DNS logs, and more.
AWS Security Hub
Aggregated security findings and posture management.
Pick between CloudWatch, CloudTrail, AWS Config, EventBridge, and Systems Manager without hesitation.
Troubleshoot EC2, Auto Scaling, ELB, Route 53, and VPC connectivity from symptoms.
Explain security group vs NACL, NAT vs VPC endpoint, Multi-AZ vs backup, and SCP vs IAM policy.
Choose operational automation: Run Command, State Manager, Patch Manager, Automation, CloudFormation, CodeDeploy, or instance refresh.
Map storage/database recovery needs to S3 versioning, EBS snapshots, RDS backups/PITR, DynamoDB PITR, and AWS Backup.
Recognize least-privilege, encryption, logging, tagging, and repeatable infrastructure patterns.
Next step: work through timed SOA-C03-style scenarios and force yourself to name the AWS service, the operational reason, and the first troubleshooting check before reading the explanation.
Exam mindset: what SOA-C03 rewards
SOA-C03 is not just a service-name recognition exam. Expect scenarios that ask what a CloudOps engineer should do when something is slow, unreachable, noncompliant, under-monitored, over-permissioned, or expensive.
Think in this order:
Observe — metrics, logs, events, traces, audit records, configuration history.
Diagnose — isolate whether the problem is identity, network, compute, storage, quota, scaling, configuration, or dependency related.
Remediate safely — prefer least-disruptive, automated, reversible, and auditable actions.
Harden — apply least privilege, encryption, backup, patching, monitoring, tagging, and drift controls.
Automate — use repeatable AWS-native mechanisms rather than manual console fixes when possible.
Tags, guardrails, and visibility are core operations tools.
Monitoring, logging, and alerting
CloudWatch essentials
Feature
Use it for
Common trap
CloudWatch metrics
Numeric signals such as CPU, network, disk, latency, error count
Metrics are dimensioned; the wrong dimension can make data appear “missing.”
CloudWatch alarms
Notify or act when metrics breach a condition
Alarms act on state changes, not every repeated datapoint.
Composite alarms
Reduce alert noise by combining alarm states
Useful for paging only when multiple symptoms matter together.
Anomaly detection
Dynamic baselines for variable workloads
Not a substitute for understanding business-critical thresholds.
CloudWatch Logs
Central log collection
Logs are not the same as CloudTrail audit events.
Logs Insights
Interactive log querying
Use it for investigation, not long-term metric trending by itself.
Metric filters
Convert log patterns into metrics
Existing historical log events do not retroactively create metric datapoints.
Subscription filters
Stream logs to another destination
Use for near-real-time processing or centralized log pipelines.
CloudWatch Agent
OS-level metrics and log collection from EC2/on-premises
Default EC2 metrics do not include every OS-level metric you may need.
Notes and examples
CloudTrail vs CloudWatch vs Config
Question in the scenario
Best first service
“Who deleted this security group rule?”
CloudTrail
“Did CPU or latency spike before the outage?”
CloudWatch metrics
“What was the previous configuration?”
AWS Config
“Which resources are noncompliant?”
AWS Config rules / conformance packs
“Which API calls are unusual?”
CloudTrail Insights
“Which log lines contain this error?”
CloudWatch Logs Insights
“How do I trigger remediation after an event?”
EventBridge + Systems Manager Automation / Lambda
Monitoring traps candidates miss
CloudTrail is not a performance monitor. It records API activity; use CloudWatch for metrics and logs.
CloudWatch alarms depend on evaluation settings. Period, datapoints to alarm, evaluation periods, and missing-data treatment can change behavior.
Not all service metrics are enabled by default at the granularity you want. EC2 detailed monitoring and custom metrics may be required.
Logs must be collected before they can be queried. Missing agent configuration or IAM permissions can explain missing logs.
A metric filter is not a log search. It creates a metric from matching log events.
AWS Config is about resource configuration and compliance, not application traces.
Centralized logging often needs cross-account design. Consider organization trails, delegated admin, log archive accounts, and resource policies.
Incident response decision flow
flowchart TD
A[Alarm, ticket, or user report] --> B{Is it availability, performance, security, or compliance?}
B -->|Availability / performance| C[Check CloudWatch metrics, alarms, target health, logs]
B -->|Security / audit| D[Check CloudTrail, IAM Access Analyzer, GuardDuty, Security Hub]
B -->|Compliance / drift| E[Check AWS Config history, rules, conformance packs]
C --> F{Likely resource layer?}
F -->|Network| G[Routes, security groups, NACLs, DNS, endpoints, load balancer]
F -->|Compute| H[EC2 status checks, ASG health, ECS/Lambda errors, capacity]
F -->|Storage / database| I[S3/KMS policies, EBS/EFS, RDS metrics, backups, replicas]
D --> J[Contain, revoke, rotate, patch, document]
E --> K[Remediate with SSM Automation, CloudFormation, or Config remediation]
G --> L[Apply least disruptive fix]
H --> L
I --> L
J --> M[Post-incident: add alarms, rules, runbooks, and tests]
K --> M
L --> M
Networking and connectivity
VPC reachability checklist
When a resource cannot connect, separate the layers:
Layer
What to check
DNS
Correct hostname, private hosted zone association, resolver rules, split-horizon behavior.
Route
Route table has a matching route to internet gateway, NAT gateway, VPC peering, Transit Gateway, VPN, or VPC endpoint.
Source / destination
Public subnet workloads need public IP or Elastic IP for direct internet access.
Security group
Stateful allow rules on the ENI or attached resource.
Network ACL
Stateless inbound and outbound rules; ephemeral ports matter.
Endpoint policy
VPC endpoint policy may block access even if IAM allows it.
Resource policy
S3 bucket policy, KMS key policy, SQS queue policy, etc.
OS / application
Local firewall, listener port, service health, certificate, proxy, or application config.
Notes and examples
Security groups vs network ACLs
Feature
Security group
Network ACL
Scope
ENI / resource level
Subnet level
State
Stateful
Stateless
Rules
Allow rules only
Allow and deny rules
Evaluation
All rules considered
Numbered rules evaluated in order
Common use
Instance/application access control
Subnet-level guardrail or explicit deny pattern
Exam trap
“Outbound response traffic” is automatically allowed for established flows
Must allow return traffic, often including ephemeral ports
Internet, private access, and hybrid access
Requirement
Common AWS pattern
Public web app
Public subnet ALB + private subnet targets where possible
Private subnet instance needs outbound internet updates
NAT gateway in a public subnet + route from private subnet