Attach an instance profile with a CodeArtifact IAM role and run aws codeartifact login on the instance

Why the Answer Is Correct

Pulling a package from an AWS CodeArtifact repository requires two things: an IAM identity authorized to read from the repository, and an authentication token that the package manager presents when it connects. An Amazon EC2 instance receives an IAM identity only through an instance profile, so the solution creates an instance profile containing an IAM role that has access to CodeArtifact and associates that instance profile with the EC2 instance (D). Because the role is attached before the CodeDeploy BeforeInstall hook runs, the hook's package installation executes with those credentials. Running the aws codeartifact login CLI command on the instance retrieves the authorization token and configures the credential helper so that pip and other package managers authenticate to CodeArtifact, which is what makes the install succeed (D). teo2157 cited the CodeArtifact security and IAM documentation as the basis for this answer, and Srikantha described both halves, the instance profile granting permission to read from CodeArtifact and the login command setting up the package manager credential configuration. D is the correct answer.

Why the Other Options Are Wrong

A creates a service-linked role for CodeArtifact, associates the role with the EC2 instance, and uses the get-authorization-token command on the instance. A service-linked role is an IAM role that a particular AWS service assumes on your behalf to perform actions in the context of that service; it is not an identity that an EC2 instance assumes, so associating it with the instance does not give the instance CodeArtifact credentials, and the instance's package install would remain unauthorized. C configures ACLs on the CodeArtifact repository to allow the EC2 instance to access the Python package. CodeArtifact repositories do not have ACLs as an access control mechanism; access is granted through IAM policies on identities and through resource-based policies on the repository and domain, so there is nothing for this option to configure. B configures a resource-based policy on the CodeArtifact repository allowing the ReadFromRepository action for the EC2 instance principal. tinyshare argued for this on the grounds that a resource policy controls who can use the repository, which is true in principle; however, the EC2 instance principal is not an IAM principal that can be named until it has an IAM role, and a resource-based policy alone does not give the instance credentials or a CodeArtifact authentication token. The instance therefore still cannot authenticate a package install. D is correct.

Community Comment Notes

Community voted D (82), with B a minority (18). teo2157 cited the CodeArtifact security and IAM documentation for D, and Srikantha explained that the IAM role is attached via the instance profile to grant permission to read from CodeArtifact while aws codeartifact login sets up the package manager credential configuration. uncledana confirmed D in full. tinyshare was the sole dissenter, preferring B on the reasoning that a resource-based policy is what allows access to the repository and cited the CodeArtifact repository policies documentation; that reasoning does not account for the fact that the instance still needs an IAM identity and a token to authenticate, which only D supplies. No alternative received majority support.