Pass the Amazon Web Services AWS Certified Associate SOA-C03 Questions and answers with CertsForce

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.

According to the AWS Cloud Operations and Compute documentation, when workloads exhibit predictable traffic patterns, the best practice is to use scheduled scaling for Amazon EC2 Auto Scaling groups.

With scheduled scaling, administrators can predefine the desired capacity of an Auto Scaling group to increase before anticipated demand (in this case, before the 2-hour peak) and scale back down afterward. This ensures that sufficient compute capacity is provisioned proactively, avoiding performance degradation while maintaining cost efficiency.

AWS notes: “Scheduled actions enable scaling your Auto Scaling group at predictable times, allowing you to pre-warm instances before demand spikes.”

Manual scaling (Option D) adds operational overhead. Adjusting launch templates (Option B) doesn’t affect scaling behavior, and permanently increasing minimum capacity (Option A) wastes resources outside of peak hours.

Thus, Option C provides an automated, cost-effective, and operationally efficient CloudOps solution.

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

Amazon EFS encryption at rest is a file system creation attribute; an unencrypted EFS file system cannot be “turned on” for encryption in place. Therefore, meeting the requirement (“encrypt an existing EFS using an existing KMS customer managed key”) requires creating a new encrypted file system and migrating data.

Option A is the most operationally efficient because EFS replication is a managed mechanism that continuously copies data and metadata from a source file system to a destination file system. By specifying the existing KMS customer managed key for the destination, the new file system is encrypted at rest under the required key. After replication has caught up, the administrator can perform a controlled cutover (failover) so applications mount the encrypted destination instead of the original source. This reduces manual copying effort, supports ongoing synchronization during migration, and simplifies the cutover window.

Option B is not possible because encryption-at-rest settings for EFS cannot be modified after creation. Option C is irrelevant because TLS certificates relate to encryption in transit and are not configured as part of EFS replication in the manner described. Option D can work functionally, but it requires building and operating a copy workflow, which is more manual and error-prone than managed replication.

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

To meet the requirement to log and audit any principal that publishes to SNS topics and interacts with SQS queues, the correct service is AWS CloudTrail, because CloudTrail records API activity (who did what, when, and from where). Enabling data events (where supported/required for deeper visibility) provides detailed records for operations such as publishing messages and sending/receiving messages. Delivering CloudTrail logs to Amazon S3 provides durable retention and supports querying workflows.

To ensure that communication uses VPC endpoints, the company should configure VPC endpoints for SNS and SQS and then validate usage by inspecting CloudTrail event records. CloudTrail includes endpoint-related context fields (for example, a VPC endpoint identifier) that allow auditors to confirm that the request path used a VPC endpoint rather than traversing the public internet. This directly addresses the “must use VPC endpoints” control with auditable evidence.

The other options do not satisfy both requirements. CloudWatch Logs does not automatically capture SNS/SQS API caller identity for publish/send/receive operations in the same authoritative way CloudTrail does. EventBridge can capture service events but is not the primary audit log of API calls and does not inherently prove VPC endpoint usage per request. Inspecting a VPC endpoint field in CloudWatch Logs is not the standard audit mechanism for these API calls.

The CloudWatch agent procstat plugin is specifically designed to collect per-process metrics such as CPU usage by process ID. It allows continuous, automated monitoring without manual intervention and integrates directly with CloudWatch.

Default CloudWatch metrics provide only instance-level CPU utilization and do not expose process-level details. Manual logins and Lambda-based polling introduce unnecessary operational overhead and are not scalable.

Therefore, configuring the procstat plugin is the most efficient solution.

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

The correct answer is D because Amazon S3 Express One Zone with directory buckets and zonal endpoints is specifically designed for single–Availability Zone, high-performance workloads such as HPC, machine learning, and analytics applications running on Amazon EC2. AWS CloudOps documentation states that S3 Express One Zone delivers single-digit millisecond latency and up to 10x higher request performance compared to general purpose S3 buckets when data is accessed from the same Availability Zone.

An S3 directory bucket is required to use the S3 Express One Zone storage class. These buckets are explicitly associated with a single Availability Zone and use zonal endpoints, which eliminate cross-AZ network hops and significantly reduce latency. Importing the data from the existing general purpose bucket ensures compatibility while achieving maximum throughput and lowest latency.

Option A is incorrect because S3 Transfer Acceleration is optimized for long-distance, internet-based transfers, not for in-Region HPC workloads. Option B is incorrect because lifecycle policies cannot move objects into S3 Express One Zone, and S3 Express One Zone does not use Regional endpoints. Option C is incorrect because general purpose buckets do not support zonal endpoints and therefore cannot achieve the same performance benefits.

AWS CloudOps performance optimization guidance clearly identifies S3 directory buckets with S3 Express One Zone and zonal endpoints as the optimal architecture for high-throughput, low-latency workloads in a single Availability Zone.

The AWS Cloud Operations and Compute documentation explains that placement groups control how EC2 instances are physically arranged within AWS data centers to optimize network performance.

Among the available placement strategies:

Cluster placement groups place instances physically close together within a single Availability Zone, connected through high-bandwidth, low-latency networking (ideal for tightly coupled, HPC, or distributed workloads).

Spread placement groups distribute instances across distinct racks or Availability Zones for fault tolerance, increasing latency.

Partition placement groups separate instances into partitions for isolation, not latency reduction.

Therefore, to minimize latency for workloads such as computational clusters, the CloudOps engineer should use a cluster placement group. This placement ensures single-digit microsecond latency and enhanced packet rate performance between instances.

Elastic IPs (Option B) do not influence internal networking. Jumbo frames (Option C) can marginally improve throughput but do not reduce propagation latency. Spread placement (Option D) increases distance, worsening latency.

Hence, Option A — using a cluster placement group — delivers the lowest possible network latency and is AWS’s best-practice design for HPC-style clusters.

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

The requirement is to alert before throttling occurs. For a DynamoDB table in provisioned capacity mode, throttling happens when demand approaches or exceeds provisioned throughput. CloudWatch provides direct table metrics such as ConsumedReadCapacityUnits and ProvisionedReadCapacityUnits (and related utilization signals). Creating an alarm on ConsumedReadCapacityUnits with a threshold set close to the table’s provisioned read capacity provides an early warning that the table is nearing its limit—before actual throttling prevents reads. The alarm can publish directly to the existing SNS topic so the operations team is notified proactively.

Option C and D focus on detecting throttling after it occurs by matching throttling exceptions in logs. That is reactive and violates “before throttled.” Option B (auto scaling) may reduce the likelihood of throttling, but it does not directly satisfy the alerting requirement and “scaling events” notifications are not a reliable proxy for “approaching throttle” (and may not fire early enough depending on scaling configuration). The simplest, most direct CloudOps approach is a CloudWatch alarm on consumption nearing provisioned capacity.

Per the AWS Cloud Operations and Security Automation documentation, Security Hub integrates with Amazon EventBridge to publish findings in real time. These events can trigger automated responses using AWS Lambda functions or AWS Systems Manager Automation runbooks.

In this scenario, the correct CloudOps approach is to configure the existing EventBridge rule to invoke a Lambda function that inspects the event payload, identifies the affected security group, and removes the offending inbound rule (e.g., port 21 open to 0.0.0.0/0).

This event-driven remediation provides continuous compliance and eliminates manual intervention. Cron jobs (Options B and C) contradict event-driven design and add operational overhead. Stopping instances (Option A) doesn’t address the root cause — the insecure security group.

Thus, Option D aligns with AWS best practices for automated security remediation through EventBridge and Lambda.