Answer - B.
Below is an excerpt from the documentation on how the credentials are evaluated when it comes to access.
So when using the CLI, if the environment variables were set with the Access Keys, they would take preference over the IAM Role.
To make requests to Amazon Web Services, you must supply AWS credentials to the AWS SDK for Java.
You can do this in the following ways:
- Use the default credential provider chain (recommended).
- Use a specific credential provider or provider chain (or create your own).
- Supply the credentials yourself.
These can be root account credentials, IAM credentials, or temporary credentials retrieved from AWS STS.
Using the Default Credential Provider Chain.
When you initialize a new service client without supplying any arguments, the AWS SDK for Java attempts to find AWS credentials using the default credential provider chain implemented by the DefaultAWSCredentialsProviderChain class.
The default credential provider chain looks for credentials in this order.
Environment variables-
AWS_ACCESS_KEY_ID.
and
AWS_SECRET_ACCESS_KEY.
The AWS SDK for Java uses the EnvironmentVariableCredentialsProvider class to load these credentials.
Java system properties-
aws.accessKeyId.
and
aws.secretKey.
The AWS SDK for Java uses the SystemPropertiesCredentialsProvider to load these credentials.
Web Identity Token credentials from the environment or container.
The default credential profiles file- typically located at
~/.aws/credentials.
(location can vary per platform), and shared by many of the AWS SDKs and by the AWS CLI.
The AWS SDK for Java uses the ProfileCredentialsProvider to load these credentials.
Amazon ECS container credentials- loaded from the Amazon ECS if the environment variable
AWS_CONTAINER_CREDENTIALS_RELATIVE_URI.
is set.
The AWS SDK for Java uses the ContainerCredentialsProvider to load these credentials.
You can specify the IP address for this value.
Instance profile credentials- used on EC2 instances, and delivered through the Amazon EC2 metadata service.
The AWS SDK for Java uses the InstanceProfileCredentialsProvider to load these credentials.
You can specify the IP address for this value.
Options A and D are incorrect since the IAM Role is instantly applied to the EC2 Instance.
Option C is incorrect because even if the CLI is corrupted.
This would still not be the cause of the underlying issue.
For more information on an example of how credentials are evaluated, please refer to the below URL-
https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html
The most likely reason why the application still has access to write to the S3 bucket, even after assigning an IAM role with read-only permissions to the EC2 instance, is that the environment variables set for SDK access are taking priority over the instance profile.
When a Java application runs on an EC2 instance, it can use the AWS SDK to interact with AWS services such as S3. To access the SDK, the application needs to provide credentials, which can be done using environment variables or by using an IAM role attached to the instance.
In this case, during the testing phase, the team provided access credentials through environment variables to the application, which allowed it to write to the S3 bucket. However, after the testing was confirmed, an IAM role was assigned to the instance, which only has permissions to read from the S3 bucket.
Even though the IAM role was assigned to the instance, the application still has access to write to the S3 bucket because the environment variables for SDK access are taking priority. The application is still using the access credentials provided through the environment variables, which have write permissions to the S3 bucket.
To solve this problem, the application needs to be updated to use the instance profile credentials instead of the environment variables. This can be done by configuring the AWS SDK to use the instance profile credentials provider. Once this is done, the application will use the IAM role assigned to the instance and will only have read-only permissions to the S3 bucket.
Restarting the instance (option A) or reattaching the EBS volume (option D) will not solve the problem, as they do not affect the SDK credentials used by the application. The CLI being corrupted (option C) is also unlikely to be the cause of the issue, as it does not affect the SDK credentials used by the application.
