AWS Certified Security Specialty SCS-C02 (SCS-C02) — Questions 901–975

VPC Flow Logs can be streamed directly to Amazon Kinesis Data Firehose in each account, and Firehose can then deliver nearly real-time data to a centrally owned Amazon OpenSearch Service domain cross-account. This is a fully managed, serverless pipeline that scales automatically with flow-log volume and avoids installing agents or operating log forwarders. A central OpenSearch cluster provides unified querying and visualization across all accounts' VPC traffic, making it the correct architecture for centralized real-time network analysis.

This policy uses an explicit Deny with a Bool condition that matches when aws:SecureTransport is false, meaning "if the request did not arrive over TLS/HTTPS, deny it." Since S3 evaluates this explicit Deny before any Allow, even a statement allowing s3:GetObject cannot override it for HTTP requests. The net effect is that every successful request to the bucket must be made over HTTPS.

CloudHSM is a dedicated hardware security module that provides FIPS 140-2 Level 3 validated, tamper-resistant devices for generating, storing, and using cryptographic keys. Unlike KMS, CloudHSM gives you exclusive, root-level control over your own HSMs and the entire key lifecycle, independent of AWS-operated key infrastructure.

Amazon Athena is the correct choice because it is a serverless, interactive query service that uses standard SQL to query data directly from S3, paying only for the data scanned. VPC Flow Logs stored in S3 can be queried immediately by creating a table in the AWS Glue Data Catalog, with no infrastructure to provision or manage. Athena is optimized for ad-hoc, cost-effective analysis, and its per-query pricing makes it ideal for the intermittent, investigative queries a security engineer typically runs. Partitioning the S3 flow log data by date and using columnar formats further reduces cost and query time.

Amazon GuardDuty is a managed threat detection service that continuously analyzes AWS account activity from VPC Flow Logs, DNS logs, CloudTrail management events, and S3 data events. It uses threat intelligence feeds and machine learning to automatically identify reconnaissance behavior such as port scans, SSH brute-force attempts, or unusual API calls from a suspicious IP range. Enabling GuardDuty and reviewing its severity-ranked findings gives a startup immediate, operational visibility into the attack without deploying agents or writing detection queries, and the findings can be integrated with AWS Security Hub or EventBridge for automated response.

Allowing `iam:UpdateAccessKey` lets the user activate or deactivate their own existing access keys, satisfying the "update" half of the manage requirement. It does not create keys, so it must be paired with `iam:CreateAccessKey`; together these two actions cover the full create-and-update scope the stem demands.

Reverting the bucket policy is the correct immediate action because the CloudTrail event shows a PutBucketPolicy call that assigned public read access (e.g., Principal * and s3:GetObject). The bucket is now publicly readable, so you must restore the previous policy version or edit the policy to remove the public grant. While you should also check S3 Block Public Access settings and audit IAM permissions, undoing the policy change is the direct way to stop the exposure.

Least privilege means constructing IAM policies that explicitly allow only the exact API actions and resources a principal needs for its job function, denying everything else by default. Each Allow statement should enumerate concrete actions such as s3:GetObject on specific resource ARNs rather than using wildcards like s3:* or Action: "*". This minimizes the blast radius if credentials are compromised and ensures that even legitimate users can only perform the minimum operations required to do their work.

This is the correct end-to-end solution: AWS CloudTrail records every management API call and delivers those logs to a CloudWatch Logs log group. A CloudWatch Logs metric filter is then created with a pattern that matches the specific event, for example the eventName or a user identity, and the filter publishes a metric value each time a matching event occurs. A CloudWatch alarm can then monitor that metric with a defined threshold, and when triggered, it sends a notification to an SNS topic, enabling real-time alerting for the exact API call of interest.

Modifying the instance's security group to remove all inbound and outbound rules is the correct containment step because security groups are instance-level stateful firewalls, and deleting every rule immediately terminates existing and new connections while leaving the instance powered on. This preserves volatile memory and running processes for live forensics, and because the change applies only to that security group, other instances and the overall subnet remain unaffected. It is preferable to a NACL change, which would block traffic to the entire subnet.

The CloudTrail event shows the calls were made using the IAM role's temporary credentials but with a sourceIP address that does not match the EC2 instance's IP. Because the role's credentials are obtainable from the instance metadata service (IMDS), if an attacker gains access (e.g., via SSRF) they can extract the credentials and replay them from an external machine, making CloudTrail log that external source IP. This is a classic credential exfiltration scenario, and it explains why the identity is the role while the network origin is elsewhere.

S3 bucket policies are resource-based policies attached to a bucket, so the Resource field must use the S3 ARN format arn:aws:s3:::bucket-name (or an object key pattern). Using an EC2 resource ARN, such as arn:aws:ec2:region:account-id:instance/instance-id, makes the policy invalid for S3 and therefore it does not grant or restrict access. This is the fundamental reason the bucket policy fails, regardless of any condition keys or endpoint configuration.

Amazon GuardDuty publishes a `GuardDuty Finding` event to the default EventBridge event bus whenever a finding is generated. An EventBridge rule with an event pattern that matches finding types, account IDs, or severity can directly invoke a Lambda function as a target, giving you a serverless, near-real-time response path. This is the most idiomatic native integration for GuardDuty because it requires no polling, no extra queue, and gives you full filtering and transformation logic inside Lambda.

CloudFormation StackSets, especially when backed by service-managed permissions, let you deploy the same CloudTrail stack to every account or OU in AWS Organizations from a single template. StackSets create, update, and delete resources in parallel across specified accounts and regions, and they can automatically add new accounts when they join the organization. This gives you a consistent, auditable, and repeatable way to ensure each account has a configured CloudTrail trail, unlike the other options that either merely report or cannot provision resources.

Security Hub natively acts as the central aggregator by ingesting GuardDuty findings and Detective investigation data as standard findings in the AWS Security Finding Format. Once you designate an administrator account and enable cross-account aggregation via AWS Organizations, all member accounts' findings flow into one dashboard with automatic deduplication, enrichment, and integration with EventBridge for remediation. This purpose-built architecture scales to hundreds of accounts without custom polling or log shipping.

This enforces use of the specific KMS key for all operations.

AWS Step Functions is a serverless workflow orchestration service that models security response runbooks as state machines with explicit states for Lambda invocations, AWS API calls, and human approvals. Its built-in retry, timeout, branching, and parallel-execution semantics let the engineer encode conditional decision points and error handling without custom code. This makes it the appropriate service for automating a coordinated, auditable response to CloudTrail events.

An organization trail created in the management account automatically logs API activity across every account in AWS Organizations into one S3 bucket, satisfying the centralisation requirement. Account-level trails would need separate configuration per account and would not aggregate automatically.

Default encryption automatically applies server-side encryption (SSE-S3, SSE-KMS, or SSE-C) to every new object written to the bucket. This is the correct remediation because it guarantees that all future uploads are encrypted at rest, establishing a consistent security baseline. It is a direct control that addresses the requirement to protect sensitive data, and it can be further enforced with a bucket policy denying unencrypted uploads. Note that default encryption does not encrypt existing objects, so those must be handled separately.

ALB access logging is the correct choice because it records detailed HTTP request data—method, URI, requester IP, user agent, latency, and the ALB's response code—for every request the load balancer processes. Since an ALB sits in front of the application's EC2 or container targets, enabling this access log and delivering it to an S3 bucket directly captures the application-level request telemetry needed to analyze client traffic patterns, troubleshoot HTTP errors, and support security investigations.

The web application must explicitly request TLS because RDS defaults to allowing both encrypted and unencrypted connections depending on the client. Adding an SSL/TLS option to the connection string—such as 'sslMode=require' or 'sslmode=verify-full'—forces the client to negotiate an encrypted channel. This is the only option that directly controls the confidentiality of data as it travels from the application to the RDS database.

Creating an AMI of the running instance captures point-in-time snapshots of its EBS volumes, preserving the full disk state without requiring a stop; this enables offline forensic analysis of the root volume and any additional data volumes. Removing the instance from its security group—or applying an empty security group—immediately blocks all inbound and outbound traffic to the instance, containing the compromise while the instance remains powered on with its memory, processes, and network flows intact. This approach gives responders the ability to perform live forensics (such as memory capture) while ensuring the attacker cannot use the instance to move laterally, and it is fully reversible if the instance is later cleared.

An organization trail, created from the management (master) account of AWS Organizations, automatically applies to every account within the organization and is centrally managed as a single trail. CloudTrail delivers log files for the management account and all member accounts to the same S3 bucket, and member accounts cannot stop or modify the trail, preserving a reliable audit baseline. This is the intended, native way to enable CloudTrail across an organization, and it fulfills the requirement with no per-account setup.

AWS IAM Access Analyzer provides centralized visibility into resource-based policies across your account or entire AWS organization by continuously generating findings when a resource is shared with external principals. It examines policies attached to S3 buckets, IAM roles, KMS keys, and Secrets Manager secrets, flagging access from outside your organization's trusted boundary. This makes it a core service for monitoring and managing external permission exposure at scale.

In a GuardDuty finding event, `detail.resources` is an array of resource objects, each containing properties like `arn`, `type`, `id`, and `partition`, rather than a flat JSON object. If the event pattern is written with `resources` as an object, such as `detail.resources.arn`, it will not match because CloudWatch Events compares the pattern against the actual array structure. An array field must be matched using an array pattern, for example `"resources": [{"arn": []}]`, so the Lambda is never invoked when the pattern has the wrong shape.

AWS WAF is the correct service because it operates at Layer 7 and can inspect every HTTP(S) request forwarded to the ALB, allowing you to block SQL injection, cross-site scripting, and other application-layer attacks via managed or custom rules. It also supports geo-match and rate-based rules, which are essential for a web-facing application. By associating a WAF web ACL directly with the ALB, traffic is filtered before reaching the application, giving you granular control over the actual request content.

OS-level authentication and system logs (e.g., /var/log/auth.log on Linux or the Security Event Log on Windows) record each successful and failed login attempt, source IP, user account, timestamp, and sudo/su command usage. These logs can directly expose the initial access vector, such as an SSH brute-force attack or a compromised credential, and also trace post-exploitation actions like privilege escalation. Because they reside on the instance itself, they contain ground-truth details about what actually occurred inside the compromised system, which no AWS service-level log can provide.

Modify the WAF web ACL rule so it permits requests from the corporate IP range when the URI path is /admin*, while allowing all other traffic to the main application path without restriction. This can be implemented as a rule with a condition combining the IP set source match and a string pattern match for the admin path, with an appropriate action to block non-matching admin requests. This preserves the public availability of the main application and maintains a tight security boundary on administrative endpoints.

This configuration is correct because it applies the principle of least privilege: the web server security group only opens HTTPS to the internet, while the database security group restricts MySQL access to only the web server security group via a security group reference. Security group references are dynamic, so any instance attached to the web server SG is automatically allowed, even as the fleet scales, without needing to update CIDR ranges. This also prevents any other source—including other VPCs or subnets—from reaching the database directly.

Referencing security group IDs as sources enforces tier-to-tier traffic only, so the app tier accepts HTTP solely from the web tier and the database accepts MySQL solely from the app tier. This satisfies the least-privilege constraint without CIDR-based exposure.

AWS CloudTrail is the appropriate service for capturing API activity across AWS. It records management events by default, including actions performed through the AWS Management Console, SDKs, CLI, and other services, and can be configured to log data events for services like Amazon S3 and Lambda. Each CloudTrail event provides the identity, timestamp, source IP, request parameters, and response elements, making it the definitive source for API call auditing.

This policy exactly implements read-only object access by allowing the s3:GetObject action on the objects within the bucket. The resource ARN arn:aws:s3:::my-bucket/* correctly scopes the action to object keys under my-bucket, rather than the bucket itself or all buckets. This grants the user the ability to retrieve object data and metadata while denying writes, deletions, or bucket-level administrative changes.

Security Hub aggregates findings from GuardDuty, Inspector, and Macie across organization accounts when centralized configuration is enabled. EventBridge can match Security Hub findings and invoke Systems Manager Automation runbooks to remediate automatically. This combination provides both centralized aggregation and automated response, directly satisfying the stated requirements for 40 accounts.

When a request is sent to S3 through a VPC gateway endpoint, the bucket policy can explicitly allow it using the aws:sourceVpce condition key, which matches the endpoint ID rather than the client's IP address. Because the policy authorizes that specific endpoint, every request routed through it satisfies the policy, regardless of the source IP. This means an IP-based restriction intended for other sources is effectively bypassed, so this option correctly identifies the root cause.

AWS CloudFormation StackSets deploys the same IAM role template to every member account, and the role is configured with a trust policy that allows the Systems Manager Automation execution role in the security account to assume it. The automation document uses the 'assumeRole' parameter in a step such as aws:executeScript to switch to that member account role, then runs the EC2 ModifySecurityGroup API against local resources. Because StackSets is integrated with AWS Organizations, the role is automatically provisioned when new accounts are added, centralizing governance while keeping permissions scoped per account.

AWS CloudTrail is the correct source because it records management events such as an IAM policy modification, capturing the requesting principal, event time, and source IP. Amazon CloudWatch Events (now Amazon EventBridge) can define an event pattern that matches the specific CloudTrail event name and source, then targets an SNS topic to notify the security team. Together they provide near-real-time, API-level monitoring and alerting for unauthorized changes.

S3 Object Lock in Compliance mode gives each object a write-once-read-many (WORM) retention period, and once a 7-year retention is applied, no user, including the AWS account root user, can delete or overwrite that object version until the period expires. Because Compliance mode is irrevocable for the locked object, even an admin with full permissions cannot shorten the retention or remove the lock. This directly enforces the seven-year audit-log requirement at the S3 API level.

When a customer-managed KMS key is scheduled for deletion, KMS enforces a mandatory waiting period (7 to 30 days, configurable) during which the key can be restored using the CancelKeyDeletion operation, which returns the key to its previous enabled state. As long as the original key is restored before the deletion completes, any ciphertext encrypted under that key—including data keys wrapped by the key—remains decryptable, so your data is not lost. The waiting period is designed exactly for this recovery scenario; after it expires, deletion is irreversible and no recovery path exists.

CloudTrail records identity-plane events such as `ConsoleLogin` (sign-in events) and `sts:AssumeRole` with the source IP address of the caller. If the same IP 203.0.113.5 appears in these events, it directly links the network traffic to authentication or authorization activity, suggesting the IP is an active user or an attacker leveraging compromised credentials. This correlation is the strongest indicator of malicious intent because VPC Flow Logs alone cannot attribute network flows to an IAM principal, whereas CloudTrail can.

Run Command uses the AWS Systems Manager (SSM) agent already installed on the instance to execute a locally supplied script, so you can run a memory acquisition tool like LiME (Linux) or WinPmem (Windows), save the memory image to a file, and upload it to Amazon S3 for analysis. Because Run Command executes without terminating or rebooting the instance, the volatile state is preserved, which is crucial for retrieving running processes, loaded kernel modules, and open network connections. The SSM agent must be running, and the instance profile needs SSM permissions and access to the destination S3 bucket.

Amazon Athena is a serverless, interactive query service that runs standard SQL directly against structured, semistructured, or unstructured data stored in Amazon S3. For AWS WAF logs, which are JSON objects, you can define a table in the AWS Glue Data Catalog and query them with Athena using partitions by date, with no servers or clusters to provision. It is the natural fit for analyzing WAF log files in S3.

AWS Site-to-Site VPN establishes a secure IPsec tunnel between your on-premises gateway and a virtual private gateway or transit gateway in AWS. Using IKEv2 and AES encryption, it encrypts all IP traffic traversing the public internet, ensuring confidentiality and integrity for data in transit. This is a core service for hybrid cloud connectivity and a valid method for protecting data.

GuardDuty continuously analyzes CloudTrail management events, VPC Flow Logs, and DNS logs with threat intelligence to produce findings in near real-time. With a delegated administrator it centrally manages all accounts in the organization. EventBridge delivers findings as events, and a rule can invoke the Lambda function directly for automated remediation with minimal overhead.

GuardDuty continuously detects threats and generates findings that are automatically emitted as events to Amazon EventBridge. An EventBridge rule filters for the relevant GuardDuty finding types and delivers them to an AWS Lambda function, which runs the remediation logic, such as quarantining an EC2 instance or revoking IAM credentials. This serverless, event-driven design provides immediate, automated response without managing underlying infrastructure.

SSE-S3 (server-side encryption with Amazon S3 managed keys) is the correct option because it uses strong AES-256 encryption with keys that are managed entirely by Amazon S3. Each object is encrypted with a unique data key, and the data key is wrapped by a regular rotating S3-managed key. This gives S3 the responsibility for encrypting confidential documents with no additional cost, no key rotation overhead, and no need for the customer to supply or manage keys.

Placing the database in private subnets with no route to an internet gateway removes any path to or from the internet, which directly satisfies the requirement that the database never be internet-reachable. Route table design, not just security groups, is what guarantees the absence of that path.

An IAM role has no embedded long-term credentials such as static IAM user access keys. Instead, it contains a trust policy and permission policies, and when an entity assumes the role, AWS STS issues temporary credentials — an access key ID, a secret access key, and a session token — that expire after a configurable duration between 15 minutes and 12 hours.

This is the correct minimal policy because s3:ListBucket is the exact permission required for the S3 ListObjects/ListObjectsV2 API calls used to list objects and prefixes. The resource is correctly set to the bucket ARN, which is where S3 checks the ListBucket authorization; object-level ARNs like arn:aws:s3:::my-bucket/* are not valid for this action. It is least-privilege because it grants only the ability to list, with no object-level read, write, or delete permissions and no bucket administrative rights.

Amazon CloudWatch Logs is incorrect because it primarily serves as a destination for log streams within individual AWS accounts, providing real-time monitoring and analysis capabilities. While CloudTrail, VPC Flow Logs, and DNS logs can be directed to CloudWatch Logs, it lacks a native, managed mechanism to centrally *collect and aggregate* these log types *from multiple accounts* within an AWS Organizations structure into a single logging account. It is tempting because CloudWatch Logs is a core log management service, ideal for operational visibility, metric extraction, and alerting on logs *per account*, or for smaller-scale log storage.

Restricting kubectl access through AWS IAM authentication is correct because it integrates IAM identities with Kubernetes RBAC, allowing precise mapping of IAM users and roles to cluster permissions. This avoids shared static credentials and ensures that only authenticated AWS principals with an explicit RBAC role can execute kubectl commands against the EKS cluster.

This is the AWS-recommended architecture for automated, cross-account GuardDuty response. GuardDuty publishes findings as EventBridge events, and because you are using a delegated administrator, you can centralize an EventBridge rule in that administrator account to capture findings from all member accounts. The triggered Lambda then assumes an IAM role in the specific affected member account (via the role's trust policy) to make the EC2 'isolate' API calls (e.g., stopping the instance or applying a security group) without requiring credentials stored in the Lambda. This pattern keep the response logic centralized, avoids per-account Lambda copies, and follows the secure cross-account role assumption model.

An organization trail is created only in the management account (or delegated administrator) and automatically applies to all accounts in the AWS organization, with no per-account setup required. It records management events across all accounts, including AWS Organizations control-plane operations like CreateAccount and AttachPolicy, and delivers the aggregated logs to a single S3 bucket in the management account. This is the correct way to centrally collect CloudTrail logs for governance and compliance.

AWS Backup is the correct choice because it natively supports scheduled backup plans, retention management, and cross-account backup copy in a single service. By enabling the AWS Backup organization feature, you can centrally define backup plans and automatically apply them to resources across all accounts, with copies delivered to the forensics account. The service also handles encryption with KMS keys, monitoring with CloudWatch, and audit trails via CloudTrail, which is essential for a defensible forensic process.

Attaching the MFA enforcement policy to every IAM user, or to a group that all users belong to, is the required deployment step: IAM policies have no effect until they are attached to an identity. Using a group is the most maintainable approach because new users added to the group automatically receive the policy, and it prevents individual users from being missed. This distribution is what makes the deny-unless-MFA condition universally enforced across the account.

AWS Organizations with Service Control Policies (SCPs) is the correct choice because SCPs are centralized policy documents that attach to the organization root, organizational units, or individual accounts and define the maximum allowed permissions for all IAM principals in those accounts. SCPs act as guardrails that restrict what services and actions can be performed, and they are enforced by a central governance layer independent of the account's local IAM administrators. Because SCPs are managed from the management account of the organization, they provide a single point to centrally administer and enforce security policies across every member account.

The ability to pass a role (iam:PassRole) combined with permission to launch EC2 instances (ec2:RunInstances) lets the instance specify a different, more privileged IAM instance profile at launch. Because the PassRole permission is often granted broadly without restricting which roles can be passed, the current instance can create a new instance carrying permissions beyond its own, thereby escalating privileges within the account.

The explicit Deny statement is skipped because the request uses HTTPS and thereby satisfies the secure-transport condition, but that only removes a blocking rule. The sole Allow statement, however, is conditioned on the request's source IP being in the specified allowed range, and this request's source IP does not fall within that range. Since the request does not match the condition of any Allow statement, no explicit allow applies, and AWS IAM falls back to the default implicit deny. The request is denied for exactly that reason: no explicit allow matches it.

Security groups are stateful and support referencing other security groups as a source, allowing an inbound rule on the database security group to permit traffic only from instances associated with the web security group on port 3306. This removes the need to track instance IP addresses or rely on broad CIDR ranges, and it automatically scales with the web tier's launch or termination. Because security groups are stateful, return traffic from the database to the web tier is implicitly allowed, reducing operational overhead while maintaining least-privilege access.

Amazon CloudWatch Logs is the correct central service for storing, monitoring, and analyzing OS logs collected from EC2 instances. It receives log data forwarded by the CloudWatch agent and organizes it into log groups and log streams, enabling real-time searching, metric filters, alarms, and querying with Logs Insights. Once OS logs are ingested, the engineer can use CloudWatch Logs to correlate events across instances, build dashboards, and set automated alerts, making it the core analysis platform for the collected logs.

AWS WAF's SQL injection match condition inspects HTTP request components—such as the URI, query string, body, cookies, and headers—for known malicious SQL patterns using transformations like URL decode and lowercasing to evade bypass attempts. Setting the rule action to Block causes the AWS WAF web ACL to terminate matching requests before they reach the protected resource, which is exactly the correct mechanism for preventing SQL injection attacks at the application layer.

The Principal element in a KMS key policy identifies the IAM role, user, service, or account that is explicitly granted permission to use the key. For example, the ARN of an IAM role is placed here so that role can call kms:Encrypt or kms:Decrypt. Since the question asks who can use the key, Principal is the correct answer.

The generate-credential-report command starts an asynchronous job in IAM, and then get-credential-report downloads the completed CSV file. The report contains columns such as access_key_1_last_rotated, access_key_2_last_rotated, and password_last_rotated, which directly provide the age of every key and password in the account. This is the standard, account-wide method for determining stale access keys and exactly satisfies the need to identify the age of a user's access key.

AWS CloudTrail is the native audit service that records API activity in your account. Every supported management event and, if enabled, data event is captured with details like the IAM user/role, source IP address, time, request parameters, and response elements. CloudTrail delivers encrypted log files to an S3 bucket and optionally CloudWatch Logs for long-term retention and analysis, making it the correct service for ensuring all API calls are logged.

The PublicAccessBlock configuration is missing the BlockPublicPolicy setting, so S3 does not reject the bucket policy that explicitly grants public read access. When BlockPublicPolicy is not enabled, a bucket policy allowing public access is evaluated as valid and takes effect, making the bucket publicly readable. Enabling BlockPublicPolicy would cause S3 to deny the policy request and preserve the bucket's private access, thereby eliminating the public exposure.

The observed egress traffic to a suspicious external IP is an indicator, but the only way to determine whether the instance is actually compromised is to inspect the operating system itself. Using a secure channel such as AWS Systems Manager Session Manager, you can examine running processes, active network sockets, scheduled tasks, and persistence mechanisms for malware, crypto miners, or reverse shells. This host-level triage is the correct immediate next step because it directly establishes the root cause and preserves forensic evidence before taking any broader network or DNS-based action.

Attaching an IAM role as the Lambda function's execution role is the recommended pattern. In the role's trust policy you allow the Lambda service principal, lambda.amazonaws.com, to assume the role; the role's permissions policy then grants the minimal DynamoDB actions needed, such as GetItem or Query. Lambda automatically calls sts:AssumeRole and obtains short-term credentials, so no long-lived keys are ever stored in the function.

For cross-account access, S3 requires an explicit allow from both the resource-based policy (the bucket policy in Account B, which is already in place) and an identity-based policy on the IAM user in Account A. The IAM user's permissions are evaluated separately, and even though the bucket policy grants the Account A root access, the user does not inherit that permission without an explicit identity-based allow. Attaching a policy that grants s3:GetObject on the specific bucket is the necessary, minimal step to complete the authorization chain.

This is the correct policy because it uses `StringNotEquals` on the `s3:x-amz-server-side-encryption` header to deny any upload that does not specify `aws:kms`. Requests that omit the encryption header or use `AES256` (SSE-S3) will have a condition that evaluates to true, triggering the Deny, while requests that explicitly send `aws:kms` are permitted. This narrowly enforces SSE-KMS for all new objects without blocking compliant uploads.

AWS CloudTrail records every API call made by an IAM user or role, and delivering those trail events to Amazon CloudWatch Events (now EventBridge) enables custom rules that match exact API actions and principals. A rule can filter on eventName, userIdentity, and request parameters, then invoke an SNS topic to notify the security team in near real time. This is the only option that directly reacts to specific API activities rather than aggregate state or threats.

Amazon EventBridge is the correct trigger because GuardDuty natively publishes all findings to the EventBridge default bus as events. A security engineer can create a rule with an event pattern matching GuardDuty finding types, then set a Lambda function as the target to automatically remediate or alert. EventBridge provides real-time, serverless event delivery without custom polling, making it the designed integration point for GuardDuty findings.

The correct solution is AWS Config with a managed rule such as s3-bucket-server-side-encryption-enabled, which continuously evaluates whether each bucket has default encryption enabled. When a bucket is noncompliant, AWS Config can invoke auto-remediation using an SSM Automation document like AWS-EnableS3BucketEncryption to apply SSE-S3 or SSE-KMS. This provides both detection and automated correction, unlike event-driven or logging-only approaches.

This pair is correct because reading a KMS-encrypted S3 object is a two-step operation: S3 GetObject retrieves the ciphertext from the bucket, and KMS Decrypt decrypts the envelope-encrypted data key so the object's contents are revealed. The s3:GetObject permission allows the actual read of the object, while kms:Decrypt grants the ability to unwrap the key that protects that object. Together they provide exactly the read-only access required.

CloudTrail delivers a record of every AWS API call, capturing the requesting principal, source IP, user agent, and request parameters, regardless of whether the call succeeded or was denied. Security teams can analyze these logs to detect unauthorized attempts, such as AccessDenied errors, calls from unexpected identities or regions, or anomalous API patterns. This detective capability is often combined with Amazon GuardDuty or Athena queries to surface suspicious activity that would otherwise go unnoticed.

Enforcing HTTPS for web traffic is a critical best practice because HTTPS runs HTTP over TLS, providing confidentiality, integrity, and server authentication for every request and response. Redirecting all HTTP requests to HTTPS and applying HTTP Strict Transport Security (HSTS) ensures clients never send or accept plaintext web communication, mitigating man-in-the-middle and session-hijacking attacks. This should be the baseline for every public-facing web workload and ideally applied to internal web consoles and APIs as well.