Security and Compliance practice questions

s3-bucket-ssl-requests-only

Why wrong: s3-bucket-ssl-requests-only validates that bucket policies enforce the aws:SecureTransport condition, thereby requiring TLS/SSL for any client connection to the bucket. This rule governs encryption in transit—data moving between the client and S3—but does not inspect how the data is stored. A bucket can be SSL-only yet still contain unencrypted data at rest, so it does not satisfy the encryption-at-rest requirement.

s3-bucket-public-read-prohibited

Why wrong: s3-bucket-public-read-prohibited checks bucket policies and ACLs to ensure no public read access is granted to the bucket or its objects. This is an access-control measure designed to prevent unauthorized exposure, not a data-protection mechanism for stored content. A bucket can be completely private and still store unencrypted objects, so this rule is irrelevant to the encryption mandate.

s3-bucket-logging-enabled

Why wrong: s3-bucket-logging-enabled verifies that server access logging is enabled on the bucket, which records detailed request data for auditing and operational monitoring. While logging is a best practice for security visibility, it applies no cryptographic protection to the bucket's contents. Enabling logging does not affect whether objects are encrypted at rest, making this rule non-compliant with the stated policy.

Configure the security group to allow only HTTPS traffic (port 443).

Why wrong: Editing the security group to allow only port 443 would drop all inbound HTTP traffic at the network layer. Because security groups operate at the instance/ENI level and are not application-aware, clients would receive a timeout or connection reset instead of being redirected. This approach prevents access but does not satisfy the intent of moving users from HTTP to HTTPS gracefully.

Use AWS WAF to block HTTP requests.

Why wrong: AWS WAF is a web application firewall that inspects HTTP/HTTPS requests and can match rules such as IP sets or SQL injection patterns, returning a custom response (e.g., 403) for blocked requests. It does not have a built-in redirect action, so using it to block HTTP traffic would terminate the user's connection rather than forwarding them to the HTTPS equivalent. In addition to being the wrong tool for a redirect requirement, WAF adds hourly costs and rule overhead that are unnecessary for simple port redirection.

Configure the ALB to use a custom SSL certificate.

Why wrong: Importing or configuring a custom SSL certificate on the ALB enables TLS termination and makes HTTPS available, but it does not automatically disable or redirect the HTTP listener. The ALB will continue accepting plaintext traffic on port 80 unless you delete that listener, change its protocol, or create a redirect rule on it. Therefore, a certificate alone leaves HTTP endpoints open and fails to enforce encryption for all clients.

Apply an S3 Bucket Policy on each bucket that denies public access.

Why wrong: A per-bucket bucket policy that denies public access is a fragmented, copy-paste control that must be manually applied to every bucket. It can be easily omitted for new buckets or removed by any user with s3:PutBucketPolicy permission. More importantly, a bucket policy cannot block all public exposure — it doesn't affect public ACLs or existing policy grants, whereas S3 Block Public Access enforces a blanket service-level denial.

Use an AWS Config managed rule 's3-bucket-public-read-prohibited' to detect and remediate public buckets.

Why wrong: The AWS Config managed rule s3-bucket-public-read-prohibited is purely detective; it evaluates the configuration after the fact and only reports non-compliance. It can trigger automatic remediation, but remediation runs after the violation and does not prevent the public access from being created, allowing a window where the data is exposed. It also only checks read access, so a bucket with public write or public ACLs may not be flagged, while account-level Block Public Access proactively prevents all such exposure.

Create an IAM policy that denies s3:PutBucketPolicy for all users.

Why wrong: An IAM policy that denies s3:PutBucketPolicy for all users fails to block public access granted through S3 access control lists (ACLs), which are a separate authorization path. It also does not cover actions like s3:PutObjectAcl or s3:PutBucketAcl, and it cannot prevent the account root user from modifying the policy. S3 Block Public Access is the appropriate service-wide control because it blocks all public access mechanisms regardless of how the request is made.

Use AWS Config with the 'approved-amis-by-id' managed rule to evaluate and automatically remediate noncompliant instances.

Why wrong: AWS Config detects noncompliant instances after launch. While automatic remediation can terminate them, it does not prevent the launch, so it does not fully meet the requirement.

Create an IAM policy that denies ec2:RunInstances for any AMI not on an approved list and attach it to all IAM users and roles.

Why wrong: Applying IAM policies requires manual updates to the policy document every time a new AMI is approved, creating significant operational overhead for future instances. This approach fails because it lacks the automated enforcement provided by AWS Organizations Service Control Policies or SCPs across an entire account. While this method works for restricting specific users from launching certain resource types in a single-account setup, it does not scale to enforce global guardrails without constant administrative intervention.

Use AWS Systems Manager Patch Manager to approve AMIs and configure the fleet to use only approved images.

Why wrong: AWS Systems Manager Patch Manager is for patching operating systems, not for controlling which AMIs can be launched. It does not prevent unapproved AMI launches.

Create an Amazon EventBridge (CloudWatch Events) rule that triggers an AWS Lambda function to check and fix public read access.

Why wrong: An EventBridge rule can certainly detect configuration changes or use scheduled events to invoke a Lambda function that scans buckets and applies fixes, but this requires you to author and deploy custom Python or Node.js code to parse bucket ACLs and policies, determine what constitutes 'public read,' and then modify the S3 configuration accordingly. While feasible, this approach introduces significant engineering effort, potential for logic errors, and needs ongoing maintenance of the Lambda function and its IAM permissions. AWS Config offers the same outcome with a fully managed rule and built-in remediation, so this custom route is unnecessarily complex and more failure-prone, not a best practice.

Apply an S3 bucket policy to each bucket that denies public read access.

Why wrong: Attaching a bucket policy that explicitly denies public read access (for example, a statement with "Principal":"*" and "Effect":"Deny" on s3:GetObject) works only for the specific buckets you manually configure. It does not automatically protect newly created buckets, nor does it detect or correct buckets that are later made public via ACLs or policy changes, so a new bucket could remain publicly readable indefinitely. In contrast, AWS Config's managed rule continuously evaluates all buckets and triggers remediation, providing a scalable and automated safeguard that a static, per-bucket policy cannot deliver.

Use AWS Trusted Advisor to check for public read access and manually remediate when notified.

Why wrong: AWS Trusted Advisor does include a check for S3 buckets with public read or write access and can notify you via email or CloudWatch Events, but it only provides a report—it has no remediation actions. You would need to manually log into the console or use the CLI to change the ACLs or policies of each flagged bucket, which is slow and error-prone, especially if multiple buckets are involved. This fails the requirement to fix the issue within five minutes because it depends on human intervention after the notification is received and reviewed.

Enable S3 default encryption at the account level in the S3 console.

Why wrong: Amazon S3 does not offer an account-level default encryption setting; encryption defaults are configured per bucket, not once for an entire account. The S3 console only allows you to enable default encryption by selecting an individual bucket and editing its properties. Therefore this action cannot enforce encryption across all existing and future buckets, because it simply cannot be performed at the account level.

Create an AWS CloudTrail trail that captures S3 API calls and triggers a Lambda function to enable encryption on any bucket that is created without it.

Why wrong: CloudTrail records S3 data and management events but does not natively invoke Lambda; you would need an additional EventBridge or CloudWatch Logs rule to trigger a custom Lambda function. This approach is purely reactive, requiring custom code to parse events and call PutBucketEncryption, and it does nothing about buckets that already exist unless you build a separate audit and remediation workflow. It is not a managed, declarative solution like AWS Config automatic remediation.

Use an AWS Organizations Service Control Policy (SCP) to deny the s3:PutBucketPublicAccessBlock action, forcing users to enable encryption.

Why wrong: SCPs are permission guardrails that restrict the maximum allowed actions for IAM principals, and they cannot directly modify or configure the encryption settings of S3 buckets. Denying s3:PutBucketPublicAccessBlock is irrelevant to encryption and actually prevents users from changing public access settings, which is neither required nor sufficient for SSE-KMS. Moreover, SCPs do not remediate existing noncompliant resources; they only deny future API operations.

Use AWS Trusted Advisor to check for instances without detailed monitoring and send a notification to the administrator via email.

Why wrong: AWS Trusted Advisor does offer checks for underutilized or improperly monitored resources, but its architecture is advisory only—it cannot perform changes on your behalf. At best, you could subscribe to email notifications or refresh the check periodically, but the administrator would still need to manually enable detailed monitoring on each flagged instance. This makes it a detection and alerting mechanism, not a policy enforcement mechanism, so it falls short of the requirement to enforce a policy that all instances have detailed monitoring.

Use an Amazon CloudWatch Events rule to detect RunInstances API calls and trigger a Lambda function that enables detailed monitoring on newly launched instances.

Why wrong: An Amazon CloudWatch Events rule (now Amazon EventBridge) that matches RunInstances API calls and invokes a Lambda function can enable detailed monitoring on new instances, but this approach has significant gaps. It requires you to write and maintain custom Lambda code, handle IAM permissions and potential race conditions, and it only addresses instances launched after the rule is deployed—existing non-compliant instances remain untouched. In contrast, AWS Config's managed rule with SSM Automation remediation immediately evaluates the entire current instance inventory and automatically fixes non-compliance with no custom development, making it operationally simpler and more complete.

Use an IAM policy that denies the ec2:RunInstances action unless the user specifies the parameter to enable detailed monitoring.

Why wrong: IAM policies cannot enforce a requirement that users pass the 'Monitoring' parameter with a value of 'true' when calling ec2:RunInstances, because no IAM condition key exists for that specific request parameter. Even if such a condition key existed, this approach would only affect new instance launches; it would do nothing for instances already running without detailed monitoring or for instances whose monitoring setting is changed after launch. Consequently, this option fails both as a preventive control and as a corrective control, whereas AWS Config can continuously detect and remediate any drift.

Create an IAM policy in each member account that denies ec2:RunInstances unless the instance type is in the approved list.

Why wrong: An IAM deny policy must be attached to every user or role in the member account, and it does not apply to the account root user, which always retains full permissions unless an SCP blocks it. This requires replicating identical policies across dozens of accounts and using groups or permission boundaries, creating a high risk of drift and missed coverage whenever an account is added or a principal is created. A centralized SCP accomplishes the same restriction with a single policy and cannot be overridden by IAM.

Use AWS Config with the managed rule 'ec2-instance-type-check' and an automatic remediation action that terminates non-compliant instances.

Why wrong: AWS Config is a detective service: it evaluates resources periodically or on configuration changes and flags them as non-compliant, but it does not block the RunInstances call. An automatic remediation that terminates the instance adds delays and requires a properly scoped remediation role with permission to terminate instances, as well as steps to handle termination protection or auto-scaling replacement. The rule must also be enabled in every account and region, making it an inefficient distributed control rather than a central preventive one.

Use Amazon EventBridge to detect RunInstances API calls and invoke a Lambda function that terminates unapproved instances.

Why wrong: EventBridge can capture RunInstances API calls only if CloudTrail is enabled, and the event is delivered asynchronously after the instance is already running, so the control is not enforced at launch time. Your Lambda termination logic adds a race window in which the unauthorized instance is live, and if the function errors or lacks the termination permission, the control silently fails. This approach is custom code, not a policy, and may also attempt to terminate short-lived instances that already shut down before the Lambda runs.

AWS CloudTrail

Why wrong: AWS CloudTrail records tenant API activity as events for auditing, such as who made a request, from what IP, and when, but it does not assess configuration state or verify whether IAM users have MFA enabled. While CloudTrail can log authentication-related events, it provides no built-in compliance rules or status checks and cannot flag a user as noncompliant for lacking MFA. Therefore, CloudTrail is unsuitable for enforcing this security policy as a configuration check.

IAM Access Analyzer

Why wrong: IAM Access Analyzer is designed to analyze resource-based policies and identify when principals from outside the account are granted access to resources like S3 buckets, KMS keys, and IAM roles. It generates findings about unintended external access but has no mechanism to inspect IAM user attributes or verify the presence of an MFA device on a user. This makes it fundamentally different from a configuration-compliance tool and, therefore, not the correct choice for this requirement.

AWS Trusted Advisor

Why wrong: AWS Trusted Advisor provides best-practice checks across cost optimization, performance, security, fault tolerance, and service limits, but its security checks are focused on high-level items such as MFA on the root account, IAM use, and security group configurations. There is no Trusted Advisor check that evaluates whether every individual IAM user has MFA enabled, so it cannot satisfy the requirement for all IAM users. Thus, while Trusted Advisor can aid security posture, it is not the right service here.

Use AWS Trusted Advisor to identify unencrypted buckets and then manually enable encryption.

Why wrong: The AWS Trusted Advisor S3 bucket encryption check identifies which buckets do not have default server-side encryption enabled, yet it is purely an advisory tool with no built-in automation. Correcting the listed findings requires a user to manually access the console or run separate SDK scripts to enable the bucket encryption setting on each non-compliant bucket. Because the company requires that all S3 buckets be encrypted and presumably wants continuous enforcement, using Trusted Advisor alone leaves human intervention in the loop and does not remediate future misconfigurations automatically.

Use AWS CloudTrail to detect PutBucket operations and trigger a Lambda function that enables encryption.

Why wrong: AWS CloudTrail records API activity, but its main purpose is auditing who made the PutBucketEncryption or CreateBucket calls, not inspecting the current state of every existing bucket. Wiring a Lambda function to CloudTrail would only execute after a qualifying API event occurs, meaning legacy buckets that never had an encryption event are never evaluated. Also, this would require building and maintaining a custom Lambda policy for each event and does not provide a native, rule-based compliance evaluation that AWS Config offers.

Create an IAM bucket policy that denies any PutObject request that does not include x-amz-server-side-encryption header.

Why wrong: An IAM bucket policy with a Deny condition on PutObject requests lacking the x-amz-server-side-encryption header ensures that new objects are uploaded with encryption, but it does nothing to require or set the bucket's default encryption configuration. The policy does not detect or remediate the preexisting bucket setting that the security team specifically wants enabled, and it fails to address scenarios like the bucket default encryption being off. This is a preventive control for object uploads, not a compliance check for the bucket requirement itself.

AWS Trusted Advisor

Why wrong: AWS Trusted Advisor does include a security check that reports whether multi-factor authentication (MFA) is enabled on the AWS account root user, but this check is only visible in the Trusted Advisor dashboard and must be accessed manually. It does not provide a way to trigger automatic notifications, run compliance history, or integrate with SNS/EventBridge when the root account falls out of compliance. Therefore, while it has similar information, it is not a suitable continuous compliance monitoring service for this security policy requirement.

AWS Identity and Access Management (IAM) Access Analyzer

Why wrong: IAM Access Analyzer is designed to analyze resource-based policies (such as S3 bucket policies, KMS key policies, and IAM roles) to identify resources shared with external principals. It does not examine the configuration of the root user or other IAM principals, such as whether MFA is enabled. Instead of checking compliance with security best practices like root MFA, it focuses on external access risks, so it cannot answer this security policy's requirement.

Amazon Inspector

Why wrong: Amazon Inspector is a vulnerability management service that performs automated security assessments of compute workloads, such as EC2 instances and container images. It scans for software vulnerabilities, unintended network exposure, and deviations from CIS benchmarks, but it has no visibility into AWS account-level settings like MFA on the root user. Since it does not evaluate IAM or identity configurations, it cannot be used to verify root account MFA for compliance.

AWS CloudTrail Insights

Why wrong: AWS CloudTrail Insights is an anomaly detection service that uses machine learning to identify unusual API activity, such as anomalous request patterns or error rates. It does not generate a report of which IAM permissions have not been used over time, nor does it track service last accessed data. Since the requirement is to identify stale permissions for least privilege, CloudTrail Insights is not the right tool.

IAM policy simulator

Why wrong: The IAM policy simulator is a testing tool that evaluates the effects of a specific policy or set of policies against a simulated request, such as a chosen action, resource, and principal. It answers 'what if' authorization questions but does not analyze actual historical API calls or track permission usage over time. Because the task is to identify unused permissions, the simulator cannot provide the required evidence of non-usage.

AWS Config managed rules

Why wrong: AWS Config managed rules continuously evaluate the configuration states of AWS resources for compliance, such as verifying that security groups do not allow unrestricted inbound traffic or that S3 buckets have versioning enabled. They do not monitor IAM principal behavior, nor do they analyze permission usage patterns across a role's actions. Consequently, Config cannot determine whether a role's permissions are being used or are stale.

AWS IAM Access Analyzer with Amazon EventBridge

Why wrong: IAM Access Analyzer uses zone-of-trust analysis to identify resources shared with external principals, generating findings when an S3 bucket allows public or cross-account access. While EventBridge can be used to react to these findings, there is no built-in mechanism for automatically applying a fix; you would need to author and manage a custom Lambda function to change the bucket policy or enable S3 Block Public Access. This makes it a detection-and-notification pattern, not a managed enforcement solution.

AWS CloudTrail and AWS Lambda

Why wrong: CloudTrail records S3 API operations and can deliver event history to a service like Lambda, but it is not a compliance engine and has no awareness of whether a bucket actually violates a security policy. To use it for remediation, you would need to build a custom Lambda function that parses trail logs, determines which buckets are public, and then applies corrective actions—a complex, maintenance-heavy approach. The combination lacks the native evaluate-and-remediate lifecycle that managed services provide.

AWS Trusted Advisor and Amazon SNS

Why wrong: Trusted Advisor runs a legacy S3 bucket permissions check that reports whether a bucket is readable or writable by anyone, but it only surfaces this as a recommendation alongside your cost, performance, and fault tolerance checks. SNS can broadcast those findings to operators, yet it has no remediation capability whatsoever, so no automatic action can be taken to enforce the company's security policy. It is a monitoring alert pattern, not an automated guardrail.

AWS CloudTrail with Amazon CloudWatch Events and AWS Lambda

Why wrong: CloudTrail is purely an audit service; it records API calls such as `PutBucketEncryption` or `CreateBucket` to a log file, but it does not compare a bucket's actual settings to a desired policy. To remediate, you would need a custom Lambda function that ingests CloudWatch Events, filters for S3 events, checks the bucket's encryption state, and then calls the S3 API to apply encryption — an approach that requires writing and maintaining code for each possible event type. It also fails to catch pre-existing noncompliant buckets that do not generate new API activity.

AWS Trusted Advisor with Amazon Simple Notification Service (SNS)

Why wrong: AWS Trusted Advisor provides best-practice recommendations, including an S3 bucket permission check, but its checks are advisory and do not include a check for default encryption on buckets. Even when a Trusted Advisor alert is published to an SNS topic, it only generates a notification — there is no remediation step to call the S3 encryption API, so the bucket remains noncompliant. Thus, it offers visibility but no enforcement mechanism.

Amazon Inspector with AWS Systems Manager Patch Manager

Why wrong: Amazon Inspector is designed for EC2 instances, inspecting network reachability and host-level vulnerabilities like CVE exposures, and it has no visibility into S3 bucket encryption attributes. AWS Systems Manager Patch Manager is likewise focused on applying OS patches to managed instances, not on S3 resource configuration. Neither tool can evaluate or alter S3 bucket encryption, making this combination wholly ineffective for the stated requirement.

AWS CloudTrail and Amazon CloudWatch Logs with metric filters and alarms

Why wrong: AWS CloudTrail records 'CreateAccessKey' API calls, so you could in principle trigger a metric filter and alarm the moment a new key is created, but it provides no insight into how long existing keys have been active. CloudWatch Logs metric filters operate only on new log events; they cannot retroactively assess the age of keys created before the filter existed. To evaluate current key ages you would need to add custom logic (e.g., Lambda listing IAM users and keys), which goes beyond the stated CloudTrail/CloudWatch combination — making it an incomplete and non-architected approach.

IAM Access Analyzer and AWS Lambda

Why wrong: IAM Access Analyzer is designed to identify external access to resource-based policies by analyzing the policies attached to S3 buckets, KMS keys, Lambda functions, and IAM roles — it does not inspect IAM user credentials or track access key creation dates. Adding a Lambda function could theoretically be used to write a custom rotation-checking script, but that custom code would not leverage Access Analyzer for anything relevant to key age. Because the combination offers no built-in mechanism for detecting stale keys, it fails the security policy's rotation requirement.

Amazon GuardDuty and Amazon EventBridge

Why wrong: Amazon GuardDuty is a threat detection service that continuously monitors for malicious activities such as compromised credentials, unusual API calls, or crypto-mining behavior, not for compliance with internal key-rotation policies. Amazon EventBridge only routes events between AWS services; it could deliver GuardDuty findings to downstream targets but cannot evaluate whether an IAM access key is older than 90 days. This stack addresses security threats rather than administrative hygiene, so it would not trigger alerts for unrotated keys under normal conditions.

Amazon CloudWatch Events with an EC2 instance state change rule and AWS Lambda

Why wrong: Amazon CloudWatch Events (now Amazon EventBridge) can invoke a Lambda function on EC2 state-change notifications, but that function must independently call ec2:DescribeTags and implement the logic to compare results to the required tags. This demands custom code and IAM permissions, and it only evaluates at the exact moment of the state transition, missing instances that become noncompliant later due to tag removal. AWS Config, by contrast, provides built-in, continuous tag evaluation without these operational burdens.

AWS Trusted Advisor with a custom check

Why wrong: AWS Trusted Advisor is limited to predefined checks for cost optimization, performance, security, fault tolerance, and service limits — customers cannot create custom or tag-specific checks. It also has no visibility into the tag attributes on EC2 instances, so it cannot validate that a required-tags security policy is satisfied. Therefore, Trusted Advisor cannot serve as a tag-compliance enforcement or alerting mechanism.

Amazon Inspector with a network assessment

Why wrong: Amazon Inspector focuses on network accessibility, unintended exposure, and host vulnerabilities by combining network reachability analysis with agent/SSM-based assessments. It has no capability to inspect EC2 instance tags or evaluate configuration policies, so it would return no information about whether required tags are present. Using Inspector for tag checks is a fundamental mismatch because tags are configuration metadata, not security findings.

IAM policy attached to the roles

Why wrong: An IAM policy attached to the roles is insufficient by itself because KMS uses a resource-based key policy to control access. Even if a role has an IAM policy allowing kms:Decrypt, the key policy must explicitly permit that role (or allow the account root to delegate permissions) for the permission to take effect. Without such a statement in the key policy, the IAM policy cannot grant any KMS usage.

Service control policy (SCP)

Why wrong: A service control policy (SCP) operates at the AWS Organizations level and applies to all principals within an account or organizational unit. SCPs can only restrict the maximum available permissions; they cannot grant specific permissions to a KMS key. Moreover, an SCP does not have the granularity to target a particular KMS key or individual IAM role, making it unsuitable for this requirement.

Resource policy attached to the KMS key

Why wrong: Although a key policy is technically a type of resource policy, AWS specifically refers to the policy attached to a KMS key as a key policy, not a resource policy. Services like S3 or SNS use resource policies, but KMS has its own key policy format and does not accept an additional resource policy attachment. The correct, unambiguous way to grant access to a KMS key is by editing its key policy, not by attaching a separate resource policy.

AWS CloudTrail, Amazon CloudWatch Logs metric filter, and Amazon SNS

Why wrong: CloudTrail can deliver events to CloudWatch Logs, where a metric filter counts occurrences of the IAM action and a CloudWatch alarm triggers SNS when the metric exceeds a threshold. However, this approach adds operational complexity and latency: you must set up a metric filter, an alarm with a minimum evaluation period of one minute, and IAM roles for log delivery, making detection less immediate than an EventBridge rule.

Amazon S3 event notifications and Amazon SNS

Why wrong: S3 event notifications are designed for object-level events within a bucket (like PutObject or DeleteObject) and can publish directly to SNS. They do not capture management events such as IAM user attempts to change bucket policies; those actions are recorded as CloudTrail management events. Therefore, this option cannot detect the required IAM user activity.

AWS CloudTrail, AWS Lambda, and Amazon SNS

Why wrong: This architecture works technically because CloudTrail can invoke a Lambda function to parse events and publish a message to SNS, but it requires you to author and manage custom Lambda code. The administrator explicitly wants to avoid custom code, so this option introduces unnecessary maintenance, a potential point of failure, and deployment overhead compared to a serverless EventBridge rule.

Amazon Inspector

Why wrong: Amazon Inspector is an agent-based vulnerability management service that scans EC2 instances and container images for software vulnerabilities and network exposure, not S3 bucket configuration settings. It has no visibility into bucket policies, default encryption attributes, or object-level metadata. Consequently, Inspector cannot detect whether a bucket has S3 default encryption disabled, making it unsuitable for this compliance requirement.

AWS CloudTrail

Why wrong: AWS CloudTrail records API activity in the management and data planes, including calls like CreateBucket or PutBucketEncryption, for security investigation and operational auditing. However, it does not proactively inspect resource configuration state or evaluate whether encryption is actually enabled on an S3 bucket. To use CloudTrail for this purpose, an administrator would need to write custom query logic against the logs, and even then it would not provide automatic, continuous compliance notifications. Therefore, CloudTrail is not the right tool for enforcing an all-buckets-must-have-encryption policy.

Amazon GuardDuty

Why wrong: Amazon GuardDuty is a managed threat detection service that analyzes CloudTrail events, VPC Flow Logs, and DNS logs using machine learning and anomaly detection to identify threats such as compromised credentials or data exfiltration. It does not inspect bucket-level configuration settings, including whether S3 default encryption is enabled. GuardDuty's focus is on detecting active malicious activity, not on compliance drift or configuration policy enforcement, so it cannot reliably identify unencrypted S3 buckets.

AWS Config with a managed rule ec2-instance-no-public-ip and an SSM Automation remediation.

Why wrong: The ec2-instance-no-public-ip managed rule only evaluates whether an EC2 instance has been assigned a public IPv4 address; it does not inspect the disableApiTermination attribute that controls termination protection. Attaching an SSM Automation remediation to this rule cannot address the requirement because the underlying compliance check is unrelated to the desired setting, and there is no native Automation document that repurposes the rule's evaluation. Consequently, instances lacking termination protection would remain compliant and un-remediated.

Amazon Inspector to scan instances and trigger a remediation action.

Why wrong: Amazon Inspector is a vulnerability management service that performs network reachability assessments and host-agent-based scans for CVEs and security exposures; it does not read EC2 control-plane attributes such as disableApiTermination, nor does it provide an action to modify them. Even if a finding triggered a Lambda function, Inspector's event model reports software vulnerabilities and network exposure, not configuration drift in instance-level API settings. Therefore, it cannot evaluate or enforce termination protection compliance.

AWS Systems Manager Patch Manager to apply a policy for termination protection.

Why wrong: Systems Manager Patch Manager creates patching baselines and schedules that install OS updates on managed instances via the SSM agent inside the guest operating system. Termination protection is a property of the EC2 resource in the AWS control plane, stored as the disableApiTermination attribute, which Patch Manager never queries or modifies. There is no policy construct in Patch Manager that can apply EC2-level protections, so the service is entirely outside the scope of this requirement.