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

A single DataSync task can use up to 10 Gbps, which is approximately 1.25 GB/s or about 108 TB per day in ideal conditions. Even allowing for protocol overhead, a single agent running at roughly 70 TB per day can move 500 TB in seven days (7 × 70 ≈ 490 TB). Therefore, deploying one on-premises agent and configuring the task to use all available bandwidth is sufficient to meet the timeline while keeping the setup simple. DataSync automatically tracks metadata and can be re-run on a schedule for incremental copies. Adding extra agents or splitting the dataset adds complexity without bypassing the 10 Gbps per-task limit, and S3 Transfer Acceleration is not used by DataSync.

A Metrics Insights query can aggregate the memory-utilization metrics from every instance into one time series, so the engineer needs only one alarm. Using SELECT MAX(mem_used_percent) FROM "CWAgent" with a 60-second period returns the highest utilization observed in each minute. Configuring the alarm with a threshold of 80 and three evaluation periods generates an SNS notification only when any instance breaches the limit for three consecutive minutes. This single alarm is cheaper and simpler than creating individual alarms, building composite alarms, or forwarding every PutMetricData call through EventBridge or log filters.

The initial client connection originates from the EC2 instance, so sg-app must allow egress on the destination port. Because sg-app's outbound rules currently restrict traffic to ports 80 and 443, the SYN packet for MySQL (TCP 3306) is dropped before it ever reaches sg-db. Adding an outbound rule that permits TCP 3306 with sg-db (or its CIDR) as the destination allows the connection to be established, while still limiting other outbound traffic. Opening sg-db to 0.0.0.0/0 or disabling both groups would grant unnecessary access, and adding an inbound rule to sg-app is irrelevant because the instance is the initiator and stateful rules already cover return traffic.

Placing a NAT gateway in each Availability Zone and ensuring that the private subnet in that AZ routes traffic to the local gateway provides resiliency against an AZ outage; if one zone fails, the other zone's NAT gateway continues to operate. This design also avoids the cross-AZ data processing charges that occur when a subnet routes through a NAT gateway in another AZ. A single NAT gateway or NAT instance represents a single point of failure, and locating both gateways in one AZ undermines availability while still incurring cross-AZ traffic costs.

The unified CloudWatch agent can collect both system-level metrics such as memory utilization and application logs like Apache access logs. By storing the agent's JSON configuration centrally in AWS Systems Manager Parameter Store, any change to the configuration can be fetched when the agent starts or is refreshed, so new and existing Auto Scaling instances stay consistent without rebuilding AMIs. Installing the package with the AWS-ConfigureAWSPackage Run Command document and then starting or reloading it with the AmazonCloudWatch-ManageAgent document lets you push the latest configuration fleet-wide. An instance profile that includes AmazonSSMManagedInstanceCore and CloudWatchAgentServerPolicy supplies the necessary permissions, so no static credentials are stored on the servers.

The older CloudWatch Logs agent publishes only logs and would still require custom scripts for memory metrics and a manual update process. Copying logs to Amazon S3 and importing them into CloudWatch Logs does not solve in-guest memory monitoring and adds scripting overhead. Enabling CloudTrail and CloudTrail Insights records management and data-plane API events but cannot collect operating-system metrics or web-server log files. Therefore, the Systems Manager-based deployment of the CloudWatch agent is the lowest-maintenance approach.

Because AWS Config is a service, the safest way to let a Config rule in another account invoke the function is to add a resource-based policy statement to the Lambda function in the owning account. Using the lambda:add-permission API (or the console) adds a statement that names config.amazonaws.com as the principal, grants only the lambda:InvokeFunction action, and scopes the permission to the caller's account with a SourceAccount or SourceArn condition. No new roles are needed in the calling account. The other options either rely on creating or changing roles in account 222222222222, use unsupported sharing mechanisms, or grant the wrong action, so they violate the stated constraints or least-privilege practice.

CloudFormation does not permit changing or deleting an exported value that is being imported by another stack. Because AppStack is still importing the output named DevVpcId, the networking stack cannot update that existing export. The correct remediation is to keep the original export intact and create a new export with a unique name (for example DevVpcIdV2) that contains the new VPC ID. This allows the networking stack update to succeed without disrupting AppStack. The other options do not address the export-name constraint: adding CAPABILITY_NAMED_IAM only affects IAM resources, modifying stack permissions will not bypass the limitation, and enabling rollback protection or termination protection has no impact on export name conflicts.

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).

CloudWatch dashboards can display metrics that reside in another Region or another account without any data replication. Each source account must allow the dashboard account to read its metrics. The documented way is to create an IAM role (any name is allowed) in each source account that trusts the monitoring account, attach a read-only CloudWatch policy, and then reference the remote Region and account ID when you build the widget (for example, account-id:region, namespace, metric-name, dimensions). No resource shares, data exports, or agents are required. The console and PutDashboard API automatically assume the role when rendering the widget, so the dashboard refreshes seamlessly across accounts and Regions. Options suggesting AWS RAM, data replication, or running agents introduce unnecessary complexity and are not required for cross-account, cross-Region dashboards.

CloudTrail Insights analyzes write-management events such as RunInstances. When the RunInstances call rate deviates from the baseline, CloudTrail generates an Insight event whose detail-type is "AWS Insight via CloudTrail" with insightType set to ApiCallRateInsight. EventBridge can match this event and invoke a Lambda target. Enabling CloudTrail Insights plus a single EventBridge rule needs no manual thresholds or extra infrastructure.

Streaming CloudTrail logs to CloudWatch Logs with a metric filter would work but requires hand-tuned thresholds and ongoing maintenance. VPC Flow Logs and Contributor Insights monitor network traffic, not API frequencies. AWS Config evaluates resource configurations on a schedule and cannot track API call rates in near real time. Therefore, CloudTrail Insights with an EventBridge rule is the most operationally efficient choice.

Publishing the API through AWS PrivateLink keeps all traffic on the AWS backbone and removes the need to manage complex routing rules or overlapping CIDRs. The service owner places the API behind a Network Load Balancer and creates a VPC endpoint service. Consumer accounts create interface VPC endpoints in their private subnets; these appear as elastic network interfaces, so no inbound traffic reaches the service VPC directly. VPC peering and Transit Gateway attachments fail the inbound-restriction or CIDR-overlap requirements, and a NAT gateway plus public ALB forces traffic across the public internet and adds needless 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.

An external ID can only be evaluated by AWS STS when an external principal tries to assume a role. S3 bucket policies do not recognize the sts:ExternalId condition key, so the requirement cannot be enforced there. The secure pattern is to replace direct bucket access with a production-side IAM role whose trust policy allows the analytics account to call sts:AssumeRole only when the expected external ID is supplied. The role then carries a permissions policy that grants the minimum s3:GetObject access to the bucket. The analytics workflow assumes the role and uses the temporary credentials to read the objects, satisfying both the security mandate and the functional need. Adding sts:ExternalId to the bucket policy, creating an SCP, or enabling Object Lock would not enforce the requirement or would block legitimate access.

When CPU is identified as the dominant wait dimension, Performance Insights proactive recommendations advise adding compute capacity. Scaling the DB instance class to a larger size (for example, moving from a burstable db.t3.medium to a compute-optimized or general-purpose db.m6g.large) directly increases available vCPUs and memory, reducing CPU saturation. Enlarging storage, creating replicas, or applying patches can help other bottlenecks but do not address immediate CPU exhaustion flagged by the recommendation.

Running the unified CloudWatch agent as its own task with the DAEMON scheduling strategy ensures that one copy of the agent (and optional Fluent Bit container) is launched on every container instance in the cluster. The agent configuration can be stored in AWS Systems Manager Parameter Store, and the task's IAM role needs permissions such as CloudWatchAgentServerPolicy. Because the agent is deployed independently of the application task definitions, no modification of those tasks is required, and every new EC2-based container instance automatically starts collecting and publishing the required metrics and logs.

Embedding the agent as a sidecar in each application task would meet the functional requirement but would require editing every task definition and updating them whenever new services are added. Installing the agent once with user data or by manually updating the ECS agent does not guarantee that future instances receive the agent without additional steps and does not automatically collect container logs. Therefore, deploying the CloudWatch agent as a DAEMON task is the most operationally efficient solution.

Route 53 Resolver query logging can stream logs directly to an Amazon S3 bucket. Each entry includes the query_name plus DNS Firewall fields such as firewall_rule_group_id and firewall_rule_action, demonstrating that the rule evaluated the request. Applying an S3 lifecycle policy moves older objects to S3 Glacier Flexible Retrieval, providing inexpensive five-year retention with no additional infrastructure. Sending logs first to CloudWatch or relying on CloudTrail, VPC Flow Logs, or GuardDuty adds cost or lacks per-query evidence.

The ALB returns a 504 Gateway Timeout when it closes the connection because no response is received from the target before the load balancer's idle timeout elapses. The default idle timeout for an ALB is 60 seconds, which is shorter than the 3- to 4-minute checkout operations. Increasing the idle timeout to exceed the longest expected request duration allows the load balancer to keep the connection open until the target responds, eliminating the observed 504 errors.

Changing the deregistration delay only affects in-flight requests during scale-in, not long-running requests on healthy targets. Enabling cross-zone load balancing distributes traffic across zones and does not influence connection timeouts. A Network Load Balancer also has a connection idle timeout (with a default of 350 seconds for TCP listeners), so replacing the ALB with an NLB would not remove timeout limits. Simply adjusting the ALB's idle timeout is the most direct and cost-effective fix.

Enabling automated backups activates continuous transaction-log capture for the RDS instance. During recovery, Amazon RDS first restores the most recent daily snapshot and then applies the logs, allowing a point-in-time restore to any second within the retention window except the last five minutes. This limits potential data loss to under 5 minutes and requires no additional administration or infrastructure.

Manual snapshots taken every 5 minutes could meet the RPO but would create thousands of snapshots each day, increasing cost and management overhead.

A Multi-AZ deployment provides a synchronous standby and a zero-RPO failover, but it roughly doubles database cost and is unnecessary for a 5-minute RPO target.

A read replica is asynchronously updated; it can lag beyond five minutes and still involves extra cost and manual promotion steps, so it does not guarantee the stated RPO.

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.

CloudWatch automatically sends an AlarmStateChange event to the local EventBridge default event bus. A cross-account EventBridge rule can forward that event to an event bus in the management account. AWS User Notifications consumes EventBridge events; creating a notification rule that matches the forwarded alarm event and chooses the AWS Console channel causes a banner/pop-up to appear in the Notification Center of anyone signed in to that account. The other options do not surface the alert in the console: AWS Chatbot sends to chat platforms, shared dashboards only show status when manually opened, and Incident Manager engages contacts by phone, SMS, or email but not via the console notification center.