Design Solutions for Organizational Complexity

The correct solution is to configure Amazon EventBridge rules to capture Trusted Advisor check status change events from the AWS Health service and route them to Lambda functions.

AWS Trusted Advisor integrates with AWS Health, which publishes events to Amazon EventBridge when Trusted Advisor check statuses change. This is the native event-driven approach that the junior engineer suggested. When a Trusted Advisor check transitions between states (green to yellow, yellow to red, etc.), AWS Health automatically generates events that can be captured by EventBridge rules.

This approach provides several key benefits:

1. Real-time event-driven architecture: Events are published immediately when status changes occur, minimizing latency between the change and the automated response - directly addressing the operations director's requirement.

2. No polling required: Unlike the senior engineer's suggestion of polling the Support API every 5 minutes, EventBridge eliminates the need for scheduled polling, reducing operational overhead and ensuring immediate notification of changes.

3. Native AWS integration: EventBridge rules can directly invoke Lambda functions, which can then create ServiceNow tickets, update DynamoDB tables, and publish to SNS topics for team notifications based on check categories.

4. Enterprise Support plan requirement: The company has an Enterprise Support plan, which is required for programmatic access to Trusted Advisor through AWS Health events.

The CloudTrail option is incorrect because CloudTrail monitors API calls, not the actual status change events from Trusted Advisor checks. It would only capture when someone refreshes or queries Trusted Advisor, not when the underlying check status changes.

The CloudWatch Events option mentioning metric threshold breaches is incorrect because Trusted Advisor doesn't publish check status changes as CloudWatch metrics that can be monitored for threshold breaches. Additionally, while CloudWatch Events and EventBridge share similar functionality, the specific integration with Trusted Advisor status changes comes through AWS Health events.

The AWS Config option is incorrect because AWS Config evaluates resource configurations against rules you define - it doesn't natively integrate with Trusted Advisor check results. Trusted Advisor checks are separate from AWS Config compliance evaluations.

The correct answer identifies the fundamental limitation of AWS security groups: security group references only work within the same VPC. When SG-Payments has an inbound rule that references SG-Orders as the source, this rule cannot match traffic coming from instances in a different VPC, even when connected via a transit gateway.

Here's the detailed analysis:

1. Why order-to-inventory works (port 8500): SG-Inventory has an inbound rule for TCP 8500 from 10.10.0.0/16 (CIDR-based), which correctly matches cross-VPC traffic from VPC-Orders.

2. Why order-to-payment fails (port 9500): SG-Payments has an inbound rule for TCP 9500 from SG-Orders (security group reference). Since SG-Orders is in a different VPC (VPC-Orders), this reference doesn't work across VPCs. The rule needs to specify CIDR 10.10.0.0/16 instead.

3. Why inventory-to-payment fails (port 9600): SG-Payments has no inbound rule for TCP 9600 at all. It needs an inbound rule for TCP 9600 from 10.20.0.0/16 to allow inventory instances to connect.

The other answers are incorrect for the following reasons:

• The transit gateway route propagation explanation is invalid because the problem statement confirms transit gateway attachments are active and order-to-inventory communication works, proving routes exist for cross-VPC communication.

• The suggestion about security group sharing on transit gateway is incorrect because AWS Transit Gateway does not have a "security group sharing" feature. Security groups are VPC-level constructs and cannot be shared across VPCs.

• Transit gateway attachments do not have security group associations. Transit gateway attachments are network-level constructs that route traffic between VPCs; security groups are applied to ENIs on instances, not on transit gateway attachments.

The correct answer explains the fundamental principle of how Service Control Policies (SCPs) work in AWS Organizations: SCPs use an intersection model across the organizational hierarchy.

In this scenario, the permission chain works as follows:

1. Root OU: Allows all services (FullAWSAccess)
2. Claims-Processing OU: Explicitly allows only EC2, S3, RDS, and Lambda
3. Claims-Automation OU (child of Claims-Processing): Explicitly allows Step Functions and EventBridge

The critical concept here is that SCPs create a permission boundary through INTERSECTION, not UNION. For any action to be permitted, it must be allowed at EVERY level in the hierarchy from the root down to the account. Even though the Claims-Automation OU explicitly allows Step Functions, the parent Claims-Processing OU does NOT include Step Functions in its allow list.

Since the Claims-Processing OU only allows EC2, S3, RDS, and Lambda, Step Functions is effectively blocked at that level. The child OU's SCP allowing Step Functions cannot grant permissions that the parent OU's SCP has already excluded. The effective permissions are the intersection of all SCPs from root to the account, meaning Step Functions must be allowed at ALL levels.

The second answer is incorrect because SCPs work with both allow and deny statements, and child OUs cannot override parent restrictions regardless of whether they use deny or allow statements.

The third answer is incorrect because SCPs ARE inherited from OUs to accounts. You don't need to attach SCPs at the account level for them to apply - OU-level SCPs automatically apply to all accounts within that OU.

The fourth answer incorrectly describes how SCP conflicts work. The root-level SCP allowing all services doesn't create a conflict - it simply provides the broadest permission set. The Claims-Processing OU then restricts this further. There's no 'highest level takes precedence' rule; instead, it's an intersection of all applicable SCPs.