SOA-C03 Practice Questions

AWS Compute Optimizer generates recommendations only for a specific list of supported EC2 instance types. If an instance type is not on this list, Compute Optimizer will not process it, and consequently, it will not appear on the dashboard. The question highlights that the fleet includes "newly released instance types" and "older instance types," which are the most likely candidates to be unsupported. Newly released types may not have been added to the supported list yet, and very old types might be excluded. This makes an unsupported instance type the most probable reason for the instances being missing from the analysis.

A. An instance with insufficient data is typically listed in the dashboard with a finding status of "Insufficient data" or "Not yet analyzed," not completely missing.

C. Optimized instances are explicitly displayed on the dashboard with the finding status "Optimized." The service does not hide them.

D. AWS Compute Optimizer supports instances running both Windows and Linux operating systems. The OS is not a reason for an instance to be excluded from the dashboard.

1. AWS Compute Optimizer User Guide

"Supported resources and requirements": This section explicitly lists the EC2 instance types that are supported for analysis. It states

"Compute Optimizer generates recommendations for the following EC2 instance types." If an instance type is not on this list

it is not analyzed. (AWS Documentation)

2. AWS Compute Optimizer User Guide

"Troubleshooting": Under the topic "Why are some of my resources missing from the Compute Optimizer dashboard?"

the guide lists the primary reason as "The resource is not of a supported configuration." This directly corresponds to the instance type not being supported. (AWS Documentation)

3. AWS Compute Optimizer User Guide

"Getting started with AWS Compute Optimizer"

"Prerequisites": This section outlines the requirements for resources to be analyzed. It lists two key prerequisites for EC2 instances: "The instances must be of a supported instance type" and "The instances must have accumulated sufficient metric data in CloudWatch." The scenario's details about new and old instance types point specifically to the first prerequisite. (AWS Documentation)

EC2 Image Builder is a fully managed AWS service designed to automate the creation, management, and deployment of customized, secure, and up-to-date server images, known as Amazon Machine Images (AMIs). It allows an organization to define a pipeline that starts with a base image, applies customizations and software installations (components), runs tests to validate the image, and then distributes the final, approved AMI. This directly addresses the requirement to create a standardized instance image with only approved software, resolving the issue of configuration drift and unapproved modules caused by manual installations. Updating the deployment workflow to use this "golden AMI" ensures consistency and security for all new instances.

A. Amazon Detective is a security service that analyzes log data to help investigate the root cause of security findings; it does not modify or manage software on instances.

B. Amazon GuardDuty is a threat detection service that monitors for malicious activity and unauthorized behavior; it does not have capabilities for creating or deploying AMIs.

C. AWS Systems Manager Run Command executes commands on existing instances. While it can install software, it does not create a new, reusable AMI, which is the core requirement to prevent future inconsistencies.

1. EC2 Image Builder User Guide: "EC2 Image Builder is a fully managed AWS service that helps you automate the creation

management

and deployment of customized

secure

and up-to-date server images that are pre-installed and pre-configured with software and settings to meet specific IT standards."

Source: AWS Documentation

EC2 Image Builder User Guide

"What is EC2 Image Builder?".

2. AWS Systems Manager User Guide: "Run Command

a capability of AWS Systems Manager

lets you remotely and securely manage the configuration of your managed nodes. ... Run Command enables you to automate common administrative tasks and perform ad hoc configuration changes at scale."

Source: AWS Documentation

AWS Systems Manager User Guide

"Systems Manager Run Command".

3. Amazon GuardDuty User Guide: "Amazon GuardDuty is a threat detection service that continuously monitors your AWS accounts and workloads for malicious activity and delivers detailed security findings for visibility and remediation."

Source: AWS Documentation

Amazon GuardDuty User Guide

"What is Amazon GuardDuty?".

4. Amazon Detective Administration Guide: "Amazon Detective automatically collects log data from your AWS resources and uses machine learning

statistical analysis

and graph theory to build a linked set of data that enables you to easily conduct faster and more efficient security investigations."

Source: AWS Documentation

Amazon Detective Administration Guide

"What is Amazon Detective?".

AWS Secrets Manager is the purpose-built service for managing the lifecycle of secrets, including credentials for services like Amazon RDS. It offers a fully managed, out-of-the-box solution for automatic password rotation. By creating a secret for the RDS database and enabling rotation, Secrets Manager automatically provisions and manages an AWS Lambda function to handle the entire rotation process. This approach requires only configuration and eliminates the need to write, test, or maintain custom code, thereby representing the least operational effort to meet the requirement.

A. This is a valid but high-effort solution. It requires the engineer to write, deploy, and maintain a custom Lambda function and its associated permissions, which is more operational overhead than the managed Secrets Manager solution.

B. AWS Systems Manager Parameter Store does not have a native, built-in capability to automatically rotate credentials for external services like Amazon RDS. A custom solution, such as a Lambda function, would still be required.

C. This option is incorrect for two reasons: it uses a plain String parameter, which is insecure for storing passwords, and Parameter Store does not natively support automatic rotation for RDS credentials.

---

1. AWS Secrets Manager User Guide

"Rotate secrets": "For secrets that store credentials for Amazon RDS... you can configure Secrets Manager to rotate the secret automatically. When you turn on automatic rotation

Secrets Manager uses a Lambda rotation function to rotate the secret." This document confirms that Secrets Manager provides a managed

automatic rotation feature specifically for RDS.

2. AWS Secrets Manager User Guide

"How rotation works": This section details the four-step process (createSecret

setSecret

testSecret

finishSecret) that the managed Lambda function performs

illustrating the complexity that is abstracted away from the user

thus minimizing operational effort.

3. AWS Systems Manager User Guide

"AWS Systems Manager Parameter Store": The documentation for Parameter Store describes its function for storing configuration data and secrets as parameters. It does not mention a native

managed feature for rotating credentials of other AWS services like RDS

which differentiates it from Secrets Manager.

4. AWS Security Blog

"AWS Secrets Manager vs. Systems Manager Parameter Store": "Secrets Manager offers secret rotation with built-in integration for Amazon RDS... If you need to rotate secrets

you should use Secrets Manager." This official blog post explicitly recommends Secrets Manager over Parameter Store for use cases involving credential rotation.

The VPC Flow Logs provide critical information. The ACCEPT record for inbound traffic (192.168.0.13 → 172.31.16.139:8080) confirms that both the Network ACL (NACL) and the EC2 instance's security group are correctly configured to allow the initial request.

However, the REJECT record for the return traffic (172.31.16.139:8080 → 192.168.0.13:59003) indicates the response is being blocked. Security groups are stateful, meaning if inbound traffic is allowed, the return traffic is automatically permitted. In contrast, NACLs are stateless and require explicit rules for both inbound and outbound traffic. The rejection of the response packet, destined for the client's ephemeral port (59003), points directly to a missing or incorrect outbound rule in the NACL associated with the instance's subnet.

A. The inbound traffic is ACCEPTed, which would not be possible if the security group were blocking traffic from the NLB's targets.

B. Network Load Balancers do not have security groups. Security groups are associated with the target EC2 instances, not the NLB itself.

C. The initial traffic from the on-premises environment was ACCEPTed by the AWS VPC, indicating the on-premises ACL is not the source of the block.

1. AWS Documentation - VPC Flow Logs: "If the traffic is permitted by both the security groups and the network ACLs

the record shows ACCEPT. If the traffic is denied by a security group or a network ACL

the record shows REJECT." (Source: AWS Documentation

VPC User Guide

"Log file format"

section on the action field).

2. AWS Documentation - Network ACLs: "Network ACLs are stateless

which means that responses to allowed inbound traffic are subject to the rules for outbound traffic (and vice versa)." (Source: AWS Documentation

VPC User Guide

"Network ACLs"

section "Network ACL basics").

3. AWS Documentation - Ephemeral Ports: "When a client connects to a server

a random port from the ephemeral port range... becomes the client's source port. The response from the server is sent to this ephemeral port on the client... The network ACL for the subnet... must have an outbound rule to allow traffic destined for the ephemeral ports." (Source: AWS Documentation

VPC User Guide

"Network ACLs"

section "Ephemeral ports").

4. AWS Documentation - Security Groups: "Security groups are stateful. If you send a request from your instance

the response traffic for that request is allowed to flow in

regardless of inbound security group rules." (Source: AWS Documentation

VPC User Guide

"Security groups"

section "Security group basics").

For Amazon EventBridge to send events from one AWS account to an event bus in another, a two-part permission model is required. First, the sender account needs an IAM role with a policy allowing the events:PutEvents action on the target event bus ARN. Second, and critically, the target event bus in the receiver account must have a resource-based policy attached. This policy explicitly grants permission to the sender account's principal (or the entire AWS Organization) to perform the events:PutEvents action. Without this resource-based policy, the receiver account's event bus will deny all incoming event requests from other accounts, which is the most likely reason the events are not being processed.

A. Interface VPC endpoints are only necessary for resources within a VPC to communicate with EventBridge privately, not a general requirement for cross-account event delivery.

B. EventBridge fully supports routing events to a target event bus in a different AWS Region. The scenario describes a valid cross-region architecture.

D. The rule's event pattern in the receiving account filters events after they have successfully arrived on the bus. The core issue is the event failing to arrive due to a permissions denial.

1. AWS Documentation

Amazon EventBridge User Guide

"Sending and receiving Amazon EventBridge events between AWS accounts": This section explicitly states the requirement for a resource-based policy on the receiving event bus. It clarifies: "To receive events from another account

you must edit the permissions for the event bus in your account... The policy grants permission to the other account to send events to the event bus in your account." It also provides example policies.

2. AWS Documentation

Amazon EventBridge User Guide

"Resource-based policies for Amazon EventBridge": This page details the structure and use of resource-based policies. It states

"To send events to an event bus in another account

you need to configure a resource-based policy that is attached to that event bus."

3. AWS Documentation

Amazon EventBridge User Guide

"Routing events to a different Region": This section confirms that cross-region event routing is a supported feature. It states

"You can create a rule that sends events to an event bus in a different Region. To do this

specify the event bus ARN in the other Region as the target of the rule." This directly refutes the claim in option B.

To meet the requirement of directing users to the closest AWS Region, Amazon Route 53 geoproximity routing is the appropriate policy. This policy routes traffic based on the geographic location of both the users and the configured AWS resources, effectively sending users to the nearest endpoint.

For automated failover, Route 53 must be able to determine the health of each regional endpoint. The most reliable method in this architecture is to monitor the Application Load Balancer (ALB) in each region. A CloudWatch alarm can be configured to trigger if the ALB becomes unhealthy (e.g., the HealthyHostCount metric drops below a threshold). A Route 53 health check can then monitor the state of this CloudWatch alarm, allowing Route 53 to automatically stop sending traffic to an unhealthy region.

B. Monitoring individual EC2 instances is less effective than monitoring the ALB, which provides an aggregated health status for the entire fleet of instances in that region.

C. Route 53 health checkers operate from the public internet and cannot reach private IP addresses of EC2 instances. Also, a single instance's health doesn't represent the region's availability.

E. Simple routing does not support routing based on user location. The description of specifying continent and country applies to geolocation routing, not simple routing, making the option incorrect.

1. Amazon Route 53 Developer Guide - Geoproximity routing: "Geoproximity routing lets Amazon Route 53 route traffic to your resources based on the geographic location of your users and your resources." This directly supports using geoproximity to route users to the closest region.

Source: AWS Documentation

Amazon Route 53 Developer Guide

"Choosing a routing policy

" section "Geoproximity routing."

2. Amazon Route 53 Developer Guide - Health checks that monitor a CloudWatch alarm: "You can create a health check that monitors a CloudWatch alarm... For example

you can create a CloudWatch alarm that monitors the status of an Application Load Balancer..." This confirms that monitoring an ALB's health via a CloudWatch alarm is a supported and recommended pattern for Route 53 health checks.

Source: AWS Documentation

Amazon Route 53 Developer Guide

"How Amazon Route 53 determines whether a health check is healthy

" section "Health checks that monitor a CloudWatch alarm."

3. Amazon Route 53 Developer Guide - Configuring DNS failover: "Route 53 health checks monitor the health of your resources... When a resource becomes unavailable

Route 53 can detect that and stop including the corresponding resource record when responding to DNS queries." This explains the mechanism for automated failover.

Source: AWS Documentation

Amazon Route 53 Developer Guide

"Concepts

" section "Health checks and DNS failover."

4. Elastic Load Balancing User Guide - Health checks for your Target Groups: "The load balancer periodically sends requests to its registered targets to test their status... The load balancer routes requests only to the healthy targets." The ALB's health status is an aggregate of its targets

making it the ideal metric for regional health.

Source: AWS Documentation

Elastic Load Balancing User Guide for Application Load Balancers

"Target Groups for Your Application Load Balancers

" section "Health checks for your target groups."

AWS Systems Manager Quick Setup is designed to simplify the configuration of Systems Manager and other services across an entire AWS Organization. By using the "Default Host Management Configuration" from the organization's management account, an administrator can automate the deployment of the necessary IAM roles and configurations to all member accounts and specified Regions. This is achieved through the use of AWS CloudFormation StackSets, which Quick Setup manages automatically. This approach ensures that all current and future EC2 instances in the organization are configured for Systems Manager, meeting the requirements for a scalable, organization-wide management solution.

B: AWS Systems Manager Run Command executes scripts on managed instances; it cannot be used to modify IAM policies or roles, which are account-level resources managed through the IAM service.

C: This describes a manual and incorrect way of using AWS CloudFormation StackSets. The "Default Host Management Configuration" is a pre-packaged Quick Setup configuration, not a parameter you define in a custom template.

D: This solution is incomplete. While creating an instance profile with the correct policy via a StackSet is a valid step, it does not attach the profile to existing or future instances, nor does it configure Systems Manager services like patching or inventory.

1. AWS Systems Manager User Guide

"AWS Systems Manager Quick Setup": This section states

"Quick Setup... helps you quickly configure frequently used AWS services and features with recommended best practices... You can use Quick Setup in an individual AWS account or across multiple AWS accounts and AWS Regions by integrating with AWS Organizations." This supports using Quick Setup for an organization-wide deployment.

2. AWS Systems Manager User Guide

"Quick Setup Host Management": This page details the "Default Host Management Configuration" option. It specifies that this configuration "deploys the AWS-SystemsManager-EC2-SSM-Ready-Role IAM instance profile to your accounts and Regions" and configures instances for core Systems Manager capabilities like inventory

patch scanning

and agent updates. This confirms that Option A provides a complete solution.

3. AWS Systems Manager User Guide

"Setting up Systems Manager for multi-account and multi-Region environments": This section explicitly recommends Quick Setup as the method for configuring Systems Manager across an organization. It notes

"We recommend that you use Quick Setup... to configure your instances for Systems Manager... Quick Setup uses AWS CloudFormation StackSets to create the required IAM instance profile role and configure your instances." This directly validates the approach in Option A.

The core issue is that the Auto Scaling group (ASG) is scaling based on network input (ASGAverageNetworkIn), which is not a direct measure of the application's workload backlog residing in the SQS queue. The most effective way to scale a fleet of workers processing messages from an SQS queue is to scale based on the number of messages waiting to be processed.

The recommended AWS pattern for this scenario is to use a target tracking scaling policy with a custom metric. This custom metric is created using Amazon CloudWatch metric math to calculate the backlog per instance (ApproximateNumberOfMessagesVisible / GroupInServiceInstances). This ensures that the ASG adds or removes instances to keep the backlog per instance at a target value, directly aligning scaling actions with the actual workload.

A. The ApproximateNumberOfMessagesDelayed metric tracks messages intentionally delayed using a timer, not the active backlog of messages ready for processing. The correct metric for the backlog is ApproximateNumberOfMessagesVisible.

C. Step scaling is a valid scaling policy, but it does not solve the fundamental problem of using an inappropriate metric (ASGAverageNetworkIn) as the scaling trigger. The trigger itself must be changed first.

D. Simple scaling is an outdated policy type that is generally not recommended. It has a cooldown period that can hinder responsiveness, and like step scaling, it doesn't fix the core issue of using the wrong metric.

1. AWS Documentation - Scaling based on Amazon SQS: This official guide explicitly details the solution. It states

"To use an SQS queue as a scaling metric for your Auto Scaling group

create a CloudWatch metric that captures the SQS queue's backlog... Then

create a target tracking scaling policy that configures your Auto Scaling group to scale based on the custom metric." It provides the exact metric math formula: ApproximateNumberOfMessagesVisible / GroupInServiceInstances.

Source: Amazon EC2 Auto Scaling User Guide

"Scaling based on Amazon SQS".

2. AWS Documentation - Target tracking scaling policies: This document explains the mechanism of target tracking and its benefits. It notes

"With target tracking scaling policies

you select a scaling metric and set a target value... For example

you can configure a target tracking scaling policy to keep the average number of messages in your SQS queue per EC2 instance at 100."

Source: Amazon EC2 Auto Scaling User Guide

"Target tracking scaling policies for Amazon EC2 Auto Scaling".

3. AWS Documentation - Using metric math: This document describes how to create new time series by applying mathematical expressions to existing CloudWatch metrics

which is the technique required for this solution.

Source: Amazon CloudWatch User Guide

"Using metric math".

AWS Control Tower is a service designed to establish and govern a secure, multi-account AWS environment. It uses preventive guardrails, which are implemented as Service Control Policies (SCPs), to enforce policies across all accounts in an organization. The "Region deny control" is a specific Control Tower feature that uses an SCP to restrict access to specified AWS Regions, meeting the requirement to block EC2 deployments in ap-southeast-2. SCPs are the only mechanism that can restrict permissions for the account root user, thereby meeting the requirement to block root user actions. An SCP can also be configured to deny actions like cloudtrail:DeleteTrail for all principals, including administrators, thus protecting the logs. This solution is centrally managed and automatically applied to new accounts created via the Control Tower account factory.

A. AWS Config is a detective, not a preventive, control. You cannot attach IAM permissions boundaries to the account root user to restrict its permissions.

B. AWS Security Hub is a security posture management service that aggregates findings; it is primarily a detective tool and does not prevent actions from occurring.

D. AWS Firewall Manager is used for centrally managing firewall rules (e.g., WAF, Security Groups), not for restricting EC2 deployments by region or limiting root user actions.

1. AWS Control Tower Documentation

"Region deny control": This document explains the Region deny control feature. It states

"The Region deny control... helps you restrict access to AWS Regions... This control is implemented using a service control policy (SCP)."

2. AWS Organizations User Guide

"Service control policies (SCPs)": This guide clarifies how SCPs work. It states

"SCPs are a type of organization policy that you can use to manage permissions in your organization... SCPs affect all IAM entities (users and roles)

including the root user

in a member account."

3. AWS Organizations User Guide

"SCP examples": This section provides examples of SCPs. The example "Prevent member accounts from leaving the organization" demonstrates denying an action (organizations:LeaveOrganization) for all principals

a principle that can be applied to deny cloudtrail:DeleteTrail or all actions for the root user.

4. AWS Control Tower User Guide

"How AWS Control Tower works": This guide describes the overall function. It explains

"When you create a new account with Account Factory

the account is enrolled automatically in AWS Control Tower

and the guardrails are applied to the account." This confirms the solution applies to existing and future accounts.

The most direct and efficient method to meet the requirement is to use Amazon S3 Event Notifications. This feature is designed to enable event-driven computing by sending a notification to a destination when a specific event, such as an object creation (s3:ObjectCreated:), occurs in an S3 bucket. AWS Lambda is a natively supported destination for these notifications. Configuring an S3 event notification to target the Lambda function creates a direct, serverless invocation pattern without unnecessary intermediate services, providing a low-latency and cost-effective solution.

A. This is a valid but indirect pattern. It introduces an unnecessary component (SNS), adding latency and complexity compared to the direct S3-to-Lambda invocation.

B. Amazon CloudWatch Alarms are used to trigger actions based on metrics crossing a defined threshold, not for discrete events like an object upload.

D. This is also a valid but indirect pattern. While useful for decoupling and throttling, adding an SQS queue is not required for the simple invocation described.

---

1. AWS Lambda Developer Guide: In the section "Using AWS Lambda with Amazon S3

" the documentation states

"You can use Amazon S3 to trigger a Lambda function to process object-created events. You can configure the S3 trigger in the Lambda console to create an S3 event notification that invokes your function." This confirms the direct integration. (Source: AWS Lambda Developer Guide

"Using AWS Lambda with Amazon S3").

2. Amazon S3 User Guide: The documentation on "Amazon S3 Event Notifications" lists the supported destinations for events. It explicitly includes "AWS Lambda function" as a destination. This highlights that a direct invocation is the intended design pattern. (Source: Amazon S3 User Guide

"Amazon S3 Event Notifications

" section "Event notification destinations").

3. Amazon S3 User Guide: The guide further details the process in "Walkthrough: Using an S3 trigger to invoke a Lambda function." This walkthrough provides a step-by-step implementation of the exact scenario described in the question

reinforcing that S3 Event Notifications are the correct mechanism. (Source: Amazon S3 User Guide

"Tutorials and examples

" section "Walkthrough: Using an S3 trigger to invoke a Lambda function").

4. Amazon CloudWatch User Guide: The documentation for "Using Amazon CloudWatch alarms" specifies that "You can create an alarm that watches a single CloudWatch metric... The alarm performs one or more actions based on the value of the metric... relative to a threshold over a number of time periods." This confirms alarms are for metric-based state changes

not event-based triggers. (Source: Amazon CloudWatch User Guide

"Using Amazon CloudWatch alarms").