Governance, compliance and operational automation

Operations notes for AWS Certified CloudOps Engineer – Associate (SOA-C03), the credential formerly called SysOps Administrator – Associate. This is the operator exam: monitoring, remediation, automation, cost control and governance, tested from the point of view of the person on call.

4 topics, 13 study points. Everything here is exam-oriented: each point is a fact or a distinction that SOA-C03 items are built on. Test yourself against the practice exam once you can explain a section without re-reading it.

1. AWS Config

AWS Config is a configuration management service that continuously records the state of your AWS resources and evaluates them against desired configurations. The Configuration Recorder discovers all supported resources in your account and creates a configuration item (a snapshot of the resource’s configuration in JSON format) every time a resource is created, modified, or deleted. This creates a complete, searchable configuration history — you can answer questions like “what was the security group configuration of this RDS instance on a specific date?” or “which IAM role was attached to this EC2 instance when the incident occurred?”

Config Rules define your desired configuration state as policy. Managed Rules are pre-built by AWS and cover hundreds of common compliance checks — examples include: “restricted-ssh” (ensures no security group allows unrestricted inbound access on port 22), “rds-multi-az-support” (ensures all RDS instances have Multi-AZ enabled), “s3-bucket-ssl-requests-only” (ensures S3 buckets require SSL for all requests), and “ec2-instances-in-vpc” (ensures all EC2 instances are running within a VPC). Custom Rules invoke a Lambda function to implement any compliance logic not covered by managed rules — for example, checking whether EC2 instances use approved AMIs from your golden image library, or verifying that S3 Glacier vaults have a Vault Lock policy applied.

AWS Config operates as a reactive system: it identifies non-compliant resources after they are created or modified. This is an important distinction compared to preventive controls (like SCPs or IAM policies that block non-compliant actions before they occur) or proactive controls (like AWS Service Catalog, which only exposes approved configurations in the first place). Config remediation can be triggered automatically via Systems Manager Automation documents when a non-compliant resource is detected — for example, automatically enabling S3 bucket encryption when a non-encrypted bucket is created.

Config Aggregator consolidates configuration and compliance data from multiple AWS accounts and regions into a single view. For accounts within an AWS Organization, you can authorize Config to aggregate data from all member accounts automatically. For accounts outside your Organization, each must be individually added. The aggregator provides a centralized dashboard showing compliance status across your entire multi-account environment — essential for large organizations managing dozens or hundreds of accounts. Config billing is based on the number of configuration items recorded (per resource change) and the number of active Config Rules evaluated — costs scale with the number of resources in your account and the frequency of changes.

2. AWS Systems Manager (Advanced)

AWS Systems Manager provides a unified operational interface for managing both EC2 instances and on-premises servers as “managed instances.” To register on-premises servers with Systems Manager, you create an IAM role with SSM permissions, generate a managed instance activation (which provides an Activation Code and ID), install the SSM Agent on the server using that activation, and the server appears in the Systems Manager Fleet Manager console alongside your EC2 instances. This enables you to apply the same operational tooling — Run Command, Patch Manager, Session Manager — to hybrid environments without VPN or complex network configuration.

State Manager automates the process of keeping your managed instances in a defined, consistent state. You create an association between an SSM document (a set of instructions) and a set of targets (instances matching specific tags or instance IDs), and State Manager applies the document on a schedule or continuously. Common use cases include: ensuring the CloudWatch Agent is always installed and running, keeping a specific software version deployed, applying security hardening configurations from a CIS benchmark, or continuously enforcing firewall rules. State Manager differs from Patch Manager (which focuses specifically on OS updates) in that it can enforce any configuration defined in an SSM document.

SSM Documents are the definition language for Systems Manager actions. They describe a sequence of steps, each specifying an action (aws

, aws

, etc.) and its parameters. AWS provides hundreds of pre-built documents for common tasks (AWS-RunShellScript, AWS-InstallWindowsUpdates, AWS-ConfigureAWSPackage). You can create custom documents in JSON or YAML and share them across accounts. Documents are versioned, enabling controlled rollouts of operational procedures. Automation Documents (runbook-style) execute multi-step workflows involving multiple AWS API calls — for example, creating an AMI snapshot, stopping an instance, updating a security group, and sending an SNS notification.

3. Amazon Inspector

Amazon Inspector is an automated security assessment service that continuously scans your AWS workloads for software vulnerabilities and unintended network exposure. Inspector v2 (the current version) automatically discovers all EC2 instances, Lambda functions, and container images in ECR across your account and begins scanning without requiring manual configuration or agent installation — unlike the original Inspector v1, which required deploying an agent on each EC2 instance. Inspector v2 integrates with AWS Organizations, enabling centralized security scanning across all accounts from a single delegated administrator account.

Inspector evaluates two primary vulnerability categories. Software vulnerability findings identify known CVEs (Common Vulnerabilities and Exposures) in the operating system packages and application libraries installed on your instances or in your container images. It continuously monitors the CVE database and generates new findings whenever a new vulnerability is published that affects your installed packages — you do not need to re-scan manually. Network reachability findings identify network paths from the internet that lead to your EC2 instances and assess whether those paths expose your instances to unintended access based on your security group and NACL configurations.

Each Inspector finding is assigned a severity score based on the CVSS (Common Vulnerability Scoring System) and contextual factors specific to your environment — such as whether the vulnerable package is actually reachable from the internet. This context-aware scoring helps security teams prioritize remediation by distinguishing between a critical vulnerability on a public-facing instance (extremely high risk) versus the same vulnerability on an isolated internal instance with no network path from the internet (lower immediate risk). Inspector findings are surfaced in the Inspector console, AWS Security Hub, and EventBridge, enabling integration with ticketing systems and SIEM tools.

4. Operational Automation & Governance

Operational automation in AWS centers on eliminating manual, error-prone tasks through event-driven workflows and scheduled jobs. EventBridge (CloudWatch Events) is the nervous system — it captures events from every AWS service and routes them to automation targets. A common pattern is detecting an operational event (an EC2 instance entering a degraded state, an S3 bucket becoming publicly accessible, a failed login attempt), routing it through EventBridge to a Lambda function, and having the Lambda function perform an automated remediation or create an incident ticket. This “event → detect → respond” pattern is the foundation of self-healing infrastructure.

AWS Systems Manager Automation documents (runbooks) enable multi-step operational workflows that combine AWS API calls with approval gates, branching logic, and cross-service orchestration. A common automation is the “create golden AMI” runbook: launch a base instance, run patching and hardening scripts via Run Command, verify compliance, create an AMI, tag it with a version number, share it to approved accounts, and terminate the instance. These runbooks can be triggered manually, on a schedule, or in response to EventBridge events. Automation provides a consistent, auditable record of every execution step — critical for regulated environments that require evidence of operational procedures.

AWS Organizations with AWS Control Tower provides a fully managed framework for setting up and governing a multi-account AWS environment. Control Tower configures foundational guardrails — preventive controls (SCPs that block non-compliant actions) and detective controls (Config rules that identify policy violations) — across the entire organization from day one. Account Factory standardizes the provisioning of new AWS accounts using pre-approved templates, ensuring every new account is born with the correct baseline configuration: logging to a centralized log archive account, security tooling enabled, network isolation, and budget alerts. This “landing zone” approach is the AWS recommended pattern for large organizations building cloud foundations at scale.

Where to go next

Back to the AWS SysOps Associate overview.
Look up any service you could not name in the AWS services glossary.
Sit the 80-item practice exam once two or three note pages are solid.