Amazon AWS Certified CloudOps Engineer - Associate SOA-C03 Exam Questions

Answer : A

According to the AWS Cloud Operations and Database Reliability documentation, Amazon RDS Multi-AZ deployments provide high availability and automatic failover by maintaining a synchronous standby replica in a different Availability Zone.

In the event of instance failure, planned maintenance, or Availability Zone outage, Amazon RDS automatically promotes the standby to primary with minimal downtime (typically less than 60 seconds). The failover is transparent to applications because the DB endpoint remains the same.

By contrast, read replicas (Option B) are asynchronous and do not provide automated failover. Auto Scaling (Option C) applies to EC2, not RDS. RDS Proxy (Option D) improves connection management but does not add redundancy.

Thus, Option A --- converting the RDS instance into a Multi-AZ deployment --- delivers the required high availability and business continuity with minimal operational effort.

Answer : D

Comprehensive and Detailed Explanation From Exact Extract of AWS CloudOps Documents:

The requirement is to fix performance degradation from predictable peak CPU load without service disruptions. The most reliable and operationally standard approach is horizontal scaling with an Auto Scaling group driven by CloudWatch metrics/alarms (or target tracking). Launching additional instances and distributing traffic (typically behind a load balancer) increases capacity while keeping existing instances serving requests---no reboot or stop/start required.

Option D meets the requirement because Auto Scaling can add capacity when CPU exceeds a threshold and remove capacity when demand falls. This improves performance during peak periods and maintains availability. It is also operationally efficient: scaling actions are automated, consistent, and can be tuned with cooldowns/health checks.

Options A and C describe vertical scaling (instance resize). Resizing an EC2 instance type generally requires stopping the instance, changing the type, and starting it again---this is disruptive for a single-instance web server and often causes downtime. Option B (restarting the application) directly introduces disruption and does not address underlying capacity constraints; it can also worsen customer impact during peaks.

Amazon EC2 Auto Scaling User Guide -- Scaling policies and CloudWatch integration

Amazon CloudWatch User Guide -- Alarms triggering Auto Scaling actions

AWS Well-Architected Framework -- Performance Efficiency and Reliability guidance

Answer : B

An Application Load Balancer (ALB) operates at Layer 7 (HTTP/HTTPS) and supports advanced routing features, including HTTP-to-HTTPS redirection. To meet the requirement of protecting traffic with ACM certificates and automatically redirecting HTTP requests, the ALB must be configured with two listeners.

The correct design is to create an HTTP listener on port 80 and an HTTPS listener on port 443. The SSL/TLS certificate from AWS Certificate Manager is attached to the HTTPS listener. A listener rule on port 80 redirects incoming HTTP requests to HTTPS on port 443, ensuring all client connections are encrypted.

Option A is invalid because HTTPS cannot operate on port 80. Option C uses TCP listeners, which do not support HTTP-level redirects. Option D uses a Network Load Balancer, which operates at Layer 4 and does not support HTTP redirects.

Therefore, Option B is the only solution that satisfies all requirements using AWS-native features with minimal complexity.

Answer : A

Network ACLs are stateless, meaning both inbound and outbound rules must explicitly allow traffic. While inbound HTTP traffic (port 80) was allowed, the return traffic from the EC2 instance uses ephemeral ports (typically 1024--65535). If outbound rules do not allow this ephemeral port range, the response traffic is dropped, preventing the website from loading.

Security groups are stateful and automatically allow return traffic, but network ACLs do not. This commonly causes connectivity issues when custom ACLs are applied without matching outbound rules.

Option B is incorrect because security groups allow all outbound traffic by default. Option C is irrelevant. Option D is incorrect because only one network ACL can be associated with a subnet at a time.

Thus, the missing outbound ephemeral port rule in the network ACL is the root cause.

Answer : D

Each subnet in a VPC has a fixed CIDR range that determines how many private IP addresses are available. AWS reserves five IP addresses per subnet, reducing the usable address count. Once the available IP addresses are exhausted, no more instances can be launched in that subnet.

AWS does not allow changing the CIDR block of an existing subnet. Therefore, Option A is invalid. Option B does not increase the number of IP addresses; Availability Zones are properties of subnets, not expansions of their CIDR ranges. Option C is incorrect because Elastic IP addresses are public IPs and do not increase the number of private IP addresses available in a subnet.

The only viable solution is to create a new subnet with a larger or additional CIDR range and deploy additional EC2 instances there. This approach aligns with AWS VPC design principles and is the standard method for handling IP exhaustion.

Answer : C

Per the AWS Cloud Operations and EventBridge documentation, when events are sent across AWS accounts --- particularly from multiple accounts in an AWS Organization --- the target event bus in the receiver account must include a resource-based policy that explicitly allows events:PutEvents API calls from the sender accounts or the organization ID.

Even if the sender accounts have IAM permissions to call PutEvents, the receiving event bus must trust those accounts via a resource policy. Without this configuration, EventBridge automatically rejects incoming cross-account events, and those events never reach the target Lambda function for processing.

AWS guidance states that ''Cross-account event delivery requires a resource-based policy on the event bus that grants permissions to the source accounts or organization.'' The policy can include either individual AWS account IDs or the organization's root ID.

In this scenario, because the events originate from multiple accounts and there is no resource policy on the target event bus to authorize those sender accounts, the events are not delivered.

Therefore, the correct cause is C -- the resource-based policy on the target event bus must be modified to allow PutEvents API calls from the sender accounts.

Answer : D

According to the AWS Cloud Operations and Deployment documentation, EC2 Image Builder is the AWS-managed service for automating the creation, maintenance, validation, and deployment of secure and compliant Amazon Machine Images (AMIs).

It allows CloudOps teams to define image pipelines that include only approved software modules and configuration scripts. EC2 Image Builder automatically tests and verifies these AMIs for compliance before deployment.

This process ensures configuration consistency, eliminates manual installation errors, and simplifies ongoing patch management. The service integrates with AWS Systems Manager, Amazon Inspector, and AWS CloudFormation for end-to-end automation.

In contrast:

Amazon Detective and GuardDuty (Options A & B) are security monitoring tools, not image management solutions.

Run Command (Option C) applies ad-hoc updates but does not create standard, reusable AMIs.

Therefore, Option D is correct---EC2 Image Builder provides the most operationally efficient and compliant way to create an approved baseline AMI for future deployments.