How Do You Fix SageMaker Studio Access Denied for Glue Sessions?

Apply authorization mechanisms.

Answer Correct answer: B — Add a policy to the data engineer's IAM user granting sts:AssumeRole for the AWS Glue and SageMaker roles in the trust policy.

A data engineer is configuring Amazon SageMaker Studio to use AWS Glue interactive sessions to prepare data for machine learning (ML) models. The data engineer receives an access denied error when the data engineer tries to prepare the data by using SageMaker Studio. Which change should the engineer make to gain access to SageMaker Studio?

Add the AWSGlueServiceRole managed policy to the data engineer's IAM user.
Add a policy to the data engineer's IAM user that includes the sts:AssumeRole action for the AWS Glue and SageMaker service principals in the trust policy. Correct Answer
Add the AmazonSageMakerFullAccess managed policy to the data engineer's IAM user.
Add a policy to the data engineer's IAM user that allows the sts:AddAssociation action for the AWS Glue and SageMaker service principals in the trust policy.

Community Votes

61%

39%

61% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The question tests whether you recognize that the Studio-to-Glue hand-off is an sts:AssumeRole authorization, and the trap is reaching for the broad AmazonSageMakerFullAccess policy whenever a SageMaker access error appears.

AWS Glue interactive sessions launched from Amazon SageMaker Studio return AccessDenied unless the engineer's IAM user is allowed to assume the Glue and SageMaker roles. This page confirms the fix is the sts:AssumeRole grant (B), not the broad AmazonSageMakerFullAccess managed policy.

The most common wrong pick is C, AmazonSageMakerFullAccess, because it intuitively 'gives SageMaker access'; it is overly permissive and does not add the sts:AssumeRole permission that the Glue interactive session path actually requires.

Community Discussion (11 comments)

tgv 👍 6 Selected: B

I don't believe you're supposed to assign a FullAccess policy, so I will go with B.

GiorgioGss 👍 5 Selected: B

I will go with B since you can get access denied even with the AmazonSageMakerFullAccess. See here: https://stackoverflow.com/questions/64709871/aws-sagemaker-studio-createdomain-access-error

mohamedTR 👍 1 Selected: B

B. the engineer needs to assume specific roles to allow interaction between these services. The sts:AssumeRole action is necessary for this purpose

junrun3 👍 2 Selected: C

B, this approach involves setting up the trust relationship for roles. It is not a typical requirement for resolving access issues with SageMaker Studio directly.

LR2023 👍 1

OPtion A https://docs.aws.amazon.com/glue/latest/dg/glue-is-security.html

Christina666 👍 1 Selected: C

SageMaker Permissions: The AmazonSageMakerFullAccess managed policy provides broad permissions for using Amazon SageMaker features, including SageMaker Studio and the ability to interact with other AWS services like AWS Glue. Least Privilege: While this policy is quite permissive, it's the most direct solution to the immediate access issue. After resolving the error, you can refine permissions for a more granular approach.

lucas_rfsb 👍 3 Selected: C

I will go with C

fceb2c1 👍 1

https://repost.aws/knowledge-center/sagemaker-featuregroup-troubleshooting

damaldon 👍 2

Ans. C https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSageMakerFullAccess.html

atu1789 👍 2 Selected: B

B. Add a policy to the data engineer’s IAM user that includes the sts:AssumeRole action for the AWS Glue and SageMaker service principals in the trust policy. • This is the most appropriate solution. The sts:AssumeRole action allows the data engineer’s IAM user to assume a role that has the necessary permissions for both AWS Glue and SageMaker. This is a common approach for granting cross-service access in AWS.

rralucard_ 👍 3 Selected: C

Amazon SageMaker requires permissions to perform actions on your behalf. By attaching the AmazonSageMakerFullAccess managed policy to the data engineer’s IAM user, you grant the necessary permissions for SageMaker Studio to access AWS Glue and other related services.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

AWS Glue interactive sessions inside SageMaker Studio work by having the user's execution context assume a role that AWS Glue and SageMaker can use, so the engineer's IAM user must be allowed to call sts:AssumeRole for those principals. The AccessDenied error is an authorization failure on that assume-role step, and adding a policy that grants sts:AssumeRole for the AWS Glue and SageMaker principals fixes it without widening anything else. This is also the least-privilege answer, because it grants exactly one action instead of an AWS-managed policy carrying hundreds of unrelated permissions. The trust policy on the target role permits the AWS Glue and SageMaker service principals to assume it, which is what makes the cross-service hand-off possible.

Why the Other Options Are Wrong

AWSGlueServiceRole (A) is a service-role policy intended for the role that AWS Glue itself assumes to reach data stores such as Amazon S3; attaching it to a human IAM user grants none of the SageMaker Studio access that is failing. AmazonSageMakerFullAccess (C) is broad and does grant Studio access, but it does not by itself establish the assume-role path Glue interactive sessions require, and learners report AccessDenied even on setups that already have it. Option D substitutes sts:AddAssociation for sts:AssumeRole, but AddAssociation is a SageMaker API operation rather than an STS action used for cross-service role assumption, so it cannot resolve the error. Only B names the correct action (sts:AssumeRole) for the correct principals (AWS Glue and SageMaker).

Community Comment Notes

Most learners landed on B — tgv reasoned "I don't believe you're supposed to assign a FullAccess policy", and mohamedTR framed it as the engineer needing "to assume specific roles to allow interaction between these services". GiorgioGss reinforced this by noting you can get an access denied error even with AmazonSageMakerFullAccess and linked a SageMaker Studio access-error thread as evidence. A sizeable minority, including rralucard_ and Christina666, chose C on the grounds that SageMaker must act on the user's behalf and that FullAccess is the "most direct solution", though Christina666 conceded it is permissive. junrun3 dismissed B as being about trust relationships between roles rather than Studio access, while LR2023 pointed at the AWS Glue interactive-sessions security documentation for option A.

Official Reference

Exam Strategy

When a DEA-C01 question describes an access denied error between two AWS services, first identify which identity is making the call and which role it must assume; the answer is usually a scoped sts:AssumeRole or iam:PassRole grant, not a FullAccess managed policy. Quickly eliminate options that name service-role policies built for the service itself (AWSGlueServiceRole) or actions that do not exist for human users in IAM/STS.

Frequently Asked Questions

Why is AmazonSageMakerFullAccess (C) not enough for Glue interactive sessions?

It grants broad SageMaker permissions but not the sts:AssumeRole call a Studio user needs before AWS Glue interactive sessions can run, so AccessDenied can persist.

Is sts:AddAssociation in option D a real AWS STS action?

No. AddAssociation is an Amazon SageMaker API operation, not an STS action; cross-service access is granted with sts:AssumeRole, which option B specifies.

Related Analysis

Practice All DEA-C01 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DEA-C01 Practice Test →

← Back to DEA-C01 Study Guide