Which security feature must be provisioned for AWS CLI access?

Why the Answer Is Correct

Interacting with AWS through the AWS CLI is programmatic access, and AWS requires a signed request for every API call the CLI makes. That signature is generated from an AWS access key, meaning an access key ID plus its matching secret access key, which is exactly what option D describes. An IAM user (or an IAM Identity Center / assumed role session) that has an access key provisioned is what makes aws configure and subsequent CLI commands work at all. Without an access key the CLI has no way to identify and authenticate the caller, so option D is the security feature that must be provisioned in the developer's account.

Why the Other Options Are Wrong

Option A, a user name and password, is the credential used for interactive console sign-in; it is not accepted by the AWS CLI, which supports SigV4 request signing, not browser-style form login. Option C, root password access, is both wrong and dangerous — the root user can technically create an access key, but AWS strongly advises against using root credentials for everyday programmatic work, so it is never the recommended provisioning step. Option B, AWS Systems Manager, is an operations service for patching, inventory, session management and parameter storage; it is not a credential and cannot authenticate a CLI request by itself. None of these three provides the signing material the CLI needs.

Community Comment Notes

Every learner answering this item converged on the same choice: its_tima commented "D. Access key for programmatic access*", explicitly tying the answer to programmatic use of the CLI. ShaiTay and d00b229 both answered with the plain phrase "D. AWS access key", reinforcing that the community treats the access key ID / secret access key pair as the credential that satisfies this scenario. The unanimous vote record (D: 100) matches the reasoning above, and in this case the community majority and the source key both agree with the technical analysis.