Select Two (Multi-Select) Questions

Assign an instance profile to the user.

Why it fails: Instance profiles deliver temporary credentials to EC2 instances through the instance metadata service; they attach to roles assumed by instances, not to IAM users. They are correct when an application running on EC2 must call AWS APIs without embedded long-term keys.

Create a VPC endpoint policy.

Why it fails: A VPC endpoint policy governs which principals may reach the S3 service through that endpoint, but it does not by itself authorise an IAM user's S3 actions. Endpoint policies are correct when restricting bucket access to traffic originating from a specific VPC or endpoint.

Use an SCP to allow access.

Why it fails: SCPs define the maximum permissions available to accounts within an organisation; they filter but never grant permissions to a principal. An SCP is the correct tool for enforcing organisational guardrails, such as blocking access to specific Regions or services across all member accounts.

Enable CloudTrail data events for S3.

Why it fails: GuardDuty uses CloudTrail management events, not data events.

Enable S3 server access logs.

Why it fails: GuardDuty does not use S3 access logs.

Enable AWS Config configuration history.

Why it fails: GuardDuty does not use Config history.

Configure CloudWatch Logs cross-account subscription to aggregate findings.

Why it fails: Configuring a CloudWatch Logs cross-account subscription is not the mechanism for enabling GuardDuty multi-account management. GuardDuty generates findings from each account's own threat-detection data sources (VPC Flow Logs, DNS, CloudTrail) and natively replicates those findings to the GuardDuty administrator account. A CloudWatch Logs subscription could be used for separate log aggregation, but it does not establish the administrative relationship that lets a master account view or manage member findings, and it cannot replace the required invitation/acceptance workflow.

Create an EventBridge rule to forward findings to the master account.

Why it fails: Creating an EventBridge rule to forward GuardDuty findings to the master account is an optional integration, not the required step for delegating GuardDuty administration. When a member account is properly linked through GuardDuty's native master-member model, findings are automatically copied to the master account's GuardDuty console without any EventBridge rule. An EventBridge rule could be used for downstream automation, such as triggering a remediation Lambda or streaming findings to a SIEM, but it does not create the administrative relationship and would be redundant for the purpose of central GuardDuty visibility.

SSL/TLS certificate

Why it fails: SSL/TLS certificates are not recognized by the IAM user authentication process. While AWS services such as API Gateway can use client certificates for mutual TLS, IAM itself never validates a certificate as proof of identity for console or API access. Server certificates in IAM are used only to enable HTTPS on your custom domain, which authenticates the server, not the user. Thus, a certificate cannot substitute for an IAM password or access key.

MFA token

Why it fails: An MFA token provides a one-time code that must be combined with a primary credential—either a password for console sign-in or an access key for programmatic requests—to complete authentication. AWS treats MFA as an additional security factor designed to protect against credential theft, not as a standalone authentication method. While IAM policies can require MFA as a condition, the token itself never initiates an authenticated session. Therefore, an MFA token alone cannot authenticate an IAM user.

SSH key pair

Why it fails: SSH key pairs are primarily used to authenticate to EC2 instances over SSH, not to the AWS account itself. Although IAM supports uploading SSH public keys for use with AWS CodeCommit over SSH, this is a service-specific repository authentication mechanism, not a general IAM user authentication credential. An SSH key pair does not sign AWS API requests or allow console access. Therefore, it is not a valid way to authenticate an IAM user to AWS.

Configure the security group of the EC2 instance to allow outbound HTTPS traffic to S3.

Why it fails: Security groups are stateful network filters that control traffic based on IP addresses, ports, and protocols; they do not evaluate IAM permissions or identity. While outbound HTTPS to S3 is typically allowed by the default outbound rule, even if you narrowed it to S3's prefix list this change would only affect network reachability, not the instance's ability to authenticate or authorize a PutObject call. The root cause of a denied write is the absence of an IAM policy granting s3:PutObject, not a missing network path.

Create a VPC endpoint for S3 in the same subnet as the EC2 instance.

Why it fails: Creating a VPC endpoint for S3 in the same subnet provides a private, low-latency network path to S3 and can be used with bucket policies that restrict access to the endpoint. However, a VPC endpoint is an optional networking component; it does not grant the EC2 instance any IAM identity or permissions to perform s3:PutObject. Without an IAM role and a bucket policy that authorize the write, the API call will still be denied even though traffic can reach S3.

Enable AWS CloudTrail to capture log write events.

Why it fails: Enabling AWS CloudTrail to capture log write events is not a mechanism for granting access; CloudTrail only records API activity for auditing, monitoring, and security analysis. After the EC2 instance begins writing, CloudTrail may log s3:PutObject events and show whether they were successful, but enabling it does not alter the IAM authorization outcome. It is a detective control, not a preventive control, so it cannot help the instance gain write permissions.

Amazon CloudWatch Metrics for the instance

Why it fails: Amazon CloudWatch Metrics provide only numerical time-series data, such as CPU utilization, disk I/O, and network throughput, which are aggregated into 1-minute or 5-minute periods. Even with detailed monitoring, they do not capture login attempts, executed commands, or file modifications—the forensic evidence needed to identify how an attacker gained access. While metrics can highlight an anomaly like a CPU spike, they are far too coarse to reveal the attack vector, making them unsuitable for incident investigation.

AWS Config configuration history

Why it fails: AWS Config tracks configuration changes to AWS resources over time, such as security group rule modifications, instance type changes, or tag updates, and maintains a timeline of those states for compliance auditing. While it could show that a security group was opened to the internet hours before the incident, it does not contain any authentication attempts, command execution, or attacker movement within the instance. Config history is therefore useful for understanding infrastructure evolution but cannot reveal the initial compromise vector or the attacker's actions on the host.

VPC Flow Logs

Why it fails: VPC Flow Logs capture metadata about IP traffic at the network interface level, including source and destination addresses, ports, protocols, and byte counts, but they do not perform deep packet inspection or payload analysis. A flow log might show a burst of connections from a suspicious IP, yet it cannot tell whether that traffic was a successful exploit, a brute-force login, or benign scanning. This lack of application-layer context means flow logs alone cannot prove maliciousness or identify the specific attack vector that compromised the instance.

AWS Config

Why it fails: AWS Config continuously records resource configuration changes and evaluates them against custom or managed rules, but it has no authority to grant, deny, or modify IAM policies. It can only flag noncompliant resources and produce a configuration history, making it a visibility and compliance tool rather than a central permissions management plane. Therefore, while Config helps audit whether policies are followed, it cannot centrally govern or enforce access controls across accounts.

AWS CloudTrail

Why it fails: AWS CloudTrail captures a detailed audit log of every API call made in an account, along with the identity, source IP, and time, but the service does not alter or administer any permission model. It is a read-only telemetry service for post-event investigation and operational forensics, not a policy control point. Thus, CloudTrail provides evidence of who did what, but it cannot centrally manage or restrict permissions.

AWS Single Sign-On

Why it fails: AWS Single Sign-On, now called IAM Identity Center, centrally manages workforce identities and their assigned access to AWS accounts and business applications through SSO and permission sets, but it does not govern what those users can do to resources. The permission sets it creates map to IAM roles, but the actual fine-grained resource actions are still defined by IAM policies attached to those roles. It is an identity and assignment hub, not a service for centrally managing resource-level permissions across accounts.

Reimage the instance from a clean AMI immediately

Why it fails: Reimaging destroys volatile evidence such as memory-resident malware and running processes before forensic capture, and the compromised instance may still be needed for analysis. It is tempting because rebuilding from a trusted AMI is the standard remediation step once evidence has been preserved and the root cause identified.

Delete all CloudTrail logs related to the instance

Why it fails: Deleting CloudTrail logs destroys the audit trail required to establish the incident's timeline, scope and API activity, and may breach retention obligations. It is tempting because removing attacker-visible logging feels like containment, but log preservation is a core response step; deletion belongs only after lawful retention periods expire.

Immediately terminate the instance to stop the attack

Why it fails: Termination erases the instance's memory, disk and network state, destroying the forensic artefacts investigators need to determine scope and root cause. It is tempting because terminating an instance is a fast, decisive way to halt active attacker activity, and is valid once evidence has been captured and contained.

Use Amazon CloudFront to serve the content.

Why it fails: Amazon CloudFront is a content delivery network (CDN) that accelerates distribution of static content, but it does not control authorization to the underlying S3 bucket. While CloudFront can be integrated with S3 via Origin Access Control to hide direct bucket access, the service itself does not restrict which IAM users or roles can call GetObject or ListBucket on the origin. Using CloudFront alone would not prevent unauthorized access to the bucket if direct access remains open, so it is not the right mechanism for enforcing bucket-level access control.

Enable VPC Flow Logs on the bucket.

Why it fails: VPC Flow Logs capture metadata about IP traffic sent to and from elastic network interfaces in a VPC; they do not log or control S3 data-plane operations like GetObject, PutObject, or ListBucket. S3 access can be audited through AWS CloudTrail or S3 server access logs, but VPC Flow Logs are irrelevant to bucket permissions. Therefore, enabling VPC Flow Logs would provide no protection over who can access the S3 bucket.

Enable S3 object ACLs.

Why it fails: S3 object ACLs are a legacy access-control mechanism that uses canonical user IDs or predefined groups rather than IAM roles, making them difficult to map to modern identity models. ACLs are also independent of bucket policies and IAM policies, which creates confusion and increases the risk of unintended public exposure. In addition, newer S3 capability such as Object Ownership and Block Public Access diminishes reliance on ACLs; AWS strongly recommends using IAM policies and bucket policies instead, so enabling ACLs is not a secure way to restrict access.

Configure an S3 lifecycle policy to re-encrypt objects

Why it fails: Incorrect. An S3 lifecycle policy does not re-encrypt objects; it transitions objects to different storage classes or expires them.

Manually rotate the key every 90 days and re-encrypt all objects

Why it fails: Incorrect. Manually rotating the key and re-encrypting all objects is not a combination; it is a single action, and the question asks for two actions. Additionally, manual rotation is not automatic.

Delete the existing key and create a new one each 90 days

Why it fails: Incorrect. Deleting the existing key breaks access to existing objects, as they cannot be decrypted.

Enable automatic key rotation in AWS KMS for the customer managed key

Why it fails: Incorrect. AWS KMS automatic key rotation for customer managed keys is annual (365 days), not every 90 days, so it does not satisfy the requirement.

Configure a NAT gateway in the private subnet for the application servers.

Why it fails: A NAT gateway provides outbound-only internet access for private subnets; it does not restrict inbound traffic from the web tier, so application servers stay reachable from other sources. It is tempting because it isolates private subnets from the internet, but that suits egress-only patterns, not tier-to-tier access control.

Use a network ACL on the application subnet to allow inbound traffic from the web subnet's IP range.

Why it fails: Network ACLs are stateless, so return traffic on ephemeral ports must be explicitly permitted; they also filter at subnet level rather than enforcing source security group membership. A security group referencing the web tier's security group is required. NACLs suit coarse subnet-level deny rules, such as blocking a known malicious CIDR range.

Place the application servers in a public subnet with a route to an internet gateway.

Why it fails: A route to an internet gateway makes the application tier directly reachable from the internet, violating the requirement that only web servers may initiate connections to it. Public subnets suit internet-facing load balancers and bastion hosts, not backend tiers that must accept traffic solely from the web tier.

AWS Config

Why it fails: AWS Config records and evaluates resource configuration changes for compliance; it neither issues credentials nor attaches roles to instances. It would be correct when auditing whether resources comply with desired configurations, not when enabling an EC2 instance to assume an IAM role.

AWS CloudFormation

Why it fails: CloudFormation provisions infrastructure as code, so it can create the role and instance profile but cannot itself make the instance assume the role. It would be the right answer when defining and deploying the stack's resources declaratively, not when supplying the runtime credential mechanism.

AWS Single Sign-On (SSO)

Why it fails: SSO is for federated user access, not for EC2 instance roles.

Use the aws:SourceIp condition key to restrict IP addresses.

Why it fails: Using the aws:SourceIp condition key is ineffective for VPC endpoint traffic because requests sent through a VPC endpoint originate from private IP addresses inside the endpoint's subnet, not from the public IP address of the client. The aws:SourceIp key checks the public IP of the requester, which is invisible to S3 when the request is tunneled through the endpoint. Consequently, you cannot rely on this key to restrict access; the aws:SourceVpce key must be used instead.

Set the Principal to the VPC endpoint ID.

Why it fails: A VPC endpoint ID (e.g., vpce-12345) is not a valid AWS Principal in an S3 bucket policy; principals can only be IAM users, roles, AWS accounts, or federated sessions but never an endpoint resource. If you attempt to set Principal to the endpoint ID, AWS will reject the policy because the principal is not recognized, and even if it were accepted, it would not limit the source of the request. The correct way to scope to a specific endpoint is to use a condition key such as aws:SourceVpce, while leaving Principal as '*' or as the relevant account/role.

Ensure the bucket policy has an explicit Allow for the VPC endpoint.

Why it fails: An explicit Allow for a VPC endpoint ID in the bucket policy is not required and, in fact, is not syntactically valid because endpoint IDs cannot be listed as the Principal. If you already have an Allow statement for the relevant IAM user or role, you can simply add a Deny statement that blocks traffic from any source except the VPC endpoint, or add the aws:SourceVpce condition to the existing Allow. Adding a separate explicit Allow specifically for the endpoint would neither authorize a specific principal nor meaningfully restrict access, so it does not address the requirement.

Amazon CloudWatch Logs

Why it fails: Amazon CloudWatch Logs is designed to ingest, store, and search log data from applications and AWS services, but it has no built-in machine learning model specifically trained to identify anomalous IAM sign-in behavior. You could use CloudWatch Logs Insights to query CloudTrail events after sending them there, but any alerting would rely on manually defined metric filters or static threshold rules, such as counting denied API calls. It cannot natively detect behavioral deviations like a login from an unusual geographic region without extensive custom logic.

AWS Config

Why it fails: AWS Config continuously records and evaluates changes to AWS resource configurations, such as security group rule modifications or whether an S3 bucket is publicly accessible. It has no visibility into IAM user sign-in events or the contextual sequence of API calls made by a principal, because its data model is based on resource state rather than user activity. Its compliance rules are designed to enforce infrastructure standards, not to identify anomalous login locations or unusual IAM user actions, so it cannot produce the needed alerts.

IAM Access Analyzer

Why it fails: IAM Access Analyzer is a policy-analysis tool that scans resource-based policies, such as S3 bucket policies, KMS key policies, and IAM role trust policies, to identify resources shared with an entity outside your AWS account. It does not monitor IAM user authentication events, source IP addresses, or API call patterns, and it does not apply threat intelligence or establish behavioral baselines for user activity. Its purpose is to reduce unintended external access to resources through policy analysis, not to detect anomalous IAM user behavior.

Enable S3 Block Public Access at the account level

Why it fails: S3 Block Public Access is a security control that only restricts who can access an object or bucket via public policies; it has no bearing on how data is encrypted at rest. Enabling it at the account level would not detect or prevent CloudFormation from deploying an S3 bucket with SSE disabled, because the bucket's encryption configuration is entirely independent of public access settings. This option fails to address the encryption requirement.

Attach an IAM role to the CloudFormation service that grants permissions to encrypt buckets

Why it fails: Attaching an IAM role to the CloudFormation service simply grants permissions to perform API calls; it does not mandate that those calls include encryption parameters. Even with the s3:PutEncryptionConfiguration permission, CloudFormation will happily create an unencrypted bucket if the template omits the BucketEncryption property. IAM roles are not policy engines for resource configuration—they only authorize actions, so this approach cannot enforce encryption as a condition of resource creation.

Use a CloudFormation stack policy to deny creation of S3 buckets without encryption

Why it fails: A CloudFormation stack policy is designed to protect existing stack resources from being accidentally updated during a stack update operation; it does not impose conditions on resource creation. When CloudFormation initially creates an S3 bucket, the stack policy has no effect because the bucket does not yet exist to be protected. Moreover, stack policies cannot require that the template's BucketEncryption property be set—they only restrict update actions like replacement or deletion, not the initial configuration.

Use AWS KMS to encrypt the traffic.

Why it fails: KMS encrypts data at rest in AWS services, not data in transit across a Direct Connect link. It is tempting because KMS is the default encryption service in AWS, and it would be correct for protecting stored objects, volumes or secrets rather than network traffic between on-premises and a VPC.

Use AWS Certificate Manager to issue certificates for the connection.

Why it fails: ACM issues and manages certificates for TLS termination on AWS services; it performs no encryption of Direct Connect traffic. It is tempting because certificates underpin encrypted channels, and ACM would be the right choice when provisioning certificates for an Application Load Balancer or CloudFront distribution, not for a private VIF.

Use SSL/TLS to encrypt the traffic between on-premises and AWS.

Why it fails: SSL/TLS secures application-layer sessions between endpoints, not the network path itself, and cannot encrypt a private VIF carrying arbitrary IP traffic. It is tempting because TLS is ubiquitous for encryption in transit, and it would be correct for protecting HTTPS or database connections rather than site-to-site traffic.

Packet payload

Why it fails: VPC Flow Logs are metadata-only records of network traffic; they never capture the actual data content, or payload, of IP packets. The payload is not part of the flow log schema because the service samples and reports only header-level information such as IP addresses, ports, and protocol. To inspect payload contents, you would need a separate solution like Traffic Mirroring or an agent-based packet capture. Thus, packet payload is not captured.

IAM user ID

Why it fails: IAM user IDs are identity-layer information, while VPC Flow Logs operate at the network interface layer and therefore have no field for IAM identities. The flow log record contains only network metadata such as IP addresses and ports, not the principal who initiated the connection. To map traffic to a specific IAM user, you must correlate flow logs with authentication records like AWS CloudTrail. An IAM user ID is never captured in a VPC Flow Log.

DNS query name

Why it fails: DNS query names are application-layer payload content, not network header metadata, so VPC Flow Logs do not capture them. Flow logs sample IP traffic metadata at the hypervisor level and never inspect the payload of DNS packets or other application protocols. To log DNS query names, you would need Route 53 DNS logging or a dedicated packet-capture tool such as Traffic Mirroring. Therefore, a DNS query name is not a field in VPC Flow Logs.

Use AWS Config rules to detect users without MFA.

Why it fails: AWS Config rules such as iam-user-mfa-enabled assess whether each IAM user has an MFA device configured and report the account's compliance status, but they are purely detective controls. They do not intercept authentication requests or prevent a user from logging in without MFA; they only generate evaluation results and can trigger remediation actions that are not native to the login flow. Relying solely on Config leaves the unprotected access vectors open until manual or automated remediation completes, so this option does not ensure MFA enforcement for console access.

Apply an SCP that requires MFA for console access.

Why it fails: SCPs in AWS Organizations apply to all principal requests for account-level AWS service API actions, but they do not govern the IAM console login event itself. The login request is processed by IAM's authentication system before any SCP is evaluated, and the SCP cannot inspect the user's MFA session state to deny the initial sign-in. At best, an SCP could deny subsequent API actions when MFA is absent, but it cannot prevent a non-MFA user from completing console authentication, making it an incomplete and incorrect solution.

Configure an IAM password policy to require MFA.

Why it fails: The IAM password policy exclusively governs password requirements such as length, rotation, and complexity, and its MFA-related setting only mandates that users provide MFA when changing their own passwords. It does not apply to the initial console login process, so a user could still sign in without MFA as long as they know their password. Thus, configuring the password policy to require MFA for password changes has no effect on console access enforcement.

Enable S3 bucket keys to reduce KMS API calls.

Why it fails: Bucket keys only reduce KMS request costs and throttling by deriving a per-bucket key; they do not deny unencrypted PUTs. The requirement needs a bucket policy with s3:x-amz-server-side-encryption conditions. Bucket keys are tempting because they cut KMS API calls, and they would be correct when KMS throttling or cost is the concern.

Enable bucket policy to enforce SSL (aws:SecureTransport).

Why it fails: aws:SecureTransport enforces TLS in transit, not encryption at rest, so unencrypted objects could still be stored. Denying uploads requires a bucket policy condition on s3:x-amz-server-side-encryption. It is tempting because the policy does restrict uploads, and it would be correct when the requirement is HTTPS-only access to the bucket.

Create a service role for CloudFormation in the pipeline account with a trust policy for the target account.

Why it fails: A CloudFormation service role is an IAM role that CloudFormation assumes to perform stack operations in the account where the stack resides; its trust policy must grant access to the CloudFormation service principal (cloudformation.amazonaws.com), not to another AWS account. Creating such a role in the pipeline account with a trust policy for the target account does not enable cross-account access; instead, the pipeline must assume an IAM role in the target account via STS. The pipeline account's CloudFormation role would only manage stacks in the pipeline account, not the target account.

Store the target account root credentials in AWS Secrets Manager and retrieve them in the pipeline.

Why it fails: Storing the target account's root user access keys in AWS Secrets Manager is a severe security anti-pattern because root credentials are long-lived, have unfettered administrative permissions, and cannot be scoped down or rotated safely. Retrieving them in the pipeline would require the pipeline role to have secretsmanager:GetSecretValue, but the pipeline would then use static, highly privileged credentials that violate IAM best practices and most compliance frameworks. Cross-account access should always rely on temporary credentials obtained via AWS STS AssumeRole, never on shared root keys.

Configure the pipeline's IAM role with a trust policy that allows the target account to access it.

Why it fails: The pipeline's IAM role is designed to grant permissions to the pipeline service itself (for example, CodePipeline or CodeBuild), and its trust policy must identify the corresponding AWS service principal as the trusted entity. Adding the target account as a trusted principal in that trust policy would invert the trust relationship: it would allow the target account (or identities in it) to assume the pipeline role, not give the pipeline any access to the target account. The correct trust relationship is on the target-account role, which must trust the pipeline account to assume it.