Select Two (Multi-Select) Questions

Automated remediation of insecure Security Group rules.

Why wrong: Amazon Inspector is primarily a detection and assessment service. While it identifies network exposure, it does not automatically modify Security Group rules to remediate findings. Remediation must be handled through other services like AWS Config with SSM Automation or manual intervention.

Real-time detection of brute-force login attempts.

Why wrong: Detecting active attacks like brute-force logins is the responsibility of Amazon GuardDuty, which analyzes VPC Flow Logs and CloudTrail. Inspector focuses on the 'state' of the resource (vulnerabilities and reachability) rather than monitoring live traffic for malicious behavioral patterns.

Malware scanning for EBS volumes attached to instances.

Why wrong: Malware scanning for EBS volumes is a feature of Amazon GuardDuty (Malware Protection). Amazon Inspector focuses on software vulnerabilities in the operating system and applications, and network configuration issues, rather than scanning the file system for actual malware signatures or viruses.

Amazon DynamoDB Tables

Why wrong: As of the current service definition, IAM Access Analyzer does not natively analyze DynamoDB tables directly via resource-based policies in the same way it does for S3 or SQS. Access to DynamoDB is typically controlled through IAM identity-based policies or VPC endpoints.

Amazon EC2 Security Groups

Why wrong: Security Groups are stateful firewalls for EC2 instances and are not analyzed by IAM Access Analyzer. To detect public access via Security Groups, services like AWS Config or Amazon Inspector's Network Reachability package should be used instead, as they focus on network-level exposure.

Amazon CloudWatch

Why wrong: CloudWatch is primarily for monitoring metrics, logs, and performance data. While it can be used to set up alarms for security events, it lacks the specialized correlation, finding aggregation, and forensic visualization capabilities that are required for centralized security incident management and deep root-cause investigation.

AWS Artifact

Why wrong: AWS Artifact provides on-demand access to AWS security and compliance reports, such as ISO certifications and SOC reports. It is not an incident response tool and does not provide visibility into active security alerts or findings related to an organization's internal infrastructure and operations.

AWS Systems Manager

Why wrong: Systems Manager is an operations management tool used for configuration, patching, and task automation. While it can be used for remediation, it is not a tool for aggregating security findings or providing the investigative visualization required for incident response and threat analysis.

Change the default SSH port from 22 to a non-standard port like 2222.

Why wrong: Changing the port is 'security through obscurity' and does not prevent access by determined attackers who can quickly scan all ports. It provides a false sense of security while complicating management. Modern security practices focus on disabling inbound access entirely through methods like Session Manager, rather than attempting to hide services.

Install a third-party antivirus agent on every EC2 instance.

Why wrong: While antivirus can be part of a defense-in-depth strategy, it does not address the fundamental issue of securing the SSH protocol itself. The priority for hardening SSH should be preventing unauthorized network access and authentication, which is achieved through configuration changes and better access management tools like AWS Systems Manager.

AWS Network Firewall

Why wrong: AWS Network Firewall provides managed stateful network firewall and intrusion detection capabilities at the VPC boundary, rather than stateless inspection specifically at the subnet boundary combined with instance-level security groups.

AWS Shield Advanced

Why wrong: AWS Shield Advanced is a managed security service that safeguards applications against distributed denial of service attacks and does not act as a packet filtering mechanism for subnets or instances.

Amazon Route 53 Resolver DNS Firewall

Why wrong: DNS Firewall filters and monitors outbound DNS queries made from resources within a VPC, protecting against domain generation algorithms and data exfiltration over DNS, but it is not a general network packet filtering feature.

Terminate the EC2 instance immediately to stop the data exfiltration.

Why wrong: Terminating an instance results in the loss of volatile memory and instance store data, destroying critical forensic evidence. Best practice dictates isolating the instance using security groups or network ACLs to block traffic while maintaining the state for memory analysis and post-mortem disk investigation.

Attach a new IAM role with administrative privileges to the instance.

Why wrong: Attaching administrative privileges to a compromised instance increases the blast radius of the attack. Any existing malware could use the elevated permissions to perform further malicious actions, such as disabling logs, deleting snapshots, or escalating privileges across the entire AWS account environment, worsening the initial security incident.

Remove the VPC flow logs to save storage costs during the investigation.

Why wrong: VPC Flow Logs are a critical source of truth for network traffic patterns, including source and destination IP addresses, ports, and protocols. Deleting these logs would remove the only evidence documenting the C2 communication, making it impossible to determine the extent of the exfiltration or the attacker's origin.

Assign IAM policies directly to the root user of every member account.

Why wrong: Modifying the root user in member accounts is an anti-pattern. The root user should have multi-factor authentication enabled and be locked away. Assigning policies to it does not scale and is unnecessary, as SCPs already provide the required governance across all identities in the account, including the root user.

Configure individual IAM users in every account to ensure fine-grained control.

Why wrong: Managing individual IAM users in every account is a high-maintenance and insecure approach. It is better to use AWS IAM Identity Center to centrally manage identities across all accounts. Manual user creation increases the surface area for credential leaks and makes consistent security posture enforcement nearly impossible at scale.

Enable AWS CloudTrail only in the primary management account.

Why wrong: CloudTrail must be enabled in all accounts to maintain a comprehensive audit log. Logging only in the management account provides zero visibility into actions taken within member accounts. Centralized logging is a non-negotiable security requirement for compliance, detection of unauthorized activity, and incident response within an enterprise-level AWS environment.

Store the root access keys in a secure, encrypted S3 bucket.

Why wrong: Root access keys should not exist. They should be deleted immediately after account creation. Storing them in an S3 bucket, even if encrypted, creates a single point of failure and potential target. The root user should only be accessed via the console using credentials and MFA, never via programmatic access keys.

Use the root account for daily administrative tasks to simplify management.

Why wrong: Using the root account for daily tasks is extremely dangerous. It violates the principle of least privilege and significantly increases the risk of accidental resource deletion or configuration changes. Administrative tasks should always be performed using an IAM user or role with the minimum necessary permissions required for the job.

The developer must assume a role in Account B that has permissions to the KMS key.

Why wrong: While assuming a role is one way to gain access to resources in another account, it is not strictly necessary for KMS. KMS supports direct cross-account access via key policies and IAM policies, which is often preferred for simple encryption tasks to avoid the overhead of role switching.

The KMS key in Account B must be converted to a multi-Region key to be accessible from Account A.

Why wrong: Multi-Region keys are used to replicate keys across different AWS Regions, not for cross-account access within the same region. A standard regional CMK can be used across different accounts as long as the key policy and identity policies are correctly configured to allow the interaction.

An IAM Peering Connection must be established between Account A and Account B.

Why wrong: There is no such thing as an 'IAM Peering Connection.' Networking features like VPC Peering are used for private network traffic but have no bearing on the IAM and KMS policy evaluation logic required to grant an identity in one account permission to use a resource in another.

An IAM User with programmatic access keys for the Identity Provider.

Why wrong: SAML federation is a provider-based trust and does not require a specific IAM user with access keys. The Identity Provider (IdP) interacts with the AWS STS service directly via the SAML assertion, making static user credentials unnecessary for the federation process itself to function correctly.

A CloudFront distribution to cache the SAML assertion responses.

Why wrong: CloudFront is a content delivery network and is not involved in the SAML authentication flow. The SAML assertion is passed directly from the user's browser to the AWS sign-in endpoint. Caching these assertions would be a security risk and is not part of the standard SAML architecture.

An Amazon Cognito User Pool to store the federated user profiles.

Why wrong: While Amazon Cognito can be used for federation in mobile or web applications, it is not a requirement for standard SAML 2.0 federation to the AWS Management Console. Direct federation uses IAM SAML providers and roles, bypassing the need for a Cognito User Pool to manage those identities.

Install the AWS CLI on each employee's local machine and configure it with their corporate username and password.

Why wrong: Standard SAML federation for the AWS Console is browser-based and does not require the AWS CLI or local configuration of corporate credentials. While CLI federation is possible using tools like 'aws-adfs', it is not a requirement for establishing the core trust relationship or for basic Management Console access.

Enable Multi-Factor Authentication (MFA) on the AWS root user to allow SAML assertions to be processed securely.

Why wrong: While securing the root user with MFA is a critical security best practice, it has no technical impact on the functionality of SAML federation. SAML authentication is handled by the external Identity Provider, and the resulting assertions are processed by the IAM service independently of the root account configuration.

Create individual IAM users for every employee and map them to their corresponding corporate identities using tags.

Why wrong: The primary goal of federation is to avoid creating individual IAM users for every employee. Instead, users are mapped to IAM roles dynamically upon login. This reduces administrative overhead and ensures that employee access is automatically revoked when they are deactivated in the corporate directory, improving the overall security posture.

Encryption at rest can be enabled for an existing unencrypted RDS DB instance by modifying the instance settings.

Why wrong: You cannot enable encryption on an existing unencrypted RDS DB instance directly. To encrypt an unencrypted instance, you must first take a snapshot of the database, create an encrypted copy of that snapshot using a KMS key, and then restore a new DB instance from the encrypted snapshot copy.

Encryption at rest can be disabled on an RDS instance to improve performance during large data imports.

Why wrong: Once an RDS instance is created with encryption enabled, you cannot disable it. This is a security design choice to prevent the accidental exposure of sensitive data. If you need an unencrypted instance, you would have to export the data and import it into a new, unencrypted database instance.

RDS encryption at rest only protects the database tables and does not apply to logs or temporary files.

Why wrong: RDS encryption at rest is comprehensive and covers more than just the tables. It encrypts the underlying storage for the DB instance, including the data files, transaction logs, temporary files, and even the system tables. This provides a holistic layer of protection for all data associated with the database.

Enable RDS encryption using an AWS managed key and configure annual rotation.

Why wrong: AWS managed keys have their own rotation schedules that cannot be modified by the user. To enforce a specific annual rotation requirement, you must use a customer-managed KMS key, which provides the necessary configuration flexibility for your organization's specific compliance and security policy standards.

Modify the existing RDS instance to enable encryption after the initial launch.

Why wrong: RDS does not allow enabling encryption on an existing unencrypted database instance. If an instance was created without encryption, you must create a snapshot, copy it with encryption enabled, and restore the snapshot to a new instance to apply the necessary data-at-rest protection measures.

Enable Transparent Data Encryption (TDE) via the RDS option group.

Why wrong: While TDE is a feature for some database engines, it is not the standard or recommended approach for AWS RDS encryption. AWS KMS-based storage encryption provides a more integrated, scalable, and audit-friendly solution that covers the entire storage volume, including logs and backups, automatically.

Enable S3 Block Public Access on all accounts via AWS Organizations.

Why wrong: While enabling S3 Block Public Access is a critical security best practice, it does not enforce encryption at rest. This configuration prevents data leaks to the public internet but does not influence or mandate the encryption status of the objects stored within the S3 buckets.

Use AWS Trusted Advisor to manually audit all buckets for encryption status.

Why wrong: Manual auditing via Trusted Advisor is a reactive measure and does not provide enforcement or governance. While it identifies buckets that are currently unencrypted, it does not prevent future occurrences, making it insufficient for an organization-wide mandate requiring strict, automated compliance for all data stored.

Apply a bucket policy to every S3 bucket in the account.

Why wrong: Applying individual bucket policies is operationally expensive and prone to human error, especially in large environments. Governance should be applied at the organizational level using SCPs rather than managing individual resource policies, which can be modified or deleted by users with sufficient IAM permissions.

Install the Macie agent on all EC2 instances that write data to the S3 buckets to classify data in real-time.

Why wrong: Amazon Macie does not use agents. It is a service-side tool that analyzes data directly within S3 buckets. Classification happens on the stored objects, not during the data transmission or on the compute instances themselves, making it a non-intrusive way to manage data security and compliance across the account.

Configure S3 Event Notifications to send every new object to a Lambda function that calls the Macie 'ScanObject' API.

Why wrong: There is no 'ScanObject' API for Macie that is intended to be called on a per-object basis via Lambda. Macie is designed to perform discovery through managed jobs that scan the bucket contents. While you can automate job creation, the per-object trigger via Lambda is not the standard or efficient way to use Macie.

Enable S3 Object Lock on all buckets to allow Macie to generate findings without the risk of data being deleted during a scan.

Why wrong: S3 Object Lock is a data protection feature for immutability, but it is not a prerequisite for Amazon Macie. Macie can scan objects regardless of whether Object Lock is enabled. While Object Lock helps with data retention, it does not impact Macie's ability to identify sensitive data within those objects.

AWS Security Hub

Why wrong: Security Hub provides a comprehensive view of security alerts and security posture across AWS accounts. While it conducts automated security checks against best practices and standards like CIS, it is primarily a detective service. It does not provide official AWS compliance reports or manage the formal evidence collection process for audits.

AWS CloudTrail

Why wrong: AWS CloudTrail records API calls and user activity across your AWS infrastructure, providing a detailed log of events. While these logs are vital for forensic analysis and can serve as raw evidence during an audit, CloudTrail itself does not organize evidence into compliance frameworks or provide formal compliance reports for auditors.

AWS Trusted Advisor

Why wrong: Trusted Advisor provides recommendations to help follow AWS best practices in categories like cost optimization and security. Although it checks for security gaps like open ports, it is not designed to track compliance against specific regulatory frameworks or provide the structured evidence reports required for a SOC 2 audit.

Reactive guardrails using AWS Systems Manager Automation documents.

Why wrong: While Systems Manager can be used for remediation, Control Tower does not categorize guardrails as 'reactive' within its native framework. It focuses on prevention and detection. Automation for remediation is typically a secondary step that the customer configures using findings from the detective guardrails provided by the service.

Proactive guardrails using IAM Permission Boundaries.

Why wrong: Control Tower does not use IAM Permission Boundaries as a standard guardrail mechanism. Permission boundaries are managed at the IAM level within individual accounts. Control Tower’s primary governance tools are SCPs for prevention and Config rules for detection, which provide broader and more centralized control than boundaries.

Administrative guardrails using AWS IAM Identity Center (Succeeded AWS SSO).

Why wrong: While Control Tower integrates with IAM Identity Center for identity management and access control, the guardrails themselves are technically defined as preventive (SCPs) or detective (Config). IAM Identity Center is the mechanism for providing access to the accounts, but it is not a 'guardrail type' within the service's governance model.

Use AWS Shield Standard to mitigate Layer 7 application attacks.

Why wrong: AWS Shield Standard is designed specifically for protecting against Layer 3 and Layer 4 Distributed Denial of Service (DDoS) attacks. It does not provide the application-level logic required to detect or block specific brute-force authentication attempts occurring at the web application layer.

Enable AWS Trusted Advisor to monitor for open security groups.

Why wrong: Trusted Advisor provides recommendations for optimizing performance and cost, as well as general security best practices like identifying open security groups. While useful for overall hygiene, it is not a detective control for real-time brute-force authentication attacks against specific web application endpoints.

Implement AWS Inspector to scan for vulnerabilities on the instances.

Why wrong: AWS Inspector performs vulnerability assessments by scanning EC2 instances for software vulnerabilities and network reachability issues. It does not monitor runtime authentication logs or detect brute-force patterns, making it unsuitable for detecting active credential-based attacks occurring against your web application endpoints.

Disable 'Source/Destination Check' on all Transit Gateway attachments.

Why wrong: Source/Destination Check is an EC2 instance-level setting, not a Transit Gateway attachment setting. While it must be disabled on the firewall instances themselves to allow them to process traffic not destined for their own IP, it is not a configuration option or requirement for the TGW attachments themselves.

Use VPC Peering between all spoke VPCs and the Security VPC to bypass the Transit Gateway.

Why wrong: VPC Peering does not support transitive routing, meaning traffic cannot pass through one VPC to get to another. To centralize inspection, a Transit Gateway or a complex mesh of peering is required. Using peering would defeat the purpose of a hub-and-spoke architecture and would not scale effectively.

Create a separate NAT Gateway in every spoke VPC to handle the inspection traffic locally.

Why wrong: Creating NAT Gateways in every spoke VPC would result in decentralized internet access, bypassing the central Security VPC's firewalls. The goal of this architecture is to consolidate egress points to a single location for better control, monitoring, and cost management of the third-party firewall licenses.

AWS WAF Logs

Why wrong: AWS WAF logs monitor traffic for web applications (HTTP/HTTPS) and are typically not involved in direct S3 bucket API calls unless the request is proxied through a web server. They would not provide visibility into direct S3 API requests made by IAM roles or users.

AWS Trusted Advisor reports

Why wrong: Trusted Advisor provides recommendations on optimization and security posture, such as identifying public buckets or open ports. It does not provide real-time logs or forensic data regarding specific object access or data transfer activity, making it irrelevant for tracking an active data exfiltration incident.