Troubleshooting practice questions

A security engineer is troubleshooting an issue where CloudTrail logs are not being delivered to the specified S3 bucket. The bucket policy allows CloudTrail to write objects. What is the MOST likely cause?

Trap 1: The S3 bucket uses server-side encryption with customer-provided…

SSE-C is a per-object encryption mode, not a bucket-level default, and it is not supported by CloudTrail for log delivery. CloudTrail automatically uses SSE-S3 for new buckets and can optionally use SSE-KMS, but it cannot supply the customer-provided key headers required for SSE-C. Even if an encryption mismatch occurred, it would surface as an S3 encryption error rather than an Access Denied caused by a bucket policy deny.

Trap 2: The S3 bucket does not have versioning enabled.

Versioning is an optional bucket property for CloudTrail log storage, not a prerequisite for writing new objects. When versioning is disabled, CloudTrail still successfully delivers log files; the only impact is that overwritten or deleted versions are not retained. Since a delivery failure would appear as an authorization or access error rather than a versioning-related error, the absence of versioning cannot explain the issue.

Trap 3: The S3 bucket is in a different AWS account.

CloudTrail explicitly supports delivering logs to an S3 bucket in a different AWS account, provided the bucket policy includes the appropriate cross-account Allow statements for the CloudTrail service principal and the expected AWSLogs prefix. A remote bucket alone does not prevent delivery; only a missing or misconfigured resource policy would. Therefore, the bucket's account location is not inherently the cause, and the contents of the bucket policy are what should be examined.

A
The S3 bucket uses server-side encryption with customer-provided keys (SSE-C).
Why it fails: SSE-C is a per-object encryption mode, not a bucket-level default, and it is not supported by CloudTrail for log delivery. CloudTrail automatically uses SSE-S3 for new buckets and can optionally use SSE-KMS, but it cannot supply the customer-provided key headers required for SSE-C. Even if an encryption mismatch occurred, it would surface as an S3 encryption error rather than an Access Denied caused by a bucket policy deny.
B
The S3 bucket has a bucket policy that denies access to the CloudTrail service principal.
An explicit Deny statement in the destination bucket policy that references the CloudTrail service principal (cloudtrail.amazonaws.com) will override any Allow that CloudTrail receives through its service role or resource-based policies. In AWS IAM policy evaluation, an explicit deny acts as an absolute veto, so CloudTrail's attempts to perform s3:PutObject and s3:GetBucketAcl fail with Access Denied. Because this would block delivery regardless of encryption, versioning, or account location, it is the likely root cause.
C
The S3 bucket does not have versioning enabled.
Why it fails: Versioning is an optional bucket property for CloudTrail log storage, not a prerequisite for writing new objects. When versioning is disabled, CloudTrail still successfully delivers log files; the only impact is that overwritten or deleted versions are not retained. Since a delivery failure would appear as an authorization or access error rather than a versioning-related error, the absence of versioning cannot explain the issue.
D
The S3 bucket is in a different AWS account.
Why it fails: CloudTrail explicitly supports delivering logs to an S3 bucket in a different AWS account, provided the bucket policy includes the appropriate cross-account Allow statements for the CloudTrail service principal and the expected AWSLogs prefix. A remote bucket alone does not prevent delivery; only a missing or misconfigured resource policy would. Therefore, the bucket's account location is not inherently the cause, and the contents of the bucket policy are what should be examined.

Question 2mediummultiple choice

A security engineer is troubleshooting why CloudTrail is not delivering logs to an S3 bucket. The bucket policy allows CloudTrail to write objects, and the trail is configured with the correct bucket name. However, no log files appear. What is the most likely cause?

Trap 1: The S3 bucket has an S3 Object Lock configuration that prevents…

S3 Object Lock does not block initial PutObject requests; it only restricts deletion or overwriting of existing versions according to a retention mode and period. CloudTrail writes new log objects on a regular basis, and unless the bucket policy denies s3:PutObject, Object Lock will not prevent those deliveries. Even with a default retention policy, writes succeed and the logs are merely locked against modification.

Trap 2: The S3 bucket is in a different AWS Region from the trail.

CloudTrail can deliver log files to an S3 bucket in any AWS Region, not only the bucket's or trail's home region. The trail must have a bucket policy that permits the CloudTrail service principal to write objects, and the bucket may be in a different account or region. A regional mismatch alone is not a cause of delivery failure, so this does not explain the troubleshooting issue.

Trap 3: CloudTrail is not enabled in the AWS Region where the S3 bucket…

CloudTrail is a regional service, but a trail is created in a home region and can record and deliver events for all regions when configured as a multi-region trail. The S3 bucket resides in some region, but CloudTrail does not need to be enabled specifically in the bucket's region to deliver logs to it. What matters is that the trail is active and the bucket policy allows CloudTrail to write; the bucket region is irrelevant.

A
The S3 bucket has an S3 Object Lock configuration that prevents writes.
Why it fails: S3 Object Lock does not block initial PutObject requests; it only restricts deletion or overwriting of existing versions according to a retention mode and period. CloudTrail writes new log objects on a regular basis, and unless the bucket policy denies s3:PutObject, Object Lock will not prevent those deliveries. Even with a default retention policy, writes succeed and the logs are merely locked against modification.
B
The S3 bucket is in a different AWS Region from the trail.
Why it fails: CloudTrail can deliver log files to an S3 bucket in any AWS Region, not only the bucket's or trail's home region. The trail must have a bucket policy that permits the CloudTrail service principal to write objects, and the bucket may be in a different account or region. A regional mismatch alone is not a cause of delivery failure, so this does not explain the troubleshooting issue.
C
CloudTrail is not enabled in the AWS Region where the S3 bucket resides.
Why it fails: CloudTrail is a regional service, but a trail is created in a home region and can record and deliver events for all regions when configured as a multi-region trail. The S3 bucket resides in some region, but CloudTrail does not need to be enabled specifically in the bucket's region to deliver logs to it. What matters is that the trail is active and the bucket policy allows CloudTrail to write; the bucket region is irrelevant.
D
The S3 bucket uses AWS KMS server-side encryption (SSE-KMS) and the KMS key policy does not grant CloudTrail permission to use the key.
When a destination bucket uses SSE-KMS, CloudTrail must have permission to call kms:GenerateDataKey for encrypting each log file and kms:Decrypt for delivering or reading those files. If the KMS key policy does not explicitly grant CloudTrail these actions, PutObject requests to the bucket will fail even if the bucket policy is correct. CloudTrail’s role also needs the appropriate KMS permissions in the trail’s advanced settings, but the key policy is the critical constraint here.

Review the full subnetting walkthrough →

Question 3hardmultiple choice

A security engineer is troubleshooting connectivity issues between an Amazon EC2 instance in a VPC and an on-premises server over a Direct Connect virtual interface. The EC2 instance has a security group that allows outbound traffic to the on-premises CIDR block (10.0.0.0/16). The VPC has a route table entry pointing the on-premises CIDR to the virtual private gateway. The on-premises firewall shows that packets are received from the EC2 instance but responses are not reaching the instance. What is the most likely cause?

Trap 1: The network ACL for the subnet is blocking outbound traffic to the…

If the subnet's network ACL were blocking outbound traffic to the on-premises CIDR, the VPC instances would be unable to send any packets toward Direct Connect, and the on-premises side would receive nothing at all. The scenario demonstrates that outbound traffic is reaching the on-premises network, which proves the NACL is permitting the egress flow. NACLs are stateless and require explicit allow rules for both outbound and inbound traffic, but here only the return path is broken.

Trap 2: The virtual private gateway is not attached to the VPC.

A virtual private gateway that is not attached to the VPC would leave the VPC route table without any viable target for Direct Connect traffic, preventing all outbound packets from ever leaving the VPC. Since the observed symptoms show outbound traffic successfully arriving at on-premises, the gateway must be attached and operational. An unattached gateway would be a total connectivity failure, not a one-way connectivity issue.

Trap 3: The security group does not allow inbound traffic from the…

Security groups are stateful: if the instance's outbound rule permits traffic to the on-premises server, the security group automatically allows the corresponding inbound response traffic, even without an explicit inbound rule. Therefore, a missing inbound rule for the on-premises CIDR cannot cause the return packets to be dropped. The issue lies in an external router lacking a return route, not in the security group configuration.

A
The on-premises router does not have a route pointing the VPC CIDR back to the Direct Connect interface.
The VPC has a route for the on-premises CIDR pointing to the virtual private gateway, so outbound packets traverse the Direct Connect virtual interface. However, for successful two-way communication, the on-premises router must have a route for the VPC CIDR that points back to the same Direct Connect interface. Because this return route is missing, response packets are either sent to a default route or dropped, so hosts in the VPC see no replies. This is a classic asymmetric routing failure.
B
The network ACL for the subnet is blocking outbound traffic to the on-premises CIDR.
Why it fails: If the subnet's network ACL were blocking outbound traffic to the on-premises CIDR, the VPC instances would be unable to send any packets toward Direct Connect, and the on-premises side would receive nothing at all. The scenario demonstrates that outbound traffic is reaching the on-premises network, which proves the NACL is permitting the egress flow. NACLs are stateless and require explicit allow rules for both outbound and inbound traffic, but here only the return path is broken.
C
The virtual private gateway is not attached to the VPC.
Why it fails: A virtual private gateway that is not attached to the VPC would leave the VPC route table without any viable target for Direct Connect traffic, preventing all outbound packets from ever leaving the VPC. Since the observed symptoms show outbound traffic successfully arriving at on-premises, the gateway must be attached and operational. An unattached gateway would be a total connectivity failure, not a one-way connectivity issue.
D
The security group does not allow inbound traffic from the on-premises server.
Why it fails: Security groups are stateful: if the instance's outbound rule permits traffic to the on-premises server, the security group automatically allows the corresponding inbound response traffic, even without an explicit inbound rule. Therefore, a missing inbound rule for the on-premises CIDR cannot cause the return packets to be dropped. The issue lies in an external router lacking a return route, not in the security group configuration.

Question 4hardmultiple choice

A Security Engineer is troubleshooting why AWS CloudTrail is not delivering logs to an S3 bucket. The bucket policy allows CloudTrail access. What is a likely cause of the issue?

Trap 1: The S3 bucket has a lifecycle policy that deletes objects too…

A lifecycle policy that transitions or expires objects operates asynchronously after objects are written; it does not block CloudTrail from delivering log files in real time. Even an aggressive expiration rule would only remove objects minutes or days later, after the delivery attempt has already succeeded. Therefore, lifecycle configuration cannot prevent CloudTrail from writing the initial log files.

Trap 2: CloudTrail is not enabled in the region

CloudTrail trails are regional resources; if CloudTrail is not enabled in the region where the trail is configured, no trail would exist to deliver logs. Because the CloudTrail console and APIs only show trails that were successfully created in a region, a missing trail indicates a creation failure or no configuration, not a delivery failure of an existing trail. This option cannot explain why an already created trail stops delivering logs.

Trap 3: The S3 bucket is in a different region than the trail

CloudTrail explicitly supports delivering logs to an S3 bucket in a different region than the trail, as long as the bucket policy allows cross-account or cross-region writes. When you create a trail, CloudTrail adds the necessary bucket policy statements to deliver to any valid S3 bucket regardless of region. Therefore, the bucket being in a different region does not inherently prevent log delivery and is not a valid cause of the issue.

A
The S3 bucket uses SSE-KMS and the key policy does not grant CloudTrail permission
CloudTrail requires explicit kms:GenerateDataKey and kms:Decrypt permissions on the customer managed KMS key used for SSE-KMS encryption of the S3 bucket. If the key policy grants these actions only to the bucket owner or other principals, CloudTrail's delivery role is denied and PutObject calls fail with an access denied error. This is a common cause of CloudTrail logs not appearing while the trail itself remains active.
B
The S3 bucket has a lifecycle policy that deletes objects too quickly
Why it fails: A lifecycle policy that transitions or expires objects operates asynchronously after objects are written; it does not block CloudTrail from delivering log files in real time. Even an aggressive expiration rule would only remove objects minutes or days later, after the delivery attempt has already succeeded. Therefore, lifecycle configuration cannot prevent CloudTrail from writing the initial log files.
C
CloudTrail is not enabled in the region
Why it fails: CloudTrail trails are regional resources; if CloudTrail is not enabled in the region where the trail is configured, no trail would exist to deliver logs. Because the CloudTrail console and APIs only show trails that were successfully created in a region, a missing trail indicates a creation failure or no configuration, not a delivery failure of an existing trail. This option cannot explain why an already created trail stops delivering logs.
D
The S3 bucket is in a different region than the trail
Why it fails: CloudTrail explicitly supports delivering logs to an S3 bucket in a different region than the trail, as long as the bucket policy allows cross-account or cross-region writes. When you create a trail, CloudTrail adds the necessary bucket policy statements to deliver to any valid S3 bucket regardless of region. Therefore, the bucket being in a different region does not inherently prevent log delivery and is not a valid cause of the issue.

Question 5mediummultiple choice

A security engineer is troubleshooting an issue where an Amazon RDS for MySQL DB instance encrypted at rest with AWS KMS is failing to launch. The error message indicates a KMS access issue. Which IAM role or policy is most likely missing?

Trap 1: The RDS subnet group is in a private subnet without a NAT gateway

The location of the RDS subnet group in a private subnet without a NAT gateway would only affect outbound internet connectivity to the public KMS endpoint. That type of network failure typically causes timeouts or connection errors, not an authorization or access-denied response. In practice, RDS can reach KMS via a VPC endpoint or the AWS managed network, so the subnet and NAT configuration alone cannot produce a KMS permission error. The underlying problem here is a missing IAM service-linked role, not the network path.

Trap 2: The DB instance's security group does not allow outbound traffic to…

Security groups are stateful and, by default, allow all outbound traffic; moreover, the DB instance's security group controls traffic to the database itself, not the RDS management plane's API calls to KMS. Even when a VPC endpoint is used for KMS, the relevant network policy is on the VPC endpoint's security group, not on the DB instance's group. KMS requests are authenticated via IAM and the service-linked role, not through security group rules, so an outbound security group rule would have no bearing on this failure.

Trap 3: The KMS key policy does not grant access to the root account

The root account inherently has full permissions over KMS keys it owns, unless the key policy explicitly contains a deny statement, so a lack of root access is not a plausible explanation. For RDS to use a KMS key for encryption, the key policy must grant permission to the RDS service-linked role or the rds.amazonaws.com service principal, not to the root account. If the service-linked role is missing, there is no RDS-specific principal to authorize, making this option incorrect even though a key policy issue could exist.

A
The RDS subnet group is in a private subnet without a NAT gateway
Why it fails: The location of the RDS subnet group in a private subnet without a NAT gateway would only affect outbound internet connectivity to the public KMS endpoint. That type of network failure typically causes timeouts or connection errors, not an authorization or access-denied response. In practice, RDS can reach KMS via a VPC endpoint or the AWS managed network, so the subnet and NAT configuration alone cannot produce a KMS permission error. The underlying problem here is a missing IAM service-linked role, not the network path.
B
The DB instance's security group does not allow outbound traffic to KMS
Why it fails: Security groups are stateful and, by default, allow all outbound traffic; moreover, the DB instance's security group controls traffic to the database itself, not the RDS management plane's API calls to KMS. Even when a VPC endpoint is used for KMS, the relevant network policy is on the VPC endpoint's security group, not on the DB instance's group. KMS requests are authenticated via IAM and the service-linked role, not through security group rules, so an outbound security group rule would have no bearing on this failure.
C
The KMS key policy does not grant access to the root account
Why it fails: The root account inherently has full permissions over KMS keys it owns, unless the key policy explicitly contains a deny statement, so a lack of root access is not a plausible explanation. For RDS to use a KMS key for encryption, the key policy must grant permission to the RDS service-linked role or the rds.amazonaws.com service principal, not to the root account. If the service-linked role is missing, there is no RDS-specific principal to authorize, making this option incorrect even though a key policy issue could exist.
D
The AWSServiceRoleForRDS service-linked role is missing
The AWSServiceRoleForRDS service-linked role is a predefined IAM role that gives RDS the ability to call AWS services, including KMS, on your behalf for tasks such as encrypting and decrypting database storage. When this role is missing, RDS cannot assume it to perform kms:Encrypt, kms:Decrypt, or kms:GenerateDataKey operations, causing failures when you create, modify, or start an encrypted instance. This is the root cause in this scenario; you can verify or create the role with the AWS CLI command aws iam create-service-linked-role --aws-service-name rds.amazonaws.com.

Question 6mediummulti select

A security engineer is troubleshooting an issue where CloudTrail is not delivering logs to an S3 bucket. The bucket policy appears correct. Which TWO additional steps should the engineer take to diagnose the issue? (Choose TWO.)

Trap 1: Check CloudWatch Logs for CloudTrail errors.

CloudTrail can be configured to stream events to an Amazon CloudWatch Logs log group for metric filters and alarm-based monitoring, but S3 delivery errors are not written to that log stream. The console Trail Details pane and CloudWatch metrics for CloudTrail delivery are the authoritative sources for S3 delivery failures. Examining CloudWatch Logs for 'CloudTrail errors' would not reveal whether the bucket is missing or misregioned, so this diagnostic step is not applicable.

Trap 2: Create an IAM role for CloudTrail with S3 write permissions.

CloudTrail does not need an IAM role to write logs to an S3 bucket; it authenticates as the cloudtrail.amazonaws.com service principal, and the bucket must grant write permission through a resource-based bucket policy. An IAM role is required only when CloudTrail delivers events to CloudWatch Logs and must assume that role to create log groups and log streams. Creating an IAM role with S3 write permissions would neither fix a nonexistent bucket nor grant the bucket policy permissions CloudTrail actually uses.

Trap 3: Enable S3 server access logging on the bucket.

S3 server access logging records detailed request-level information about every API call made to the destination bucket, which is useful for post-hoc compliance and audit analysis once logs are arriving. It does not, however, trigger, enable, or repair CloudTrail delivery, and it cannot fix a bucket that is missing or in the wrong Region. Enabling it would only add another place to look after CloudTrail delivery is already working, not diagnose why it is failing.

A
Verify that the S3 bucket exists and is in the correct region.
CloudTrail can only write log files to an S3 bucket that already exists and is located in the same AWS Region as the trail. If the bucket was accidentally deleted, renamed, or created in another Region, every delivery attempt fails, and the trail's status shows a delivery error. Confirming this prerequisite is therefore the correct first troubleshooting step, because no policy or role change can compensate for a missing or misregioned destination.
B
Check CloudWatch Logs for CloudTrail errors.
Why it fails: CloudTrail can be configured to stream events to an Amazon CloudWatch Logs log group for metric filters and alarm-based monitoring, but S3 delivery errors are not written to that log stream. The console Trail Details pane and CloudWatch metrics for CloudTrail delivery are the authoritative sources for S3 delivery failures. Examining CloudWatch Logs for 'CloudTrail errors' would not reveal whether the bucket is missing or misregioned, so this diagnostic step is not applicable.
C
Create an IAM role for CloudTrail with S3 write permissions.
Why it fails: CloudTrail does not need an IAM role to write logs to an S3 bucket; it authenticates as the cloudtrail.amazonaws.com service principal, and the bucket must grant write permission through a resource-based bucket policy. An IAM role is required only when CloudTrail delivers events to CloudWatch Logs and must assume that role to create log groups and log streams. Creating an IAM role with S3 write permissions would neither fix a nonexistent bucket nor grant the bucket policy permissions CloudTrail actually uses.
D
Enable S3 server access logging on the bucket.
Why it fails: S3 server access logging records detailed request-level information about every API call made to the destination bucket, which is useful for post-hoc compliance and audit analysis once logs are arriving. It does not, however, trigger, enable, or repair CloudTrail delivery, and it cannot fix a bucket that is missing or in the wrong Region. Enabling it would only add another place to look after CloudTrail delivery is already working, not diagnose why it is failing.
E
Review the CloudTrail configuration in the AWS Management Console for error messages.
The CloudTrail console is a legitimate place to start because the Trails page shows the current delivery status and any associated error messages, such as 'S3 bucket does not exist'. If an error is displayed, it usually points directly to the underlying requirement, namely an existing, correctly Regioned destination bucket. Reviewing these console errors can quickly confirm or exclude the bucket configuration issue, making this a valid diagnostic step for this failure.