Security and Compliance practice questions

s3-bucket-ssl-requests-only

Why wrong: Incorrect. This rule enforces encryption in transit (SSL/TLS), not encryption at rest.

s3-bucket-public-read-prohibited

Why wrong: Incorrect. This rule prevents public read access, unrelated to encryption.

s3-bucket-logging-enabled

Why wrong: Incorrect. This rule checks if server access logging is enabled, not encryption.

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

Why wrong: Incorrect. Blocking port 80 at the security group level will drop HTTP requests but not redirect them; clients will see connection failures.

Use AWS WAF to block HTTP requests.

Why wrong: Incorrect. WAF can block HTTP requests but does not redirect; it also adds complexity and cost.

Configure the ALB to use a custom SSL certificate.

Why wrong: Incorrect. A custom SSL certificate enables HTTPS but does not enforce it; HTTP traffic would still be accepted if the listener is configured for HTTP.

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

Why wrong: Incorrect. This requires applying to each bucket and can be modified by users with appropriate permissions.

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

Why wrong: Incorrect. This is detective, not preventive, and may not stop the configuration from being made public.

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

Why wrong: Incorrect. This prevents changing bucket policies but does not block public ACLs or other access paths.

AWS CloudTrail and Amazon CloudWatch Events

Why wrong: CloudTrail logs API calls, and CloudWatch Events can trigger a Lambda function on the RunInstances event to check tags and terminate if needed. While this can work for new launches, it does not provide ongoing compliance monitoring for tag changes after launch, and it requires more custom logic than using AWS Config.

AWS Service Catalog and AWS Organizations

Why wrong: Service Catalog enforces tagging only for products provisioned through it. This does not cover instances launched outside Service Catalog, and AWS Organizations is for account management, not direct EC2 tag enforcement.

Amazon Inspector and AWS Systems Manager

Why wrong: Amazon Inspector is for vulnerability assessments, and Systems Manager is for operational management. Neither service is designed to enforce tags or terminate instances based on tags automatically.

Use Amazon CloudWatch Events to detect CreateBucket API calls and trigger an AWS Lambda function to enable versioning

Why wrong: This reactive approach only addresses buckets created after the rule is set up. It does not handle existing buckets that lack versioning, nor does it detect buckets that have versioning disabled after creation. It requires separate handling for existing resources.

Use AWS CloudTrail to monitor CreateBucket events and send an alert to the SysOps administrator for manual action

Why wrong: Manual intervention is not automated and may lead to delays or missed buckets. This does not meet the requirement for automatic remediation.

Use AWS Service Catalog to enforce versioning on all buckets provisioned through it

Why wrong: Service Catalog only enforces compliance on resources provisioned through its products. Buckets created outside of Service Catalog (e.g., directly via the console or CLI) are not covered. This solution is incomplete.

Use an AWS Service Control Policy (SCP) to deny ec2:RunInstances if the AMI ID is not in an approved list.

Why wrong: While SCPs can enforce this, they are configured at the organization level and require AWS Organizations, adding complexity and operational overhead.

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: This requires managing policy attachments for every principal, increasing operational overhead and risk of missing some principals.

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

Why wrong: Patch Manager is for patching existing instances, not for controlling which AMIs can be used to launch new instances.

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

Why wrong: While this works, it requires custom Lambda code, which is more effort than using AWS Config's managed rule with remediation.

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

Why wrong: This requires manual per-bucket configuration and does not automatically detect new buckets or changes.

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

Why wrong: Trusted Advisor provides checks but requires manual remediation; it does not automatically fix the issue within five minutes.

Use two AWS Config managed rules: 'rds-instance-encrypted' and 'rds-backup-enabled'. Configure each rule with an automatic remediation action that triggers an Amazon CloudWatch alarm, which then invokes an AWS Lambda function to enable encryption and backups.

Why wrong: While this could work, it is not the most efficient. CloudWatch alarms are not designed to be triggered directly by Config rule compliance changes. The native remediation integration in AWS Config uses Systems Manager Automation runbooks, which are simpler and do not require custom Lambda code.

Create custom AWS Config rules as AWS Lambda functions that evaluate the RDS instance configuration. In the Lambda function, if a resource is non-compliant, call the RDS API to enable encryption and modify backup settings.

Why wrong: Custom rules require writing and maintaining Lambda code. Managed rules already exist for both requirements, reducing operational overhead. The automatic remediation should use pre-built runbooks when possible.

Use a single custom AWS Config rule that checks both encryption and backup settings. If non-compliant, trigger an AWS Lambda function that uses the RDS API to configure both settings.

Why wrong: Although this reduces the number of rules, it requires writing and maintaining a custom rule and Lambda function. The use of managed rules for each requirement is simpler and leverages AWS best practices. Also, combining two checks into one rule makes it harder to manage separate remediation actions.

Enable default encryption on the AWS account's S3 buckets using an S3 account-level setting in the S3 console, which automatically applies SSE-KMS to all new buckets.

Why wrong: There is no account-level default encryption for all S3 buckets. Default encryption must be configured per bucket. This option is not feasible.

Create an AWS CloudTrail event that triggers an AWS Lambda function when a bucket is created, and the Lambda applies SSE-KMS encryption. Use AWS Config to periodically scan existing buckets and apply encryption.

Why wrong: While this could work, it uses CloudTrail events for bucket creation and a separate periodic Lambda for existing buckets. This is more complex and requires two Lambda functions, whereas AWS Config can handle both detection and remediation in a unified way.

Use AWS Identity and Access Management (IAM) with a Service Control Policy (SCP) that denies any S3 bucket creation without SSE-KMS enabled, and use AWS Config to detect and notify on non-compliance.

Why wrong: SCP can prevent creation of buckets without encryption but does not remediate existing buckets. The requirement includes detecting and remediating both existing and new buckets. This solution only addresses new buckets and does not automatically apply encryption to existing ones.

Enable AWS Config rules in each account to detect public S3 buckets and automatically remediate them using AWS Lambda.

Why wrong: AWS Config rules are detective and reactive, not preventive. They can remediate after creation but do not prevent an account admin from making a bucket public in the first place.

Use an IAM policy attached to all IAM users in each account that denies s3:PutBucketPolicy.

Why wrong: IAM policies only affect users and roles, not the root user or resources created by AWS services. An account administrator with full administrative privileges could override this policy.

Apply Amazon S3 Block Public Access at the account level in each individual AWS account.

Why wrong: S3 Block Public Access at the account level is a strong setting, but it can be disabled by an account root user or admin with appropriate permissions. It is not a fully preventive control across an organization as it can be bypassed by account administrators.

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

Why wrong: S3 does not have an account-level default encryption setting. Default encryption must be enabled on each bucket individually.

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: This is possible but requires custom code and is not a managed solution. It also does not fix existing buckets automatically.

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

Why wrong: SCPs are used to control permissions, not to directly configure encryption. Also, this does not automatically enable encryption on existing buckets.

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

Why wrong: Trusted Advisor provides checks and notifications but does not automatically remediate.

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: This approach can work but requires custom code and does not cover existing instances. AWS Config provides a managed service solution with less operational overhead.

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 specific parameter values for detailed monitoring; there is no condition key for this purpose.

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

Why wrong: This requires managing policies in each account individually, increasing operational overhead and risk of inconsistency.

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

Why wrong: This is a detective control that reacts after launch, potentially incurring cost and delay before termination. It is not preventive.

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

Why wrong: This is also a reactive approach with custom code, and it may terminate instances after they have already launched, causing resource waste and potential security exposure.

s3:ExistingObjectTag

Why wrong: s3:ExistingObjectTag is used to conditionally allow access based on tags attached to S3 objects, not buckets. This would not restrict bucket-level access.

s3:ResourceTag

Why wrong: This is not a valid IAM condition key for any service. IAM condition keys follow a 'service:conditionkey' pattern, and 's3:ResourceTag' does not exist.

iam:ResourceTag

Why wrong: iam:ResourceTag is used to control access based on tags attached to IAM resources (users, roles, policies), not S3 buckets.

AWS CloudTrail

Why wrong: CloudTrail logs API calls, but it does not perform configuration compliance checks.

IAM Access Analyzer

Why wrong: Access Analyzer is for analyzing resource policies to identify unintended external access, not for checking MFA status.

AWS Trusted Advisor

Why wrong: Trusted Advisor checks cost optimization, performance, security, and fault tolerance, but it does not have a specific check for IAM user MFA.

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

Why wrong: Trusted Advisor flags unencrypted buckets but does not provide automatic remediation, requiring manual intervention.

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

Why wrong: This requires custom Lambda code and deals with API calls rather than current bucket configuration. It would not detect existing unencrypted buckets.

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

Why wrong: This enforces encryption on uploads but does not detect or remediate existing buckets that lack default encryption.

AWS Trusted Advisor

Why wrong: Trusted Advisor includes a check for root MFA, but it only provides a status in the dashboard and does not easily integrate with automatic notifications for compliance violations.

AWS Identity and Access Management (IAM) Access Analyzer

Why wrong: IAM Access Analyzer analyzes resource-based policies to identify unintended access, not root user MFA configuration.

Amazon Inspector

Why wrong: Amazon Inspector is a vulnerability management service that scans workloads for software vulnerabilities and unintended network exposure, not IAM configuration checks.

AWS CloudTrail Insights

Why wrong: Identifies unusual API activity, not unused permissions.

IAM policy simulator

Why wrong: Tests policy effects but does not analyze historical usage.

AWS Config managed rules

Why wrong: Evaluates resource compliance, not permission usage.

AWS IAM Access Analyzer with Amazon EventBridge

Why wrong: Detects public access but does not provide automatic remediation.

AWS CloudTrail and AWS Lambda

Why wrong: Requires custom Lambda code to detect and remediate.

AWS Trusted Advisor and Amazon SNS

Why wrong: Provides recommendations only, no automatic remediation.

Amazon GuardDuty and AWS Lambda

Why wrong: GuardDuty is a threat detection service that monitors for malicious activity. It does not evaluate S3 bucket encryption compliance.

AWS CloudTrail and Amazon EventBridge

Why wrong: CloudTrail logs API events, and EventBridge can trigger on those events. However, this would only react to bucket creation or modification events, not proactively detect existing buckets without encryption, and would require custom code to compare state.

Amazon Macie and AWS Step Functions

Why wrong: Macie is used for discovering sensitive data in S3, not for checking encryption settings. Step Functions would add unnecessary orchestration complexity.