IAM Policy practice questions

A developer needs to access an S3 bucket from an EC2 instance. For security best practices, the developer must avoid hardcoding long-term credentials on the instance. What is the most secure method to provide the necessary permissions?

Trap 1: Create an IAM user with S3 access and store the access key and…

Storing static credentials in local configuration files is a high-risk security practice. If the file is accidentally committed to version control or accessed by unauthorized users, the credentials could be compromised, leading to potential data breaches. IAM roles are the standard, secure alternative to this method.

Trap 2: Configure the S3 bucket policy to allow public read access to the…

Bucket policies that rely on public IP addresses are insecure and difficult to maintain. IP addresses for EC2 instances can change, and public access policies expose the bucket to the internet, increasing the attack surface. IAM roles are the correct, secure mechanism for service-to-service authorization within AWS.

Trap 3: Modify the instance security group to allow all traffic to and from…

Security groups control network traffic at the instance level but do not govern authentication or authorization. Even if the network path is allowed, the instance still needs valid IAM credentials to perform API requests against S3. Security groups are irrelevant to the identity-based access requirements for S3.

A
Create an IAM user with S3 access and store the access key and secret key in a local configuration file.
Why it fails: Storing static credentials in local configuration files is a high-risk security practice. If the file is accidentally committed to version control or accessed by unauthorized users, the credentials could be compromised, leading to potential data breaches. IAM roles are the standard, secure alternative to this method.
B
Attach an IAM role to the EC2 instance with an S3 access policy.
IAM roles provide temporary credentials via the AWS metadata service, which the SDK uses automatically. This method avoids hardcoding credentials on the disk, follows the principle of least privilege, and ensures that permissions are tied to the compute resource rather than a long-lived user identity.
C
Configure the S3 bucket policy to allow public read access to the specific EC2 instance's public IP address.
Why it fails: Bucket policies that rely on public IP addresses are insecure and difficult to maintain. IP addresses for EC2 instances can change, and public access policies expose the bucket to the internet, increasing the attack surface. IAM roles are the correct, secure mechanism for service-to-service authorization within AWS.
D
Modify the instance security group to allow all traffic to and from the S3 endpoint.
Why it fails: Security groups control network traffic at the instance level but do not govern authentication or authorization. Even if the network path is allowed, the instance still needs valid IAM credentials to perform API requests against S3. Security groups are irrelevant to the identity-based access requirements for S3.

Question 2mediummultiple choice

Refer to the exhibit. A solutions architect reviews the following IAM policy applied to a user. What is the effect of this policy when the user attempts to access an object in the bucket from an IP address of 198.51.100.5?

Exhibit

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*",
    "Condition": {"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}}
  }]
}

Trap 1: Access is allowed because the policy grants s3:GetObject…

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.

Trap 2: Access is allowed because there is no explicit Deny statement in…

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.

Trap 3: Access is denied because the policy does not include permissions…

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.

A
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.
B
Access is denied because the source IP address is not within the 203.0.113.0/24 range.
The policy includes an IpAddress condition that limits the Allow effect to the 203.0.113.0/24 subnet. Because the user's IP address (198.51.100.5) does not match this range, the policy does not provide the necessary permission to access the S3 object, resulting in an implicit deny.
C
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.
D
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.

Question 3hardmultiple choice

Refer to the exhibit. A company is using this S3 bucket policy to secure high-performance data accessed by an analytics fleet on EC2. Users report that despite having the correct IAM permissions, they are receiving 403 Forbidden errors when trying to download data. What is the most likely cause of this performance and access issue?

Exhibit

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::my-high-perf-data/*",
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpce": "vpce-1a2b3c4d"
        }
      }
    }
  ]
}

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

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.

Trap 2: The IAM role assigned to the EC2 instances lacks S3:GetObject…

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.

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

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.

A
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.
B
The EC2 instances are not using the specified VPC Endpoint to access S3.
The policy explicitly denies all S3 actions unless the 'aws:sourceVpce' matches 'vpce-1a2b3c4d'. If the EC2 instances are accessing S3 via a NAT Gateway or public internet rather than the specified VPC Endpoint, the condition will trigger a Deny, resulting in the 403 error reported.
C
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.
D
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.

Question 4mediummultiple choice

Refer to the exhibit. An IAM policy is applied to an IAM user to grant access to an S3 bucket. However, the user is still receiving an 'Access Denied' error when attempting to list the objects in the bucket. What is the cause of this error?

Exhibit

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

Trap 1: The user does not have an IAM role attached.

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.

Trap 2: The bucket policy is explicitly denying access.

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.

Trap 3: The S3 bucket is encrypted with a KMS key.

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.

A
The policy is missing the s3:ListBucket permission.
The s3:ListBucket action is required to list the contents of an S3 bucket. The current policy only provides read access to the objects themselves, not the bucket's file listing. Adding this action to the policy will resolve the Access Denied error when performing the list command.
B
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.
C
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.
D
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.

Question 5mediummultiple choice

Refer to the exhibit. The current IAM policy allows an EC2 instance to read backups. The architect wants to ensure the data is recoverable if the source bucket is compromised by an external actor with write access. What should be done?

Exhibit

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-backup-bucket/*"
    }
  ]
}

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

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.

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

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.

Trap 3: Enable S3 Server-Side Encryption (SSE-S3).

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.

A
Enable S3 Object Lock on the bucket.
Object Lock provides WORM (Write Once, Read Many) protection. By preventing objects from being overwritten or deleted for a set period, it ensures that even an account compromise cannot destroy the backup data. This is the most effective way to secure backups against malicious actors and accidental data loss.
B
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.
C
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.
D
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.

Question 6mediummultiple choice

Refer to the exhibit. A security administrator is reviewing a CloudTrail log entry for an 'Access Denied' error. The user 'Alice' is trying to upload a file to an S3 bucket. Alice has an IAM policy that allows 's3:PutObject' on all resources. What is the most likely cause of this error?

Exhibit

{
  "Records": [
    {
      "eventVersion": "1.08",
      "userIdentity": {
        "type": "IAMUser",
        "principalId": "AIDACKCEVSQ6C2EXAMPLE",
        "arn": "arn:aws:iam::123456789012:user/Alice",
        "accountId": "123456789012"
      },
      "eventTime": "2023-10-27T14:30:00Z",
      "eventSource": "s3.amazonaws.com",
      "eventName": "PutObject",
      "awsRegion": "us-east-1",
      "sourceIPAddress": "192.0.2.50",
      "errorCode": "AccessDenied",
      "errorMessage": "Access Denied"
    }
  ]
}

Trap 1: Alice is not using an encrypted connection (HTTPS) to upload the…

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.

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

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.

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

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.

A
The S3 bucket has a bucket policy with an explicit Deny for Alice or the action.
Even though Alice has an identity-based policy allowing 's3:PutObject', an explicit 'Deny' in a resource-based policy (like a bucket policy) always overrides any 'Allow'. This is a common cause of Access Denied errors when multiple layers of security policies are applied to a resource.
B
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.
C
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.
D
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.

Question 7mediummultiple choice

Refer to the exhibit. A junior cloud financial analyst needs to monitor and optimize costs across the organization's AWS account. The analyst requires the ability to view historical cost data and check how effectively Reserved Instances and Savings Plans are being used. Which AWS service is the analyst most likely using with this IAM policy?

Exhibit

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ce:GetCostAndUsage",
        "ce:GetReservationUtilization",
        "ce:GetSavingsPlansUtilization"
      ],
      "Resource": "*"
    }
  ]
}

Trap 1: AWS Budgets

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.

Trap 2: AWS Trusted Advisor

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.

Trap 3: AWS Compute Optimizer

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.

A
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.
B
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.
C
AWS Cost Explorer
AWS Cost Explorer is the service that enables users to query cost and usage data programmatically or via the console. The permissions listed in the exhibit allow the analyst to retrieve granular data about spending and the efficiency of their commitment-based pricing models, which is the core functionality of Cost Explorer.
D
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.

Question 8mediummultiple choice

Refer to the exhibit. This bucket policy grants access to a specific account. A user in that account still cannot access the object. What is the most likely reason?

Exhibit

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

Trap 1: The bucket policy needs to use 'Effect': 'Deny'.

Using 'Deny' would explicitly block access, which is the opposite of the objective. The policy currently uses 'Allow', which is correct for granting access. Changing this to 'Deny' would prevent the user from accessing the bucket entirely, failing to resolve the connectivity issue mentioned in the scenario.

Trap 2: The bucket policy must include 'Principal': '*'.

Setting the principal to '*' makes the bucket public, which is a major security violation and should never be done for secure data. The current policy correctly restricts access to a specific AWS account, which is the secure and intended way to handle cross-account access in AWS.

Trap 3: The resource ARN is incorrectly formatted.

The ARN provided, 'arn:aws:s3:::my-secure-bucket/*', is the standard format for granting access to objects within an S3 bucket. There is no evidence of a syntax error here. The problem is almost certainly an identity-side IAM permissions issue, as bucket policies and IAM policies work together for authorization.

A
The bucket policy needs to use 'Effect': 'Deny'.
Why it fails: Using 'Deny' would explicitly block access, which is the opposite of the objective. The policy currently uses 'Allow', which is correct for granting access. Changing this to 'Deny' would prevent the user from accessing the bucket entirely, failing to resolve the connectivity issue mentioned in the scenario.
B
The user in the target account lacks IAM permissions.
In cross-account access, both the bucket policy and the user's local IAM policy must explicitly permit the action. The bucket policy allows access from the account, but the individual user identity still requires an IAM policy that authorizes the s3:GetObject action to complete the authorization request successfully.
C
The bucket policy must include 'Principal': '*'.
Why it fails: Setting the principal to '*' makes the bucket public, which is a major security violation and should never be done for secure data. The current policy correctly restricts access to a specific AWS account, which is the secure and intended way to handle cross-account access in AWS.
D
The resource ARN is incorrectly formatted.
Why it fails: The ARN provided, 'arn:aws:s3:::my-secure-bucket/*', is the standard format for granting access to objects within an S3 bucket. There is no evidence of a syntax error here. The problem is almost certainly an identity-side IAM permissions issue, as bucket policies and IAM policies work together for authorization.