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

The AWS CLI reaches higher S3 PUT throughput by uploading multiple parts concurrently. Adding the settings multipart_threshold = 64MB (so the 2 TB object is automatically split) and max_concurrent_requests = 50 (so up to 50 threads transfer parts in parallel) enables dozens of parallel TCP streams, allowing the instance to drive far more bandwidth. Changing the storage class provides no performance benefit, using 5 MB parts adds overhead rather than throughput, and disabling enhanced networking would further reduce, not increase, network speed.

The workload requires only a few hundred IOPS, so the io1 volume is greatly over-provisioned. A gp3 volume delivers a baseline of 3,000 IOPS and 125 MiB/s throughput at any size for a per-GiB price about 20 percent lower than gp2 and far lower than io1, with no per-IOPS charge until the application exceeds the baseline. That performance margin comfortably covers the observed 500-IOPS peak while minimizing cost. Converting to st1 would dramatically limit random I/O to roughly 500 IOPS, risking throttling. Reducing io1 provisioned IOPS still leaves the premium io1 price model in place. Switching to gp2 would work functionally, but gp3 offers the same or better performance at a lower price, making it the most economical option.

The most lightweight solution is to use Amazon EventBridge as the glue between the CloudWatch alarm and Systems Manager. A CloudWatch alarm for MemoryUtilization > 90 percent (5 data points) automatically emits a state-change event on the default event bus. A rule that matches the alarm's change to the ALARM state can target Systems Manager Automation directly. By adding an input transformer, the rule passes the InstanceId dimension from the event payload to the runbook's InstanceId parameter, ensuring that the cache-clearing automation runs only on the affected instance. No Lambda functions, Auto Scaling groups, or Maintenance Windows are required.

A Lambda-based approach functions correctly but adds an extra service to build, secure, and maintain. Auto Scaling and Maintenance Windows either perform the wrong remediation or run on a schedule regardless of the metric state. CloudWatch alarm EC2 actions cannot invoke Automation documents, so they do not satisfy the requirement.

Because network ACLs are stateless, return traffic must be explicitly allowed. The NAT gateway translates the source instance's IP address, but the return traffic from the API (source port 443) must be able to reach the original instance on the ephemeral port it used to initiate the connection (destination ports 1024-65535). If the private subnet's NACL does not allow inbound traffic on this high port range, the connection fails. This rejection is captured by VPC flow logs. Allowing this inbound ephemeral port range on the private subnet's NACL resolves the issue. Attaching an internet gateway would make the instances public, which violates the requirement. Disabling source/destination check is only relevant for NAT instances, not managed NAT gateways. Security groups are stateful, so they automatically allow return traffic for connections initiated by the instance; no inbound rule is needed.

Network ACLs are stateless, so return traffic must be explicitly permitted. When an instance initiates an HTTPS session, the reply from the remote host arrives from source port 443 and is addressed to an ephemeral port (1024-65535) on the instance. Because the inbound rule set does not currently allow that destination port range, the response is dropped, breaking the connection. Adding an inbound rule that allows TCP 1024-65535 from any source permits only the necessary return traffic while leaving other traffic blocked, satisfying the principle of least privilege. Allowing the same range on the outbound side does nothing for inbound return packets, and opening all ports or all protocols is less restrictive than required.

CloudWatch cross-account observability lets you visualize metrics that reside in other AWS accounts without moving data. You designate the monitoring account as a monitoring account and link the prod-01 and prod-02 accounts as source accounts. CloudWatch automatically grants the monitoring account permission to query GetMetricData and ListMetrics in each source account, so the dashboard widgets can reference metrics by specifying the account ID and Region.

To satisfy the security constraint, attach an IAM policy to the developers' role in the monitoring account that allows only cloudwatch:GetDashboard, cloudwatch:ListDashboards, cloudwatch:GetMetricData, and cloudwatch:ListMetrics. The policy omits cloudwatch:PutDashboard, which prevents users from creating, editing, or deleting dashboards.

Options that rely on CloudWatch dashboard snapshots or AWS Resource Access Manager do not allow live cross-account metrics. Exporting metrics to S3 and building a QuickSight dashboard adds unnecessary infrastructure and does not use CloudWatch dashboards, while embedding metrics in Amazon Managed Grafana exceeds the stated scope and cost.

The CloudWatch agent publishes only the metrics that are explicitly listed in the metrics_collected section of its JSON configuration. The current file defines no collectors, so the agent sends no memory or disk data even though it is running. Adding the appropriate collectors (for example, a mem block for memory and a disk block for file-system usage) and then restarting or reloading the agent causes the agent to gather and publish those metrics. Enabling EC2 detailed monitoring affects only the built-in instance metrics (CPU, network, etc.) and cannot add memory or disk metrics. Changing the instance role's permissions or modifying the Systems Manager document does not cause the agent to start collecting additional metrics when they are not specified in the configuration.

Storing the Terraform state in an S3 bucket that has server-side encryption and versioning, while using a DynamoDB table for state locking, satisfies the requirement for a central, collision-free state store. In the pipeline, CodeBuild can assume an account-specific IAM role through AWS STS, so no permanent access keys are exposed. Terraform is initialized with the S3 backend and automatically uses the temporary credentials provided by the assumed role. The other options either lack state locking, rely on insecure long-lived credentials, or misuse services (for example, CodeCommit and CloudFormation are not supported remote backends for Terraform state).

AWS Compute Optimizer analyzes CloudWatch metrics and compares them against instance specifications, then recommends smaller or different instance types that will satisfy observed resource needs at lower cost. Applying the rightsizing recommendation reduces over-provisioned capacity without touching application code or changing the multi-AZ design. Reserved Instances lower the hourly rate but lock in the same oversized m5.4xlarge footprint, so waste remains. Mixing Spot and On-Demand capacity would cut cost but introduces interruption risk and adds operational complexity. Adding a scaling policy still uses the oversized instance type; because utilization rarely exceeds 18 percent, the group will seldom scale in or save meaningful cost. Therefore, enabling Compute Optimizer and acting on its recommendation is the most economical, low-effort solution.

The CloudWatch agent must be used because the standard CloudWatch metrics do not include memory utilization. The AmazonCloudWatch-ManageAgent SSM document can remotely install or update the unified CloudWatch agent on both Linux and Windows instances. When the agent starts, it can pull its JSON configuration from an SSM parameter, allowing administrators to store and edit a single configuration in Systems Manager Parameter Store and apply it across multiple accounts by using Run Command or State Manager. This removes the need to manually place files on every instance.

Using the legacy CloudWatch Logs agent cannot emit memory metrics, and mixing two different agents increases management effort. Storing the configuration locally on each instance still requires manual distribution whenever changes are needed. AWS Config does not collect operating-system metrics, so enabling it would not meet the monitoring requirement.

c5n.9xlarge instances are drop-in replacements for c5.9xlarge but include the "n" network-optimized variant, increasing available bandwidth from 10 Gbps to up to 50 Gbps on Nitro without any additional configuration. Switching the instance type in the launch template is a minimal, low-risk change that immediately satisfies the >20 Gbps requirement.

Cluster placement groups cannot span multiple Availability Zones, so re-architecting the Auto Scaling group to use one would require sacrificing AZ resilience and still would not raise the hard network cap of the c5 instances. Enabling jumbo frames improves efficiency but cannot raise the instance's maximum throughput limit. Elastic Fabric Adapter is designed for HPC and requires a cluster placement group in a single AZ; it does not increase bandwidth across AZs for general TCP traffic and adds operational complexity.

Performance Insights automatically publishes the DBLoad (average active sessions) metric to the AWS/RDS namespace in CloudWatch. A common best practice is to compare DBLoad to the vCPU count; sustained values above the vCPU count indicate CPU saturation. Creating a CloudWatch alarm on the DBLoad metric with a period of 60 seconds, five evaluation periods, and a threshold of 2 (the vCPU count) directly monitors the required condition. CloudWatch alarms can invoke Systems Manager runbooks through alarm actions, so no custom polling or additional services are needed.

The CPUUtilization metric does not measure active sessions and can miss database-specific contention like I/O waits. Building a custom Lambda poller with Enhanced Monitoring adds unnecessary complexity and operational overhead. RDS event subscriptions do not emit events for high DB load; they are for state changes like failures or reboots, so they cannot trigger the runbook for this scenario.

Enabling Container Insights for the EKS cluster is an AWS-managed feature that deploys the CloudWatch agent and Fluent Bit as DaemonSets. The agent sends detailed node, pod, and container metrics to CloudWatch, and Fluent Bit streams application logs to CloudWatch Logs. After the one-time enablement, updates to the agents are handled by AWS, so ongoing maintenance is minimal. The other options do not satisfy the stated constraints:

• Control-plane logging only delivers API server logs; it does not provide container metrics or workload log files.
• Prometheus and Grafana are self-managed and require ongoing patching and scaling, and a custom exporter would still need to be maintained.
• Installing the CloudWatch agent through user-data captures host metrics but not container-level metrics and does not address log collection; it also leaves lifecycle management to the operations team.

The low CPUUtilization combined with a CPUCreditBalance of 0 indicates that the burstable T3 instances are being throttled after depleting their earned CPU credits. Enabling T3 Unlimited lets the instances draw surplus credits, eliminating throttling while keeping the same instance family and size. Surplus credits incur a small additional fee only when used, which is typically cheaper than permanently moving to larger general-purpose instances. Changing scaling policies or using Spot capacity does not address the credit exhaustion, and larger fixed-performance instances remove the throttling but at a higher constant cost.

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 simplest native approach is to use CloudWatch Logs metric filters. A metric filter applied to the ProdTrail log group with the pattern { $.eventName = "DeleteBucket" } turns every matching event into a custom CloudWatch metric. A CloudWatch alarm that monitors this metric with a 1-minute period and one evaluation can change its state almost immediately after a matching log entry appears. Configuring the alarm action to publish to an SNS topic delivers the required email notification. The other choices either do not generate a CloudWatch alarm (EventBridge rule), rely on Insights events that only detect anomalies (CloudTrail Insights), or introduce unnecessary custom code and maintenance (Lambda parser for S3 object events).

A NAT gateway is an AWS-managed, highly available service within a single AZ. If that AZ fails, the gateway becomes unavailable. Best practice is to create a separate NAT gateway in every AZ and configure each private subnet's route table to use the local gateway. This restores internet access during an AZ outage and prevents traffic from crossing AZ boundaries, eliminating inter-AZ data transfer fees. NAT instances add operational overhead and do not provide built-in redundancy; a single gateway cannot survive an AZ failure; and attaching an internet gateway directly to a private subnet is not possible because IGWs must be associated with the VPC as a whole and require public IP addresses on the instances.

CloudWatch alarms can directly invoke several types of predefined actions. When you need an Auto Scaling group to add or remove capacity without any intermediary service, you attach the ARN of an Auto Scaling scaling policy to the alarm. When the alarm transitions into the ALARM state, CloudWatch signals that scaling policy, which immediately updates the group's desired capacity and launches an additional instance. Publishing to an SNS topic and then invoking Lambda introduces extra components and does not satisfy the "no custom code" constraint. Systems Manager Automation documents and EC2 recovery actions are valid alarm actions, but neither changes Auto Scaling group capacity.

AWS Backup provides fully managed, incremental backups of Amazon S3 buckets. By assigning the bucket to a daily backup plan, recovery points are created automatically and stored in a backup vault. The vault can be protected with Vault Lock so that retention rules (for example, 7 years) cannot be altered, delivering immutability. The service also offers console-based, point-in-time restores and central policy management. Versioning with lifecycle rules, cross-region replication, or custom Lambda copy jobs can offer extra copies but do not provide centrally enforced retention, immutable recovery points, or the simplified restore workflow required.

A Route 53 calculated health check can aggregate the status of other Route 53 health checks. By creating one HTTP health check for each microservice's /status endpoint and then creating a calculated health check that is considered healthy when at least one of the three child checks is healthy, the parent check becomes unhealthy only when every microservice is down. Associating this calculated health check with the primary failover record causes Route 53 to direct traffic to the standby stack only after all three microservices have failed.

A single health check against the ALB (choice A) becomes unhealthy if the load balancer itself or any target returns errors, so it can trigger premature failover. Monitoring an ALB CloudWatch metric through a metric-based health check (choice D) requires additional alarms and offers no advantage over using native Route 53 health checks. Configuring a calculated health check that is healthy only when all child checks are healthy (choice C) would mark the primary as unhealthy as soon as one microservice fails, resulting in unnecessary failover.