A company has a team of data scientists who use Amazon SageMaker notebook instances to test ML models. When the data scientists need new permissions, the company attaches the permissions to each indiv

Question

Options

• ACreate a single IAM role that has the necessary permissions. Attach the role to each notebook
• BCreate a single IAM group. Add the data scientists to the group. Associate the group with each
• CCreate a single IAM user. Attach the AdministratorAccess AWS managed IAM policy to the user.
• DCreate a single IAM group. Add the data scientists to the group. Create an IAM role. Attach the

• A
  77% (46)
• B
  5% (3)
• C
  3% (2)
• D
  15% (9)

Explanation

Option A is correct because SageMaker notebook instances authenticate as AWS services using IAM roles, not users or groups - and by pointing all notebooks at one shared role, any permission change made to that role is instantly inherited by every notebook, achieving centralized management.

Why the distractors fail:

• B & D are wrong because IAM groups can only contain IAM users (humans); they cannot be attached to or assumed by AWS services like SageMaker notebook instances.
• C is wrong for two reasons: IAM users are for human or application identities, not service resources, and granting AdministratorAccess violates the principle of least privilege - it's also not "centralizing" management, just consolidating excessive access.

Memory tip: Think "Roles for Resources, Users for Humans, Groups for Humans in Bulk." Whenever an AWS service (SageMaker, Lambda, EC2, etc.) needs permissions, the answer is always an IAM role - never a user or group.

No community discussion yet for this question.