Security and Compliance practice questions

Use AWS Single Sign-On (SSO) to assign permissions to users across accounts.

Why it fails: Incorrect. AWS SSO manages user access to accounts but does not centrally manage cross-account IAM roles as described.

Create an IAM role in the Security account with a trust policy that references a service control policy (SCP) in AWS Organizations.

Why it fails: Incorrect. Trust policies cannot reference SCPs; SCPs are attached at the OU or account level and are not referenced within a trust policy.

Create a resource-based policy on each IAM role in the member accounts that allows the Security account to assume the role.

Why it fails: Incorrect. IAM roles use trust policies, not resource-based policies. Resource-based policies are for services like S3 buckets.

The SCP requires an explicit allow statement in the IAM policy to override the deny.

Why it fails: SCPs are not an override mechanism where an IAM explicit allow can cancel a deny; effective permissions are the intersection of all policies. If an SCP denies or omits an action, even an explicit IAM allow for that action cannot make it permitted. The statement confuses the relationship between SCPs and IAM, as SCPs act as boundary controls that cannot be bypassed by adding an allow in the role's policy.

The IAM role does not have permission to tag resources.

Why it fails: The IAM role is described as having full DynamoDB access, which includes the DynamoDB:TagResource action through the wildcard resource and action permissions. Therefore, the failure to create the table is not caused by insufficient tagging permissions; the role can tag resources when the correct API call is made. The real limitation is that the CreateTable request does not carry tag information, so a tag-on-create condition cannot be evaluated.

The SCP is not applied to the development account because it is in a different OU.

Why it fails: The account's location in a different OU is not the cause because the scenario states the SCP applies to the development account, and SCPs can be attached directly to an account regardless of OU structure. Even if the SCP were attached only to the OU, being in a different OU would mean the SCP is not in effect, but that would produce a different error than a permissions denial. The observed denial is due to the tag condition, not the organizational hierarchy.

The Null condition incorrectly allows uploads without encryption.

Why it fails: Null condition denies when encryption header is missing, but if AES256 is provided, the header is not null.

The bucket policy does not apply to cross-account uploads.

Why it fails: The policy applies to all principals, including cross-account.

The bucket policy lacks an explicit Allow statement for s3:PutObject.

Why it fails: Deny statements are effective without an explicit Allow.

Use an IAM role in each account that grants write access to the central bucket, and use S3 default encryption.

Why it fails: Relying on per-account IAM roles and S3 default encryption is insufficient because default encryption uses SSE-S3, which lacks the auditability and fine-grained control of SSE-KMS, and the bucket policy cannot enforce that every writer actually applies encryption or uses HTTPS. Managing separate IAM roles in each account also increases complexity and the risk of misconfiguration, leaving central logging without a single, enforced access boundary.

Configure each account to write logs to its own S3 bucket, then replicate to a central bucket using S3 Cross-Region Replication.

Why it fails: Using per-account S3 buckets with S3 Cross-Region Replication to a central bucket adds latency and operational overhead, and replication does not automatically preserve encryption settings or access controls. CRR only replicates new objects after a source bucket is configured, and you must build cross-account IAM roles and handle encryption key differences, making the solution brittle and less secure because the destination bucket cannot enforce the same security posture on the original writes.

Use Amazon CloudWatch Logs in each account and export logs to a central S3 bucket using a Lambda function.

Why it fails: Exporting CloudWatch Logs through a Lambda function to S3 introduces custom code, Lambda timeouts, and potential data loss if the function fails, making it less reliable than a direct, managed integration. CloudWatch Logs does not encrypt at rest by default unless you configure KMS manually, and the Lambda-based export path is operationally complex, with no built-in monitoring or retry semantics, so it is not a secure or simple solution for centralizing audit logs.

Apply a service control policy (SCP) to deny opening port 22.

Why it fails: SCPs are an AWS Organizations feature that governs which AWS API calls principals in an account or OU can make; they cannot directly modify or rewrite security group rules, and they cannot 'deny opening port 22' as a network-level action. Although an SCP could deny the ec2:AuthorizeSecurityGroupIngress actions, that would block all ingress rule changes across the account rather than selectively restrict SSH from known IPs, and it still would not remediate rules that already exist. Network access control is enforced in the VPC by security group rules, which are evaluated in the data plane, not by IAM authorization policies.

Manually update each security group to restrict SSH to known IPs.

Why it fails: Manually updating each security group is operationally brittle because it relies on human effort to track and edit every current and future group, and it fails to detect configuration drift or newly created groups that reintroduce the same SSH exposure. In a dynamic environment with many instances, this approach is time-intensive, prone to errors (e.g., allowing the wrong CIDR), and provides no audit trail or automated verification. AWS Config's managed rule, by contrast, continuously evaluates all security groups against the restricted-ssh rule and can trigger automatic remediation the moment an offending rule appears.

Use CloudWatch Events to trigger a Lambda function that modifies security groups.

Why it fails: CloudWatch Events can trigger a Lambda function to modify security groups, but this approach lacks the ability to automatically detect newly created or modified EC2 instances whose security groups violate the policy. The scenario requires continuous, scalable remediation across all current and future resources, which CloudWatch Events cannot achieve without custom logic to poll for changes. This option is tempting because CloudWatch Events is commonly used to react to state changes, such as triggering a Lambda on an EC2 instance state change, and would be correct if the requirement were to remediate only existing, static security groups after a one-time audit.

AWS CloudFormation

Why it fails: AWS CloudFormation is an infrastructure-as-code provisioning engine that creates and updates AWS resources from templates. It does not manage or rotate application credentials; at most, it can reference secrets stored elsewhere via dynamic references such as `{{resolve:secretsmanager:...}}` in resource properties. Since it has no scheduling or credential lifecycle mechanism, it is wrong for this task.

AWS KMS

Why it fails: AWS KMS is a key management service that creates and controls KMS keys and performs encryption and decryption operations. It supports automatic rotation of the key material for KMS keys, but that rotates the encryption key, not the actual secret value such as a database password. Storing credentials and rotating those secrets is outside KMS's scope, so it cannot serve as a standalone secret management and rotation service.

AWS IAM

Why it fails: AWS IAM governs identities for AWS API access, including users, roles, groups, and policies, and supports rotating IAM user access keys for programmatic access. It does not manage application-defined secrets like database passwords, and its access keys are separate from credentials used by applications. Since the question asks about data credential management and rotation, IAM is not one of the correct services.

{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"ec2:CreateVpc","Resource":"*"}]}

Why it fails: This SCP only denies ec2:CreateVpc. It leaves ec2:ModifyVpc permissible, so administrators could still alter the CIDR block, DNS settings, or default tenancy of an existing VPC. Since the intent is to prevent all configuration changes to VPCs, restricting only creation leaves a critical control gap in the guardrail.

{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"ec2:*","Resource":"*"}]}

Why it fails: Denying ec2:* is overly broad; it blocks not only VPC changes but also foundational actions like RunInstances, DescribeInstances, and CreateSubnet. Such a policy would effectively freeze all EC2 usage in the OU, likely causing production outages and breaking operational tooling. The requirement is limited to prohibiting VPC creation/modification, not disabling the entire EC2 service.

{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":["ec2:CreateVpc","ec2:DeleteVpc"],"Resource":"*"}]}

Why it fails: This policy denies creation and deletion but omits ec2:ModifyVpc, so an adversary could still change a VPC's CIDR block, enable classic link, or adjust DNS attributes. Furthermore, deletion is not the stated concern; modification is what must be prevented. Since ModifyVpc is the primary action for altering existing VPCs, failing to deny it leaves the SCP ineffective.

Attach an IAM policy to the user in account 111111111111 allowing s3:GetObject.

Why it fails: An identity policy on the user in account 111111111111 grants nothing on a bucket owned by account 222222222222, because S3 evaluates the resource owner's policy. Cross-account access needs a bucket policy in account 222222222222 naming the source principal. Identity policies are correct for granting a user access to resources within their own account.

Set the bucket ACL to grant full control to account 222222222222.

Why it fails: ACLs are not recommended; bucket policy is preferred.

{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111111111111:root"},"Action":"s3:GetObject","Resource":"arn:aws:s3:::example-bucket/*"}]}

Why it fails: The Principal names account 111111111111, but the bucket belongs to account 222222222222, so this policy grants the wrong account and the intended source is denied. The Principal must reference the source account whose users need access. This structure is correct when the named account genuinely owns the requesting principals.

Client-Side Encryption

Why it fails: Client-side encryption is not a server-side encryption feature of Amazon S3 because the data is encrypted by the customer's application before it is ever sent to AWS. With this approach, S3 receives only ciphertext and has no access to plaintext or encryption keys, which are managed entirely by the customer. This satisfies a security requirement of maintaining key ownership, but it is ineligible in this scenario because the question explicitly asks for an S3 server-side encryption mechanism.

Server-Side Encryption with S3-Managed Keys (SSE-S3)

Why it fails: SSE-S3 is inappropriate here because, although it is a legitimate server-side encryption option, AWS completely manages and rotates the encryption keys on the customer's behalf. The customer cannot upload or control their own keys, and there is no way to satisfy a requirement that the customer provide and control keys. Therefore, even though SSE-S3 provides strong encryption at rest, it does not meet the 'customer-provided keys' condition.

Server-Side Encryption with AWS KMS-Managed Keys (SSE-KMS)

Why it fails: SSE-KMS is also server-side, but the encryption keys are generated and managed by AWS Key Management Service; the customer only controls access through IAM and key policies, not the key material itself. Although S3 integrates with KMS to provide envelope encryption, automatic rotation, and audit logging, this does not allow the customer to directly supply their own encryption key with each API call. Because the key remains AWS-managed, SSE-KMS fails the requirement that the customer provides and manages the keys.

The policy creates an IAM role for MFA enforcement.

Why it fails: An IAM policy is a permissions document attached to users, groups or roles; it never creates a role. Role creation is a separate IAM action. The policy's purpose is to deny API calls lacking MFA context, which would be the correct approach when enforcing MFA on a role's sessions.

The policy applies to the AWS account root user.

Why it fails: IAM identity-based policies attached to users do not govern the root user, which has unrestricted account access regardless. The root user's MFA is configured in account settings. This policy is the right tool for restricting IAM users' API operations, not the root account.

The bucket policy requires HTTPS, but the user is using HTTP.

Why it fails: The policy does not contain a Condition block that requires aws:SecureTransport, so HTTPS is not enforced. If the user is calling over HTTP, S3 will still process the request and apply the same allow/deny decisions based on the Action and Principal, not the transport protocol. Therefore an HTTP request would not be denied by this policy, and the inability to list objects is not transport-related.

The policy does not allow s3:ListBucket, so the user cannot list objects.

Why it fails: The bucket policy grants only s3:GetObject, not s3:ListBucket. In the S3 console, the first step is to list the objects in the bucket via ListObjectsV2, which requires s3:ListBucket on the bucket resource. Even though the user has permission to download an object (GetObject), they cannot see any object names in the console without ListBucket, so they cannot select and download anything. The root cause is the missing list permission.

The bucket policy does not allow s3:GetObjectVersion.

Why it fails: The user is attempting to download the current version of an object, and that operation is permitted by s3:GetObject alone. s3:GetObjectVersion is only required when you explicitly request a specific version ID, for example through the S3 console's 'Versions' tab or by including a versionId parameter in the API call. Since the policy already allows s3:GetObject, a lack of GetObjectVersion is not the cause of the access problem.

The role to decrypt any KMS key.

Why it fails: The Resource element is set to '*', but this policy is embedded in a single customer master key's key policy. Resource wildcards inside a key policy do not grant access to other keys; the policy's effect is scoped to this exact CMK. IAM policies alone cannot allow the role to use other keys unless those keys' policies also grant permission, so this description is incorrect.

The role to decrypt via any AWS service.

Why it fails: The kms:ViaService condition constrains the allowed caller to a specific service principal, s3.us-east-1.amazonaws.com. Every KMS request must satisfy this condition, which means the role can only decrypt when the call is made in the context of Amazon S3 in that region. Other services or API calls, even with the same IAM role, would fail the condition and be denied, so the role cannot decrypt via any AWS service.

Any IAM role to decrypt using this key.

Why it fails: The principal in the key policy is the ARN of one specific role, so only that exact role is allowed to use this key. Other IAM roles are not listed in the key policy and therefore receive no permission from it; IAM identity-based policies alone are insufficient for KMS access unless the key policy grants access. Thus, saying 'any IAM role' is false because the principal field restricts it to a single role.

AmazonSQSFullAccess

Why it fails: AmazonSQSFullAccess is wrong because SQS (Simple Queue Service) manages message queues, not log ingestion. Writing to CloudWatch Logs requires the logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents permissions, none of which are included in the SQS policy. Attaching this managed policy would grant broad, irrelevant queue permissions while leaving the instance unable to perform any CloudWatch Logs writes.

AmazonDynamoDBFullAccess

Why it fails: AmazonDynamoDBFullAccess targets DynamoDB's NoSQL table operations, such as dynamodb:PutItem and dynamodb:Query, which have no bearing on CloudWatch Logs. This policy supplies zero logs: permission actions, so an EC2 instance relying on it would fail at runtime when the CloudWatch agent attempts to send log events. Furthermore, it exposes unnecessary database write/read privileges, directly violating least privilege.

AmazonS3FullAccess

Why it fails: AmazonS3FullAccess is irrelevant because CloudWatch Logs has its own PutLogEvents API endpoint and is not a destination inside an S3 bucket. While CloudWatch Logs can export data to S3 via export tasks, that is a separate administrative operation performed by CloudWatch, not by an EC2 instance writing logs. This policy would grant broad S3 object and bucket permissions yet still lack the required CloudWatch Logs write actions.

Use CodePipeline's built-in artifact signing feature.

Why it fails: CodePipeline does not have a built-in artifact signing feature; it relies on S3 for artifact storage and does not generate or attach digital signatures to the artifacts themselves. AWS Signer can sign code for specific runtimes, but it is not integrated into CodePipeline's artifact delivery mechanism and cannot be used to certify the encryption key of a stored artifact. Since no such native signing option exists, this cannot provide the required cryptographic verification.

Use S3 pre-signed URLs to download artifacts.

Why it fails: Pre-signed URLs are temporary, credential-bearing URLs that grant permission to download a specific S3 object, but they only prove that a request is authorized; they do not attest to or enforce the object's encryption state or the KMS key that encrypted it. An object protected with SSE-S3, a different customer-managed key, or even no encryption would still be downloadable via the same pre-signed URL. Therefore, a pre-signed URL cannot help the vendor confirm that the artifact was encrypted with the vendor's KMS key.

Amazon CloudWatch Logs and Amazon SNS

Why it fails: CloudWatch Logs does not automatically log S3 access.

VPC Flow Logs and Amazon GuardDuty

Why it fails: VPC Flow Logs are for network traffic, not S3 access.

Amazon S3 server access logs and Amazon Macie

Why it fails: Server access logs record requests; Macie can alert on sensitive data.

AWS Security Hub

Why it fails: AWS Security Hub is a central security posture management service that aggregates and correlates findings from multiple AWS services and third-party tools, but it does not itself inspect container image layers or identify vulnerabilities. In a CI/CD pipeline, Security Hub only receives and displays findings after they have already been generated by a scanning service. Therefore, choosing Security Hub as the image-scanning mechanism would leave the image unscanned at build time and provide no actionable vulnerability data to block the pipeline.

Amazon Inspector

Why it fails: Amazon Inspector is a vulnerability assessment service that is designed to evaluate the software and network configuration of EC2 instances, not to perform on-push vulnerability scans of container images stored in Amazon ECR. While it can identify issues in the runtime environment, it does not have a direct integration to scan image layers as they are pushed during a CI/CD build. Consequently, it cannot serve as the scanning step that inspects the container image itself in the pipeline.

AWS Config

Why it fails: AWS Config records and evaluates the configuration state of AWS resources against compliance rules, such as checking whether a resource has a particular tag or encryption setting. It is not designed to inspect the contents of container images, including installed packages and operating system dependencies, for known security vulnerabilities. As such, AWS Config would not provide the vulnerability-scanning feedback that the CI/CD pipeline needs before promoting the image.

Configure security group to allow only HTTPS.

Why it fails: Security groups are stateless and don't encrypt traffic.

Install a certificate on the ALB and use HTTP.

Why it fails: HTTP is not encrypted.

Enable encryption in transit on the ALB.

Why it fails: ALB can terminate HTTPS but not automatically encrypt backend traffic.

Use an AWS Config managed rule to detect non-compliant buckets and trigger a remediation Lambda function.

Why it fails: Reactive, not preventive.

Enable AWS CloudTrail and create a metric filter to alert on bucket creation, then manually review.

Why it fails: Manual and reactive.

Apply an S3 bucket policy in each account that denies s3:PutBucketPublicAccessBlock with a condition.

Why it fails: Requires per-account configuration.

Generate an access key for the root user of the source account and use it in the application.

Why it fails: Using the source account root user's access keys in an application is a critical security anti-pattern. Root credentials are not scoped by IAM policies — they have full administrative privileges, so any compromise of the application exposes the entire account. AWS also forbids creating or storing root access keys for ongoing programmatic use, and long-term access keys are unnecessary when you can use roles with temporary credentials for cross-account access. This approach completely violates least privilege and should never be used for a legacy application migration.

Create an IAM user in the target account with access keys and store them in AWS Secrets Manager.

Why it fails: Creating an IAM user in the target account and storing its access keys in AWS Secrets Manager still leaves the application dependent on long-term credentials. Secrets Manager provides encryption and rotation, but it does not remove the risk of static keys being leaked, and rotating them requires the application to fetch updated values. IAM roles offer time-limited, automatically rotated credentials for cross-account access, so this option needlessly introduces credential management overhead and violates the principle of least privilege.

Create an IAM user in the source account with programmatic access and a bucket policy allowing that user.

Why it fails: This option configures a long-term IAM user in the source account and then relies on a bucket policy in the target account to allow that exact user ARN. Unlike a role, an IAM user has permanent access keys, which cannot be rotated as seamlessly and remain valid for an indefinite period, increasing exposure if the keys are extracted. Cross-account access should be granted to an IAM role that the application can assume, not to a static IAM user, because roles provide temporary credentials and make the trust relationship explicit and auditable. This approach is not a secure or maintainable pattern for a production migration.

Modify the custom resource to use the EC2 instance profile instead of a Lambda function.

Why it fails: Using the EC2 instance profile is not a standard method for custom resources; moreover, the instance profile would still need permissions to update the bucket policy, which is not addressed.

Add an inline policy to the Lambda execution role that allows s3:PutBucketPolicy and ensure the bucket policy allows the EC2 instance role.

Why it fails: Adds the s3:PutBucketPolicy permission to the Lambda role but does not explicitly add the bucket policy; it only ensures it allows the EC2 instance role, which may not exist. The correct approach requires both the Lambda permission and the explicit creation of the bucket policy.

Attach a policy to the EC2 instance role that allows s3:GetObject on the bucket.

Why it fails: This only grants the EC2 instance read access but does not resolve the Lambda function's permission issue to update the bucket policy.