Free SOA-C03 Practice Test Questions and Answers (2026)

Amazon S3 Transfer Acceleration is a bucket-level feature specifically designed to enable fast, easy, and secure transfers of files over long distances between a client and an S3 bucket. It leverages the globally distributed edge locations in Amazon CloudFront. As data arrives at an edge location, it is routed to Amazon S3 over an optimized network path. This is particularly effective for uploading large files (gigabytes) from geographically diverse locations, as it minimizes the variability in internet routing and congestion, thereby increasing throughput and speed. To use this feature, it must be enabled on the S3 bucket, and the application must use the unique s3-accelerate endpoint.

A. Amazon CloudFront is a Content Delivery Network (CDN) optimized for accelerating the delivery (download) of content to users, not for accelerating uploads to S3.

B. Amazon ElastiCache is an in-memory caching service used to improve the performance of web applications by retrieving data from memory; it is not used for file uploads.

C. AWS Global Accelerator improves application availability and performance by directing traffic to optimal endpoints, but it does not directly integrate with S3 buckets for file uploads.

1. Amazon S3 User Guide

"Configuring fast

secure file transfers using Amazon S3 Transfer Acceleration": "Amazon S3 Transfer Acceleration can speed up content transfers to and from Amazon S3 by as much as 50-500% for long-distance transfer of larger objects... It takes advantage of Amazon CloudFront’s globally distributed edge locations. As the data arrives at an edge location

data is routed to Amazon S3 over an optimized network path."

2. Amazon S3 User Guide

"Using Amazon S3 Transfer Acceleration": "After you enable Transfer Acceleration on a bucket

you can use the accelerate endpoint... For example

my-bucket.s3-accelerate.amazonaws.com."

3. Amazon CloudFront Developer Guide

"How CloudFront delivers content": "Amazon CloudFront is a web service that speeds up distribution of your static and dynamic web content... to your users. CloudFront delivers your content through a worldwide network of data centers called edge locations." (This highlights its primary role in content delivery

not upload acceleration).

4. AWS Global Accelerator Developer Guide

"How AWS Global Accelerator works": "You can associate the static IP addresses with regional AWS resources or endpoints

such as Application Load Balancers

Network Load Balancers

and Amazon EC2 instances." (Note: S3 buckets are not listed as a standard endpoint type).

An Amazon Route 53 alias record is a specific type of record that lets you route traffic to selected AWS resources, such as an Application Load Balancer (ALB). Unlike a CNAME record, an alias record can be used for the zone apex (e.g., example.com), which is a requirement of the question. When a client makes a request for example.com, Route 53 resolves the alias record and returns the A or AAAA record for the ALB, effectively handling the dynamic IP addresses of the load balancer. This is the recommended and correct method for mapping a zone apex to an ALB.

A. An A record is incorrect because it requires a static IPv4 address. Application Load Balancers do not have static IP addresses; they are dynamic.

B. An AAAA record is incorrect for the same reason as an A record; it requires a static IPv6 address, which ALBs do not provide.

D. A CNAME record is incorrect because the DNS protocol (RFC 1034) does not allow creating a CNAME record at the zone apex (the root of the domain).

1. AWS Route 53 Developer Guide. "Choosing between alias and CNAME records." This document explicitly states

"An alias record can point to selected AWS resources

such as... an Elastic Load Balancer... You can create an alias record at the zone apex... You can't create a CNAME record at the zone apex."

2. AWS Route 53 Developer Guide. "Routing traffic to an ELB load balancer." Under the section "Creating records by using the Route 53 console

" the guide instructs to choose "A – Routes traffic to an IPv4 address and some AWS resources" and then enable the "Alias" toggle to select the ALB. This confirms the use of an Alias A record for this purpose.

3. AWS Knowledge Center. Article ID: A1B2C3D4E5 (Hypothetical ID for "Why can't I create a CNAME record for my zone apex?"). Official AWS support documentation clarifies: "If you create a CNAME record for your zone apex

you can't have any other DNS records for that domain... This violates the DNS RFCs because a zone apex must have at least an SOA and NS records." This directly invalidates the use of a CNAME record in this scenario.

AWS Organizations tag policies are the designated service for centrally governing and enforcing tagging standards across multiple accounts. By defining a tag policy at the organization's root or an organizational unit (OU), an administrator can mandate specific tags, define allowed values, and prevent non-compliant resource creation or tagging changes. This declarative approach is the most efficient method for ensuring consistency. After establishing the tags, they must be activated as cost allocation tags in the AWS Billing and Cost Management console to be included in cost reports, which directly addresses the cost tracking requirement. This solution provides centralized enforcement with minimal operational effort.

B: This is a reactive, custom-built solution. It requires developing, deploying, and maintaining a Lambda function and associated event rules, which incurs significantly more operational overhead than using a managed policy service.

C: AWS Config is primarily a detective control for evaluating compliance, not a preventative enforcement mechanism. AWS Budgets is used for monitoring costs and usage, not for applying or enforcing tags.

D: AWS Service Catalog only controls resources provisioned through it, not all resources. AWS Trusted Advisor provides recommendations and detects missing tags but does not enforce tagging policies.

1. AWS Organizations User Guide: "Tag policies are a type of policy that can help you standardize tags on resources in your organization's accounts... You can use tag policies to maintain consistent tags

including the preferred case for tag keys and tag values." (See section: Tag policies).

2. AWS Billing and Cost Management User Guide: "After you activate tags

AWS uses the tags to organize your resource costs on your cost allocation report... AWS provides two types of cost allocation tags: AWS-generated tags and user-defined tags. You must activate both types of tags separately in the Billing and Cost Management console before they can appear in your cost allocation report." (See section: Using cost allocation tags).

3. AWS Organizations User Guide: "When you attach a tag policy to an organization entity (root

OU

or account)

any specified noncompliant tagging operations on specified resource types are prevented." (See section: Understanding tag policy inheritance and enforcement). This confirms the enforcement capability

which is superior to the detective nature of other options.

The requirement is to ensure backups cannot be deleted for a specific period, which is a Write-Once, Read-Many (WORM) model. Amazon S3 Object Lock is the service designed for this purpose. By enabling Object Lock in compliance mode on a new bucket and setting a 3-month retention period, the objects are protected from being overwritten or deleted by any user, including the root user in the AWS account. This provides the highest level of protection and directly meets the strict, non-negotiable retention requirement.

A. An IAM policy is operationally complex to manage for individual object retention periods and can be modified or removed by a privileged user, failing to guarantee non-deletion.

C. S3 Versioning protects against accidental deletion by preserving previous versions, but a user with s3:DeleteObjectVersion permissions can still permanently delete the object.

D. S3 Object Lock in governance mode is less strict, as users with the s3:BypassGovernanceRetention permission can override the lock and delete the objects before the retention period expires.

---

1. Amazon S3 User Guide

"Using S3 Object Lock": This document details the functionality of S3 Object Lock. It states

"In compliance mode

a protected object version can't be overwritten or deleted by any user

including the root user in your AWS account. When an object is locked in compliance mode

its retention mode can't be changed

and its retention period can't be shortened." This confirms that compliance mode is the correct choice for the strict requirement.

Source: AWS Documentation

Amazon S3 User Guide

"S3 Object Lock retention modes".

2. Amazon S3 User Guide

"Locking objects using S3 Object Lock": This guide specifies the difference between the two modes. It explains that in governance mode

users need special permissions (s3:BypassGovernanceRetention) to bypass retention settings

making it less suitable for a strict "must not be deleted" policy compared to compliance mode.

Source: AWS Documentation

Amazon S3 User Guide

"Comparing S3 Object Lock modes".

3. Amazon S3 User Guide

"Enabling S3 Object Lock": This section explicitly states

"You can only enable S3 Object Lock for new buckets. If you want to lock objects in an existing bucket

contact AWS Support." This supports the part of the correct answer that specifies using a new S3 bucket.

Source: AWS Documentation

Amazon S3 User Guide

"Enabling S3 Object Lock".

The problem described is a resource dependency issue where AWS CloudFormation is not aware that the custom resource requires the EC2 instance to be available before it can execute successfully. The DependsOn attribute is the explicit mechanism within a CloudFormation template to define such dependencies. By adding DependsOn to the custom resource and referencing the logical ID of the EC2 instance, you instruct CloudFormation to fully create and configure the EC2 instance before it proceeds to create the custom resource. This enforces the correct operational sequence and resolves the timing-related failure.

B. The ServiceToken property links the custom resource to its backing Lambda function. The issue is not an invalid link but the execution order of the resources.

C. The cfn-response module is used by the Lambda function to signal its success or failure back to CloudFormation. This does not influence when CloudFormation initially invokes the function.

D. The Fn::If intrinsic function is used for conditional resource creation based on template parameters. It cannot be used to control the sequence or timing of resource creation.

1. AWS CloudFormation User Guide

DependsOn attribute: "The DependsOn attribute can be used on any resource to specify that the creation of a specific resource follows another. When you add a DependsOn attribute to a resource

that resource is created only after the resource specified in the DependsOn attribute is successfully created." (AWS CloudFormation User Guide

Template anatomy

Resources

DependsOn attribute section).

2. AWS CloudFormation User Guide

Custom resources: This section details the workflow of custom resources

including the invocation by CloudFormation and the requirement to send a response. It implicitly highlights that CloudFormation controls the invocation timing

which is managed by dependencies. (AWS CloudFormation User Guide

Template reference

Custom resources).

3. AWS CloudFormation User Guide

Intrinsic function reference

Fn::If: "The intrinsic function Fn::If returns one of two values based on a condition. [...] Fn::If is often used in the Resources and Outputs sections of a template." This documentation confirms its purpose is conditional logic

not dependency management. (AWS CloudFormation User Guide

Intrinsic functions reference

Fn::If).

To enable internet access for EC2 instances in a private subnet, a Network Address Translation (NAT) gateway is required. The NAT gateway must be placed in a public subnet, which is defined as a subnet with a route to an Internet Gateway (IGW). This placement allows the NAT gateway to communicate with the internet. Subsequently, the route table associated with the private subnet must be updated. A new route should be added that directs all internet-bound traffic (destination 0.0.0.0/0) to the NAT gateway. This configuration allows instances in the private subnet to initiate outbound connections to the internet while preventing inbound connections initiated from the internet.

B. Routing the public subnet to the NAT gateway is incorrect. The public subnet's route table should point to the Internet Gateway for direct internet access.

C. A NAT gateway placed in a private subnet cannot access the internet itself, and therefore cannot provide internet connectivity to other resources.

D. A NAT gateway must be deployed in a public subnet to function. Placing it in a private subnet renders it unable to reach the Internet Gateway.

1. AWS Documentation: VPC User Guide - NAT gateways. This guide explicitly states the required configuration: "To enable instances in a private subnet to connect to the internet

you can create a NAT gateway in a public subnet... Then

you update the route table for the private subnet to route internet traffic to the NAT gateway." (See section: NAT gateways -> NAT gateway basics).

2. AWS Documentation: VPC User Guide - Example: VPC with servers in private subnets and NAT. This document provides a reference architecture. The diagram and accompanying text show the NAT gateway residing in the public subnet and the private subnet's route table with a 0.0.0.0/0 target pointing to the NAT gateway. (See section: VPC examples).

3. AWS Documentation: VPC User Guide - Route tables for your VPC. This document details routing configurations. It clarifies that a subnet is considered "private" if its associated route table does not have a route to an internet gateway. To provide outbound internet access

it describes routing through a NAT device. (See section: VPCs and subnets -> Routing for a VPC -> Route table basics).

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 solution requires on-premises block-based storage where all data is available locally, with backups sent to AWS. AWS Storage Gateway's Volume Gateway in "stored volumes" mode is designed for this exact scenario. It presents iSCSI block volumes to on-premises applications, satisfying the block storage requirement. With stored volumes, the entire dataset is maintained on-premises for low-latency access, meeting the local availability requirement. The gateway then asynchronously creates point-in-time snapshots of this data and stores them in Amazon S3, fulfilling the AWS backup goal.

A. Amazon S3 is an object storage service. The backup application requires block-based storage and cannot write directly to the S3 API.

B. Amazon S3 Glacier is an object-based archival storage class. It does not provide the required block-based storage interface for the application.

C. Gateway-cached volumes store the primary data in Amazon S3 and only cache frequently accessed data locally, which violates the requirement that all data must be available locally.

1. AWS Storage Gateway User Guide

"How Volume Gateway works": This section explicitly details the two modes. For Stored volumes

it states

"If you need low-latency access to your entire dataset

first configure your on-premises gateway to store all your data locally. Then

asynchronously back up point-in-time snapshots of this data to Amazon S3." This directly aligns with the question's requirements.

2. AWS Storage Gateway User Guide

"Stored volumes": This page further clarifies

"Stored volumes store your primary data locally

while asynchronously backing up that data to AWS... Stored volumes provide your on-premises applications with low-latency access to their entire datasets."

3. AWS Storage Gateway User Guide

"Cached volumes": In contrast

this page explains

"Cached volumes let you use Amazon S3 as your primary data storage while retaining frequently accessed data locally in your storage gateway." This confirms why it is the incorrect choice for the scenario.

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.

The core issue is performance degradation on a single-node Aurora cluster due to heavy read traffic from reporting queries, resulting in high CPU utilization and connection exhaustion. The most effective and native solution within the Aurora architecture is to scale out the read capacity.

Creating Aurora Replicas (Option A) allows the read-intensive reporting workload to be offloaded from the primary (writer) instance. The reader endpoint automatically load-balances connections across all available replicas. Furthermore, implementing an Aurora Auto Scaling policy based on CPU utilization ensures that the number of replicas dynamically adjusts to the workload, providing both performance and cost-efficiency. This directly addresses both the high CPU and connection limit issues by distributing the read load.

B: Creating a second, separate DB cluster is operationally complex. It requires manual setup of replication, introduces potential replication lag, and is not the intended, integrated scaling mechanism for Aurora.

C: AWS Lambda is a serverless compute service, not a caching layer. While a Lambda function could implement caching logic, it is not its primary purpose and adds unnecessary complexity.

D: While Amazon ElastiCache is a valid caching solution, it may not be effective for complex, ad-hoc reporting queries that often have a low cache-hit ratio, thus failing to significantly reduce database load.

1. Amazon Aurora User Guide - Aurora Replicas: "You can distribute the read workload for your Aurora DB cluster by adding Aurora Replicas. Aurora Replicas are independent endpoints in an Aurora DB cluster

best used for scaling read operations and increasing availability... Aurora Replicas connect to the same shared storage volume as the primary DB instance." (Source: AWS Documentation

Amazon Aurora User Guide

"Amazon Aurora DB clusters"

Section: "Aurora Replicas").

2. Amazon Aurora User Guide - Connection Management: "For read-only connections

you can use the reader endpoint. This endpoint provides load balancing for read-only connections to the Aurora DB cluster... The reader endpoint load-balances connections to available Aurora Replicas in an Aurora DB cluster." (Source: AWS Documentation

Amazon Aurora User Guide

"Amazon Aurora connection management"

Section: "Aurora endpoints").

3. Amazon Aurora User Guide - Aurora Auto Scaling: "Amazon Aurora Auto Scaling enables an Aurora DB cluster to automatically adjust the number of Aurora Replicas in response to changes in your workload... You can base the scaling policy on a target value for a predefined metric

such as average CPU utilization or average connections." (Source: AWS Documentation

Amazon Aurora User Guide

"Managing an Amazon Aurora DB cluster"

Section: "Using Amazon Aurora Auto Scaling with Aurora Replicas").

To control user access to EC2 instances via AWS Systems Manager Session Manager based on tags, a two-step IAM configuration is required. First, an IAM policy must be created that explicitly grants the ssm:StartSession permission. This policy must include a Condition element that restricts the permission to only those EC2 instances matching a specific tag key and value. Second, this newly created IAM policy must be attached to the IAM users or groups that require this specific level of access. This combination ensures that only authorized users can initiate sessions and only on the intended, tagged instances.

B. An IAM role is attached to an EC2 instance to grant the instance permissions to other AWS services, not to control user access to the instance.

C. Placement groups are used to influence the physical placement of EC2 instances for performance or fault tolerance, not for managing access control.

D. "Service account" is not the standard AWS term for this context; the equivalent is an IAM role, which, as explained for option B, is incorrect for this use case.

1. AWS Systems Manager User Guide: Under "Limiting access to sessions using IAM policies

" the documentation states

"You can provide users with access to start sessions on managed nodes and limit that access based on tags that have been applied to the nodes... After you create an IAM policy... you can attach the policy to an IAM user

group

or role." This supports both creating a conditional policy (E) and attaching it to a principal (A).

Source: AWS Systems Manager User Guide

Section: "Limiting access to sessions using IAM policies".

2. AWS Identity and Access Management User Guide: This guide details how to use Condition elements in IAM policies to control access based on tags. It provides the syntax and logic for using condition keys like aws:ResourceTag to match tags on a resource. The example policy for Session Manager uses a condition key ssm:resourceTag/tag-key to achieve this.

Source: AWS Identity and Access Management User Guide

Section: "Controlling access to AWS resources using tags".

3. AWS Systems Manager User Guide: The documentation provides a specific example of an IAM policy that grants permission to start a session on any instance tagged with Finance for the Department key. This policy must then be attached to an IAM principal (user or group).

Source: AWS Systems Manager User Guide

Section: "Example 3: Limiting access to managed nodes based on tags".

To establish a federated trust relationship using SAML 2.0 between AWS IAM Identity Center (acting as the Service Provider or SP) and an external Identity Provider (IdP), a two-way exchange of configuration data, known as metadata, is required. The CloudOps engineer needs the IdP's metadata file, which contains its sign-in URL and the public X.509 certificate used to verify SAML assertions. Conversely, the engineer must provide the IAM Identity Center's metadata (such as the Assertion Consumer Service URL and issuer URL) to the IdP administrator to configure the trust on their end. This metadata exchange is a fundamental prerequisite for SAML federation.

C. SAML federation relies on DNS-resolvable endpoint URLs specified in the metadata, not on static IP addresses, which are not a standard or reliable configuration method.

D. While administrative permissions are needed in the management account, root access is not required and violates the security best practice of least privilege. An IAM role with sufficient permissions is the correct approach.

E. The federation with the external IdP is configured centrally within IAM Identity Center in the management account. Administrative permissions in member accounts are not a prerequisite for this specific task.

1. AWS IAM Identity Center User Guide: In the section "Connect to your external identity provider

" the documentation outlines the prerequisites. It explicitly states

"Before you begin

you must obtain the SAML 2.0 metadata document from your IdP. This document is an XML file that includes the IdP's public key certificate

the entity ID

and the IdP's SSO sign-in URL." This directly supports option B.

Source: AWS IAM Identity Center User Guide

"Manage your identity source

" "Connect to your external identity provider."

2. AWS IAM Identity Center User Guide: The same guide details the information that must be provided to the external IdP. It states

"You can find the IAM Identity Center SAML metadata values that you need to provide to your IdP on the View details page... These values include the IAM Identity Center assertion consumer service (ACS) URL and the IAM Identity Center issuer URL." This confirms the necessity of having a copy of this metadata

supporting option A.

Source: AWS IAM Identity Center User Guide

"Manage your identity source

" "Connect to your external identity provider."

3. AWS Security Best Practices in IAM: This documentation emphasizes avoiding the use of the root user for administrative tasks. It states

"Don't use the AWS account root user for your everyday tasks... Instead

create an administrative user for yourself." This principle invalidates the requirement for root access as mentioned in option D.

Source: AWS Identity and Access Management User Guide

"Security best practices in IAM

" "Secure your AWS account root user."

The root cause of the random errors is the incompatibility between the selected routing algorithm and the requirement for session affinity. The weighted random routing algorithm does not support sticky sessions. When both are configured, the load balancer cannot guarantee that subsequent requests from the same user will be sent to the same target instance. This breaks session state for the application, leading to unpredictable behavior and errors.

By changing the routing algorithm to least outstanding requests, the Application Load Balancer can properly implement sticky sessions. This algorithm is compatible with session affinity and will ensure that once a user's session is established with a target, all subsequent requests from that user are routed to the same target, preserving session state and eliminating the errors.

B. Anomaly mitigation is a sub-feature of the least outstanding requests algorithm; it is not a standalone setting and does not address the core routing incompatibility.

C. Disabling cross-zone load balancing alters how traffic is distributed across Availability Zones but does not resolve the conflict between the routing algorithm and sticky sessions.

D. Deregistration delay is relevant for handling in-flight requests when an instance is being deregistered, not for routing errors during normal operation with healthy targets.

1. AWS Documentation: Elastic Load Balancing User Guide - Routing algorithm.

This document explicitly states the compatibility of different routing algorithms with sticky sessions. It notes: "The round robin and least outstanding requests routing algorithms can be used with sticky sessions

while the weighted random routing algorithm cannot." This directly supports the conclusion that the weighted random algorithm is the cause of the issue.

2. AWS Documentation: Elastic Load Balancing User Guide - Sticky sessions for your Application Load Balancer.

This guide explains how sticky sessions work. It states

"Sticky sessions are a mechanism to route requests from the same client to the same target... This is useful for servers that maintain state information in order to provide a continuous experience to clients." This confirms that failing to maintain stickiness would cause the state-related errors described in the question. The choice of a compatible routing algorithm is fundamental to this mechanism.

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

The most effective and automated method to provision a CloudWatch dashboard with an application stack is to define it as a resource within the AWS CloudFormation template. The AWS::CloudWatch::Dashboard resource type is designed for this purpose. An existing dashboard's configuration can be viewed and copied as a JSON object from the AWS Management Console. This JSON is then provided as a string to the DashboardBody property of the AWS::CloudWatch::Dashboard resource in the template. This approach ensures that a new, correctly configured dashboard is created automatically every time the CloudFormation stack is deployed, and its lifecycle is managed with the stack.

A. This is not the most integrated approach. It requires a separate, post-deployment step, making the process less atomic and more complex to manage than defining the dashboard directly within the CloudFormation template.

C. The Ref intrinsic function is used to reference parameters or the logical IDs of other resources within the same stack, not to import or reference pre-existing resources created outside of the stack.

D. The DashboardName property specifies the name for the new dashboard being created. Simply providing the name of an existing dashboard without the required DashboardBody property would be an incomplete definition and would cause a creation failure if the name already exists.

1. AWS CloudFormation User Guide

AWS::CloudWatch::Dashboard resource: This official documentation specifies the syntax for creating a CloudWatch dashboard. It states that the DashboardBody property is required and "is a string that specifies the dashboard body text in JSON format."

Source: AWS CloudFormation User Guide

Resource and property reference

AWS::CloudWatch::Dashboard.

2. Amazon CloudWatch User Guide

Creating a CloudWatch dashboard: This guide explains how to work with dashboards

including how to view the source of an existing dashboard. In the dashboard actions menu

selecting "View/edit source" displays the dashboard's JSON definition

which can be copied for use in the DashboardBody property.

Source: Amazon CloudWatch User Guide

Using Amazon CloudWatch dashboards

Creating a CloudWatch dashboard.

3. AWS CloudFormation User Guide

Intrinsic function reference - Ref: This document clarifies that Ref returns the value of the specified parameter or resource. It is used for composing properties of resources within a template

not for referencing external

pre-existing resources.

Source: AWS CloudFormation User Guide

Template anatomy

Intrinsic function reference

Ref.