AWS certification practice

Free SOA-C03 Practice Test

10 free SOA-C03 exam-style questions for AWS Certified CloudOps Engineer - Associate, with answers, explanations and source references.

Last updated November 4, 2026

Full set: 219 questions

SOA-C03 is the exam for the AWS Certified CloudOps Engineer – Associate certification. It is meant for people who run workloads on AWS day to day and need to keep them monitored, reliable, secure and automated. The exam has 65 multiple choice or multiple response questions in 130 minutes, with a passing score of 720, and the certification is valid for 3 years.

Three domains carry 22% each: monitoring, logging, analysis, remediation and performance optimization; reliability and business continuity; and deployment, provisioning and automation. These areas focus on operational detail, such as deciding which metric or log answers a question, or which recovery approach meets a stated requirement. Networking and content delivery (18%) and security and compliance (16%) can appear together in one scenario, so study how the two interact.

Work through the free practice questions one at a time and check each answer before moving on. Read every explanation, even when you were right, because the reasoning about why other options fail is where most of the learning happens. Track which of the five domains you miss most, review those parts of the official exam guide, and come back to the questions after that review.

Get Full Access

Domain Cost and Performance Optimization

Optimization] A CloudOps engineer is using AWS Compute Optimizer to generate recommendations for a fleet of Amazon EC2 instances. Some of the instances use newly released instance types, while other instances use older instance types. After the analysis is complete, the CloudOps engineer notices that some of the EC2 instances are missing from the Compute Optimizer dashboard. What is the likely cause of this issue?

Answer options

Correct Answer:

Explanation

AWS Compute Optimizer generates recommendations only for a specific list of supported EC2 instance types. If an instance type is not on this list, Compute Optimizer will not process it, and consequently, it will not appear on the dashboard. The question highlights that the fleet includes "newly released instance types" and "older instance types," which are the most likely candidates to be unsupported. Newly released types may not have been added to the supported list yet, and very old types might be excluded. This makes an unsupported instance type the most probable reason for the instances being missing from the analysis.

Why Incorrect

A. An instance with insufficient data is typically listed in the dashboard with a finding status of "Insufficient data" or "Not yet analyzed," not completely missing.
C. Optimized instances are explicitly displayed on the dashboard with the finding status "Optimized." The service does not hide them.
D. AWS Compute Optimizer supports instances running both Windows and Linux operating systems. The OS is not a reason for an instance to be excluded from the dashboard.

References

1. AWS Compute Optimizer User Guide

"Supported resources and requirements": This section explicitly lists the EC2 instance types that are supported for analysis. It states

"Compute Optimizer generates recommendations for the following EC2 instance types." If an instance type is not on this list

it is not analyzed. (AWS Documentation)

2. AWS Compute Optimizer User Guide

"Troubleshooting": Under the topic "Why are some of my resources missing from the Compute Optimizer dashboard?"

the guide lists the primary reason as "The resource is not of a supported configuration." This directly corresponds to the instance type not being supported. (AWS Documentation)

3. AWS Compute Optimizer User Guide

"Getting started with AWS Compute Optimizer"

"Prerequisites": This section outlines the requirements for resources to be analyzed. It lists two key prerequisites for EC2 instances: "The instances must be of a supported instance type" and "The instances must have accumulated sufficient metric data in CloudWatch." The scenario's details about new and old instance types point specifically to the first prerequisite. (AWS Documentation)

Question breakdown

Tests: Troubleshoot AWS Compute Optimizer coverage for EC2 rightsizing
Difficulty: Medium

Key idea: Compute Optimizer analyzes only EC2 instances whose instance types are on its supported list, so unsupported types are left out of the results entirely.

How to reach the answer

The symptom is that instances are missing from the dashboard, not that they show a particular finding.
The question deliberately mentions both newly released and older instance types.
Compute Optimizer only analyzes a defined set of instance families, and that set can lag new launches or exclude legacy generations.
Optimized instances still appear with an Optimized finding, and Windows instances are supported, so neither explains the gap.
The instance-type clue therefore points to unsupported types.

Each option

AIncorrect. Metric history is a real requirement, but nothing in the scenario points to it; the question highlights instance-type age instead.
BCorrect. Instance types outside Compute Optimizer's supported list are not analyzed, so they do not show up in the recommendations.
CIncorrect. Instances that are already well sized are still listed, with a finding of Optimized.
DIncorrect. Compute Optimizer supports Windows instances, so the operating system does not remove them from the analysis.

Common trap: Option A is tempting because metric history is a genuine Compute Optimizer prerequisite, but the scenario's clue is about new and old instance types, not about how long instances have run.

In practice: During cost reviews, teams often find that legacy-generation or brand-new instance types are absent from Compute Optimizer exports and have to rightsize them manually or migrate them to supported families.

Remember: If EC2 instances are missing from Compute Optimizer, first check whether their instance types are supported.

Official documentation: AWS Compute Optimizer supported resources and requirements

Open this question on its own page

Domain Deployment, Provisioning, and Automation

A company's developers manually install software modules on Amazon EC2 instances to deploy new versions of a service. A security audit finds that instances contain inconsistent and unapproved modules. A CloudOps engineer must create a new instance image that contains only approved software. Which solution will meet these requirements?

Answer options

Correct Answer:

Explanation

EC2 Image Builder is a fully managed AWS service designed to automate the creation, management, and deployment of customized, secure, and up-to-date server images, known as Amazon Machine Images (AMIs). It allows an organization to define a pipeline that starts with a base image, applies customizations and software installations (components), runs tests to validate the image, and then distributes the final, approved AMI. This directly addresses the requirement to create a standardized instance image with only approved software, resolving the issue of configuration drift and unapproved modules caused by manual installations. Updating the deployment workflow to use this "golden AMI" ensures consistency and security for all new instances.

Why Incorrect

A. Amazon Detective is a security service that analyzes log data to help investigate the root cause of security findings; it does not modify or manage software on instances.
B. Amazon GuardDuty is a threat detection service that monitors for malicious activity and unauthorized behavior; it does not have capabilities for creating or deploying AMIs.
C. AWS Systems Manager Run Command executes commands on existing instances. While it can install software, it does not create a new, reusable AMI, which is the core requirement to prevent future inconsistencies.

References

1. EC2 Image Builder User Guide: "EC2 Image Builder is a fully managed AWS service that helps you automate the creation

management

and deployment of customized

secure

and up-to-date server images that are pre-installed and pre-configured with software and settings to meet specific IT standards."

Source: AWS Documentation

EC2 Image Builder User Guide

"What is EC2 Image Builder?".

2. AWS Systems Manager User Guide: "Run Command

a capability of AWS Systems Manager

lets you remotely and securely manage the configuration of your managed nodes. ... Run Command enables you to automate common administrative tasks and perform ad hoc configuration changes at scale."

Source: AWS Documentation

AWS Systems Manager User Guide

"Systems Manager Run Command".

3. Amazon GuardDuty User Guide: "Amazon GuardDuty is a threat detection service that continuously monitors your AWS accounts and workloads for malicious activity and delivers detailed security findings for visibility and remediation."

Source: AWS Documentation

Amazon GuardDuty User Guide

"What is Amazon GuardDuty?".

4. Amazon Detective Administration Guide: "Amazon Detective automatically collects log data from your AWS resources and uses machine learning

statistical analysis

and graph theory to build a linked set of data that enables you to easily conduct faster and more efficient security investigations."

Source: AWS Documentation

Amazon Detective Administration Guide

"What is Amazon Detective?".

Question breakdown

Tests: Build standardized golden AMIs for consistent EC2 deployments
Difficulty: Easy

Key idea: EC2 Image Builder automates building, testing, and distributing hardened AMIs, so deployments start from an approved, consistent image.

How to reach the answer

The requirement is to create a new instance image, which means an AMI.
The image must contain only approved software, so the build should be repeatable and testable.
Detective and GuardDuty investigate and detect security issues; neither builds images.
Run Command patches existing instances but produces no reusable image.
Image Builder pipelines with components and tests meet the requirement directly.

Each option

AIncorrect. Amazon Detective investigates security findings and cannot uninstall software or build images.
BIncorrect. GuardDuty detects threats and has no AMI creation or deployment capability.
CIncorrect. An in-place update with Run Command leaves drift on running instances and creates no new image.
DCorrect. Image Builder produces a tested AMI that contains only approved components, and pointing deployments at that AMI enforces consistency.

Common trap: Run Command looks attractive because it can install the approved modules fleet-wide, but it fixes running instances instead of producing the required image.

In practice: Platform teams run Image Builder pipelines on a schedule to produce patched golden AMIs, then reference them in launch templates for Auto Scaling groups.

Remember: When a question asks for a new image with approved software, think EC2 Image Builder plus launch templates.

Official documentation: What is EC2 Image Builder?

Open this question on its own page

Domain Security and Compliance

A company requires the rotation of administrative credentials for production workloads on a regular basis. A CloudOps engineer must implement this policy for an Amazon RDS DB instance's master user password. Which solution will meet this requirement with the LEAST operational effort?

Answer options

Correct Answer:

Explanation

AWS Secrets Manager is the purpose-built service for managing the lifecycle of secrets, including credentials for services like Amazon RDS. It offers a fully managed, out-of-the-box solution for automatic password rotation. By creating a secret for the RDS database and enabling rotation, Secrets Manager automatically provisions and manages an AWS Lambda function to handle the entire rotation process. This approach requires only configuration and eliminates the need to write, test, or maintain custom code, thereby representing the least operational effort to meet the requirement.

Why Incorrect

A. This is a valid but high-effort solution. It requires the engineer to write, deploy, and maintain a custom Lambda function and its associated permissions, which is more operational overhead than the managed Secrets Manager solution.
B. AWS Systems Manager Parameter Store does not have a native, built-in capability to automatically rotate credentials for external services like Amazon RDS. A custom solution, such as a Lambda function, would still be required.
C. This option is incorrect for two reasons: it uses a plain String parameter, which is insecure for storing passwords, and Parameter Store does not natively support automatic rotation for RDS credentials. ---

References

1. AWS Secrets Manager User Guide, "Rotate secrets": "For secrets that store credentials for Amazon RDS... you can configure Secrets Manager to rotate the secret automatically. When you turn on automatic rotation, Secrets Manager uses a Lambda rotation function to rotate the secret." This document confirms that Secrets Manager provides a managed, automatic rotation feature specifically for RDS.

2. AWS Secrets Manager User Guide, "How rotation works": This section details the four-step process (createSecret, setSecret, testSecret, finishSecret) that the managed Lambda function performs, illustrating the complexity that is abstracted away from the user, thus minimizing operational effort.

3. AWS Systems Manager User Guide, "AWS Systems Manager Parameter Store": The documentation for Parameter Store describes its function for storing configuration data and secrets as parameters. It does not mention a native, managed feature for rotating credentials of other AWS services like RDS, which differentiates it from Secrets Manager.

4. AWS Security Blog, "AWS Secrets Manager vs. Systems Manager Parameter Store": "Secrets Manager offers secret rotation with built-in integration for Amazon RDS... If you need to rotate secrets, you should use Secrets Manager." This official blog post explicitly recommends Secrets Manager over Parameter Store for use cases involving credential rotation.

Question breakdown

Tests: Automate credential rotation for Amazon RDS
Difficulty: Easy

Key idea: AWS Secrets Manager has native, managed rotation for RDS credentials, so no custom rotation code is needed.

How to reach the answer

The goal is rotating the RDS master password on a schedule.
The phrase LEAST operational effort rules out writing custom code.
Parameter Store has no built-in automatic rotation for RDS credentials.
Secrets Manager integrates with RDS and provides managed rotation on a schedule.
Secrets Manager is therefore the lowest-effort fit.

Each option

AIncorrect. It works, but a custom Lambda function plus an EventBridge schedule must be built and maintained, which is more effort.
BIncorrect. SecureString parameters are encrypted, but Parameter Store cannot automatically rotate RDS passwords.
CIncorrect. A plain String parameter stores the password unencrypted, and Parameter Store has no native rotation.
DCorrect. Secrets Manager stores the RDS secret and rotates it automatically through managed rotation, with minimal setup.

Common trap: Parameter Store SecureString seems like an equivalent, cheaper secret store, but it lacks managed rotation.

In practice: Many teams enable RDS managed master user passwords in Secrets Manager so the password is rotated automatically and applications retrieve it at runtime.

Remember: Choose Secrets Manager whenever credentials need automatic rotation; Parameter Store does not rotate them.

Official documentation: Rotate AWS Secrets Manager secrets · Password management with Amazon RDS and AWS Secrets Manager

Open this question on its own page

Domain Networking and Content Delivery

Application A runs on Amazon EC2 instances behind a Network Load Balancer (NLB). The EC2 instances are in an Auto Scaling group and are in the same subnet that is associated with the NLB. Other applications from an on-premises environment cannot communicate with Application A on port 8080. To troubleshoot the issue, a CloudOps engineer analyzes the flow logs. The flow logs include the following records: ACCEPT from 192.168.0.13:59003 → 172.31.16.139:8080 REJECT from 172.31.16.139:8080 → 192.168.0.13:59003 What is the reason for the rejected traffic?

Answer options

Correct Answer:

Explanation

The VPC Flow Logs provide critical information. The ACCEPT record for inbound traffic (192.168.0.13 → 172.31.16.139:8080) confirms that both the Network ACL (NACL) and the EC2 instance's security group are correctly configured to allow the initial request. However, the REJECT record for the return traffic (172.31.16.139:8080 → 192.168.0.13:59003) indicates the response is being blocked. Security groups are stateful, meaning if inbound traffic is allowed, the return traffic is automatically permitted. In contrast, NACLs are stateless and require explicit rules for both inbound and outbound traffic. The rejection of the response packet, destined for the client's ephemeral port (59003), points directly to a missing or incorrect outbound rule in the NACL associated with the instance's subnet.

Why Incorrect

A. The inbound traffic is ACCEPTed, which would not be possible if the security group were blocking traffic from the NLB's targets.
B. Network Load Balancers do not have security groups. Security groups are associated with the target EC2 instances, not the NLB itself.
C. The initial traffic from the on-premises environment was ACCEPTed by the AWS VPC, indicating the on-premises ACL is not the source of the block.

References

1. AWS Documentation - VPC Flow Logs: "If the traffic is permitted by both the security groups and the network ACLs, the record shows ACCEPT. If the traffic is denied by a security group or a network ACL, the record shows REJECT." (Source: AWS Documentation, VPC User Guide, "Log file format", section on the action field).

2. AWS Documentation - Network ACLs: "Network ACLs are stateless, which means that responses to allowed inbound traffic are subject to the rules for outbound traffic (and vice versa)." (Source: AWS Documentation, VPC User Guide, "Network ACLs", section "Network ACL basics").

3. AWS Documentation - Ephemeral Ports: "When a client connects to a server, a random port from the ephemeral port range... becomes the client's source port. The response from the server is sent to this ephemeral port on the client... The network ACL for the subnet... must have an outbound rule to allow traffic destined for the ephemeral ports." (Source: AWS Documentation, VPC User Guide, "Network ACLs", section "Ephemeral ports").

4. AWS Documentation - Security Groups: "Security groups are stateful. If you send a request from your instance, the response traffic for that request is allowed to flow in, regardless of inbound security group rules." (Source: AWS Documentation, VPC User Guide, "Security groups", section "Security group basics").

Question breakdown

Tests: Troubleshoot VPC connectivity using flow logs, security groups, and network ACLs
Difficulty: Medium

Key idea: Network ACLs are stateless, so return traffic to client ephemeral ports needs an explicit outbound rule, while security groups allow return traffic automatically.

How to reach the answer

The inbound request to port 8080 shows ACCEPT, so the inbound filtering works.
The response from port 8080 to client port 59003 shows REJECT.
Security groups are stateful, so the response to an accepted request cannot be rejected by a security group.
Only a stateless control can block the return path, which means the subnet's network ACL.
The NACL needs an outbound rule allowing the ephemeral port range (1024-65535) to the on-premises CIDR.

Each option

AIncorrect. The inbound flow was accepted, so the instance security group already allows the traffic, and its stateful nature permits the reply.
BIncorrect. Whatever the NLB security group configuration, the inbound request reached the instance and was accepted, so the failure is on the return path.
CIncorrect. The flow logs record a reject inside the VPC on the outbound response, not a block in the on-premises network.
DCorrect. A stateless NACL without an outbound allow for ephemeral ports drops the response to port 59003, which matches the REJECT record.

Common trap: People see REJECT and blame a security group, forgetting that stateful security groups automatically allow replies to accepted requests.

In practice: Teams that tighten NACLs to specific service ports often break return traffic until they add outbound ephemeral port rules, and flow logs reveal it as an ACCEPT-in, REJECT-out pair.

Remember: An ACCEPT inbound followed by a REJECT on the reply points to a stateless NACL missing an ephemeral-port rule.

Official documentation: Control subnet traffic with network access control lists · Logging IP traffic using VPC Flow Logs

Open this question on its own page

Domain Monitoring, Logging, and Remediation

A company uses an organization in AWS Organizations to manage multiple AWS accounts. The company needs to send specific events from all the accounts in the organization to a new receiver account, where an AWS Lambda function will process the events. A CloudOps engineer configures Amazon EventBridge to route events to a target event bus in the us- west-2 Region in the receiver account. The CloudOps engineer creates rules in both the sender and receiver accounts that match the specified events. The rules do not specify an account parameter in the event pattern. IAM roles are created in the sender accounts to allow PutEvents actions on the target event bus. However, the first test events from the us-east-1 Region are not processed by the Lambda function in the receiving account. What is the likely reason the events are not processed?

Answer options

Correct Answer:

Explanation

For Amazon EventBridge to send events from one AWS account to an event bus in another, a two-part permission model is required. First, the sender account needs an IAM role with a policy allowing the events:PutEvents action on the target event bus ARN. Second, and critically, the target event bus in the receiver account must have a resource-based policy attached. This policy explicitly grants permission to the sender account's principal (or the entire AWS Organization) to perform the events:PutEvents action. Without this resource-based policy, the receiver account's event bus will deny all incoming event requests from other accounts, which is the most likely reason the events are not being processed.

Why Incorrect

A. Interface VPC endpoints are only necessary for resources within a VPC to communicate with EventBridge privately, not a general requirement for cross-account event delivery.
B. EventBridge fully supports routing events to a target event bus in a different AWS Region. The scenario describes a valid cross-region architecture.
D. The rule's event pattern in the receiving account filters events after they have successfully arrived on the bus. The core issue is the event failing to arrive due to a permissions denial.

References

1. AWS Documentation, Amazon EventBridge User Guide, "Sending and receiving Amazon EventBridge events between AWS accounts": This section explicitly states the requirement for a resource-based policy on the receiving event bus. It clarifies: "To receive events from another account, you must edit the permissions for the event bus in your account... The policy grants permission to the other account to send events to the event bus in your account." It also provides example policies.

2. AWS Documentation, Amazon EventBridge User Guide, "Resource-based policies for Amazon EventBridge": This page details the structure and use of resource-based policies. It states, "To send events to an event bus in another account, you need to configure a resource-based policy that is attached to that event bus."

3. AWS Documentation, Amazon EventBridge User Guide, "Routing events to a different Region": This section confirms that cross-region event routing is a supported feature. It states, "You can create a rule that sends events to an event bus in a different Region. To do this, specify the event bus ARN in the other Region as the target of the rule." This directly refutes the claim in option B.

Question breakdown

Tests: Configure cross-account and cross-Region event routing with Amazon EventBridge
Difficulty: Medium

Key idea: Cross-account delivery to an EventBridge bus requires a resource-based policy on the target bus that allows events:PutEvents from the sender accounts or organization.

How to reach the answer

The sender side is configured: rules exist and IAM roles allow PutEvents on the target bus.
Nothing is stated about the receiver bus permissions, which is the missing half of cross-account access.
Cross-Region bus targets are supported, and VPC endpoints are not required for this flow.
A missing account field in the event pattern does not block delivery, because pattern filtering happens after events arrive.
Adding a bus policy, for example using aws:PrincipalOrgID, fixes delivery.

Each option

AIncorrect. Interface endpoints are only for private access from within a VPC and are not needed for bus-to-bus delivery.
BIncorrect. EventBridge supports sending events to an event bus in another Region, and the Lambda function is invoked locally in us-west-2.
CCorrect. Without a resource-based policy granting PutEvents to the sender accounts, the receiver bus rejects the cross-account events.
DIncorrect. Omitting the account field makes the pattern match events from any account, so it does not cause the failure.

Common trap: Option B tempts people who assume EventBridge cannot cross Regions, but cross-Region bus targets are supported; the missing piece is the receiver-side permission.

In practice: Central security or operations accounts aggregate events from every member account by attaching an organization-scoped policy to a central event bus.

Remember: Cross-account EventBridge needs permissions on both sides: an IAM role in the sender and a resource policy on the receiving bus.

Official documentation: Sending and receiving events between AWS accounts in Amazon EventBridge · Permissions for event buses in Amazon EventBridge

Open this question on its own page

Domain Reliability and Business Continuity

A global gaming company is preparing to launch a new game on AWS. The game runs in multiple AWS Regions on a fleet of Amazon EC2 instances. The instances are in an Auto Scaling group behind an Application Load Balancer (ALB) in each Region. The company plans to use Amazon Route 53 for DNS services. The DNS configuration must direct users to the Region that is closest to them and must provide automated failover. Which combination of steps should a CloudOps engineer take to configure Route 53 to meet these requirements? (Select TWO.)

Answer options

Correct Answer:

A, D

Explanation

To meet the requirement of directing users to the closest AWS Region, Amazon Route 53 geoproximity routing is the appropriate policy. This policy routes traffic based on the geographic location of both the users and the configured AWS resources, effectively sending users to the nearest endpoint. For automated failover, Route 53 must be able to determine the health of each regional endpoint. The most reliable method in this architecture is to monitor the Application Load Balancer (ALB) in each region. A CloudWatch alarm can be configured to trigger if the ALB becomes unhealthy (e.g., the HealthyHostCount metric drops below a threshold). A Route 53 health check can then monitor the state of this CloudWatch alarm, allowing Route 53 to automatically stop sending traffic to an unhealthy region.

Why Incorrect

B. Monitoring individual EC2 instances is less effective than monitoring the ALB, which provides an aggregated health status for the entire fleet of instances in that region.
C. Route 53 health checkers operate from the public internet and cannot reach private IP addresses of EC2 instances. Also, a single instance's health doesn't represent the region's availability.
E. Simple routing does not support routing based on user location. The description of specifying continent and country applies to geolocation routing, not simple routing, making the option incorrect.

References

1. Amazon Route 53 Developer Guide - Geoproximity routing: "Geoproximity routing lets Amazon Route 53 route traffic to your resources based on the geographic location of your users and your resources." This directly supports using geoproximity to route users to the closest region.

Source: AWS Documentation

Amazon Route 53 Developer Guide

"Choosing a routing policy

" section "Geoproximity routing."

2. Amazon Route 53 Developer Guide - Health checks that monitor a CloudWatch alarm: "You can create a health check that monitors a CloudWatch alarm... For example

you can create a CloudWatch alarm that monitors the status of an Application Load Balancer..." This confirms that monitoring an ALB's health via a CloudWatch alarm is a supported and recommended pattern for Route 53 health checks.

Source: AWS Documentation

Amazon Route 53 Developer Guide

"How Amazon Route 53 determines whether a health check is healthy

" section "Health checks that monitor a CloudWatch alarm."

3. Amazon Route 53 Developer Guide - Configuring DNS failover: "Route 53 health checks monitor the health of your resources... When a resource becomes unavailable

Route 53 can detect that and stop including the corresponding resource record when responding to DNS queries." This explains the mechanism for automated failover.

Source: AWS Documentation

Amazon Route 53 Developer Guide

"Concepts

" section "Health checks and DNS failover."

4. Elastic Load Balancing User Guide - Health checks for your Target Groups: "The load balancer periodically sends requests to its registered targets to test their status... The load balancer routes requests only to the healthy targets." The ALB's health status is an aggregate of its targets

making it the ideal metric for regional health.

Source: AWS Documentation

Elastic Load Balancing User Guide for Application Load Balancers

"Target Groups for Your Application Load Balancers

" section "Health checks for your target groups."

Question breakdown

Tests: Configure Route 53 routing policies and health-check-based failover
Difficulty: Medium

Key idea: Geoproximity routing sends users to the nearest Region, and a health check tied to a CloudWatch alarm on each ALB removes an unhealthy Region from DNS answers.

How to reach the answer

Two needs are stated: route to the closest Region, and fail over automatically.
For 'closest Region', geoproximity routes on user and resource location. Simple routing has no location awareness.
For failover, the ALB is the regional entry point and reflects the health of the whole fleet behind it.
A CloudWatch alarm on an ALB metric such as HealthyHostCount can drive a Route 53 health check.
Private IP checks cannot work because Route 53 health checkers run from the internet.

Each option

ACorrect. A Route 53 health check that tracks a CloudWatch alarm on each Region's ALB gives Route 53 a Region-level signal for automated failover.
BIncorrect. Alarms on individual instances in a scaling fleet do not represent the Region's overall availability the way the ALB does.
CIncorrect. Route 53 health checkers cannot reach private IP addresses, and one instance does not represent the Region's health.
DCorrect. Geoproximity routing directs each user to the Region whose resources are geographically closest.
EIncorrect. Simple routing has no location-based logic; continent, country and state settings belong to geolocation routing.

Common trap: Option B looks equivalent to A, but in an Auto Scaling fleet the ALB is the correct aggregated health signal, not individual instances.

In practice: Multi-Region active-active applications commonly pair a location-aware routing policy with health checks on the regional load balancer. This lets DNS steer users away from a failed Region.

Remember: Health-check the regional entry point (the ALB), not individual or private instances, and pick a routing policy that matches the 'closest' requirement.

Official documentation: Geoproximity routing · Configuring DNS failover

Open this question on its own page

Domain Deployment, Provisioning, and Automation

A company's AWS accounts are in an organization in AWS Organizations. The organization has all features enabled. The accounts use Amazon EC2 instances to host applications. The company manages the EC2 instances manually by using the AWS Management Console. The company applies updates to the EC2 instances by using an SSH connection to each EC2 instance. The company needs a solution that uses AWS Systems Manager to manage all the organization's current and future EC2 instances. The latest version of Systems Manager Agent (SSM Agent) is running on the EC2 instances. Which solution will meet these requirements?

Answer options

Correct Answer:

Explanation

AWS Systems Manager Quick Setup is designed to simplify the configuration of Systems Manager and other services across an entire AWS Organization. By using the "Default Host Management Configuration" from the organization's management account, an administrator can automate the deployment of the necessary IAM roles and configurations to all member accounts and specified Regions. This is achieved through the use of AWS CloudFormation StackSets, which Quick Setup manages automatically. This approach ensures that all current and future EC2 instances in the organization are configured for Systems Manager, meeting the requirements for a scalable, organization-wide management solution.

Why Incorrect

B: AWS Systems Manager Run Command executes scripts on managed instances; it cannot be used to modify IAM policies or roles, which are account-level resources managed through the IAM service. C: This describes a manual and incorrect way of using AWS CloudFormation StackSets. The "Default Host Management Configuration" is a pre-packaged Quick Setup configuration, not a parameter you define in a custom template. D: This solution is incomplete. While creating an instance profile with the correct policy via a StackSet is a valid step, it does not attach the profile to existing or future instances, nor does it configure Systems Manager services like patching or inventory.

References

1. AWS Systems Manager User Guide, "AWS Systems Manager Quick Setup": This section states, "Quick Setup... helps you quickly configure frequently used AWS services and features with recommended best practices... You can use Quick Setup in an individual AWS account or across multiple AWS accounts and AWS Regions by integrating with AWS Organizations." This supports using Quick Setup for an organization-wide deployment.

2. AWS Systems Manager User Guide, "Quick Setup Host Management": This page details the "Default Host Management Configuration" option. It specifies that this configuration "deploys the AWS-SystemsManager-EC2-SSM-Ready-Role IAM instance profile to your accounts and Regions" and configures instances for core Systems Manager capabilities like inventory, patch scanning, and agent updates. This confirms that Option A provides a complete solution.

3. AWS Systems Manager User Guide, "Setting up Systems Manager for multi-account and multi-Region environments": This section explicitly recommends Quick Setup as the method for configuring Systems Manager across an organization. It notes, "We recommend that you use Quick Setup... to configure your instances for Systems Manager... Quick Setup uses AWS CloudFormation StackSets to create the required IAM instance profile role and configure your instances." This directly validates the approach in Option A.

Question breakdown

Tests: Enable Systems Manager management across an AWS Organization
Difficulty: Medium

Key idea: Deploying Default Host Management Configuration through Quick Setup from the management account makes EC2 instances in all current and future member accounts managed by Systems Manager, without editing instance profiles.

How to reach the answer

The clues are 'all current and future EC2 instances' across an organization with all features enabled.
Default Host Management Configuration (DHMC) lets SSM Agent connect using a service-level role, so no per-instance profile changes are needed.
Quick Setup integrates with Organizations and uses StackSets to push the configuration to member accounts and Regions.
Quick Setup requires a home Region to be set in the management account first.
Custom StackSets or Run Command approaches are either incomplete or technically invalid.

Each option

ACorrect. Quick Setup DHMC from the management account applies to the whole organization, including accounts added later.
BIncorrect. Run Command runs commands on instances and is not the mechanism for attaching IAM policies; AmazonSSMServiceRolePolicy is also the wrong policy for instances.
CIncorrect. DHMC is enabled through the Systems Manager service setting and role, not through a parameter defined in a custom stack set.
DIncorrect. Creating an instance profile does not attach it to existing or future instances, so those instances would not become managed.

Common trap: Option D seems sensible because that policy is the right one for SSM, but an unattached instance profile does nothing for the instances.

In practice: Teams moving from SSH-based administration to Session Manager and Patch Manager use DHMC through Quick Setup to bring every account under management in one step.

Remember: For organization-wide Systems Manager onboarding, deploy DHMC with Quick Setup from the management account.

Official documentation: AWS Systems Manager Quick Setup · Configure Default Host Management Configuration with Quick Setup

Open this question on its own page

Domain Cost and Performance Optimization

Optimization] A company uses an Amazon Simple Queue Service (Amazon SQS) queue and Amazon EC2 instances in an Auto Scaling group with target tracking for a web application. The company collects the ASGAverageNetworkIn metric but notices that instances do not scale fast enough during peak traffic. There are a large number of SQS messages accumulating in the queue. A CloudOps engineer must reduce the number of SQS messages during peak periods. Which solution will meet this requirement?

Answer options

Correct Answer:

Explanation

The core issue is that the Auto Scaling group (ASG) is scaling based on network input (ASGAverageNetworkIn), which is not a direct measure of the application's workload backlog residing in the SQS queue. The most effective way to scale a fleet of workers processing messages from an SQS queue is to scale based on the number of messages waiting to be processed. The recommended AWS pattern for this scenario is to use a target tracking scaling policy with a custom metric. This custom metric is created using Amazon CloudWatch metric math to calculate the backlog per instance (ApproximateNumberOfMessagesVisible / GroupInServiceInstances). This ensures that the ASG adds or removes instances to keep the backlog per instance at a target value, directly aligning scaling actions with the actual workload.

Why Incorrect

A. The ApproximateNumberOfMessagesDelayed metric tracks messages intentionally delayed using a timer, not the active backlog of messages ready for processing. The correct metric for the backlog is ApproximateNumberOfMessagesVisible.
C. Step scaling is a valid scaling policy, but it does not solve the fundamental problem of using an inappropriate metric (ASGAverageNetworkIn) as the scaling trigger. The trigger itself must be changed first.
D. Simple scaling is an outdated policy type that is generally not recommended. It has a cooldown period that can hinder responsiveness, and like step scaling, it doesn't fix the core issue of using the wrong metric.

References

1. AWS Documentation - Scaling based on Amazon SQS: This official guide explicitly details the solution. It states

"To use an SQS queue as a scaling metric for your Auto Scaling group

create a CloudWatch metric that captures the SQS queue's backlog... Then

create a target tracking scaling policy that configures your Auto Scaling group to scale based on the custom metric." It provides the exact metric math formula: ApproximateNumberOfMessagesVisible / GroupInServiceInstances.

Source: Amazon EC2 Auto Scaling User Guide

"Scaling based on Amazon SQS".

2. AWS Documentation - Target tracking scaling policies: This document explains the mechanism of target tracking and its benefits. It notes

"With target tracking scaling policies

you select a scaling metric and set a target value... For example

you can configure a target tracking scaling policy to keep the average number of messages in your SQS queue per EC2 instance at 100."

Source: Amazon EC2 Auto Scaling User Guide

"Target tracking scaling policies for Amazon EC2 Auto Scaling".

3. AWS Documentation - Using metric math: This document describes how to create new time series by applying mathematical expressions to existing CloudWatch metrics

which is the technique required for this solution.

Source: Amazon CloudWatch User Guide

"Using metric math".

Question breakdown

Tests: Choose an appropriate scaling metric for queue-based workloads
Difficulty: Medium

Key idea: Workers that consume from SQS should scale on backlog per instance, calculated with metric math as visible messages divided by in-service instances, and used in a target tracking policy.

How to reach the answer

The symptom is a growing SQS queue while the group scales on network input.
The root cause is the scaling metric, which does not reflect the queued work.
Backlog per instance (ApproximateNumberOfMessagesVisible / GroupInServiceInstances) measures the real workload.
Target tracking can use a metric math expression directly, so it adjusts capacity to hold the backlog at a target value.
Changing only the policy type (step or simple) leaves the wrong metric in place.

Each option

AIncorrect. ApproximateNumberOfMessagesDelayed counts messages held back by delay settings, not messages waiting to be processed.
BCorrect. Metric math backlog per instance in target tracking ties capacity directly to queue depth.
CIncorrect. Step scaling changes how the group responds, not what metric drives it, so the mismatch remains.
DIncorrect. Simple scaling has the same metric problem and waits for cooldowns, so it responds more slowly.

Common trap: Option A names an SQS metric and looks queue-aware, but 'Delayed' is the wrong metric; the backlog is the visible messages.

In practice: Batch and worker fleets that drain SQS queues are routinely scaled on backlog per instance, so processing keeps up during traffic spikes.

Remember: Scale SQS consumers on ApproximateNumberOfMessagesVisible divided by in-service instances, using target tracking.

Official documentation: Scaling policy based on Amazon SQS · Target tracking scaling policies for Amazon EC2 Auto Scaling

Open this question on its own page

Domain Security and Compliance

A multinational company uses an organization in AWS Organizations to manage over 200 member accounts across multiple AWS Regions. The company must ensure that all AWS resources meet specific security requirements. The company must not deploy any EC2 instances in the ap-southeast-2 Region. The company must completely block root user actions in all member accounts. The company must prevent any user from deleting AWS CloudTrail logs, including administrators. The company requires a centrally managed solution that the company can automatically apply to all existing and future accounts. Which solution will meet these requirements?

Answer options

Correct Answer:

Explanation

AWS Control Tower is a service designed to establish and govern a secure, multi-account AWS environment. It uses preventive guardrails, which are implemented as Service Control Policies (SCPs), to enforce policies across all accounts in an organization. The "Region deny control" is a specific Control Tower feature that uses an SCP to restrict access to specified AWS Regions, meeting the requirement to block EC2 deployments in ap-southeast-2. SCPs are the only mechanism that can restrict permissions for the account root user, thereby meeting the requirement to block root user actions. An SCP can also be configured to deny actions like cloudtrail:DeleteTrail for all principals, including administrators, thus protecting the logs. This solution is centrally managed and automatically applied to new accounts created via the Control Tower account factory.

Why Incorrect

A. AWS Config is a detective, not a preventive, control. You cannot attach IAM permissions boundaries to the account root user to restrict its permissions.
B. AWS Security Hub is a security posture management service that aggregates findings; it is primarily a detective tool and does not prevent actions from occurring.
D. AWS Firewall Manager is used for centrally managing firewall rules (e.g., WAF, Security Groups), not for restricting EC2 deployments by region or limiting root user actions.

References

1. AWS Control Tower Documentation, "Region deny control": This document explains the Region deny control feature. It states, "The Region deny control... helps you restrict access to AWS Regions... This control is implemented using a service control policy (SCP)."

2. AWS Organizations User Guide, "Service control policies (SCPs)": This guide clarifies how SCPs work. It states, "SCPs are a type of organization policy that you can use to manage permissions in your organization... SCPs affect all IAM entities (users and roles), including the root user, in a member account."

3. AWS Organizations User Guide, "SCP examples": This section provides examples of SCPs. The example "Prevent member accounts from leaving the organization" demonstrates denying an action (organizations:LeaveOrganization) for all principals, a principle that can be applied to deny cloudtrail:DeleteTrail or all actions for the root user.

4. AWS Control Tower User Guide, "How AWS Control Tower works": This guide describes the overall function. It explains, "When you create a new account with Account Factory, the account is enrolled automatically in AWS Control Tower, and the guardrails are applied to the account." This confirms the solution applies to existing and future accounts.

Question breakdown

Tests: Apply preventive multi-account guardrails with Control Tower and SCPs
Difficulty: Medium

Key idea: SCPs, applied directly or through Control Tower controls, are preventive guardrails that restrict every principal in member accounts, including the root user and administrators.

How to reach the answer

Each requirement uses preventive wording: must not deploy, completely block, prevent deletion.
Detective services (Config, Security Hub) only report or remediate after the fact.
Only SCPs can limit the member account root user and deny actions to administrators.
Control Tower applies SCP-based controls, including Region deny, centrally and to new accounts enrolled through Account Factory.
Firewall Manager handles network and WAF policies, not Region or root restrictions.

Each option

AIncorrect. Config is detective, and permissions boundaries cannot be applied to the root user.
BIncorrect. Security Hub aggregates and evaluates findings; it cannot block actions before they happen.
CCorrect. Control Tower with Region deny controls and SCPs gives central, preventive enforcement on existing and future accounts, including root.
DIncorrect. Firewall Manager manages firewall-type policies, and Config conformance packs only detect violations.

Common trap: Config or Security Hub with automated remediation sounds like enforcement, but it reacts after a violation instead of preventing it.

In practice: Landing zones commonly use SCPs to deny unused Regions, restrict the root user, and protect CloudTrail from tampering across every account.

Remember: When the requirement is to prevent actions organization-wide, even for root or admins, use SCPs, usually through Control Tower.

Official documentation: Service control policies (SCPs) · What is AWS Control Tower?

Open this question on its own page

Domain Deployment, Provisioning, and Automation

A company runs a website on Amazon EC2 instances. Users can upload images to an Amazon S3 bucket and publish the images to the website. The company wants to deploy a serverless image- processing application that uses an AWS Lambda function to resize the uploaded images. The company's development team has created the Lambda function. A CloudOps engineer must implement a solution to invoke the Lambda function when users upload new images to the S3 bucket. Which solution will meet this requirement?

Answer options

Correct Answer:

Explanation

The most direct and efficient method to meet the requirement is to use Amazon S3 Event Notifications. This feature is designed to enable event-driven computing by sending a notification to a destination when a specific event, such as an object creation (s3:ObjectCreated:), occurs in an S3 bucket. AWS Lambda is a natively supported destination for these notifications. Configuring an S3 event notification to target the Lambda function creates a direct, serverless invocation pattern without unnecessary intermediate services, providing a low-latency and cost-effective solution.

Why Incorrect

A. This is a valid but indirect pattern. It introduces an unnecessary component (SNS), adding latency and complexity compared to the direct S3-to-Lambda invocation.
B. Amazon CloudWatch Alarms are used to trigger actions based on metrics crossing a defined threshold, not for discrete events like an object upload.
D. This is also a valid but indirect pattern. While useful for decoupling and throttling, adding an SQS queue is not required for the simple invocation described. ---

References

1. AWS Lambda Developer Guide: In the section "Using AWS Lambda with Amazon S3," the documentation states, "You can use Amazon S3 to trigger a Lambda function to process object-created events. You can configure the S3 trigger in the Lambda console to create an S3 event notification that invokes your function." This confirms the direct integration. (Source: AWS Lambda Developer Guide, "Using AWS Lambda with Amazon S3").

2. Amazon S3 User Guide: The documentation on "Amazon S3 Event Notifications" lists the supported destinations for events. It explicitly includes "AWS Lambda function" as a destination. This highlights that a direct invocation is the intended design pattern. (Source: Amazon S3 User Guide, "Amazon S3 Event Notifications," section "Event notification destinations").

3. Amazon S3 User Guide: The guide further details the process in "Walkthrough: Using an S3 trigger to invoke a Lambda function." This walkthrough provides a step-by-step implementation of the exact scenario described in the question, reinforcing that S3 Event Notifications are the correct mechanism. (Source: Amazon S3 User Guide, "Tutorials and examples," section "Walkthrough: Using an S3 trigger to invoke a Lambda function").

4. Amazon CloudWatch User Guide: The documentation for "Using Amazon CloudWatch alarms" specifies that "You can create an alarm that watches a single CloudWatch metric... The alarm performs one or more actions based on the value of the metric... relative to a threshold over a number of time periods." This confirms alarms are for metric-based state changes, not event-based triggers. (Source: Amazon CloudWatch User Guide, "Using Amazon CloudWatch alarms").

Question breakdown

Tests: Implement event-driven invocation from Amazon S3
Difficulty: Easy

Key idea: S3 Event Notifications can invoke a Lambda function directly on object-created events, with no intermediary service required.

How to reach the answer

The trigger is an object upload to an S3 bucket.
S3 Event Notifications support Lambda as a native destination for s3:ObjectCreated events.
SNS or SQS would only help if fan-out or buffering were required, and neither is mentioned.
CloudWatch alarms respond to metric thresholds, not individual object events.

Each option

AIncorrect. SNS can be placed in the path, but it still needs S3 notifications as the source and adds an unneeded hop.
BIncorrect. CloudWatch alarms evaluate metric thresholds and do not fire on individual object uploads.
CCorrect. S3 Event Notifications invoke the Lambda function directly when new objects are created.
DIncorrect. An SQS queue adds buffering that the requirement does not call for and still depends on S3 notifications to receive events.

Common trap: SNS and SQS are familiar decoupling services, so they seem necessary, but S3 can call Lambda directly.

In practice: Thumbnail generation, file validation and metadata extraction pipelines are commonly built on S3 notifications that trigger Lambda, optionally filtered by prefix or suffix.

Remember: For 'run code when an object is uploaded', configure an S3 Event Notification with Lambda as the destination.

Official documentation: Process Amazon S3 event notifications with Lambda · Amazon S3 Event Notifications

Open this question on its own page

Question 1 of 10

Browse AWS exams

About the exam

SOA-C03 exam at a glance

Key facts for the AWS Certified CloudOps Engineer - Associate exam, taken from the official exam page.

Exam code	SOA-C03
Number of questions	65
Time allowed	130 minutes
Passing score	720
Question types	Either multiple choice or multiple response
Exam price	150 USD
Delivery	Pearson VUE testing center or online proctored exam
Languages	English, Japanese, Korean, and Simplified Chinese
Validity and renewal	This certification is valid for 3 years.
Version status	The Simplified Chinese and Korean versions will be retired after November 19, 2026.

Source: official SOA-C03 exam page. Verified October 6, 2026. Prices and policies can change, so confirm with the provider before booking.

Exam objectives

What the SOA-C03 exam covers

The SOA-C03 exam is organized into 5 official domains. Weight shows the share of the exam each domain represents, so spend your study time in proportion.

Monitoring, Logging, Analysis, Remediation, and Performance Optimization 22%
Reliability and Business Continuity 22%
Deployment, Provisioning, and Automation 22%
Security and Compliance 16%
Networking and Content Delivery 18%

Domains and weights from the official SOA-C03 exam outline.

Quick answers

SOA-C03 exam FAQ

How many questions are on the SOA-C03 exam?

The SOA-C03 exam has 65 questions and gives you 130 minutes to finish. Question types include either multiple choice or multiple response.

What is the passing score for SOA-C03?

You need 720 to pass the AWS Certified CloudOps Engineer - Associate exam.

How much does the SOA-C03 exam cost?

The SOA-C03 exam costs 150 USD. Check the official exam page for the price in your country.

How long is the SOA-C03 certification valid?

This certification is valid for 3 years.

Study resources

SOA-C03 study guides and comparisons

Go deeper than the practice questions: certification comparisons, study plans, and career context for SOA-C03.

All guides

IT Certification Comparisons · 25 min read AWS SOA-C03 vs SOA-C02: Everything That Changed When SysOps Became CloudOps Engineer (2025/2026 Complete Guide) Read the guide

Cloud Certifications · 13 min read AWS Advanced Networking Specialty Is Retiring: What to Do Before December 31 (and Where AWS’s New “Maintain” Option Fits) Read the guide

Source context

How this practice set is maintained

Maintained by the CertMage content team, this page loads questions from the exam dataset connected to its preparation resource. When an answer includes a supporting reference, it is shown with that answer so you can review the underlying vendor documentation.

Certification objectives, interfaces, and vendor services can change. Verify important details against the provider's current exam guide and documentation before your exam.

Reviewed by David Mercer AZ-104, AZ-305, AWS SAA-C03, GCP Professional Cloud Architect, DP-900

How many questions are on the SOA-C03 exam?

What is the passing score for SOA-C03?

How much does the SOA-C03 exam cost?

How long is the SOA-C03 certification valid?

How this practice set is maintained

AWS Certified Solutions Architect – Associate

AWS Certified Cloud Practitioner

AWS Certified Generative AI Developer – Professional

AWS Certified AI Practitioner

AWS Certified Solutions Architect – Professional

AWS Certified Security – Specialty