AWS SysOps is the operations exam: it tests whether you can keep AWS workloads healthy in production - monitoring them, automating their provisioning, making them reliable and secure, troubleshooting their networking, and controlling their cost. Where the Solutions Architect Associate asks you to design a system, SysOps asks you to run it after it is built. That difference shapes everything about how you should study: the marks reward the instincts of someone who has actually watched a metric spike, traced a packet that did not arrive, and rolled back a bad deployment, not someone who has only read about those things. This guide is a full, self-study course. It walks through each operational area in depth, explains the AWS services behind it and the decisions they involve, and then turns all of it into a week-by-week plan and a final-preparation routine. It is original teaching material only, with no real or simulated exam questions.
Before anything else, one fact has to be stated plainly, because it governs how you book.
A note on the exam version (read this first)
The certification you are studying for has been renamed and re-versioned. The SOA-C02 version was retired, with a last test date of 29 September 2025. AWS replaced it with the AWS Certified CloudOps Engineer - Associate (SOA-C03), which began on 30 September 2025. Both names describe the same operations-focused associate credential, and the underlying skills are essentially unchanged: monitoring, automation, reliability, security, networking, and cost on AWS. If you are scheduling a sitting now, you book the CloudOps Engineer - Associate (SOA-C03), not the old SysOps SOA-C02. The format is the same in length: 65 multiple-choice and multiple-response questions in 130 minutes at an indicative US$150. Confirm the current name, format, scoring, and domain list on AWS’s own certification page before you book, because AWS updates these periodically and the wording on third-party sites lags behind. Everything this course teaches about operating AWS is what both versions test. Where the structure differs between versions, this guide says so explicitly rather than pretending the older six-domain split is still the live one.
Chapter 1: Exam overview and how to use this guide
What this exam actually measures
This exam measures whether you can operate workloads that are already running on AWS. That is a narrower and more practical thing than it sounds. A question rarely asks you to invent an architecture from scratch; far more often it hands you a system that exists and asks what you would do when something about it needs monitoring, fixing, hardening, scaling, or cheaper running. The reliable way to read almost any question is to ask, “I operate this system - what is the correct operational response here?”. That framing keeps you out of the trap of designing a grander solution when the marks are for a clean operational fix.
Because the content is operational, it is detail-heavy. You are expected to know not just that CloudWatch exists but what a metric, an alarm, and a log group each are and when you would reach for each one; not just that VPCs exist but how a route table, a security group, and a network ACL combine to allow or block a specific packet. This is why hands-on time matters so much. The knowledge that wins marks is the knowledge you build by actually setting an alarm and watching it fire, not by reading a list of service names.
The shape of the exam, and how the versions differ
The live exam is 65 questions in 130 minutes, scored on a scaled system. The older SOA-C02 used a published pass mark of 720 / 1000; confirm the current scoring for the CloudOps SOA-C03 version on the AWS page, since scaled scores are set per exam and the figure can change. Questions are multiple choice (one correct answer) and multiple response (choose two or more), and they are written as short operational scenarios rather than bare definitions.
The two versions organise the same material slightly differently, and it is worth being precise about this so you study the right map:
- The older SOA-C02 split the content into six domains: Monitoring/Logging/Remediation (20%), Deployment/Provisioning/Automation (18%), Networking and Content Delivery (18%), Reliability and Business Continuity (16%), Security and Compliance (16%), and Cost and Performance Optimization (12%).
- The current CloudOps SOA-C03 uses five domains, folding cost and performance optimisation into monitoring: Monitoring, Logging, Analysis, Remediation and Performance Optimization (22%); Reliability and Business Continuity (22%); Deployment, Provisioning and Automation (22%); Security and Compliance (16%); and Networking and Content Delivery (18%).
The practical takeaway is the same either way. Monitoring, automation, and reliability carry the most weight; networking is a substantial slice that trips people up; security is always present; and cost and performance, whether counted as their own domain or rolled into monitoring, are tested. This course is organised by operational area so it serves both versions, and the chapters below map cleanly onto whichever domain list AWS is currently using.
How to use this course
Read the chapters in order once, because the monitoring chapter builds the observability mindset that the reliability, security, and cost chapters all draw on. Treat each bold service name and concept as something you should be able to explain in a sentence and, ideally, have clicked through once in a free-tier account. The last three chapters turn the content into a schedule, a final-preparation routine, and a description of exam day. Short worked examples appear where a concept is easy to misread; none of them are exam questions, they are teaching illustrations to make an operational idea concrete.
Chapter 2: Monitoring, logging, and remediation
This is the heaviest area on the exam and the heart of operations, so it deserves the most study. The unifying idea is observability: you cannot operate what you cannot see, so the first job of a SysOps administrator is to make a system’s health visible and then to react to it, ideally automatically.
What it is, and the three things CloudWatch gives you
Amazon CloudWatch is the monitoring service, and it is easiest to understand as three related capabilities. Metrics are time-ordered numbers about a resource: CPU utilisation of an instance, the number of requests hitting a load balancer, the length of a queue. Alarms watch a metric and change state when it crosses a threshold you set, which lets you turn a number into an action. Logs capture the textual output of your systems - application logs, operating-system logs, service logs - in log groups and log streams, where you can search and retain them. A fourth capability, dashboards, simply puts metrics on a screen for humans. Knowing which of these three you need for a given problem is half of this domain.
A point that catches people out is that some metrics are not collected by default. AWS publishes a standard set of metrics for each service, but anything inside the guest operating system - memory usage and disk space on an EC2 instance are the classic examples - is not visible to AWS from outside the instance. To monitor those you install the CloudWatch agent, which runs on the instance and pushes the extra metrics and logs out to CloudWatch. As a teaching example: if a scenario complains that you cannot see an instance’s memory utilisation, the operational fix is to deploy the CloudWatch agent, because memory is a guest-level metric that the platform does not see on its own.
Why it matters
Monitoring matters because every other operational concern depends on it. You cannot prove reliability without metrics on availability, you cannot catch a security event without logs, and you cannot right-size for cost without utilisation data. The exam treats monitoring as the foundation, which is why it carries the most weight, and why so many “what do you do” answers begin with making the problem visible before acting on it.
How to study it
Build the habit of mapping a symptom to the right tool. Performance question, think metrics and alarms. Audit-trail or “who did what” question, think AWS CloudTrail, which records API calls across the account and is the go-to for security and change auditing - distinct from CloudWatch Logs, which captures application and system output. Event-driven reaction, think Amazon EventBridge, the event bus that routes events (a state change, a scheduled time, a service notification) to targets that act on them. The strongest single pattern to internalise is automated remediation: a CloudWatch alarm or an EventBridge rule detects a condition and triggers a response - an SNS notification to a human, a Lambda function to fix it, or a Systems Manager automation document to run a predefined repair - without anyone watching a screen. In the SOA-C03 version this domain also explicitly folds in performance optimisation, so connect monitoring to action: you watch a metric, decide the resource is over- or under-provisioned, and adjust.
Common pitfalls
The recurring trap is confusing the logging services: CloudTrail is for API activity and auditing, CloudWatch Logs is for application and system output, and mixing them up loses marks on security and troubleshooting questions alike. A second trap is forgetting the agent for guest-level metrics, as above. A third is reaching for a human notification when the scenario clearly wants automation - if the question stresses that the same fix happens repeatedly and should not need a person, the intended answer is an automated remediation, not an email alert.
Chapter 3: Deployment, provisioning, and automation
This area is about creating and changing infrastructure in a controlled, repeatable way rather than by hand. Its weight is high in both versions, and its mindset - never click your way to production - runs through the whole exam.
What it is, and the two pillars
Two services dominate. AWS CloudFormation is infrastructure as code: you describe the resources you want in a template, and CloudFormation creates, updates, and deletes them as a single unit called a stack. The value is repeatability and safety - the same template builds the same environment every time, and changes are previewed and applied in a controlled way rather than made ad hoc. AWS Systems Manager is the operations toolkit for the fleet you already run: it lets you manage instances at scale through capabilities like Run Command (execute a command across many instances), Patch Manager (keep operating systems updated on a schedule), Parameter Store (hold configuration values and secrets), and Automation documents (predefined runbooks that perform multi-step operational tasks). Where CloudFormation builds the infrastructure, Systems Manager operates it day to day.
A useful distinction the exam rewards is knowing which tool fits which job. “Stand up this whole environment reproducibly” is CloudFormation. “Apply this patch, or run this command, across fifty existing instances” is Systems Manager. They complement each other rather than compete.
Why it matters
Automation matters because manual operations do not scale and do not stay consistent. A patch applied by hand to forty instances will be applied wrongly to at least one; a Run Command or Patch Manager job applies it the same way everywhere and records the result. The exam is built on the assumption that a good operator automates, so when a scenario describes a repetitive manual task or configuration drift, the intended answer almost always involves codifying or centralising it.
How to study it
Write at least one small CloudFormation template by hand so the structure stops being abstract - know that a template has resources, that parameters let you reuse it across environments, and that updates are applied through change sets that show you what will happen before it happens. For Systems Manager, learn the headline capabilities by name and, crucially, by purpose, because questions describe a need (“centralise configuration values”, “patch on a schedule”, “run a script fleet-wide”) and expect you to name the right capability. As a teaching example: if a scenario asks how to store a database password so that instances can retrieve it securely without hard-coding it, the operational answer is a secure parameter in Parameter Store (or AWS Secrets Manager for richer secret rotation), not baking the value into an AMI.
Common pitfalls
The classic mistake is treating CloudFormation and Systems Manager as interchangeable; they are not, and questions are written to test that you know the boundary. Another is missing that CloudFormation can detect and report drift - where someone has changed a resource outside the template - which is the right answer when a scenario worries that live infrastructure no longer matches its code. A third is choosing a manual or one-off solution when the scenario stresses scale or repetition, which is exactly the cue to automate.
Chapter 4: Networking and content delivery
Networking is a large slice of the exam and the area where hands-on troubleshooting pays off most, because the questions often describe traffic that should flow but does not, and expect you to find the block.
What it is, and the building blocks of a VPC
A Virtual Private Cloud (VPC) is your isolated network in AWS, and operating it means understanding how a handful of pieces combine to permit or deny a specific connection. Subnets divide the VPC and are public or private depending on their routing. Route tables decide where traffic goes: a subnet is “public” because its route table sends internet-bound traffic to an internet gateway, while private subnets reach the internet outbound only through a NAT gateway. Two layers of filtering then apply: security groups, which are stateful and attach to resources (return traffic is automatically allowed), and network ACLs, which are stateless and attach to subnets (you must allow both directions explicitly). Connectivity problems almost always come down to one of these - a missing route, a security group that does not allow the port, or a network ACL that blocks the return path.
Beyond the VPC, two services round out the area. Amazon Route 53 is AWS’s DNS service, mapping names to resources and supporting routing policies and health checks. Amazon CloudFront is the content delivery network, caching content at edge locations close to users to cut latency and offload origins.
Why it matters
Networking matters because it is where production incidents concentrate and where the cost of a wrong mental model is highest. A SysOps administrator is frequently the person paged when an application is unreachable, and the difference between fixing it in minutes and flailing for hours is knowing exactly which of route table, security group, and network ACL to check, in order. The exam mirrors this with troubleshooting scenarios that reward methodical elimination.
How to study it
Practise tracing a connection end to end in a free-tier account: launch an instance in a public subnet, confirm you can reach it, then break it deliberately - remove the route, tighten the security group, add a deny in the network ACL - and observe each failure mode. That muscle memory is what the troubleshooting questions test. Learn the stateful-versus-stateless distinction cold, because it is one of the most reliable sources of marks: security groups remember the outbound request and allow the response, network ACLs do not. As a teaching example: if a scenario says outbound requests work but responses never arrive, and security groups look fine, suspect a network ACL that allows the outbound port but not the ephemeral return ports, because the ACL is stateless and needs both directions opened.
Common pitfalls
The biggest is treating security groups and network ACLs as the same thing; their stateful/stateless behaviour is different and questions exploit the confusion. Another is forgetting that private subnets need a NAT gateway for outbound internet access, so “the instance in the private subnet cannot download updates” usually points to a missing or misplaced NAT path. A third is overlooking DNS and CDN: when a scenario is about latency for global users, CloudFront is often the operational answer, and when it is about routing traffic by health or geography, Route 53 policies are.
Chapter 5: Reliability and business continuity
This area is about keeping systems available through failure and recovering them when something is lost. It carries heavy weight in both versions, and its core idea is that resilience is designed and operated, not hoped for.
What it is, and the mechanisms of availability
Reliability on AWS rests on a few mechanisms you must know by purpose. Availability Zones are physically separate datacentres within a Region, and spreading resources across them - multi-AZ - is the fundamental defence against a single datacentre failure. Elastic Load Balancing (ELB) distributes incoming traffic across healthy targets and stops sending to ones that fail their health checks. Auto Scaling adjusts the number of instances to match demand and replaces unhealthy instances automatically, which is as much a reliability tool as a cost one. For data, snapshots provide point-in-time backups of volumes and databases, and AWS Backup centralises backup policies across services. Managed databases add their own resilience: a multi-AZ database keeps a synchronous standby ready to take over.
Business continuity extends this to disaster recovery, where the vocabulary to know is the trade-off between cost and speed of recovery. The standard strategies, from cheapest and slowest to most expensive and fastest, are backup and restore, pilot light, warm standby, and multi-site (active-active). Two terms frame the choice: Recovery Time Objective (RTO), how quickly you must be back up, and Recovery Point Objective (RPO), how much data loss you can tolerate.
Why it matters
Reliability matters because availability is usually the operator’s primary promise, and the exam tests whether you can match a mechanism to a requirement rather than over- or under-engineering. Knowing that multi-AZ defends against a datacentre failure while multi-Region defends against a regional one, and that a stricter RTO/RPO costs more, is exactly the judgement these questions reward.
How to study it
Anchor every reliability decision to a stated requirement. When a scenario gives you an RTO and RPO, let them point to a disaster-recovery strategy: near-zero RTO and RPO imply warm standby or multi-site, while a tolerance of hours and a modest budget imply backup-and-restore or pilot light. Practise the difference between scaling for load and scaling for healing - Auto Scaling does both, and the exam may frame it either way. As a teaching example: if a single-instance database must survive a datacentre outage with minimal downtime, the operational answer is to enable multi-AZ so a standby in another Availability Zone can take over, rather than relying on restoring a snapshot, which would breach a tight RTO.
Common pitfalls
A frequent error is confusing the scope of resilience: multi-AZ is not the same as multi-Region, and a question about surviving a whole-Region failure needs a cross-Region answer. Another is treating backups as a recovery plan without checking the RPO - if data can only be lost up to a few minutes, nightly snapshots are not enough. A third is forgetting that load balancer and Auto Scaling health checks are what make self-healing work, so a misconfigured health check is often the hidden cause when unhealthy instances keep receiving traffic.
Chapter 6: Security, compliance, cost, and performance
The last two operational areas are grouped here because the current exam version itself folds cost and performance into the monitoring domain, while security stands on its own. Both are always present, and both reward a clear, practical mental model over memorised trivia.
Security and compliance: what it is
Security in SysOps is operational security - applying and auditing controls on running systems rather than designing a security architecture. The centre of it is AWS Identity and Access Management (IAM): users, groups, roles, and policies that decide who can do what. The single most important habit the exam rewards is least privilege - grant only the permissions needed - and the strong preference for IAM roles over long-lived access keys, because roles provide temporary credentials and avoid secrets sitting on instances. For data protection, encryption at rest is typically delivered through the AWS Key Management Service (KMS), which manages the encryption keys, and encryption in transit through TLS. AWS Config tracks resource configurations and evaluates them against rules, which makes it the go-to for compliance and for catching configuration drift, while CloudTrail (from Chapter 2) supplies the audit trail of who did what.
Security and compliance: why it matters and how to study it
Security matters because operators are the last line of defence on a live system, and the exam consistently rewards the secure-by-default choice. Study IAM until the relationships are second nature: a policy grants permissions, a role is assumed to gain them, and an instance gets AWS access through an instance profile attached to a role rather than through stored keys. Learn which service answers which question: “audit who made this change” is CloudTrail, “check whether resources comply with a rule” is Config, “manage encryption keys” is KMS, “store and rotate a secret” is Secrets Manager. As a teaching example: if an application on EC2 needs to read from an S3 bucket, the secure operational answer is to attach an IAM role granting that specific access to the instance, not to place an access key in the application’s configuration.
Cost and performance optimisation: what it is and how to study it
Cost and performance optimisation is about running workloads efficiently - neither paying for capacity you do not use nor starving a workload that needs more. The core operational move is right-sizing: using utilisation metrics to match instance type and size to real demand, scaling down what is over-provisioned and up what is constrained. Tools to know include AWS Cost Explorer for analysing spend, AWS Budgets for alerting when costs cross a threshold, AWS Trusted Advisor for recommendations across cost, performance, security, and fault tolerance, and AWS Compute Optimizer for right-sizing suggestions based on usage. On the pricing side, understand at a high level that committing to usage (Savings Plans or Reserved Instances) is cheaper than on-demand for steady workloads, and that Spot capacity is cheapest for interruptible work. Because the current version ties this to monitoring, study it as a loop: measure utilisation, decide the resource is mis-sized, and act.
Common pitfalls
For security, the recurring trap is choosing stored access keys when a role is available, or granting broad permissions when the scenario calls for least privilege. For cost, it is reaching for a pricing model that does not fit the workload pattern - committing to a Reserved Instance for a short-lived workload, or putting a critical, uninterruptible service on Spot. And across both, it is ignoring the data: the right operational answer to “should we resize this?” is to look at the utilisation metrics first, which loops you straight back to the monitoring discipline that anchors the whole exam.
Chapter 7: Study plan and timeline
With the operational areas understood, the work is pacing them so that nothing - least of all hands-on practice and the heavier monitoring, automation, and reliability areas - gets squeezed out. Three things drive the plan: your starting experience, the domain weights, and the need to actually operate services rather than only read about them.
Set your starting point honestly
This is not a beginner’s exam. AWS recommends around a year of hands-on operational experience, and the questions assume it. If you are comfortable in the AWS console and have run real workloads, a focused eight weeks at roughly eight hours a week is realistic. If you have solid experience and can push harder, a six-week intensive at around twelve hours a week works. If you are newer to AWS, build Cloud Practitioner-level foundations first and plan a longer twelve-week run at about five hours a week, because trying to learn the platform and the operations exam at once stretches both thin. Whichever you choose, confirm you are studying for the current CloudOps SOA-C03 version, since that is what you will book.
Allocate time by weight, and keep your hands on the console
Spend your hours roughly in proportion to the weights, which means the most on monitoring, automation, and reliability, a serious share on networking because it is both heavily weighted and error-prone, and steady coverage of security and of cost and performance. A balanced eight-week shape works through one area at a time: monitoring and remediation first, then deployment and automation, then networking, then reliability and business continuity, then security, then cost and performance - with hands-on practice in a free-tier account throughout and full-length timed mocks at the end. The non-negotiable thread is that you do the work in a real account: set an alarm and watch it fire, write and deploy a small CloudFormation template, deliberately break and fix a VPC route, attach a role to an instance. To turn whichever timeline you pick into dated weeks for your own start date, use the free study-plan generator.
Practise the way the exam tests
Because the questions are operational scenarios, move from reading to scenario practice as soon as you have covered an area, not only at the very end. For each practice scenario, force yourself to articulate the operational response and why the alternatives are wrong - “I would deploy the agent because memory is a guest-level metric”, “I would check the network ACL because security groups are stateful and the return traffic is blocked”. That habit of reasoning to the correct operational action is exactly what the marks reward. If you are still deciding between this operations track and the design-focused alternative, the SysOps versus Solutions Architect Associate comparison lays out how the two differ in focus and in the roles they map to.
Chapter 8: Final preparation, exam day, and format
Final preparation
In the last week or two, shift from learning new services to full-length, timed practice across all the operational areas, treating each session as both a stamina run and a diagnosis. Note which area leaks marks - very often it is networking troubleshooting or the logging-service distinctions - and go back to the console to shore it up rather than only re-reading. Aim to be scoring comfortably above the pass mark on fresh material before you book. Keep building from genuine practice rather than memorised answer sets; the exam rewards operational understanding, and there is no shortcut around having actually run the services.
Prerequisites and booking
There is no formal prerequisite, but the assumed background is real: roughly a year of hands-on AWS operations experience makes the difference between a hard exam and a fair one. When you book, schedule the current AWS Certified CloudOps Engineer - Associate (SOA-C03), which replaced the retired SysOps SOA-C02 on 30 September 2025, and confirm the current fee, scoring, and domain list on AWS’s certification page, since these are the details that change. The credential is valid for three years, after which you recertify by passing the then-current version or a qualifying exam.
Exam day and format
On the day, you face 65 multiple-choice and multiple-response questions in 130 minutes, taken either at a Pearson VUE test centre or through online proctoring, with government-issued identification required. Pace yourself: roughly two minutes per question on average, but the operational scenarios vary in length, so do not let a single wordy question eat your time - flag it, move on, and return. Read each scenario for what it is really asking, hold the operator’s frame (“this system exists; what is the correct operational response?”), and eliminate options that over-engineer a fix the scenario does not need. Multiple-response questions tell you how many answers to pick, so honour that count. Having practised at full length and, more importantly, having actually operated the services in a real account, the format will feel familiar rather than intimidating, which is exactly the advantage you built over the weeks of hands-on study.