Refer to the Exhibit Practice Questions

Access is allowed because the policy grants s3:GetObject permissions to the bucket.

Why it fails: While the policy does grant s3:GetObject permissions, the condition block must also be satisfied for the permission to take effect. Since the user's IP address (198.51.100.5) is not within the specified 203.0.113.0/24 range, the Allow statement is not applicable to this specific request.

Access is allowed because there is no explicit Deny statement in the policy.

Why it fails: AWS IAM uses an implicit deny by default, meaning that if no policy explicitly allows an action, the action is denied. Although there is no explicit Deny statement, the Allow statement only functions when the condition is met. Since the condition is failed, the request is not authorized.

Access is denied because the policy does not include permissions for the s3:ListBucket action.

Why it fails: The s3:ListBucket permission is required to see the contents of a bucket, but s3:GetObject is the specific permission needed to download or read an individual object. The lack of ListBucket does not inherently prevent GetObject if the full path to the object is already known by the user.

The S3 bucket is in a different region than the EC2 instances.

Why it fails: While cross-region S3 access can increase latency and costs, it would not result in a 403 Forbidden error due to this specific policy unless the VPC Endpoint itself is region-specific. The primary issue here is the logical denial based on the source VPC endpoint ID.

The IAM role assigned to the EC2 instances lacks S3:GetObject permissions.

Why it fails: The prompt states that users have the 'correct IAM permissions.' Even if IAM permissions were granted, the explicit Deny in the bucket policy for non-matching VPC endpoints would take precedence, making the IAM permissions irrelevant until the networking path is corrected to use the endpoint.

The S3 bucket has Object Lock enabled, preventing data retrieval.

Why it fails: S3 Object Lock is used to prevent objects from being deleted or overwritten for a fixed amount of time. It does not prevent users from downloading or reading objects (GetObject). Therefore, Object Lock would not cause a 403 Forbidden error for standard read operations.

Increase the RDS instance size to handle more connections.

Why it fails: Increasing the instance size does not resolve connection exhaustion if the application code is not managing connections properly. The bottleneck is the connection pool management, not the CPU or memory resources. RDS Proxy is the purpose-built solution to handle database connection pooling and multiplexing effectively.

Enable Multi-AZ failover to distribute the load.

Why it fails: Multi-AZ is for high availability and failover, not for load balancing connections. Enabling it will not fix connection pool exhaustion. The database still has a limit on the number of concurrent connections it can support, and Multi-AZ does not provide additional read/write endpoints for connection pooling.

Add more read replicas to the RDS cluster.

Why it fails: Read replicas are used to scale read traffic, not to manage application connection pools. Each replica has its own connection limits, and adding them won't solve the issue of connection exhaustion on the primary instance. RDS Proxy is required to handle the underlying connection pool architecture properly.

The Launch Template version is hardcoded to version 1 instead of using $Latest or $Default.

Why it fails: A hardcoded launch template version still deploys instances across the group's subnets, so it does not by itself cause partial downtime during an AZ outage. The failure stems from the group spanning too few Availability Zones or an unbalanced subnet distribution. Pinning a version matters only when a newer template must be rolled out.

The MinSize and DesiredCapacity are set too low to handle sudden spikes in traffic during an outage.

Why it fails: While a minimum size of two instances provides basic high availability, the primary cause of downtime during an AZ outage is the inability to provision replacement instances outside the hardcoded zone list, not just the initial capacity.

The Auto Scaling group is missing a health check type configuration set to ELB instead of EC2.

Why it fails: While setting the health check type to ELB improves application-level health monitoring, it is not the primary root cause preventing the Auto Scaling group from surviving an entire Availability Zone outage in this template configuration.

The user does not have an IAM role attached.

Why it fails: IAM users do not need an IAM role attached to perform actions; their permissions are derived directly from the policies attached to their identity. The issue here is a lack of specific permissions within the existing policy, not the absence of a role. This is a fundamental misunderstanding of IAM.

The bucket policy is explicitly denying access.

Why it fails: While a bucket policy could override an IAM policy, the prompt focuses on the provided IAM policy. Without seeing an explicit Deny, the most likely cause is the missing permission in the IAM policy. There is no evidence in the prompt to suggest an explicit Deny is present in the bucket.

The S3 bucket is encrypted with a KMS key.

Why it fails: While KMS encryption requires additional permissions (kms:Decrypt), the 'Access Denied' error specifically during a list operation is almost always caused by missing ListBucket permissions. If KMS were the issue, the error would likely occur when attempting to access the content of the files, not during the listing of bucket objects.

It enables S3 Transfer Acceleration for faster global uploads.

Why it fails: S3 Transfer Acceleration uses Amazon CloudFront's edge locations to speed up long-distance data transfers over the public internet. The policy in the exhibit, however, restricts access to a specific VPC endpoint, which keeps traffic entirely within the AWS private network. These are two different performance optimization strategies that serve different geographic use cases.

It provides cross-region replication for high availability of data.

Why it fails: Cross-region replication is a feature used to automatically copy objects across different AWS Regions for disaster recovery or latency reduction for global users. The exhibited policy is a resource-based access control policy and does not configure or enable replication features. It focuses strictly on controlling the network path used to access the bucket.

It allows public access to the bucket for faster content delivery.

Why it fails: The policy actually restricts access rather than allowing general public access, as it requires the request to originate from a specific VPC endpoint. While the Principal is a wildcard, the Condition block effectively limits access to authorized internal network paths. This improves security and performance for internal applications but does not facilitate public delivery.

Intelligent-Tiering is only supported for objects larger than 128 KB.

Why it fails: Intelligent-Tiering does not have a hard requirement for object size, though very small objects may not benefit from storage class transitions as much as larger ones. The primary issue here is the cost structure of the monitoring fees when applied to a very high volume of individual objects.

The lifecycle rule should use S3 Glacier Deep Archive instead of Intelligent-Tiering.

Why it fails: While Deep Archive is cheaper for storage, it is intended for long-term archival with retrieval times of hours. If the logs need to be accessed occasionally for troubleshooting, Deep Archive would be too slow. The issue in the exhibit is the monitoring fee for millions of files in Intelligent-Tiering.

The prefix filter is too broad and will include active logs.

Why it fails: The prefix 'logs/' is a standard practice for grouping objects. Assuming the application writes logs to this path, the lifecycle rule correctly targets them. The prefix itself does not cause cost inefficiencies; the cost issue stems from the choice of storage class and the volume of small objects.

It allows all users to retrieve objects from the bucket if they are using any IP address.

Why it fails: The inclusion of the 'IpAddress' condition explicitly limits the scope of the permission. If a user tries to access the bucket from an IP address outside the defined range, the request will be denied. This policy is restrictive rather than permissive for all global traffic.

It denies access to anyone from the 192.0.2.0/24 range and allows everyone else.

Why it fails: The policy uses an 'Allow' effect with a condition that must be met. Therefore, it permits access only for the specified IP range. It does not deny the specified range nor does it grant broad access to the rest of the internet; it effectively creates an IP-based allowlist.

It grants full administrative access to the bucket for the 192.0.2.0/24 IP range.

Why it fails: The policy only grants the 's3:GetObject' action. It does not grant administrative actions like 's3:DeleteBucket', 's3:PutObject', or 's3:PutBucketPolicy'. Administrative access requires a wider set of permissions than what is defined in the action list, so this is not a full administrative policy.

Apply a Bucket Policy to deny s3:PutObject for all users.

Why it fails: Applying a permanent Deny on PutObject would prevent the application from ever updating the backups. While this prevents unauthorized modifications, it also breaks the functionality of the backup process itself. Object Lock is a more granular and effective control that allows writes but prevents deletions and overwrites.

Create a read-only IAM user for the EC2 instance.

Why it fails: The EC2 instance already has read access. Adding an IAM user does not solve the underlying risk of the source bucket being compromised. The problem is about protecting the bucket's content, not limiting the permissions of the client that is consuming the backups for recovery.

Enable S3 Server-Side Encryption (SSE-S3).

Why it fails: Encryption protects data at rest from being read by unauthorized parties. It does not prevent a malicious actor with write permissions from deleting or overwriting the objects. Resilience against data compromise requires features that prevent deletion and modification, such as Object Lock, not just encryption of the data.

Enable S3 Cross-Region Replication for all objects.

Why it fails: Cross-Region Replication provides disaster recovery across regions but does not inherently protect against accidental deletions within the source bucket. If an object is deleted in the source, the delete marker is replicated to the destination. Versioning is required to truly protect against accidental deletions in S3.

Modify the IAM policy to include s3:DeleteObject in the Deny statement.

Why it fails: Applying a broad Deny on delete operations makes it impossible to manage data lifecycles or clean up temporary files. This is not a scalable way to protect against accidental deletions. Robust protection should rely on S3 bucket features like Versioning and MFA Delete rather than restrictive IAM policies alone.

Use S3 Intelligent-Tiering for all objects to reduce storage costs.

Why it fails: S3 Intelligent-Tiering is a cost-optimization feature that moves objects between access tiers based on usage patterns. While it reduces costs, it does not provide protection against accidental deletion. Resilience and data protection must be addressed through features like Versioning, independent of the storage tiering strategy implemented for cost.

The request will be allowed because the IP address is within the allowed range.

Why it fails: Access is not granted solely based on the IP address. The policy contains two conditions that must both be satisfied for the 'Allow' statement to apply. Since the MFA condition is not met, the policy does not grant the necessary permission to the user for this request.

The request will be allowed because the 'Bool' condition is only evaluated if MFA is configured.

Why it fails: The 'aws:MultiFactorAuthPresent' key checks whether MFA was used during the authentication process. If the session does not include MFA, the key evaluates to false. It is not dependent on whether the user has MFA configured on their account, but rather if it was used.

The request will be denied because S3 bucket policies require an explicit 'Deny' statement to block traffic.

Why it fails: AWS follows a 'default deny' logic where access is restricted unless an explicit 'Allow' exists. While an explicit 'Deny' would override an 'Allow', the absence of a successful 'Allow' (due to failed conditions) is sufficient to result in the request being denied by the system.

Alice is not using an encrypted connection (HTTPS) to upload the file.

Why it fails: While S3 can be configured to require HTTPS via a bucket policy condition, the CloudTrail log shows a general 'Access Denied' error. If HTTPS were the issue, the error would specifically relate to the secure transport condition in the policy, but the log indicates a more fundamental permission failure.

The S3 bucket is located in a different region than the IAM user.

Why it fails: IAM is a global service, and users can access resources in any AWS region provided they have the appropriate permissions. The region of the bucket does not cause an 'Access Denied' error unless there is an explicit policy condition restricting access based on the 'aws:RequestedRegion' key.

Alice's IAM user is missing the 's3:ListBucket' permission.

Why it fails: The 's3:PutObject' action is used to upload objects and does not require 's3:ListBucket' permission to function. 's3:ListBucket' is needed to see the contents of a bucket, but individual object operations are independent, so the lack of listing permissions would not cause a 'PutObject' failure.

Convert the instance to a Spot Instance to save up to 90%.

Why it fails: While Spot Instances offer great savings, they are not a direct 'conversion' for an existing production instance. Spot Instances can be terminated by AWS, making them unsuitable for many production workloads that require high availability. Right-sizing the existing instance is a safer and more predictable way to reduce costs for this workload.

Switch the instance to a T3 instance type with Unlimited mode enabled.

Why it fails: T3 instances are burstable and use a credit system. While they can be cheaper, 'Unlimited' mode can incur additional charges if the instance consistently bursts above its baseline. Given the current metrics, a smaller fixed-size instance is a more predictable way to save money without the risk of surprise burst charges.

Purchase a Compute Savings Plan for the current m5.4xlarge instance.

Why it fails: Buying a Savings Plan for an over-provisioned instance locks the company into paying for capacity they do not need. The correct order of operations for cost optimization is to right-size the workload first to find the actual resource requirement, and then apply a Savings Plan to the optimized, smaller instance.

AWS Budgets

Why it fails: AWS Budgets allows users to set custom budgets that alert them when costs or usage exceed certain thresholds. While related to cost management, the specific actions in the exhibit, like GetCostAndUsage and GetSavingsPlansUtilization, are programmatic calls specifically designed for retrieving data from the Cost Explorer API for visualization and analysis.

AWS Trusted Advisor

Why it fails: AWS Trusted Advisor provides recommendations for cost optimization, security, and performance based on best practices. However, it uses different IAM permissions to check service limits and configurations. It does not primarily use the 'ce:' prefix actions shown in the exhibit, which are dedicated to the Cost Explorer service.

AWS Compute Optimizer

Why it fails: AWS Compute Optimizer uses machine learning to recommend optimal AWS resources for workloads to reduce costs and improve performance. It focuses on rightsizing EC2 instances, EBS volumes, and Lambda functions. It does not use the cost-retrieval APIs defined in the exhibit, as its logic is based on performance metrics.

It ensures that all objects stored in the bucket are encrypted using AES-256 server-side encryption.

Why it fails: Server-side encryption (SSE-S3 or SSE-KMS) protects data at rest within the S3 bucket but does not govern how data is transmitted. This policy specifically targets the transport layer (OSI Layer 4/7) rather than the storage layer, so it does not ensure that the data is encrypted once stored.

It logs all access attempts to the bucket to identify users who are not using SSL.

Why it fails: Bucket policies apply to all principals when the Principal field is set to a wildcard, but they do not automatically enable logging. CloudTrail or S3 server access logs must be configured separately to track access requests, whereas this policy is designed to enforce security protocols for incoming traffic.

It automatically redirects all HTTP requests to HTTPS for the specified S3 bucket.

Why it fails: Unlike some web servers or CloudFront, S3 bucket policies cannot perform a protocol redirect from HTTP to HTTPS. Instead, the policy simply denies the insecure request, forcing the client to resubmit the request using the secure HTTPS protocol to gain access to the bucket's resources.