AWS Certified CloudOps Engineer Associate Practice Test (SOA-C03)

Failover routing is designed specifically for active-passive architectures. You designate one record as PRIMARY and one as SECONDARY and associate a health check with the primary record. While the primary health check is healthy, Route 53 returns only the primary record. If the health check fails, Route 53 automatically returns the secondary record until the primary becomes healthy again. Latency-based, weighted, and geolocation policies can each attach health checks, but they continue to serve traffic according to latency metrics, weight values, or user location, meaning some requests could still go to an unhealthy endpoint. Only the failover policy guarantees an all-or-nothing switch to the standby endpoint.

Amazon RDS Proxy sits between an application and its database and maintains a pool of established connections that can be reused by short-lived clients such as Lambda functions. This dramatically reduces the total number of concurrent database sessions, which in turn lowers memory consumption on the DB instance. RDS Proxy natively supports IAM database authentication, so no credential management changes are required. Upgrading the DB instance class or increasing the max_connections parameter is costlier and only masks the symptom. Adding a read replica does not reduce the write-side connection load, and routing writes to multiple endpoints risks data inconsistency. Caching connection objects in ElastiCache does not help because each Lambda invocation would still create a new TCP session to MySQL. Therefore, creating and using an Amazon RDS Proxy is the most effective and least disruptive solution.

When a target group is created with the default settings, its port is 80 and the health check uses the traffic port. Because the application listens on port 8080, the load balancer's health check requests sent to port 80 receive no response. The load balancer therefore marks every instance as unhealthy and returns HTTP 503 to clients. Changing the target group (and optionally the listener rules) to forward traffic and perform health checks on port 8080 will resolve the issue. The other options do not by themselves prevent a target from passing the health check: the HTTP protocol works across Availability Zones, cross-zone load balancing does not affect health probing, and the default deregistration delay occurs only after a target fails, not before it can become healthy.

Creating a gateway VPC endpoint for Amazon S3 and adding its route to the isolated subnets' route table directs all S3 traffic to the endpoint. The route entry uses the AWS-provided S3 prefix list as the destination and the endpoint ID as the target. Because this route is more specific than the 0.0.0.0/0 NAT route, only S3 traffic is redirected, eliminating NAT data-processing charges while maintaining private connectivity. Pointing the subnets to an internet gateway would expose them publicly. Using an interface endpoint is unnecessary for S3 object access and incurs additional hourly and data charges. An egress-only internet gateway handles only IPv6 traffic and still sends traffic over the public internet, failing to meet the requirement.

A CloudWatch metric alarm can be configured to publish a state-change event automatically to Amazon EventBridge. An EventBridge rule that matches the alarm's ARN when the state transitions to ALARM can invoke an AWS Systems Manager Automation runbook. The runbook uses the Systems Manager agent already running on the instance to restart the application service and reports detailed execution output in the Automation console. This approach is completely managed, needs no custom code or manual SSH access, and keeps all operational data within AWS.

Using an SNS topic with a Lambda function introduces extra components to build and maintain. Auto Scaling policies or EC2 recovery actions do not restart the application process itself and therefore do not address the requirement. CloudTrail cannot trigger Automation directly; it only logs API calls.

The organization trail has already delivered the required management event to the S3 bucket. Amazon Athena can query those log files directly, with only a one-time table creation step and no additional data movement or recurring charges other than the small per-query cost. CloudTrail Event History retains events for only 90 days, so the 6-month-old record is no longer available there. CloudTrail Lake would not contain historical events that occurred before the lake was created and would introduce additional storage costs. Streaming the trail to CloudWatch Logs before performing a Logs Insights search would require new infrastructure and would still not include past events. Therefore, querying the existing logs in S3 with Athena is the simplest and least expensive option.

Amazon FSx for Lustre is designed for compute-intensive, throughput-heavy workloads such as genomics or financial modeling. It provides sub-millisecond latencies, up to hundreds of gigabytes per second of aggregate throughput, and the ability to link to an S3 data repository so data can be imported at start-up and exported on completion. Creating the file system in scratch deployment mode lets the team delete it after each run with no persistent cost or additional management.

FSx for Windows File Server targets Windows SMB workloads and does not integrate directly with S3 or scale to the required throughput. FSx for NetApp ONTAP offers multiprotocol access and caching, but its per-file-system throughput is lower and the added data-management features are unnecessary overhead. Amazon EFS delivers regional durability and elasticity, but even in Provisioned Throughput mode cannot reach hundreds of GB/s and lacks native S3 integration required for efficient import and export.

DynamoDB on-demand capacity mode adapts instantly to traffic changes and can accommodate thousands of requests per second without prior capacity planning. Because it automatically tracks and serves traffic based on the previous high-water mark, it prevents throttling during sudden spikes while scaling back during normal periods, eliminating manual intervention. Raising the maximum auto-scaling limits still incurs the several-minute ramp-up delay inherent to auto scaling, so short-lived spikes may continue to throttle. Adding a global secondary index with the same keys doubles write capacity consumption and does not address the underlying provisioning issue. Enabling DAX improves read latency and off-loads eventually consistent reads, but it does not help with write throttling, so traffic surges would still be limited by write throughput. Therefore, switching the table to on-demand capacity mode is the most effective and operationally simple choice.

Sending S3 ObjectCreated events to an Amazon SQS queue provides durable, at-least-once delivery and effectively buffers sudden traffic spikes. Lambda polls the queue in batches and scales automatically with the backlog. If an invocation fails, the message becomes visible again after the visibility timeout, allowing multiple retry attempts. When the message's receive count exceeds the configured maxReceiveCount, SQS moves it to the dead-letter queue for later analysis, preventing data loss.

Directly invoking Lambda from S3 lacks this buffering and stops after three retries, risking dropped events under high load or persistent errors. Using SNS relies on its built-in retry policy (up to 23 days) but still offers no buffer against concurrency limits and requires additional configuration for a DLQ. EventBridge adds filtering and optional archiving, yet by default drops undelivered events after 24 hours unless a DLQ is configured. SQS therefore remains the simplest and most reliable approach with minimal operational overhead.

Performance Insights automatically publishes the DBLoad metric to Amazon CloudWatch for each DB instance. Creating a standard CloudWatch alarm on that metric with a 1-minute period and a threshold of 8 that must be breached for 5 consecutive datapoints generates an alarm state after five minutes of sustained load. Associating the alarm with an Amazon SNS topic delivers the required notification, and no custom code or non-AWS service is needed.

RDS event subscriptions do not emit a high-load event, so that option cannot alert on DBLoad. An alarm on CPUUtilization might miss database-specific waits and does not directly monitor average active sessions. Polling the Performance Insights API from a Lambda function would work but introduces custom code and ongoing operational overhead, violating the "least administration" constraint.

A single AWS Transit Gateway provides a hub-and-spoke topology that enables transitive routing between any number of attached VPCs. It can be shared across accounts with AWS Resource Access Manager, so each VPC needs only one attachment, greatly reducing the total connections and route entries compared with a VPC-peering mesh or many VPN tunnels. The gateway can later attach to a Direct Connect gateway for on-premises connectivity without redesign. PrivateLink exposes only specific services and does not allow full VPC-to-VPC traffic. Therefore, attaching all VPCs to an AWS Transit Gateway is the most scalable and operationally simple choice.

Applying a stack policy that denies all Update actions on the RDS resource blocks CloudFormation from creating a replacement DB instance. When an update would trigger a Replace action on that resource, CloudFormation detects the policy violation, cancels the operation, and rolls the stack back before it touches other resources. This satisfies the requirement automatically and does not require manual review.

Previewing a change set still relies on a human to cancel execution, so a replacement could proceed by mistake. Setting DeletionPolicy or UpdateReplacePolicy to Retain only preserves the old DB instance after a replacement; it does not stop the replacement from occurring. Creating manual snapshots adds operational overhead and likewise does not prevent replacement.

The recommended pattern for cross-account access is to create a role in the resource-owning account and allow the calling account to assume it. A role in Account B can be given a least-privilege policy that permits only s3:PutObject on the target bucket. Its trust policy lists Account A, so the EC2 instance profile in Account A can assume the role through AWS STS. No long-term keys are stored, and the permissions are scoped to a single operation on one bucket. Creating users with access keys retains long-term credentials. Granting AmazonS3FullAccess to the instance profile violates least-privilege. S3 replication or anonymous writes do not satisfy the requirement or security controls.

Enabling DynamoDB Point-in-Time Recovery (PITR) provides continuous backups that let administrators restore the table to any second in the preceding 35 days. Restores create a new table in minutes, easily meeting a 15-minute RTO without manual backup scheduling or additional infrastructure. Hourly on-demand backups would still leave gaps of up to 59 minutes and would increase storage and API costs. Streaming table updates to S3 and replaying them would require building and operating custom pipelines and would not guarantee the target RTO. Creating a global table offers high availability but does not give the ability to roll back to an arbitrary point in the past; it also incurs additional write-replication costs. Therefore, enabling PITR is the most economical and operationally simple solution.

For failover routing, Route 53 must be able to determine when the primary endpoint is unhealthy. When an alias record targets an ALB, Route 53 can automatically evaluate the load balancer's own health by enabling the Evaluate target health setting. If this flag is set to Yes on the primary failover record, Route 53 monitors the ALB's overall state; when the ALB becomes unhealthy (for example, all targets are unhealthy or the load balancer is unreachable), Route 53 stops returning that record and instead serves the secondary record. Creating an external health check, changing target group ports, or adjusting TTLs does not give Route 53 the information it needs to detect a Regional outage, and cross-zone load balancing affects traffic distribution inside a Region, not DNS failover across Regions.

The error NO_PROPOSAL_CHOSEN indicates that the IKE Phase 1 proposals offered by one peer do not match any proposal accepted by the other. AWS's default Phase 1 parameters for new VPN connections are AES-256 encryption, SHA-256 hashing, and Diffie-Hellman group 14 (2048-bit). After the firmware upgrade, the on-premises firewall is probably proposing a different cipher or DH group, preventing Tunnel 1 from establishing. Aligning its Phase 1 policy with AES-256, SHA-256, and DH 14 allows the proposal exchange to succeed, bringing the tunnel up. Adjusting DPD timers, inside tunnel IP ranges, or enabling NAT-T do not address a proposal mismatch and would leave the tunnel down.

Storing the CloudWatch agent JSON configuration as a Systems Manager Parameter allows a single, centrally managed source of truth. A State Manager association that targets the Auto Scaling group's instance profile can install or update the agent by invoking the AWS-provided AmazonCloudWatch-ManageAgent document and passing the Parameter name. When the association runs at launch or on a schedule, every new or existing instance retrieves the latest configuration, starts the agent, and publishes memory metrics and log files without any manual intervention. Embedding the file in user data or an AMI would require redeployment for every change, and the default EC2 metrics or the older CloudWatch Logs agent cannot publish memory utilization.

Network ACLs are stateless, so return traffic must be explicitly allowed in the opposite direction. When the ALB initiates a connection, it uses an ephemeral source port (1024-65535) and destination port 80 on the instance. The return packets from the instance therefore target the ALB on that same ephemeral port range. The existing outbound rule allows only ports 0-1023, so the responses are dropped. Allowing outbound TCP 1024-65535 to the ALB subnet permits the return traffic while exposing no additional destinations or ports. Adding a broad inbound rule, opening all outbound traffic, or switching to port 443 does not address the missing return-path rule or violates least-privilege principles.

Migrating the database to an Amazon Aurora Serverless v2 PostgreSQL-compatible cluster satisfies every requirement. Aurora Serverless v2 automatically and rapidly adjusts the number of Aurora capacity units in fine-grained increments based on workload, so it can react within seconds to the month-end spike and then scale back when demand subsides. The cluster presents a single writer endpoint, so application connectivity does not change, and billing is based on the capacity actually consumed. Storage Auto Scaling only adds storage, not compute. Manually changing the DB instance class (even through automation) incurs downtime and maintenance effort. Adding read replicas or placing them behind a load balancer can relieve read pressure but does not increase write throughput or CPU capacity on the primary instance, and it introduces replication lag and additional management.

Using a service-managed CloudFormation StackSet that targets the desired OU meets all stated requirements. When trusted access is enabled, CloudFormation automatically assumes the required execution roles in each member account. By enabling the StackSet's auto-deployment feature, CloudFormation automatically creates stack instances in any account that is subsequently moved into or created within the target OU and deletes them if the account leaves the OU. Self-managed StackSets, manual scripts, or CDK pipelines would require manual additions or separate automation each time an account is created, resulting in higher operational overhead.