Management and Security Governance practice questions

Apply a bucket policy on each bucket denying PutObject without encryption

Why it fails: Bucket policies apply to individual buckets, not all buckets.

Enable AWS Config with the s3-bucket-server-side-encryption-enabled rule

Why it fails: Config rules only detect non-compliant resources, they do not enforce.

Attach an IAM policy to each account's admin user requiring encryption

Why it fails: IAM policies are per-account and not inherited across accounts.

Remove the developer's permissions and require all changes through IT.

Why it fails: Removing developer permissions and funneling all changes through IT is an operational process, not a durable security control. It blocks the team's agility and still leaves the bucket vulnerable to accidental or malicious deletion by the IT staff themselves. Proper security would apply least privilege with versioning-based recovery, not eliminate access entirely.

Configure an S3 lifecycle policy to archive objects to S3 Glacier.

Why it fails: An S3 lifecycle policy that transitions objects to S3 Glacier only changes the storage class; it does not shield objects from deletion. Once archived, a DeleteObject request will still permanently remove the object (and its versions, if versioning is not enabled). Lifecycle rules can even be used to expire objects, so this option actually introduces additional deletion risk rather than preventing it.

Use AWS CloudTrail to monitor deletions and alert the security team.

Why it fails: CloudTrail alerts are detective and reactive—they notify you after a deletion has already occurred. While logging data events can aid forensics, monitoring cannot restore deleted objects or block the DeleteObject API call. Without versioning, by the time the security team receives an alert, the data is already irretrievably gone.

Enable AWS CloudTrail in the management account and use S3 bucket policies.

Why it fails: Enabling CloudTrail only in the management account captures events for that single account, not for the hundreds of member accounts that also need audit trails. An S3 bucket policy can restrict who reads or deletes the log objects, but it cannot force member accounts to remain configured with CloudTrail, nor can it stop those accounts from stopping their own trails or deleting trail configurations. Without an organization-wide guardrail, administrators in member accounts can disable or alter CloudTrail independently, leaving the centralized bucket policy useless as a preventive control.

Use an IAM policy in each account to prevent trail modifications.

Why it fails: IAM policies are scoped to individual accounts and principals, and any user with IAM administrative permissions could modify or remove the policy, or bypass it by using the root user, which is not restricted by IAM policies. With hundreds of accounts, creating and maintaining separate IAM policies in every account is operationally inconsistent and does not ensure organization-wide enforcement. Only an SCP at the AWS Organizations level can provide a single, unmodifiable-by-member-admins control that prevents disabling CloudTrail across the entire enterprise.

Use AWS Config rules to detect and alert on disabled trails.

Why it fails: AWS Config rules are detective, not preventive—they can evaluate whether CloudTrail trails are configured or enabled and trigger alerts, but they cannot stop a trail from being disabled or a log bucket from being deleted. By the time Config delivers a compliance notification, the trail may already be disabled, and log delivery may have stopped, leaving a gap in immutable audit evidence. To satisfy the requirement of preventing disabled trails, a preventive SCP deny is required rather than a reactive Config rule.

Use Amazon Macie to discover public buckets and alert the security team.

Why it fails: Macie is for sensitive data discovery, not preventive control.

Create an SCP that denies s3:PutBucketPolicy only for policies that specify 'Principal': '*' or 'Principal': {'AWS': '*'}

Why it fails: This does not cover ACL-based public access.

Deploy an AWS Config rule in each account that triggers a Lambda function to make non-compliant buckets private.

Why it fails: This is reactive, not preventive, and requires per-account setup.

Create a bucket policy that denies s3:DeleteObject and s3:PutObject to all principals.

Why it fails: A bucket policy that denies s3:DeleteObject and s3:PutObject to all principals is ineffective against the account root user. The root user bypasses IAM policy evaluation for resource-based policies and can edit or delete the bucket policy itself before touching any objects. Once the policy is removed or changed, the root user can freely delete or overwrite all objects, so this approach fails to provide immutable log protection.

Enable MFA Delete on the S3 bucket and configure CloudTrail to log to that bucket.

Why it fails: Enabling MFA Delete on the bucket adds a second factor for critical operations like deleting object versions, but the root user possesses — or can recover — the MFA device and can disable MFA Delete. Configuring CloudTrail to log to this bucket only generates an audit trail; it does not prevent deletion or modification of the logs. A compromised root user can turn off MFA Delete, delete the log objects, and then erase the CloudTrail trail evidence, leaving no reliable forensic record.

Enable CloudTrail log file validation and store logs in a separate account.

Why it fails: CloudTrail log file validation uses hash chaining to detect tampering or deletion after the fact, and storing logs in a separate account limits exposure to the original account's users. However, neither measure stops an attacker who compromises the separate account, especially its root user, from modifying or deleting log files before validation can occur. The separate account also does not enforce write-once-read-many (WORM) behavior, so the logs remain mutable and can be altered without detection at the moment of change.

Create a new security group that allows inbound traffic from the web-sg security group on port 3306, then attach the new security group to the database instance.

Why it fails: Creating a new security group and attaching it to the RDS instance does not remove the existing permissive rule on db-sg, because security group rules are additive and the instance will still inherit the 0.0.0.0/0 inbound rule from its current association. Additionally, modifying the association of a database instance with a new security group requires an API call that can cause a brief connection disruption, and the legacy rule remains active unless the old SG is explicitly detached. The correct approach is to edit the current db-sg rule to reference web-sg and delete the open source rule without changing the instance's network attachment.

Update the network ACL for the database subnet to deny inbound traffic from 0.0.0.0/0 on port 3306.

Why it fails: Network ACLs operate at the subnet level and lack the ability to reference security group IDs, meaning they cannot distinguish between legitimate web server traffic and malicious internet traffic. Implementing this rule would block all incoming connections to the database, causing the application downtime the team must avoid. This approach is appropriate when implementing a coarse-grained perimeter defence for an entire subnet rather than performing granular, identity-based access control for specific resource instances.

Move the RDS instance to a private subnet and update the application's database endpoint to use the new private IP address.

Why it fails: Moving the RDS instance to a private subnet is not an in-place operation; RDS does not support changing the subnet of an existing DB instance, so you would have to create a snapshot and restore it into a new private subnet, then update the application's database endpoint—a process that incurs downtime and potential data loss. Even after moving to a private subnet, the instance's security group rules still apply, so unless the db-sg inbound rule referencing 0.0.0.0/0 is also revised, the database would remain reachable from any IP that can route to it (e.g., through a NAT or peered VPC). This approach is far more complex and risky than editing the existing security group, and it does not address the root cause: the over-permissive security group rule.

1. Invite member accounts. 2. Enable GuardDuty in the master account. 3. Accept invitations from member accounts. 4. Configure findings export. 5. Delegate administration.

Why it fails: Inviting member accounts before enabling GuardDuty in the master account is invalid because GuardDuty must be active in the master account first to generate invitation tokens and establish the administrative relationship. Without a GuardDuty-enabled master, the 'Invite members' action is unavailable, so member accounts cannot be onboarded or accept any invitation. This ordering breaks the prerequisite that the master account must already exist and be running GuardDuty before any multi-account management can occur.

1. Enable GuardDuty in the master account. 2. Invite member accounts. 3. Configure findings export. 4. Accept invitations from member accounts. 5. Delegate administration.

Why it fails: Configuring the findings export immediately after inviting members but before they accept their invitations is incorrect because the export destination, typically an S3 bucket encrypted with a KMS key, is defined at the GuardDuty account level and initially contains only findings from the master account. Once member accounts accept and begin streaming findings, the export configuration would need to be revisited to include their accounts and adjust the bucket policy or KMS key permissions, otherwise member findings may be omitted or fail to write. Therefore, export configuration should wait until all member relationships are fully established.

1. Enable GuardDuty in the master account. 2. Configure findings export. 3. Invite member accounts. 4. Accept invitations from member accounts. 5. Delegate administration.

Why it fails: Moving findings export ahead of member invitations is premature because at that point GuardDuty consists of a single account, so the export setup would be tailored solely to the master account's own findings and would lack the cross-account permissions needed for future members. If you create the S3 bucket policy or KMS key grant before knowing which member account IDs will participate, you will later have to modify those resources to add the member principals, creating extra churn and potential misconfiguration. The correct sequence establishes members first, then configures export to include all accounts.

VPC flow logs: Captures network traffic for a specific subnet only

Why it fails: Incorrect — VPC flow logs cover all subnets in the VPC, not a single subnet.

Subnet flow logs: Captures network traffic for a specific ENI only

Why it fails: Incorrect — subnet flow logs include all ENIs in the subnet, not just one.

Configure a bucket policy on each S3 bucket to deny public access.

Why it fails: Applying a bucket policy to deny public access is a resource-level control that must be configured individually for every existing S3 bucket in each account. It does not prevent future buckets from being created without such a policy, nor does it stop users from later removing the policy or modifying the bucket policy to allow public access. Additionally, bucket policies do not block the s3:PutBucketPublicAccessBlock API call, which is the action that toggles the account or bucket-level public access block settings, so this approach is an incomplete and non-scalable manual effort.

Apply an IAM policy to the root user of each account.

Why it fails: Applying an IAM policy to the root user of each account is ineffective because the root user policy only restricts the root user's own permissions; it does not restrict any other IAM users, roles, or the STS-assumed sessions that other principals use. It also does not prevent an IAM identity with sufficient permissions from calling s3:PutBucketPublicAccessBlock or creating a bucket with public access. Furthermore, managing individual root user policies across multiple accounts is operationally complex and fails to provide a centralized, enforceable guardrail across the entire AWS organization.

Use AWS CloudFormation StackSets to deploy a bucket with public access blocked.

Why it fails: AWS CloudFormation StackSets can deploy a template that creates S3 buckets with the PublicAccessBlockConfiguration property, but this approach only governs the specific buckets that are managed by those CloudFormation stacks. It has no effect on pre-existing buckets, buckets created outside of CloudFormation, or any bucket whose public access block is later modified by a user. The StackSets deployment does not enforce a persistent policy; it only ensures the resource configuration at the time of deployment, so it cannot prevent future non-compliant changes to any bucket, including those it created.

Apply an SCP to deny s3:GetObject for any principal outside the organization.

Why it fails: SCPs apply to principals within the organization, not to external principals.

Remove the bucket policy and add an IAM policy to the company's users.

Why it fails: Does not restrict access to existing objects that are already shared.

Modify the condition to use 'aws:SourceArn' with an ARN from the company's account.

Why it fails: Does not prevent other accounts from using a different source ARN.

s3:x-amz-tagging-directive

Why it fails: The s3:x-amz-tagging-directive condition key is evaluated only for copy operations (CopyObject, UploadPartCopy) where it checks the value of the x-amz-tagging-directive header to decide whether to copy or replace tags. It does not inspect the tags themselves, nor does it apply to PutObject requests that create new objects. Consequently, it cannot be used in a Deny statement to block an untagged upload because it never evaluates whether a classification tag is present in the request.

s3:ExistingObjectTag

Why it fails: s3:ExistingObjectTag is evaluated against tags that are already stored on an existing S3 object. At the moment of an upload (PutObject), the object does not yet exist, so there are no existing tags to compare against; the condition would either not match or fail to be evaluated. This key is designed for operations like GetObject, DeleteObject, or bucket-level actions where the target object's current tags matter, and thus it cannot enforce a required tag on a newly created object.

s3:object-lock-mode

Why it fails: s3:object-lock-mode is a condition key that checks the Object Lock retention mode (GOVERNANCE or COMPLIANCE) specified in an S3 API request, which is part of the Object Lock WORM feature. It is completely unrelated to S3 object tags and cannot be used to validate or require a classification tag on uploads. Using it would neither deny untagged uploads nor provide any control over tagging, as its only purpose is to restrict which retention modes can be applied to objects.

Enable CloudTrail to log key deletion events.

Why it fails: CloudTrail is a detective control: it records API activity such as kms:ScheduleKeyDeletion after the fact, providing an audit log of who deleted or scheduled deletion of a key. It does not stop the deletion from being scheduled in the first place, so relying on logging alone fails to protect the key from being deleted. While useful for post-incident analysis, it does not satisfy the requirement for a preventive measure.

Enable automatic key rotation.

Why it fails: Automatic key rotation creates new cryptographic material for an existing KMS key (replacing the backing key) while preserving the key's ARN, alias, and policy. Rotation does not alter any permissions and has no bearing on whether the key can be scheduled for deletion; a key scheduled for deletion is excluded from rotation. Therefore, enabling rotation does nothing to prevent unauthorized deletion.

Disable the key to prevent usage.

Why it fails: Disabling a KMS key places it in a 'Disabled' state, which makes its cryptographic operations fail, but the key policy and IAM permissions are unchanged. A disabled key can still be scheduled for deletion via kms:ScheduleKeyDeletion, and disabling it may even allow an administrator to proceed with deletion since some organizations treat disabled keys as candidates for cleanup. Thus, disabling the key only prevents usage, not deletion.

The resource ARN should include the bucket name without the '/*' suffix.

Why it fails: The resource ARN `arn:aws:s3:::bucket/*` is correctly formatted for object-level actions like `s3:GetObject` and `s3:PutObject`, which are the operations affected by encryption conditions. Using only the bucket-level ARN without the `/*` suffix would restrict the statement to bucket-level actions such as `s3:ListBucket` or `s3:GetBucketLocation`, none of which involve per-object encryption headers. Thus the suffix is intentional and not an error; it grants access to all objects within the named bucket.

The condition should use 'Null' instead of 'StringEquals'.

Why it fails: The `Null` condition operator checks whether the condition key is absent or has a null value, so it would actually allow requests that omit the `x-amz-server-side-encryption` header entirely. This would defeat the purpose of enforcing server-side encryption, as a client could upload an object without any encryption header and still be granted access. Using `StringEquals`—as the original policy does—requires the header to be present and to match the specified encryption value, which is the correct way to mandate encryption on writes.

The condition should use 'aws:SecureTransport' instead.

Why it fails: `aws:SecureTransport` is a condition key that only verifies the request was made over HTTPS/TLS, protecting data in transit, not data at rest. Server-side encryption governs how S3 encrypts the object after it is stored, and a request submitted over HTTP could still include the encryption header or result in an encrypted object if bucket default encryption is enabled. Replacing the server-side encryption condition with `aws:SecureTransport` would permit unencrypted objects to be placed in the bucket, so it does not address the intended requirement.

The ReadWriteType is set to 'All', which does not include write events.

Why it fails: The ReadWriteType field in a CloudTrail advanced event selector controls whether read events, write events, or both are logged. Valid values are Read, Write, and All, and setting it to All actually means both read and write data events are captured, not just read events. Therefore, this cannot be the reason write events are missing; the configuration already logs the event types in question.

The IncludeManagementEvents should be set to false to focus on data events.

Why it fails: IncludeManagementEvents is a separate Boolean setting that controls whether the trail captures management events like CreateBucket or PutBucketPolicy. Data events are configured independently through event selectors, so toggling this flag to false would disable management events but would have absolutely no effect on the data event filter that is already missing the proper '/*' prefix. The issue lies in the data event selector's Values field, not in the management event setting.

The trail should be configured as a multi-region trail to capture all regions.

Why it fails: A multi-region trail delivers CloudTrail events from all AWS regions, but the provided output excerpt does not show the IsMultiRegionTrail field, so we cannot determine if this trail is already multi-region. More importantly, converting a trail to multi-region does not alter the S3 data event selector's filter prefix; even if the trail captures events across regions, the bucket object events still fail to match because the Values entry lacks the '/*' wildcard. This proposed change is thus neither supported by the evidence nor a valid fix.

It blocks all access to the bucket.

Why it fails: This policy contains a single statement that Denies requests when the `aws:SecureTransport` condition key is `false` (i.e., HTTP). It has no statement that blocks HTTPS traffic, so HTTPS requests to the bucket remain subject to normal IAM evaluation. A Deny for HTTP only narrows the set of blocked requests; it does not deny all possible access, and it does not revoke access for authenticated or public HTTPS callers.

It allows anonymous access to the bucket over HTTPS.

Why it fails: There is no `Allow` statement in the bucket policy, and a Deny statement never grants permissions. Anonymous access over HTTPS would require an explicit Allow that grants actions to the unauthenticated principal (`*` without authentication) or a public ACL, neither of which is present here. The only effective outcome of this policy is to reject non-TLS traffic; it cannot enable any access, so it is incorrect to say it allows anonymous HTTPS requests.

It requires server-side encryption for all objects.

Why it fails: To enforce server-side encryption, a bucket policy must use a condition key such as `s3:x-amz-server-side-encryption` (or `aws:SecureTransport` is not an encryption condition). The policy shown only checks `aws:SecureTransport`, which determines whether the request arrived over TLS, and does not inspect encryption headers or the `x-amz-server-side-encryption` parameter. Therefore it neither requires nor validates encryption at rest; it only enforces that data is encrypted in transit over HTTPS.

Add the user to an IAM group with restricted permissions

Why it fails: Adding the user to an IAM group with restricted policies can help, but it does not enforce a hard limit because the user might still have other attached policies that grant permissions beyond the group's policies.

Use a resource-based policy on the user

Why it fails: Resource-based policies are JSON documents attached to AWS resources (such as S3 buckets, SQS queues, or KMS keys) that specify which principals can take actions on that resource. An IAM user is a principal, not a resource, so there is no way to attach a resource-based policy to the user itself to define a permissions cap. While you can place the user as a principal in a resource-based policy for a different resource, that grants access to a specific resource rather than constraining the user's overall permissions. Therefore, this approach cannot enforce the least-privilege limiting needed here.

Attach a service control policy (SCP) to the user's account

Why it fails: Service control policies (SCPs) are applied at the AWS Organizations level to the entire root, an OU, or an individual AWS account, and they apply uniformly to every IAM principal operating in that account. Attaching an SCP to the user's account would restrict all users, roles, and service-linked roles in that account, not just the one IAM user in question. Additionally, SCPs only work for accounts that are managed by AWS Organizations, and an SCP cannot be targeted at a single IAM user's identity. As a result, it is an ineffective and overly broad tool for enforcing least privilege on a specific user.

AWS CloudTrail with a metric filter

Why it fails: CloudTrail only logs, does not prevent.

S3 Block Public Access settings on each account

Why it fails: Block Public Access can be changed by account administrators.

IAM permissions boundary

Why it fails: Permissions boundaries are per-entity, not per-account.

Use IAM policies to restrict ec2:RunInstances to only approved AMIs

Why it fails: IAM policies can constrain ec2:RunInstances using condition keys such as ec2:Owner, ec2:ImageId, or ec2:RootDeviceType, but they cannot reference an AMI's underlying properties like operating system or compliance tags. The ec2:ImageId condition key matches a specific AMI ID, yet enforcing a dynamic 'approved AMI list' requires maintaining an allowlist that attackers can circumvent by launching with a different unapproved ID. Crucially, IAM operates in the request context, so it cannot evaluate the AMI's compliance state (e.g., whether the AMI has been deprecated or contains a known vulnerable configuration). Thus, IAM alone is an incomplete control for enforcing 'all EC2 instances launch from approved AMIs' because it lacks awareness of the AMI's actual compliance status.

Use AWS Service Catalog with a product that launches approved AMIs

Why it fails: AWS Service Catalog lets you create products that launch approved AMIs, and you can constrain IAM principals to launch only via Service Catalog using permission boundaries or scoped IAM policies. However, Service Catalog does not block a user with direct ec2:RunInstances permission from bypassing the catalog entirely—it simply provides a governed launch path, not an enforcement mechanism on all EC2 activity. Since the security team needs to enforce that all EC2 instances launch from approved AMIs, a Service Catalog product only applies to users who choose to use it; it cannot deny raw API calls. Therefore, this option does not meet the 'all instances' requirement unless you also revoke direct EC2 access, which is not stated.

Use AWS CloudTrail to log all EC2 launches and alert on noncompliant AMIs

Why it fails: AWS CloudTrail records every EC2 API call, including RunInstances, and you can set up CloudWatch Events/EventBridge rules to alert on noncompliant AMI launches. However, CloudTrail is a logging service—it captures events after they are executed and has no mechanism to block or deny an API call. At best, you can respond to the alert by terminating the instance or reverting changes, but this is a detective, post-hoc control, not an enforcement mechanism. Since the security team must 'enforce' that all instances launch from approved AMIs, CloudTrail alone cannot prevent the noncompliant launch from occurring; it only records that it happened.

Amazon GuardDuty and Amazon SNS

Why it fails: GuardDuty detects threats but does not log all API calls.

AWS Config and AWS Lambda

Why it fails: Config evaluates resource configurations, not API calls.

Amazon Inspector and Amazon S3

Why it fails: Inspector is for vulnerability assessments, not API monitoring.

Grant full administrative access to all users to simplify management

Why it fails: Full admin violates least privilege.

Use service control policies (SCPs) to restrict user permissions

Why it fails: SCPs restrict accounts, not individual users.

Use the root user for daily administrative tasks

Why it fails: Root user should not be used daily.