Security and Compliance practice questions

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

Why it fails: 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 it fails: 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 it fails: 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.

aws:SourceVpc

Why it fails: The aws:SourceVpc condition key is only applicable when the request comes through a VPC endpoint, such as an interface VPC endpoint for Systems Manager. It checks the VPC ID associated with that endpoint, not the client's IP address, so it cannot enforce IP-based allow/deny rules for requests from the internet or a VPN. Furthermore, if the request does not use a VPC endpoint, this condition will not match and access may be denied, making it unsuitable for source IP restrictions.

aws:RequestedRegion

Why it fails: The aws:RequestedRegion condition key restricts which AWS region a request targets, based on the region in the API endpoint or the credential's region. It does not evaluate the client's IP address at all, instead limiting the geographical scope of operations like accessing Parameter Store in a specific region. While it can prevent access to parameters in certain regions, it cannot block an individual caller based on their source IP, so it is not the correct key for IP-based restrictions.

aws:UserAgent

Why it fails: The aws:UserAgent condition key matches the User-Agent header sent by the calling client, such as the AWS CLI, SDK, or custom application. It identifies the software or version making the request, not the network location or IP address of the caller. Using this key would let you allow or deny access from specific tools or agent strings, but it does not provide any control over the requester's IP address, making it incorrect for IP-based access restrictions.

Set an IAM permissions boundary on all users that denies 'iam:CreateAccessKey'.

Why it fails: IAM permissions boundaries are advanced features that set the maximum permissions an IAM entity can receive, but they apply only to IAM roles, not to IAM users directly. Even if you could attach a boundary to a user (which is not supported), the root user is not an IAM entity governed by such policies, so the root account could still create access keys. Additionally, permissions boundaries do not deny actions outright; they limit what a policy allows, and an explicit deny in a boundary would conflict with how boundaries are evaluated—they only restrict allowed permissions, not deny them directly. Thus, this approach fails both because it cannot target the root user and because boundaries are not a valid mechanism to prohibit access key creation.

Create an S3 bucket policy that denies access to IAM users with access keys.

Why it fails: An S3 bucket policy controls access to the bucket itself—it specifies who can perform actions like s3:GetObject or s3:PutObject on that bucket, not on IAM services. IAM access key creation is governed by the IAM service's control plane (iam:CreateAccessKey), which is unrelated to any S3 resource policy. Even if you wrote a policy that denies access to users with access keys, it would only affect S3 operations, and it would not prevent creation of new access keys through the IAM API or console. Moreover, S3 bucket policies are resource-based policies that apply to the bucket, not to identity-based actions, so they have no authority over IAM user management actions.

Create an IAM group with a policy that denies 'iam:CreateAccessKey' and add all users to that group.

Why it fails: An IAM group policy that denies iam:CreateAccessKey only affects the users who are members of that specific group, and it relies on the group membership being universally applied. If any user is not added to the group, or if a new user is created later and not immediately placed in the group, that user can freely create access keys. More critically, the IAM root user is not subject to IAM group permissions at all—the root user is the account owner and does not belong to any IAM group, so this policy would not stop the root user from creating access keys. This approach is fragile and incomplete because it lacks the organization-wide enforcement that an SCP provides.

Use AWS KMS customer master key (CMK) with automatic rotation enabled and client-side encryption.

Why it fails: Using an AWS KMS customer master key (CMK) with automatic rotation and client-side encryption gives you a managed key service, but KMS automatic rotation occurs only once per year (approximately 365 days), not every 90 days as required. While you could manually rotate a KMS CMK, the option as stated specifies automatic rotation, which cannot be configured to a 90-day interval. Additionally, client-side encryption with KMS still requires careful key policy management, but the primary failure here is the rotation frequency.

Use SSL/TLS to encrypt data in transit from EC2 to S3.

Why it fails: SSL/TLS only protects data during transmission between EC2 and S3, leaving the data unencrypted once it is stored as an S3 object. Because the requirement is to encrypt the data itself before writing to S3, transport-layer encryption alone does not satisfy it. Additionally, SSL/TLS offers no key management or rotation mechanism, so a 90-day rotation schedule cannot be implemented.

Use Amazon S3 server-side encryption with SSE-S3.

Why it fails: Amazon S3 server-side encryption with SSE-S3 encrypts data at rest using S3-managed keys, but those keys cannot be controlled, rotated, or audited by the customer. The requirement demands a 90-day key rotation schedule and the ability to audit key usage, which SSE-S3 does not provide. This option also does not perform client-side encryption, so data remains visible in transit unless separately secured.

Add a condition in the S3 bucket policy to allow only requests from the VPC.

Why it fails: S3 bucket policy does not control KMS key usage.

Use an IAM policy with a condition that requires the request to come from the VPC.

Why it fails: IAM policies cannot restrict KMS based on VPC.

Configure a network ACL that blocks all traffic to KMS except from the VPC.

Why it fails: NACLs control network traffic, not API calls.

The policy does not allow the 'ec2:DescribeSubnets' action, so the user cannot list subnets.

Why it fails: The error is not about listing subnets; it occurs during the RunInstances API call. The IAM policy's condition key 'ec2:Subnet' is evaluated against the launch request itself, so a missing or incorrect subnet ID triggers the denial. Lacking 'ec2:DescribeSubnets' would only prevent the user from viewing available subnets in the console or CLI, not from launching an instance when a valid subnet ID is supplied. The permission to describe subnets is separate from the permission to run instances, and the condition key is what is causing the failure.

The policy denies all subnets except subnet-12345.

Why it fails: The policy does not contain an explicit Deny statement; it uses an Allow with a condition, which creates an implicit deny for any subnet other than subnet-12345. The statement 'denies all subnets except subnet-12345' is imprecise because IAM evaluates Allow statements with conditions by checking if the condition is true; if the requested subnet does not match, the request is not explicitly denied but simply not allowed. This distinction matters because an explicit Deny overrides all allows, while an implicit deny can be overridden by a broader Allow statement from a different policy. The user could be receiving this error by launching into a different subnet, but the mechanism is an implicit, not explicit, denial.

The condition key 'ec2:Subnet' is not supported for RunInstances.

Why it fails: The 'ec2:Subnet' condition key is fully supported for the RunInstances action and is commonly used to restrict instance launches to specific subnets. It can be used with string condition operators such as StringEquals or ArnEquals, depending on whether you specify a subnet ID or ARN. If the key were unsupported, the condition would be ignored rather than causing a denial, so the error indicates the condition was evaluated and failed. The real issue is not the key's support status but that the request did not satisfy the condition, typically because no subnet ID was provided or a different subnet was selected.

Enable default encryption on the bucket.

Why it fails: Default encryption (SSE-S3 or SSE-KMS) ensures that all objects are encrypted at rest, protecting data confidentiality if an unauthorized entity gains access to the underlying storage. However, encryption does not affect authorization; it does not prevent a user or service from reading or writing objects if they have valid IAM credentials. The requirement is to restrict access to the VPC, which is an access-control problem, not a data-at-rest protection problem.

Enable MFA Delete on the bucket.

Why it fails: MFA Delete is a versioning feature that requires a one-time code from a hardware or virtual MFA device to permanently delete an object version or suspend versioning. It is designed to protect against accidental or malicious deletion, not to control read, write, or list operations. Since the scenario is about limiting who can access the bucket (and from where), enabling MFA Delete has no effect on the bucket's accessibility.

Use Amazon CloudFront with Origin Access Identity (OAI).

Why it fails: CloudFront with an Origin Access Identity (OAI) lets CloudFront retrieve objects from an S3 bucket as a trusted principal, so users only see CloudFront URLs and cannot access S3 directly through the origin. Yet this only secures the origin; it does not restrict access to a VPC because the bucket remains accessible to any principal with IAM permissions, and a bucket policy that grants public access would still allow direct access. OAI is about protecting the origin, not constraining the network path to a VPC.

s3:SourceVpce

Why it fails: s3:SourceVpce is not a recognized condition key; the correct prefix for VPC endpoint conditions is aws:SourceVpce, not s3:. S3-specific condition keys use the s3: prefix (e.g., s3:prefix, s3:max-keys), but SourceVpce is not among them, so this option is invalid and would cause a policy error if used.

aws:SourceIp

Why it fails: aws:SourceIp restricts based on the source IP address, but it cannot guarantee that a request originates from a particular VPC because VPC traffic can traverse public IPs or NAT gateways. This condition key is useful for IP-based access control, but it does not validate the VPC context, so it fails to meet the requirement of restricting to a specific VPC.

ec2:Vpc

Why it fails: ec2:Vpc is not a valid condition key in S3 bucket policies; S3 only recognizes a limited set of condition keys, including those prefixed with s3: and AWS-wide keys like aws:SourceVpc. The ec2 namespace is reserved for EC2-specific conditions, but ec2:Vpc is not a defined key, and even if it were, S3 bucket policies would not evaluate it.

Create a new IAM policy that denies access from the IP address and attach it to all users.

Why it fails: This is incorrect. An IAM policy attached to all users would only affect users in the current account, not all accounts in the organization. Additionally, managing policies for all users individually is not scalable and does not block API calls from roles or other principals.

Create an IAM policy that denies access from the IP address and attach it to the organization root.

Why it fails: IAM policies are identity-based or resource-based and can only be attached to IAM users, groups, roles, or specific AWS resources—never to the organization root, an organizational unit, or an AWS account as a whole. The organization root is a container for accounts and OUs, and the only policy type that can be attached at that level is a service control policy (SCP), which manages permissions across all accounts in the organization. Attaching an IAM policy to the organization root is not a valid operation in AWS, so this approach would not deny access from the IP address.

Create a service control policy (SCP) that denies access from the IP address and attach it to the IAM user.

Why it fails: This is incorrect. Service control policies cannot be attached directly to IAM users; they are applied at the organization root, OU, or account level. Also, SCPs affect all principals in the target accounts, not a single user.

Enable S3 Block Public Access at the account level.

Why it fails: Account-level S3 Block Public Access is a powerful safeguard against unintended public exposure, but it operates on a completely different axis than encryption. It does nothing to require or even encourage SSE-S3, SSE-KMS, or SSE-C on newly created buckets. Because encryption configuration is independent of public access settings, an unencrypted S3 bucket can still be created and remain private, leaving data at rest unprotected.

Enable default encryption on each existing bucket.

Why it fails: Applying default encryption to each existing bucket remediates only the buckets that already exist today. When a developer calls CreateBucket without specifying encryption parameters, the new bucket is born without any default encryption because bucket-level default encryption is a per-bucket setting. This approach provides no forward-looking guarantee and requires continuous manual or automated maintenance to cover every new bucket.

Use a service control policy (SCP) to deny creation of buckets without encryption.

Why it fails: An SCP that denies s3:CreateBucket when the request does not include appropriate encryption settings is a true preventive control. For example, you can add a condition key such as s3:x-amz-server-side-encryption or s3:x-amz-server-side-encryption-aws:kms, and if absent, the CreateBucket call fails across all accounts in the organization. This enforces encryption at creation time before any object can be stored.

Use a network ACL to allow only port 443.

Why it fails: A network ACL (NACL) operates at the subnet boundary and is stateless, meaning it filters traffic based on port, protocol, and source/destination IP addresses. Allowing only port 443 would permit HTTPS/TLS traffic to enter the subnet, but a NACL does not perform any encryption or decryption; it simply allows or denies packets. Thus, this approach does not ensure that data in transit is encrypted, and stateless rules also require separate outbound rules for return traffic.

Use a security group to allow only TLS traffic.

Why it fails: Security groups are stateful, virtual firewalls that control inbound and outbound traffic at the instance level, but they only evaluate packet metadata such as protocol and port, not whether the application layer payload is actually TLS-encrypted. You cannot create a rule that 'allows TLS traffic' because security groups do not inspect or validate the encryption of the data stream; they can only allow, for example, TCP port 443. As a result, a security group rule would permit non-encrypted traffic on allowed ports and does not enforce encryption.

Use AWS Direct Connect to route all traffic.

Why it fails: AWS Direct Connect establishes a dedicated, private physical network connection between your data center and AWS, bypassing the public internet, but it does not intrinsically encrypt the data crossing that link. While the connection is private, traffic can still be exposed to physical layer risks or internal interception, so you must separately enable encryption such as IPsec VPN or TLS over the Direct Connect VIF. Therefore, routing traffic via Direct Connect alone does not satisfy a requirement for encryption in transit.

A trust policy in Account B allowing the IAM role to access the bucket.

Why it fails: A trust policy is an IAM role attribute that defines which principals are allowed to assume the role, so it must be attached to the IAM role in Account A—not placed in Account B. In Account B, the resource side controls access via a bucket policy, which explicitly lists the role ARN. A trust policy in Account B would be invalid and would not grant the role in Account A any S3 permissions, because trust policies only answer the question of who can assume a role, not what that role can do.

A bucket policy in Account B allowing access from the IAM role.

Why it fails: The bucket policy in Account B is one half of the solution, but it cannot work alone. For the IAM role in Account A to actually have credentials, the role must include a trust policy that specifies which principals can assume it; otherwise, no user or service can obtain the role's temporary credentials to present in a signed S3 request. Without an assumed role session, the bucket policy's Allow statement referencing the role ARN never matches an actual principal, so the request is denied.

An IAM role in Account A with a policy allowing access to the bucket.

Why it fails: The role's identity-based policy in Account A is necessary but insufficient for cross-account access. When a request reaches the bucket in Account B, S3 evaluates both the principal's permissions and the bucket's resource policy; because the resource owner is a different account, the bucket policy must explicitly allow the role ARN, otherwise the default implicit deny applies. Since the role's policy alone cannot grant access to a bucket owned by another account, the bucket policy in Account B must also be configured to authorize the role.

Create a bucket policy that allows the auditor's IP address.

Why it fails: A bucket policy that restricts by source IP only controls the network origin; it still requires the requester to authenticate with valid AWS credentials in the request. Without an IAM identity or access keys assigned to the auditor, the policy has no principal to match, and setting Principal to "*" would expose the bucket to any user on that IP. IP-based restrictions also break if the auditor's egress IP changes.

Create an IAM user for the auditor and share the credentials.

Why it fails: Creating a dedicated IAM user and sharing credentials introduces long-term access keys that must be rotated, monitored, and revoked after the engagement. This violates the principle of least privilege and creates unnecessary risk, since the auditor would have a persistent identity in your account. AWS recommends cross-account roles or temporary credentials for external access, but for simple object sharing, presigned URLs are more controlled and do not require creating a user.

Use CloudFront signed URLs.

Why it fails: CloudFront signed URLs also provide time-limited access, but they require deploying and configuring a CloudFront distribution in front of the S3 bucket, including an origin access identity and corresponding bucket policy changes. This adds architectural complexity, management overhead, and cost for a scenario that only needs direct object access. Additionally, CloudFront signed URLs restrict access at the edge, not at the S3 object level, so the bucket must be private via CloudFront, which is far more than what an external auditor read-only access requires.

Use an Action element to allow only MFA actions.

Why it fails: Using an Action element to allow only MFA actions is incorrect because Action specifies the actions, not the MFA requirement; MFA enforcement requires a Condition.

Use a NotAction element to allow password change without MFA.

Why it fails: Using a NotAction element to allow password change without MFA is incorrect because NotAction does not enforce MFA; it only excludes actions from the policy.

Use a Resource element to limit access to MFA-enabled users.

Why it fails: Using a Resource element to limit access to MFA-enabled users is incorrect because Resource specifies which resources the policy applies to, not the authentication condition.

Create an IAM user in the administrator's account and share the access key and secret key with the developer.

Why it fails: Sharing long-term access keys created in the administrator's account is insecure because the developer inherits every permission of that IAM user, not just access to the S3 bucket, and the credentials are never subjected to MFA or environment-specific controls. The keys remain valid indefinitely until manually rotated, and any copy in source control or chat logs becomes a persistent backdoor. Moreover, this approach grants access using the administrator's account identity, making audit logs and policy boundaries confusing, and it violates the AWS Well-Architected practice of not sharing credentials across accounts.

Generate pre-signed URLs for all objects and share them with the developer.

Why it fails: Pre-signed URLs only authorize a single object GET (or PUT) for a limited time, normally 15 minutes to 7 days, after which they expire and cannot be renewed. You cannot generate a pre-signed URL for s3:ListBucket, so the developer would be unable to enumerate objects, which is a required action in the scenario. With many objects, creating and managing an individual URL for each object is impractical, and anyone who obtains the URL can access the object without being authenticated as the developer.

Grant the developer's AWS account root user access to the bucket using a bucket policy.

Why it fails: Granting access to the developer's AWS account root user is an anti-pattern for two reasons: the bucket policy would authorize only the root principal, not the developer's IAM user, so the developer would still be denied access when acting as an IAM user. Root credentials are synonymous with full account control, and every security recommendation prohibits using the root user for programmatic access; even if the root user could delegate via IAM, this option would not solve the developer's need. Least privilege demands granting access to the exact IAM user ARN that the developer uses, not to an account-level principal.

Create a new IAM role for each instance and attach the tag.

Why it fails: This is not scalable and does not enforce the tag requirement.

Use a service control policy (SCP) to deny the ec2:AssumeRole action for instances without the required tag.

Why it fails: SCPs apply to accounts, not to EC2 instances.

Modify the instance profile to include the tag requirement.

Why it fails: Instance profiles do not support tag-based conditions.

Disable the KMS key so it cannot be used but can still be deleted.

Why it fails: Disabling a KMS key only changes its enabled state to false, which immediately prevents any cryptographic operations such as encrypt, decrypt, or generate-data-key. This does not protect against deletion because the key remains in the same key policy and can still be scheduled for deletion via kms:ScheduleKeyDeletion at any time. In fact, a disabled key that is scheduled for deletion cannot be made available again unless the deletion is canceled before the waiting period expires. Thus, disabling alone leaves an organization vulnerable to accidental or malicious deletion, and data encrypted with that key would become permanently unrecoverable once deleted.

Create a backup of the KMS key in another AWS Region.

Why it fails: AWS KMS key material is created, stored, and used only within the AWS Region where the customer managed key exists; KMS does not provide any export or backup operation for symmetric or asymmetric keys. Attempting to 'back up' a key would mean creating a new customer managed key in another Region, but that new key has entirely different key material and cannot decrypt data that was encrypted by the original key. Even cross-region key replication is not available for KMS keys, so this option provides no disaster-recovery or deletion-protection benefit for the original key.

Use a service control policy (SCP) to deny the kms:ScheduleKeyDeletion action.

Why it fails: Service control policies (SCPs) are available only when the account is part of AWS Organizations, and they are inherited by all principals in a member account, but an SCP cannot restrict the root user of the management account. Even if an SCP could deny kms:ScheduleKeyDeletion for most IAM users, a user with IAM permissions to attach or modify SCPs, or the root user, could bypass it, and SCPs alone do not protect a key from deletion by an administrator in the same account. Additionally, the correct defense is to use the KMS key policy with a condition requiring MFA, not an SCP, because SCPs do not govern direct KMS API calls from the root user in the same account.

Disable the IAM user's account immediately

Why it fails: Disabling the IAM user account entirely is an overly aggressive response that removes all access, including any legitimate operations that may be running in the expected region, and it can cause business disruption far beyond the scope of the alert. It also fails to address the underlying issue that long-term access keys can be used from anywhere unless a policy condition restricts the allowed regions or source IPs. A targeted solution is to apply a Deny condition to the user's policy so that only the expected region is permitted, leaving the rest of the user's functionality intact.

Enable multi-factor authentication (MFA) for the IAM user

Why it fails: Enabling MFA on the IAM user adds an authentication factor but does not restrict which geographic region or source IP can use the user's access keys. Access keys are long-term credentials that directly authenticate requests without requiring an MFA challenge, and unless the policy explicitly includes a condition like 'aws:MultiFactorAuthPresent' (enforced via a Deny for false), MFA does not affect API call authorization. Even when MFA is enforced, it only proves the user authenticated with a device; it does not stop a key from being used in an unexpected region, so the alert condition would remain unresolved.

Delete the IAM user's access key and create a new one

Why it fails: Deleting the access key and rotating a new one treats the symptom by invalidating any credential already stolen, but it does not implement any control to prevent the new key from being used from unexpected regions if it is compromised again. Without a policy condition such as 'aws:SourceIp' or 'aws:RequestedRegion', the freshly generated key will have exactly the same unrestricted geographic access as the old one. This reactive measure is important for credential hygiene but must be paired with a restrictive condition to address the root cause of location-based misuse.

Disable public access to the S3 bucket

Why it fails: Disabling public access to the S3 bucket is a foundational security practice, but it is not a specific step for securely transferring a large dataset from on-premises. Public access is typically already blocked in a well-configured account, and the question focuses on securing the transfer path—such as network endpoints and encryption—rather than ensuring the bucket isn't publicly readable. In fact, if the bucket were publicly writable, disabling public access alone would not protect data in transit or at rest; it simply closes a misconfiguration that should already be avoided.

Use an S3 bucket policy that denies requests unless they are made over HTTPS

Why it fails: While requiring HTTPS via a bucket policy is a sound policy to enforce secure transport, it is a configuration that is often already implied by the transfer method and does not directly address the on-premises transfer path. The statement is also incomplete: the administrator would need to write a deny statement with the condition 'aws:SecureTransport' equals false, but this is a policy action, not an operational step like enabling encryption or configuring an endpoint. In a VPC or Direct Connect scenario, traffic is already private, but this policy would still be useful for any public HTTP attempts—however, it does not secure the on-premises source boundary, which the endpoint policy achieves.

Send CloudTrail logs to CloudWatch Logs for real-time monitoring

Why it fails: Sending CloudTrail logs to CloudWatch Logs allows you to create metric filters and alarms to monitor API activity in real time, such as detecting unauthorized calls. However, this is a detective control; it does nothing to prevent deletion or modification of the CloudTrail trail or the underlying log files, nor does it provide any integrity checking. An attacker who gains sufficient permissions could still disable CloudTrail or alter the logs before an alarm triggers.

Enable MFA delete on the S3 bucket

Why it fails: MFA delete requires a six-digit code and a device code from a hardware MFA device to permanently delete an object version or suspend versioning, but it only applies to version-enabled S3 buckets and only when the root user is not the caller. It does not prevent overwriting of objects or deletion of the current version if versioning is not enabled, and it does not protect the CloudTrail trail configuration itself. Therefore, it offers limited and not CloudTrail-specific protection against a determined attacker who might not be the root user.