AWS Certified Security Specialty SCS-C02 (SCS-C02) — Questions 751–825

Compliance mode prevents any user, including the root account, from overwriting or deleting locked object versions until the retention period expires. This directly satisfies the requirement that logs survive seven years despite users holding full S3 permissions.

A bucket policy in the destination account is the only mechanism CloudTrail uses to authorize cross-account log delivery, so the policy must allow the CloudTrail service principal (cloudtrail.amazonaws.com) to perform s3:PutObject and s3:GetBucketAcl on the bucket. For additional security, restrict the policy with aws:SourceAccount or aws:SourceArn to a specific source account, and when SSE-KMS is enabled, also include kms:GenerateDataKey and kms:Decrypt in the policy.

Enabling MFA for all IAM users is a core AWS security best practice because it requires something the user has, such as a TOTP device or U2F key, in addition to a password or access key. This materially reduces the risk that a stolen password or access key alone can be used to access the account, and AWS recommends MFA for every user including root. MFA protects against credential theft and is an explicit requirement for privileged accounts in many compliance frameworks.

Run the AWS CLI command `aws cloudtrail validate-logs --trail-arn ... --start-time ... --end-time ...` to validate CloudTrail log file integrity. The command downloads the signed digest files, verifies their digital signatures using CloudTrail's public key, and then compares the SHA-256 hash of each log file against the hash recorded in the digest, detecting any modification, deletion, or insertion. This is the only option that cryptographically verifies log integrity and is purpose-built for exactly this scenario.

The correct approach is to designate a delegated administrator account in AWS Organizations for GuardDuty. This delegated admin can enable GuardDuty for all member accounts, manage their detectors, and view aggregated findings centrally without needing per-account invitations. It is the only method that provides a single admin control plane over multi-account GuardDuty coverage and findings.

Modifying the existing rule is the correct action because security group inbound rules are evaluated as an allow list, and changing the source to 203.0.113.0/24 removes the wildcard entry while authorizing only the specified IP range. The update is an in-place edit, so no duplicate rule remains and the stateful security group automatically permits the return traffic for established SSH sessions. The existing rule should be changed rather than appended because any remaining 0.0.0.0/0 rule would continue to allow all source IPs.

AWS WAF integrates directly with the Application Load Balancer, inspecting HTTP requests against rule groups that block SQL injection and cross-site scripting patterns before traffic reaches the EC2 instances. This satisfies the stem's requirement for protection from common web exploits at the ALB layer, filtering malicious payloads inline.

When you create a VPC Flow Log, the destination S3 bucket must be in the same AWS account as the VPC; Amazon VPC does not support publishing flow logs directly to an S3 bucket in a different account. To aggregate logs from member accounts into a central account, you must first deliver them to an S3 bucket in each member account, then configure S3 replication or another copy mechanism to move the logs to the central bucket. Because the company attempted direct cross-account delivery, the flow logs fail to appear in the central destination.

AWS Config can continuously record configuration changes to an S3 bucket policy and evaluate those changes against a managed or custom rule. When a PutBucketPolicy event occurs, AWS Config marks the configuration item as changed and invokes a custom Lambda function, which can in turn publish a message to an SNS topic to notify security teams. This design provides real-time detection and alerting because the Lambda function is triggered by the configuration change, not by a periodic scan.

The Amazon S3 encryption client performs all cryptographic operations locally, encrypting the object's plaintext with a data key before anything is transmitted; the resulting ciphertext and an encrypted copy of the data key are then uploaded. The plaintext data key is never sent to AWS, and you can choose to wrap the data key with a KMS key or an internal master key that remains entirely under your control. This design is exactly what is needed when only the customer should ever possess the unencrypted form of the data.

S3 Block Public Access at the account level is a preventive control that overrides any bucket policy or ACL that would grant public access, while AWS Config managed rules such as s3-bucket-public-read-prohibited and s3-bucket-policy-not-more-permissive provide continuous detective monitoring. Together they address both the existence of public ACLs and public bucket policies, which are the two primary vectors for accidental public exposure. This combination satisfies the security requirement without relying on noisy event monitoring or unrelated threat-detection tools.

A NAT gateway sits in the public subnet with an Elastic IP and performs source NAT, letting private-subnet instances initiate outbound internet traffic for updates while blocking unsolicited inbound connections. This satisfies the requirement to give private subnets internet access without exposing them.

CloudHSM automatically stores encrypted backups of each HSM partition in Amazon S3, and you can schedule backups on a regular basis to protect against hardware failure or cluster loss. These backups capture the HSM's key material and data in an encrypted, point-in-time snapshot that can be restored to a new cluster in the same region. By regularly backing up, you ensure that if the cluster becomes unavailable, you can launch a new cluster and restore the backup, preserving access to the keys. This is the supported disaster-recovery mechanism for CloudHSM.

Because the RDS MySQL instance already has encryption at rest enabled with a KMS key, all automated backups and manual DB snapshots are encrypted automatically using that same KMS key. AWS handles this at the storage layer with no further input from you, so backup encryption is inherently included.

This is the correct immediate response because modifying the security group to remove all inbound and outbound rules—except for a single forensic analysis instance—instantly severs the attacker's network channel while preserving the running instance for investigation. It halts data exfiltration in real time and prevents the attacker from issuing further commands over the network, unlike a snapshot that captures disk state but does not stop ongoing activity. The isolated instance retains volatile evidence like process memory and active network connections, which a forensic analyst can later harvest using controlled, trusted access.

This is the correct and complete solution. For cross-account S3 access, AWS requires that both the resource-based policy (bucket policy) in Account A and the identity-based policy (IAM policy) attached to the user in Account B explicitly allow the s3:GetObject action. The bucket policy grants the Account B principal access to the bucket, while the IAM policy provisions that principal with the necessary action permissions in its own account. Without either side, the request is denied. This dual-policy requirement ensures both the resource owner and the caller's account are aligned.

AWS Organizations is the foundation for GuardDuty's multi-account management: when you designate a delegated administrator and enable GuardDuty for the organization, GuardDuty automatically provisions detectors in all current and future member accounts and centrally aggregates their findings. This native integration lets you onboard new accounts without manual invites and gives you unified visibility through the administrator account, making Organizations the correct answer.

AWS Secrets Manager is a purpose-built service for storing and managing database credentials, API keys, and other sensitive values. It natively supports automatic rotation of secrets using a customizable AWS Lambda function, with one-click integration for Amazon RDS, Redshift, and DocumentDB to rotate the password on the datastore as well. Because it combines secure storage, fine-grained IAM access control, secret versioning, and scheduled rotation, it directly meets the stated requirement for securely storing database credentials with automatic rotation.

A Gateway Load Balancer (GWLB) transparently intercepts traffic using Gateway Load Balancer endpoints, which are VPC endpoints that can be designated as route-table targets. After you deploy the GWLB in one VPC and the security appliances in target groups, you create endpoints in each subnet and update those subnets' route tables to point the Direct Connect prefix or default route to the endpoints. The GWLB then encapsulates traffic using the GENEVE protocol and distributes flows across the appliance fleet, enabling scaling, health checks, and automatic failover while keeping the appliances transparent to the source and destination. This is the standard pattern for inserting a horizontal fleet of third-party security appliances inline for inspection of Direct Connect traffic.

An egress-only internet gateway (EIGW) is a special gateway that enables outbound IPv6 connectivity from a VPC to the internet while blocking any inbound IPv6 traffic. It is the IPv6 counterpart to a NAT gateway, designed for private subnets that need to initiate internet requests without being connetionally reachable. The presence of a route for ::/0 pointing to the EIGW in the private subnet's route table exactly produces the observed outbound-only behavior.

AWS Security Hub is a cloud security posture management service that aggregates security findings from GuardDuty, Inspector, Macie, and other AWS services into a consistent format. It supports cross-account aggregation through AWS Organizations, enabling a consolidated view of threat findings across all accounts. Security Hub also runs continuous security standard checks and enables automated remediation, making it the correct service to centralize GuardDuty findings.

The trust policy, also called the assume-role policy, is attached to the IAM role and grants the external AWS account permission to call sts:AssumeRole, with the account ID listed as the Principal. When the external account's IAM users or roles have permission to use that trust relationship, AWS then issues temporary credentials scoped by the role's permissions policy. This is exactly the cross-account role assumption pattern required to give the external account access.

S3 server access logging produces detailed log records containing the requester, bucket name, object key, action string (e.g., REST.GET.OBJECT), and response status for each API call. Querying these logs with Amazon Athena lets you filter for the 'Anonymous' requester and identify specific objects being read publicly. A scheduled Athena query orchestrated via CloudWatch Events (now Amazon EventBridge) can publish findings to SNS or Lambda, enabling alerting on suspicious read patterns.

AWS CloudTrail is the only service listed that natively records the KMS API calls, including the Decrypt operation used when S3 fetches an SSE-KMS-encrypted object. Each KMS event in CloudTrail includes the key ARN, the IAM identity of the caller, the source IP address, and the encryption context, which together provide the complete audit trail required for security investigations. By default, KMS data-plane events like Decrypt are captured in the CloudTrail event history, and you can optionally set up a trail to deliver them to an S3 bucket or CloudWatch Logs for long-term retention.

The correct approach is to create a custom IAM role with a policy that grants only the required DynamoDB actions (e.g., GetItem, Query) on the specific table ARN, and then assign that role to the Lambda function as its execution role. At runtime, Lambda uses this role to obtain temporary credentials through AWS STS, which are automatically rotated and scoped to the policy. This follows the principle of least privilege because the function can only perform the exact actions on the exact table it needs, minimizing the blast radius of a compromise. It is the AWS-recommended best practice for granting Lambda functions access to AWS services.

Customer managed KMS keys with automatic rotation satisfy both mandates: RDS backups inherit the instance's encryption at rest, and KMS rotates the key annually. AWS managed keys do not offer customer-controlled rotation, so they fail the compliance requirement.

Lambda functions assume an execution role via the service principal lambda.amazonaws.com. The trust policy must allow that principal to call sts:AssumeRole. The permissions policy then grants secretsmanager:GetSecretValue on the secret ARN, enabling the function to retrieve credentials securely without embedding them in code. This is the standard, least-privilege approach for Lambda accessing Secrets Manager.

AWS Config with auto-remediation is the correct choice because it continuously evaluates bucket configuration against a managed rule such as s3-bucket-server-side-encryption-enabled. When a bucket is non-compliant, Config automatically triggers a Systems Manager Automation document, often AWS-EnableS3BucketEncryption, to enable SSE-S3 or SSE-KMS on that bucket. This provides a closed-loop detective-and-remediative workflow that handles both newly created and already-existing unencrypted buckets.

A NAT gateway is a managed AWS service that enables instances in a private subnet to initiate outbound connections to the internet (e.g., for software updates or API calls) while preventing unsolicited inbound connections. It is deployed in a public subnet with an Elastic IP address, and the private subnet's route table sends non-local traffic to the NAT gateway's network interface. This exactly matches the requirement to provide outbound internet access for private subnet instances without exposing them to inbound traffic.

The AWS/SecretsManager namespace provides SecretRotationSucceeded, which is published after each automatic rotation attempt for a secret and increments when the rotation callback completes successfully. The complementary SecretRotationFailed metric reports failures; by using an alarm on SecretRotationSucceeded with a period and statistic appropriate for the rotation schedule, you can detect missed or unsuccessful rotations. Because this metric is emitted by the Secrets Manager service directly from the rotation process, it is the most precise signal for verifying that rotation is working as configured. For example, you can alarm when SecretRotationSucceeded equals zero for the expected rotation interval.

In IAM, the default behavior is to deny access, but that default is overridden by any applicable allow statement from another policy. This policy only allows RunInstances when the specified condition keys match; it does not explicitly deny RunInstances when the conditions are not met. Consequently, if the user has any other identity-based or resource-based policy that allows RunInstances without conditions, the user can still launch non-compliant instances. An explicit Deny statement using a condition like StringNotEquals (or a NotCondition) would be required to block those non-compliant launches, making the missing deny the root cause.

Launching an encrypted RDS instance with a customer-managed KMS key ensures data at rest is protected by an encryption key you create and control. Enabling automated backups provides point-in-time recovery, while a cross-region read replica serves as a disaster recovery target that can be promoted to a primary database in a regional outage. This combination fully meets the requirements for encryption, availability, and automated recovery.

This is the correct solution because it eliminates the unintended public exposure of port 8080 while still enabling the ALB to forward client traffic to the instances on that port. The ALB security group should only permit inbound HTTP/HTTPS on ports 80 and 443, and the ALB listener should be configured with a forward action to the target group on port 8080. Instance security groups should then independently restrict port 8080 to only accept traffic from the ALB security group, preserving a defense-in-depth architecture where instances are not directly internet-reachable.

AWS CloudTrail is the correct choice because it records every management event API call made in your AWS account, including all IAM policy changes such as PutRolePolicy, AttachUserPolicy, DeletePolicy, and CreatePolicy. Each event includes the identity of the caller (user, role, or service), the timestamp, source IP address, request parameters, and response elements, giving you a complete and verifiable audit trail. CloudTrail trails can deliver event logs to an Amazon S3 bucket for long-term retention and optionally to CloudWatch Logs for monitoring. This makes CloudTrail the authoritative service for auditing who changed an IAM policy, when, and what exactly was changed.

By setting the Principal to "arn:aws:iam::111111111111:root", the trust policy authorizes all IAM users and roles within account 111111111111 to assume the role. This root principal syntax is idiomatic for granting an entire account access, including both current and future IAM principals in that account. The policy does not restrict to a specific user or role, so the correct interpretation is that the whole account is permitted.

Attaching the Lambda function to the VPC and placing it in the same private subnet as the RDS instance allows the function's elastic network interface to communicate directly with the database over private IP addresses. This satisfies the security group rules—Lambda can use its own security group to allow inbound traffic to RDS on the database port. There is no need for internet access or NAT, and the connection remains within the private network. This is the recommended AWS pattern for Lambda plus RDS in the same VPC.

AmazonSSMManagedInstanceCore is the AWS-managed policy specifically designed for EC2 instances that need to be managed through Systems Manager and Session Manager. It includes the required actions such as ssm:UpdateInstanceInformation, ssmmessages:CreateControlChannel, ssmmessages:CreateDataChannel, and s3:GetObject for patch retrieval, while excluding unrelated administrative permissions. Applying this policy to an instance role is the recommended least-privilege approach, ensuring the SSM agent can communicate with the control plane without opening the instance to broader AWS management capabilities.

Forcing traffic through Direct Connect requires a Virtual Private Gateway (VGW) attached to the VPC and a private virtual interface (VIF) connecting the Direct Connect connection to that VGW. Once the VGW is attached, you update each subnet's route table with a static route pointing to the on-premises CIDR via the VGW, and you must also enable route propagation from the VGW so that routes are advertised. This ensures that any packet bound for the on-premises network is sent to the VGW and then over the Direct Connect private VIF, bypassing the internet entirely.

Including a statement that allows the account root user full KMS permissions is the standard way to enable IAM policies in that account to control access to the key. Without this, IAM policies alone cannot grant access. This statement effectively delegates control to IAM for principals in the same account, which is necessary for same-account access.

Lambda does not include a built-in AWS service that intercepts and validates event payloads for injection attacks such as SQL, OS command, or NoSQL injection. The correct approach is to implement custom input validation and sanitization inside the function code—for example using allowlists, parameterized queries, and parsing libraries—because only the function itself understands the expected schema and context of its event data.

AWS CloudFormation StackSets with a service-managed permission model centralizes template management in the management account, and the StackSets service automatically creates and manages IAM roles in every target account within the AWS Organization, so end users cannot alter the template or the KMS key reference during deployment. Stack instances are deployed with identical configuration, and updates are controlled by the administrator, ensuring the approved KMS key is consistently used across all accounts. This is an enforceable control because the template content is immutable to users in target accounts, and StackSets provides auditable, repeatable deployments through the Organizations integration.

This is the correct answer because each service plays a specific role in a real-time alert pipeline: CloudTrail captures the API activity from adminrole, CloudWatch Events (now Amazon EventBridge) applies a custom pattern to match events containing that role's ARN or name and forwards them to SNS, and SNS delivers the notification to subscribers. The integration is event-driven and near-real-time, with no need for polling or querying, which makes it the ideal setup for immediate alerts.

Systems Manager Automation is the correct service because it uses automation documents (runbooks) designed specifically to perform operational remediation in a controlled, repeatable way. A runbook can include steps that modify security group rules, stop or isolate EC2 instances, collect diagnostics, or invoke Lambda functions, and it supports IAM roles, approval gates, and rate controls for safe execution. EventBridge rules can trigger these runbooks automatically from security findings, making it the orchestration layer for automated incident response.

A service control policy (SCP) is a feature of AWS Organizations that you attach to the organization root, an organizational unit (OU), or an individual account to centrally set the maximum permissions available to all principals within those accounts. SCPs do not grant permissions; instead, they act as a permission boundary, and their effects are inherited by all child accounts, making them the only option among these that can consistently restrict services across many accounts at once. For example, you can use an SCP to deny the use of a specific AWS service or the ability to leave the organization, which cannot be accomplished with IAM or resource-based policies alone. This makes the SCP the correct choice for organization-wide service restriction.

AWS Network Firewall is a managed stateful firewall that performs packet-level inspection on all traffic traversing a VPC using a Suricata-compatible engine. It supports both intrusion detection (IDS) and intrusion prevention (IPS) modes, with managed or custom rule groups that match against packet signatures, domain lists, and port/protocol patterns. When a stateful rule fires, the service can emit alert logs to Amazon S3, CloudWatch Logs, or Kinesis Data Firehose, making it an AWS-native service that directly detects and alerts on suspicious network traffic.

Creating a suppression rule that matches the vulnerability scanner's IP address is the correct action because GuardDuty suppression rules automatically archive findings from trusted sources without changing your security posture. The rule can be scoped to the specific IP and finding type (or even the specific scanner instance), preventing future false positives while preserving detection of real SSH brute-force attempts from any other source.

AWS Security Token Service (STS) is the service that issues short-lived credentials composed of an access key ID, secret access key, and session token, exactly what an IAM user needs for temporary access. By calling sts:AssumeRole (or GetFederationToken), the developer can request a role's permissions for a configurable duration and receive credentials that expire automatically. This matches the requirement: STS is the correct service for granting temporary access to AWS resources.

The aws:SecureTransport condition key is a global IAM condition that evaluates to true only when the request to S3 was made over HTTPS/TLS. By including it in a bucket policy with a Deny effect, you can reject any HTTP request, thereby enforcing encryption in transit for all S3 API operations. This condition directly addresses the requirement that sensitive data not be transmitted in plaintext.

AWS KMS customer managed keys encrypt logs at rest with granular key policies and audit trails via CloudTrail. This satisfies the secure storage constraint by ensuring only authorised principals can decrypt, and key revocation instantly blocks access.

AWS Single Sign-On (now AWS IAM Identity Center) authenticates users by acting as a broker between AWS and a trusted external identity provider, such as Okta, Azure AD, or a built-in identity store. It validates the user's credentials through the IdP and then issues temporary AWS credentials or federation tokens, making it a fully functional authentication service for workforce users.

SSE-S3 (Server-Side Encryption with S3-Managed Keys) encrypts objects at rest using S3's native AES-256 encryption, where Amazon S3 fully manages the encryption keys on the customer's behalf. When enabled, S3 automatically encrypts all new objects before persisting them and decrypts them on retrieval, with no additional configuration, key management cost, or KMS API usage. It is the simplest and most lightweight way to meet an encryption-at-rest compliance requirement for S3 data.

Once the metric filter confirms that the CreateAccessKey events are being published to CloudWatch, the alarm logic itself is the next layer to inspect. A period that is too long, a threshold set above the number of events in the window, or an inappropriate statistic (such as Average instead of Sum) can keep the alarm in OK even though events are occurring. Also, the alarm must be configured with a ComparisonOperator and EvaluationPeriods that reflect the expected bursty nature of access-key creation; one event in a five-minute period will never breach a threshold of 1 if the metric is evaluated every minute.

Referencing the application instances' security group as the source makes the rule follow the Auto Scaling group automatically, so only those instances can reach the database port. This satisfies the constraint that access be limited to the application tier despite changing instance IPs.

SSE-KMS integrates with AWS KMS to provide granular IAM and key policies that separate permissions for who can use a key (e.g., kms:Encrypt, kms:Decrypt) from who can administer it (e.g., kms:PutKeyPolicy, kms:ScheduleKeyDeletion). Additionally, every KMS API call is recorded in AWS CloudTrail, enabling robust audit trails of encryption key usage—something SSE-S3 cannot offer because S3 manages the keys entirely behind the scenes. This separation of duties and auditability is essential for many compliance frameworks, making it the correct benefit.

AWS Organizations with Service Control Policies (SCPs) is the correct mechanism for centrally managing access because SCPs act as organization-wide authorization filters that cap the maximum permissions for every IAM principal—including the root user—in every member account. You can attach SCPs at the root, organizational unit (OU), or account level, and they apply transitively to all child accounts. SCPs do not grant permissions; instead, they explicitly allow or deny API actions, effectively enforcing common compliance guardrails and permission boundaries consistently across the whole organization.

SSE-KMS encrypts CloudTrail log files with a customer-managed KMS key, giving you explicit control over decryption permissions and key rotation. CloudTrail log file integrity validation then publishes signed digest files containing SHA-256 hashes of each log file, allowing you to cryptographically verify that files were not altered or deleted after delivery. The two features together satisfy confidentiality and tamper detection.

Enable EBS encryption by default establishes that every newly created EBS volume and snapshot is encrypted with the volume's key—the AWS managed key with alias aws/ebs—without requiring per-volume configuration. Because this is an AWS managed key, AWS rotates it automatically and handles the key material, so the company does not need to manage lifecycle or permissions. This satisfies the requirement to encrypt data at rest in the EBS volume directly at the block-storage layer.

Amazon CloudWatch Logs is the managed destination where log data is stored, monitored, and queried; it centralizes log events from EC2, Lambda, and on-premises sources into log groups and log streams. When the CloudWatch agent publishes log records to this service, you can search them with Logs Insights, alarm on error patterns, and export them to S3 for long-term retention.

Centralizing CloudTrail logs in a single S3 bucket is the AWS-recommended architecture for historical analysis. Amazon Athena uses serverless Presto/Trino to run SQL directly over S3 objects, charging only for bytes scanned, which is cost-effective for infrequent deep queries. Partitioning the data by date and converting to columnar formats like Parquet further reduces scan costs and speeds up analysis. This approach avoids provisioning any compute, making it the natural fit for auditing historical events across accounts.

ec2:InstanceType is the IAM condition key specifically intended for restricting the type of EC2 instance a principal can launch, and it can be used with the ec2:RunInstances action. By applying, for example, a StringLike condition of "t3.*" or "t3.micro", an administrator can deny all other instance families and sizes. This key is evaluated as a request-level condition during the RunInstances call, so it directly matches the requirement to control which instance type a user is allowed to create.

Amazon GuardDuty is a threat-detection service that continuously analyzes S3 data-plane events from CloudTrail, using anomaly detection and threat intelligence to identify patterns like unusual object access or credential abuse. When a finding is generated, GuardDuty emits it as an event to the default event bus, where Amazon EventBridge rules can filter on severity or finding type and trigger Lambda, SNS, or other targets for immediate alerting. This pair combines detection and event-driven response, making it the appropriate real-time security monitoring solution for the sensitive S3 bucket.

The iam:PassRole error occurs because the role ARN in the request does not exactly match the Resource element in the policy. IAM evaluates ARNs literally, so any mismatch in account, path, or role name denies the action despite the Allow.

This is correct because the KMS key policy is the authoritative control for who can use the customer-managed key, and CloudWatch Logs calls KMS on behalf of the Lambda function when encrypting/decrypting log data. Adding a statement with Principal as logs.amazonaws.com and a condition using kms:ViaService logs.<region>.amazonaws.com restricts the key's use to calls that come through the CloudWatch Logs service endpoint. To ensure the request is tied to the specific Lambda function, you would also include a condition such as aws:SourceArn matching the Lambda function ARN or an EncryptionContext condition on the log group ARN, so the key cannot be used for unrelated log groups or services.

VPC Flow Logs capture IP traffic metadata for network interfaces in a VPC, including source/destination IP, ports, and protocol. Publishing directly to Amazon S3 requires no agent installation or additional pipeline, making it the lowest-overhead solution. The default format already includes the required fields, and flow logs can be created at the VPC, subnet, or ENI level.

AWS Config continuously records the configuration of supported resources, including Network ACLs and their inbound/outbound rules, as configuration items in a timeline. It then evaluates those config items against managed rules—such as the managed rule 'incoming-ssh-disabled'—or custom Lambda rules that can inspect each NACL entry and mark any ingress rule allowing 0.0.0.0/0 on port 22 as non-compliant. When non-compliance is detected, AWS Config can trigger an Amazon SNS notification for immediate alerting, and it retains a compliance history for auditing, which is exactly what the company needs.

Enabling session logging in Session Manager preferences is the correct approach because it captures the actual interactive session stream—every keystroke, command, and output—and delivers it to centralized destinations such as Amazon S3 and CloudWatch Logs. This configuration is applied at the Systems Manager account level and can enforce audit trails for all sessions, including the ability to search and alert on command history. Without this, there is no native way to retroactively review the commands executed inside a session, making it essential for compliance and forensic requirements.

For cross-account access, the resource owner must explicitly grant the external account or its principal access in the resource-based policy. This policy defines the trust relationship because it specifies who can access the resource and what actions they can perform. Without this allow, the request fails even if the caller has valid IAM permissions in their own account.

Service control policies (SCPs) are the correct mechanism because AWS Organizations lets you attach them to the root, OUs, or individual accounts, where they act as an account-wide permission guardrail. An SCP defines the maximum allowed actions for every IAM principal in the account, including the root user, so it can deny entire AWS services across all enrolled accounts. This central, inherited control does not require touching each IAM role or user individually.

A bucket policy in Account A can specify the Amazon Resource Names (ARNs) of IAM users from Account B in the Principal element, granting them explicit actions such as s3:GetObject on the bucket and its objects. For this to work, those IAM users also need an identity-based policy in Account B that allows the corresponding S3 actions, but the bucket policy is what authorizes the cross-account access at the resource level. This approach is precise, auditable, and follows least privilege because only the named IAM users get access, not any broader principal.

The root user is the only IAM principal that CloudTrail identifies with userIdentity.type equal to Root, and its ARN is always arn:aws:iam::123456789012:root with no session context or userName. The presence of a login event with this type proves the AWS account root user directly authenticated using the account's email and password (plus any MFA), bypassing any identity provider or IAM role. This is exactly what the CloudTrail event indicates.

Security groups act as stateful, instance-level firewalls, and AWS allows one security group to reference another as a source or destination in its rules. By configuring the EC2 security group's outbound rule to destination the RDS security group, and the RDS security group's inbound rule to source the EC2 security group, the two sets of instances can communicate only with each other, without hard-coding IP addresses. Because security groups default to deny-all and automatically allow return traffic, this pattern creates a minimal-privilege channel between the application tier and the database tier, and it self-maintains when instances are replaced or auto-scaled since the rule references the group, not individual instance IPs.

AWS Organizations is a governance service that lets you centrally manage multiple AWS accounts by organizing them into organizational units and applying service control policies (SCPs). SCPs define the maximum allowed permissions for every IAM principal in an account, effectively managing identity and access by creating guardrails at the organization level. This makes Organizations a correct service for managing identity and access across accounts.

A custom IAM policy should be scoped to the exact S3 actions the application requires, such as s3:GetObject and s3:PutObject, and limited to the specific bucket ARNs and optional prefixes. When attached to the instance role, this policy ensures the temporary credentials issued to the EC2 instance can perform only the intended S3 operations, aligning with the least-privilege principle. This is the standard and recommended way to control S3 access for EC2 roles.

The CLI output shows SSEAlgorithm set to 'AES256', which is the exact algorithm identifier that Amazon S3 uses to represent SSE-S3 in a bucket default encryption configuration. With SSE-S3, S3 automatically manages all encryption keys, encrypts each object with a unique key, and wraps that key with a regularly rotated master key, requiring no customer action or KMS involvement. This precisely matches the output shown, confirming that the bucket is configured for SSE-S3.

Designating a GuardDuty delegated administrator in AWS Organizations is the native, recommended pattern because it uses the service's integration with Organizations to auto-enable GuardDuty for every current and future member account via a single API call. The delegated administrator account receives a centralized view of all findings and can configure threat detection policies, while individual accounts retain read access to their own results. This eliminates per-account manual steps and provides a consistent audit trail of enablement state across the organization.