AWS Certified Security Specialty SCS-C02 (SCS-C02) — Questions 1126–1200

Adding a bucket policy with a condition that denies requests when `aws:SecureTransport` is `false` enforces HTTPS by rejecting any HTTP or unencrypted requests at the S3 API level. This satisfies the stem’s requirement to ensure encryption is enforced for data in transit, as the policy explicitly blocks non-HTTPS traffic regardless of the client’s protocol choice.

Amazon RDS Audit Logs are the correct source because they record the actual SQL statements executed against the database, along with the connecting user, source IP, and timestamp. For RDS MySQL or MariaDB, you enable the audit_log plugin via a DB parameter group and then export the logs to CloudWatch Logs; for PostgreSQL, you use the pgaudit extension. Misconfigured database users or SQL injection attempts will appear in these logs, making them the definitive forensic evidence during a security incident.

This is the correct and recommended approach: AWS publishes the complete set of CloudFront IP addresses used to fetch content from origins in the ip-ranges.json file, with a specific service indicator (CLOUDFRONT_ORIGIN_FACING). By adding a security group rule that allows inbound TCP 80/443 only from those CIDR blocks, the ALB will refuse connections from any other public IP, including direct internet clients that bypass CloudFront. You can implement this effectively using a managed prefix list that AWS keeps updated, or by periodically refreshing your security group rules from the published ranges.

The pipeline must call the AWS Security Token Service (STS) AssumeRole API using the pipeline's existing IAM role or a dedicated deployment role, passing the ARN of the target-account role as the RoleArn parameter. STS then returns temporary, automatically expiring credentials (access key, secret key, and session token) that grant exactly the permissions defined in the target role's permissions policy. These temporary credentials can be passed to AWS SDK clients or exported as environment variables so that the deployment commands interact with the target account without human involvement or long-lived secrets.

Amazon Macie is purpose-built to discover and protect sensitive data in Amazon S3, using machine learning and pattern matching to identify personally identifiable information (PII), credentials, and other categories. After you enable Macie, it automatically inventories S3 buckets and continuously evaluates objects for sensitive content, generating alerts when it finds them. This directly aligns with the company's requirement to detect and alert on S3 object content.

Using a customer managed KMS key with EBS encryption is the correct approach because it gives you full control over the key lifecycle, key policy, and permissions, allowing you to restrict access to specific principals or services. EBS encryption uses envelope encryption where a CMK generates a data key to encrypt the volume, and you can audit key usage through CloudTrail. This provides a native, seamless encryption solution for data at rest without requiring application changes, and it supports compliance requirements that mandate customer-controlled keys.

This is the correct pattern because it explicitly denies every request where aws:SecureTransport is false, i.e., plaintext HTTP, while leaving HTTPS requests unaffected and able to be allowed by other statements. An explicit Deny always overrides any Allow, so even a broad bucket policy cannot accidentally permit insecure HTTP traffic. This is the standard, recommended way to enforce TLS for S3 data in transit.

Enabling server-side encryption on the S3 bucket that stores CloudTrail logs ensures that every delivered log object is encrypted at rest, either with SSE-S3 using Amazon-managed keys or with SSE-KMS using a customer-managed key. This directly protects the audit trail from being read by anyone who obtains the underlying storage, and it is a core requirement for compliance frameworks that mandate encrypted audit data. CloudTrail supports SSE-KMS through its own integration, allowing you to control the encryption key separately from the bucket.

The trail delivers logs to S3 only if the bucket policy, KMS key policy, and CloudTrail service principal have the required permissions. If delivery fails, events will not appear in S3 even though the trail is enabled. Checking the bucket for the expected prefix and recent timestamps confirms whether the trail is actually delivering, which directly addresses the discrepancy before assuming attacker evasion.

The srcaddr field in VPC Flow Logs records the source IP address of the traffic. For outbound flows, this is the private IP address of the EC2 instance's network interface that generated the traffic. Because the question asks to identify the instance that sent the suspicious traffic, srcaddr is the correct field to filter on; it uniquely points to the originating instance within the VPC.

The AWS Region where the API call was made is a definitive field in CloudTrail's event history (the awsRegion attribute), whereas VPC Flow Logs are tied to a specific VPC and only describe traffic within that VPC's region. An API call's endpoint region may differ from the region of the VPC through which the traffic flows, so only CloudTrail provides this region information.

Enabling AWS CloudTrail to log KMS API calls provides a detailed audit trail of every kms:Encrypt, kms:Decrypt, GenerateDataKey, and other KMS operation, including the IAM principal, source IP, and request timestamp. This is a detective control that lets security engineers monitor and investigate who is using the key and when, which is the correct approach when the goal is visibility into KMS usage. CloudTrail does not prevent or allow operations, so it complements, rather than replaces, access-control policies.

Setting the target group protocol to HTTPS instructs the ALB to establish a new TLS session with each registered EC2 target rather than forwarding plaintext HTTP. This encrypts the second segment of the request path, so combined with an HTTPS listener the data is encrypted end to end. It directly addresses the missing encryption between the load balancer and the instances, making it the correct action.

An instance profile is a container for an IAM role that you attach to an EC2 instance, and its trust policy allows the EC2 service to assume the role on behalf of the instance. When the instance calls the instance metadata service (IMDS) at 169.254.169.254, it receives temporary security credentials with the role's permissions, and these credentials are automatically rotated before they expire. This eliminates the need to store any long-term access key on the instance, keeps permissions centrally managed, and is the secure AWS-recommended approach for granting instance-level access to resources like S3.

S3 Object Lock in compliance mode prevents any user, including the root user, from deleting or overwriting objects until the retention period expires. This satisfies the requirement for immutability for 10 years. The other options either do not prevent deletion by administrators or do not provide the required retention guarantee.

Enabling multi-factor authentication (MFA) on the management account's root user is a mandatory security best practice because the root user holds unrestricted permissions across the entire organization, including billing and the ability to close accounts. Without MFA, a compromised password or access key for the root user grants an attacker complete control of the organization's structure and member accounts. MFA forces a second authentication factor, mitigating password theft or phishing attacks on that critical identity.

The KMS key policy is the most likely root cause. When a trail is configured with SSE-KMS, CloudTrail must call kms:GenerateDataKey and kms:Decrypt on the customer-managed key to encrypt and decrypt log files. If the key policy does not grant these permissions to the `cloudtrail.amazonaws.com` service principal, CloudTrail cannot use that key and silently falls back to encrypting the log files with SSE-S3, which is exactly the observed behavior. You must add a policy statement that allows CloudTrail to use the key, and you may also need to grant the CloudTrail IAM role the corresponding kms:Decrypt permission.

This is the correct policy because it denies all S3 actions (s3:*) when the request is not using secure transport, as indicated by aws:SecureTransport being false. By using Deny on the entire action set and the Bool condition, it ensures that any request over HTTP is rejected, while HTTPS requests remain unaffected. This is the standard AWS recommended pattern for enforcing encryption in transit on an S3 bucket.

An SCP in AWS Organizations can apply a deny to s3:CreateBucket for every principal in the organization by using the condition key s3:x-amz-server-side-encryption to require an encryption header such as AES256 or aws:kms. Because service control policies are evaluated before any IAM policy and apply across the root, OU, or account level, they act as a centrally managed preventive control that blocks the creation of unencrypted buckets in all member accounts. With the correct condition, any request that omits or misconfigures the encryption parameter will be denied, meeting the company's objective.

The AWS IAM Credentials Report is a built-in console or API-generated CSV that inventories every IAM user and the root user, listing each access key's ID, status, creation date, and the exact date and time it was last used. This report is the authoritative source for producing a usage report because it directly provides last-used timestamps without requiring log mining. Generating it is a single action, and it can be refreshed on demand to reflect the most recent activity.

AWS Lambda is correct for the response side of the detect-and-respond workflow. You can configure Lambda as the target of an Amazon GuardDuty finding through EventBridge rules, then execute a custom response playbook—such as isolating the EC2 instance by detaching security groups, stopping the instance, or capturing a forensic snapshot. This serverless execution gives security teams a fast, reproducible, and policy-driven way to contain malware without provisioning a dedicated incident-response server.

CloudTrail is the correct choice because it records StartSession API calls as management events, capturing the IAM principal, source IP, and timestamp of each session request. This gives you a detective control to answer who initiated a session and when, which is essential for security auditing and alerting on unusual activity.

This is the correct least-privilege policy because s3:ListBucket is the only permission needed to list the objects in a bucket, and it must be applied to the bucket ARN (arn:aws:s3:::my-bucket). Unlike object-level actions such as GetObject, ListBucket is evaluated against the bucket resource itself, so adding an object-path wildcard would make the ARN invalid. This statement grants exactly the ability to list keys and nothing else, such as reading or writing object contents.

AWS CloudTrail is the native service that records management events in the AWS control plane, including every IAM policy change such as PutRolePolicy, AttachUserPolicy, and DeletePolicy. Each event includes the requesting principal, source IP, timestamp, and request/response details, giving you a complete audit trail. You can configure a trail to deliver these logs to S3 or CloudWatch Logs for long-term storage, analysis, and alerting on unauthorized IAM modifications.

This is the correct order: first snapshot the EBS volumes to preserve point-in-time disk evidence before any destructive or state-changing action occurs, then detach the instance from the Auto Scaling group so it won't be terminated or replaced by the group, and finally modify the security group by removing all inbound and outbound allow rules to block all network traffic and isolate the host.

DynamoDB encryption at rest integrates with AWS KMS, allowing the use of customer managed keys. This provides control over key policies, enables auditing via AWS CloudTrail, and supports automatic rotation. It requires minimal operational effort because DynamoDB manages the encryption and decryption transparently, and KMS handles key management, meeting all requirements.

This is correct because the CloudWatch Logs Insights query uses `filter @message like /ERROR|WARN/` to match any log event containing either substring, and then `sort @timestamp desc | limit 20` orders by timestamp descending and returns the 20 newest matching events. That combination of a regex-style filter and a descending sort with a limit accomplishes exactly the stated goal, making it the only option that describes what the exhibited query does.

Amazon CloudWatch Logs acts as the aggregation and monitoring layer for Route 53 Resolver query logs. The resolver service can publish DNS query logs directly to a CloudWatch Logs log group, where you can create metric filters and subscription filters to detect suspicious queries. CloudWatch Logs supports near-real-time querying with Logs Insights, making it a central destination for ongoing monitoring.

AWS CloudTrail is the correct answer because it records management events for all API calls made in your account, including ec2:AuthorizeSecurityGroupIngress, ec2:RevokeSecurityGroupIngress, and ec2:CreateSecurityGroup. Each event captures the identity of the caller, the source IP address, and a timestamp, giving you full attribution for who changed a security group rule and when. This makes CloudTrail the go-to service for auditing who took a specific action against a security group, which directly answers the requirement to monitor for unauthorized changes.

The 10.0.0.0/8 CIDR block is the entire RFC1918 Class A private address space, covering every possible 10.x.x.x network used by VPCs and internal environments. Opening SSH to this range allows any compromised host in that vast address space to attempt to connect to the instance, which is an unnecessary and overly permissive ingress rule. Best practice is to scope SSH to a specific management CIDR or single IP to maintain least privilege.

The key policy's Allow for kms:Decrypt is explicitly conditioned on kms:ViaService matching the S3 service endpoint, for example s3.us-east-1.amazonaws.com. When the call is made directly to KMS or through any service other than S3, that condition key does not match. Since the condition is false, the Allow is not applied and KMS returns AccessDenied. The decryption therefore fails precisely because the request did not come via Amazon S3.

The Deny statement blocks requests from IPs not in the allowed range.

The aws:SecureTransport condition key evaluates the request's protocol, so denying when it is false blocks any plain HTTP request to the bucket. This enforces TLS for data in transit between the on-premises application and S3.

AWS CloudTrail is the authoritative audit service that records API calls made in your account, including the exact access key ID that signed each request. By querying CloudTrail events with the compromised access key ID, a security engineer can reconstruct the attacker's actions, identify which AWS resources were accessed or modified, and determine the scope of potential data exposure. This read-only forensic step does not alter the environment and should be performed immediately to capture evidence while the trail is still available.

AWS Config configuration history is the correct choice because it records the complete configuration of supported AWS resources, including security groups, whenever a change occurs. Each configuration item is timestamped, so you can retrieve the exact set of security group rules at any point in time, including during the incident. This provides a reliable, auditable point-in-time state without needing to reconstruct it from API calls or traffic logs.

Amazon CloudTrail is the authoritative source for S3 API activity, capturing both management events (e.g., CreateBucket, DeleteBucket) and, when enabled, data events for object-level actions such as PutObject, GetObject, and DeleteObject. By delivering those CloudTrail logs to Amazon CloudWatch Logs, you can create metric filters and alarms for real-time monitoring of API calls, making this the correct combination for a complete S3 audit trail.

The CloudWatch agent needs IAM permissions to publish metrics to CloudWatch; specifically, the instance's attached IAM role must include cloudwatch:PutMetricData. The managed policy CloudWatchAgentServerPolicy grants this permission, and without it the agent can collect data but every publish attempt is denied by CloudWatch, resulting in no metrics appearing in the console.

This is correct because the user successfully authenticated to IAM Identity Center (the portal loaded and they can log in), but the portal only displays AWS accounts to which the user has been explicitly granted access. In IAM Identity Center, administrators must create an account assignment that pairs a principal (user or group) with a permission set for a specific AWS account. If no such assignment exists for this user, the login succeeds but the account list is empty, so the user sees no accounts to choose from.

NODATA means the capture window closed with no matching packets, which is common for flows that are logging only accepted or only rejected traffic. REJECT means packets were observed but denied by a security group, network ACL, or similar control, so the connection attempt is visible in the record.

ECS Exec uses the ExecuteCommand API to open an interactive shell in a running container without opening inbound ports, allowing you to run forensic utilities like 'dd' or 'gcore' to capture volatile memory from inside the container's PID namespace. Before the task is stopped, you can also snapshot the task's ephemeral storage by copying files to an external volume or using an EBS-optimized instance to preserve the disk state. This preserves both volatile and persistent evidence, unlike stopping the task first.

AWS CloudTrail is the correct choice because it is the native AWS service for recording management events such as the CreateRole API call, capturing the requesting IAM principal, source IP, request parameters, and timestamp. By default, CloudTrail logs management events for all IAM actions, and you can deliver these logs to an S3 bucket or CloudWatch Logs for long-term retention and analysis. This makes CloudTrail the authoritative audit trail for answering 'who created this IAM role and when'.

Service Control Policies (SCPs) are organization policies attached to the AWS Organizations root, an organizational unit, or an individual account, and they apply to every IAM principal—including the root user—within the affected accounts. An explicit Deny in an SCP overrides any Allow generated by identity-based, resource-based, or permissions-boundary policies, but an SCP itself never grants permissions. This makes SCP the correct choice for an account-wide, centrally managed restriction that cannot be bypassed by individual principals.

Enabling automatic key rotation in AWS KMS for the customer-managed KMS key used by RDS meets the data protection requirement with minimal operational overhead. AWS KMS rotates the cryptographic backing key each year while keeping the same KMS key ID, so the RDS instance, its storage, and all future snapshots continue using the same key reference with zero manual intervention. Existing data remains decryptable via the previous backing key, and new writes automatically use the new backing key, providing continuous protection.

Recording the date, time, and digital signature of the acquisition is a cornerstone of establishing chain of custody, demonstrating exactly when the dump was taken and by whom. A digital signature binds the acquisition record to the responder and protects against later allegations that the evidence was fabricated or altered during collection. This documentation is distinct from, but complements, the hash verification that protects the integrity of the dump file itself.

AWS Security Hub cross-account aggregation in the management account consolidates findings from GuardDuty, Inspector and Security Hub across every member account into one pane, satisfying the centralized-view requirement. It uses the Organizations management account as the aggregation administrator, avoiding per-account tooling or duplicated dashboards.

An explicit Deny statement always overrides any Allow in IAM policy evaluation. The simulate-custom-policy output returning explicitDeny confirms a matching Deny statement exists for ec2:RunInstances, so the request is blocked regardless of any Allow statements present.

An explicit deny statement using the condition 'aws:MultiFactorAuthPresent' equals 'false' will reject any IAM user request that did not authenticate with MFA. Because AWS IAM evaluation logic gives explicit deny precedence over every allow, this pattern universally blocks non-MFA access while still permitting MFA-authenticated requests. Correctly scoped, this is the standard and reliable way to enforce MFA across all users, including those with other grants.

This is correct because cross-account role assumption requires two halves: the role's trust policy in the development account must list the production account (or the user ARN) as a trusted principal, and the user in the production account must have an IAM identity policy that explicitly grants sts:AssumeRole against the development role's ARN. Without this identity-side permission, the user is not authorized to call AssumeRole even though the role trusts the account. Attaching the policy to the user therefore completes the authorization chain and allows the user to receive temporary credentials for the development role.

The aws:SourceVpce condition key is the correct way to restrict an S3 bucket to requests that came through a specific VPC endpoint. You write it in the bucket policy's Condition block using StringEquals and set the value to the full VPC endpoint ID, such as vpce-0abcdef123456789. Because this key is present in the request context only when the request traffic actually travels through the specified VPC endpoint, it gives the most precise endpoint-level control among the listed options.

AWS Config continuously records the configuration state of security groups, including each ingress and egress rule change, and can deliver configuration-history timelines and compliance snapshots. AWS CloudTrail captures the API actions that initiate those changes, logging the principal, user agent, and request parameters for every management event. Together they provide both the 'what' (configuration state via Config) and the 'who/when/how' (API activity via CloudTrail), enabling a complete audit trail of security group changes. For example, when a rule is removed, Config shows the new state while CloudTrail reveals the identity of the caller.

When you create a CloudTrail trail in the management account with the 'Apply trail to my organization' option enabled, CloudTrail automatically creates and configures trails in every member account, delivering all management events to a single S3 bucket. The trail is managed centrally by the organization management account, and any new accounts that join the organization are automatically included without additional manual setup. This provides the lowest operational overhead and ensures comprehensive, centralized logging of API activity across the entire AWS organization, which is exactly what the requirement demands.

AWS Systems Manager Incident Manager is purpose-built to manage the full incident lifecycle—it creates an incident record, routes notifications to on-call responders, aggregates related findings, and provides a status page. Systems Manager Automation publishes runbooks (SSM documents) that can perform defined remediation steps, such as isolating an EC2 instance or revoking IAM permissions, either automatically for pre-approved actions or with manual approval. Together they give a security team a closed-loop incident response capability that can reduce mean time to respond and maintain a post-incident audit trail.

A CloudTrail trail defaults to recording only management events, which cover control-plane operations such as creating or deleting buckets, not data-plane operations like deleting objects within an S3 bucket. Object-level S3 activities, including DeleteObject and PutObject, are classified as data events and must be explicitly enabled using data event selectors in the trail configuration. Since only management events are being logged, the DeleteObject API calls will not appear in CloudTrail event history, matching the scenario exactly.

For cross-account S3 access, the IAM role must have an identity-based policy that explicitly allows s3:GetObject on the target bucket. Even if the bucket policy trusts the role, the role's own permissions are evaluated independently; without that allow, the request fails with Access Denied. This is the classic root cause of this scenario.

CloudTrail event history is a built-in feature that provides a view of the last 90 days of account activity, and this retention period is not configurable. Once an event is older than 90 days, it is no longer visible in event history, and the only way to retain it is to configure a trail that delivers CloudTrail log files to Amazon S3 (and optionally CloudWatch Logs) with a suitable lifecycle policy. This 90-day limit applies uniformly to all management events, regardless of the client, region scope, or whether the calls are read-only or write-only.

aws:PrincipalOrgID is a global IAM condition key that compares the unique organization ID of the principal's AWS account to the value you specify. In an S3 bucket policy, setting "aws:PrincipalOrgID": "o-12345" allows any principal from any account within that organization to deliver logs, automatically covering new accounts as they join. Because it operates on the principal's organization rather than the request source, it is the most scalable and appropriate condition for this cross-account logging scenario.

Multi-Region keys are a set of interoperable KMS keys in different Regions that share the same key material and key ID. They allow data encrypted in one Region to be decrypted in another without re-encryption. Creating a primary key and a replica in the second Region provides availability and low-latency access, meeting all requirements.

To satisfy a 90-day rotation requirement, you must perform manual key rotation by creating a new KMS key every 90 days and then re-encrypting your EBS volumes with that new key. A typical scripted approach creates an encrypted snapshot of each volume using the new key, creates a new volume from that snapshot, and attaches it to the instance after detaching the old volume. This changes the actual key ID and re-encrypts the volume data, which is the only way to meet a sub-yearly rotation schedule because KMS automatic rotation only occurs every year.

Amazon EventBridge is a serverless event bus that can consume AWS service events, including CloudTrail API call events, via a custom or the default event bus. You can define fine-grained event patterns that match specific API actions, resources, or principals, and route matched events to targets like Lambda, SNS, or SQS with low latency. This event-driven mechanism is exactly what enables real-time notifications when a specified AWS API call occurs.

An explicit deny in the S3 bucket policy takes precedence over any allow granted by the IAM policy attached to the role. When the role attempts to access the bucket, S3 evaluates the bucket policy alongside the IAM policy; if it contains a Deny statement that applies to the role's ARN (or any principal that includes the role), the request fails with AccessDenied. This is the most direct cause here because the role and instance are otherwise correctly configured, isolating the issue to the resource policy.

AWS CloudTrail is the service designed to record API activity across AWS, capturing the identity of the caller, source IP address, event time, request parameters, and response elements for management events by default. You can create trails that deliver compressed event logs to an Amazon S3 bucket, CloudWatch Logs, or CloudTrail Lake for long-term retention and analysis. For complete coverage, use a multi-region trail with management events enabled and add data events for S3, Lambda, and other services as needed, because CloudTrail is the authoritative source for ensuring all API calls are auditable.

AWS WAF is a web application firewall that monitors and filters HTTP(S) requests based on conditions like IP reputation, country, URI, and SQL injection signatures. When integrated with AWS Shield Advanced, it provides the primary mechanism for application layer (L7) DDoS mitigation—enabling you to add rate-based rules and block anomalous traffic before it reaches the origin. This direct, request-level inspection makes it the correct option for protecting a web application.

Cross-account access requires two sides: the target account's role trust policy naming the source account as principal, plus a permissions policy granting the needed actions. The source account must additionally let its users call sts:AssumeRole, otherwise the role cannot be assumed.

Amazon Inspector is a vulnerability management service that automatically scans Amazon EC2 instances, container images in Amazon ECR, and Lambda functions for software vulnerabilities and unintentional network exposure. It assesses the OS and application packages against known CVE databases and CIS benchmarks, producing a risk score. This is precisely the security assessment tool suited for checking compute workloads for weaknesses.

CloudWatch Logs supports server-side encryption with customer-managed KMS keys (CMKs). When you associate a CMK with a log group, the service uses envelope encryption: it calls KMS to generate a data key that encrypts your log data, and that data key is then encrypted by the CMK. To control access, you must configure both the KMS key policy and IAM policies that grant or deny actions such as kms:Decrypt and logs:DescribeLogGroups. This is the only method natively supported by CloudWatch Logs for customer-controlled encryption keys.

KMS allows you to create a customer managed key with your own cryptographic key material rather than using AWS-generated bytes. This import capability is essential for organizations needing to retain exclusive control over key material to satisfy regulatory or compliance mandates. However, once you import key material, you cannot enable automatic rotation of that KMS key, so you must plan for manual rotation or replacement.

A VPC Gateway Endpoint for S3 uses the AWS-managed prefix list (com.amazonaws.<region>.s3) as a route-table target in the private subnet, so traffic to S3 stays on the AWS backbone and never leaves the VPC. Instances do not need public IPs, NAT, or an internet gateway, and gateway endpoints do not incur hourly charges. Configuring the route table and endpoint policy enables the private instance to download patches from selected S3 buckets securely without altering the instance's public/private status.

CloudTrail records all API activity in your account—who made the call, from which IP, when, and with what outcome—enabling you to audit for suspicious behavior like new keys or unusual regions. But simply enabling CloudTrail is not enough; you must actively monitor the logs via CloudWatch Logs, Athena, or a SIEM. This is a detective control, not a preventive one, so it requires continual human or automated review to catch anomalies.

Creating a gateway VPC endpoint for DynamoDB gives the Lambda function's subnet a private route to the DynamoDB service, avoiding the public internet and any need for a NAT gateway. The Lambda execution role should carry an identity policy with the specific DynamoDB actions and resource (table ARN) so the function is both network-reachable and authorized to perform the operation. This combines the correct network path with the correct IAM authorization, and the endpoint works through a route-table prefix list rather than an ENI in the function's subnet.

AWS CloudFormation StackSets with automatic deployment is the proactive, organization-native solution because it deploys a CloudTrail template to all current accounts and automatically to any new accounts that are added later. Using service-managed permissions, StackSets creates the trail, the logging S3 bucket, and the necessary IAM role in each account without custom code or manual steps. This ensures CloudTrail is enabled before any activity can occur in a new account, since the stack set rollout happens as part of account creation and organization integration. It is declarative, idempotent, and centrally managed from the management account.

This is the exact IAM action that authorizes the RunInstances API call, which provisions one or more EC2 instances along with associated root volumes and network interfaces. The action can be scoped with condition keys such as ec2:SubnetId to restrict launches to specific subnets, and it is the only action listed that creates the underlying compute resource. Therefore, this is the correct permission for allowing a developer to launch EC2 instances.

Enabling an AWS CloudTrail organization trail in the management account automatically delivers log files for all accounts in the AWS Organization to a single S3 bucket, centralizing API activity without per-account setup. Amazon EventBridge can then ingest CloudTrail events and use rules to match specific API calls, triggering automated responses via targets like Lambda functions, Step Functions, or SNS topics. This native integration provides real-time, account-wide monitoring and response, making it the recommended and most scalable pattern.

AWS Site-to-Site VPN is the correct service because it builds an encrypted IPsec tunnel between a customer gateway and a virtual private gateway, encrypting all traffic in transit across the public internet. It uses IKE for key exchange and IPsec protocols like ESP to provide confidentiality and integrity for every packet. This directly satisfies the requirement to ensure all data transferred between the company's network and AWS is protected.

A CloudWatch Events rule (now Amazon EventBridge) can use an event pattern matching the iam:CreateAccessKey API call emitted by CloudTrail, specifying source as 'aws.iam' and eventName as 'CreateAccessKey'. The rule can invoke an SNS topic within seconds of the API call, allowing immediate email, SMS, or Lambda-based notifications. This is the only option that is event-driven, real-time, and precisely scoped to the security-sensitive action of creating an IAM access key.