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

DEA-C01 By islever Editorial Last updated

Apply authorization mechanisms.

Short 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.

Question

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?
  1. Add the AWSGlueServiceRole managed policy to the data engineer's IAM user.
  2. 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
  3. Add the AmazonSageMakerFullAccess managed policy to the data engineer's IAM user.
  4. 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.

Key Takeaways

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.

Common mistake: 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.

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

These links open the official vendor documentation in a new tab.

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.

More DEA-C01 FAQ →

Community Votes

B
61%
C
39%

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

Discussion 11 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 11

  1. tgv 👍 6 Answered B
    I don't believe you're supposed to assign a FullAccess policy, so I will go with B.
  2. GiorgioGss 👍 5 Answered 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
  3. rralucard_ 👍 3 Answered 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.
  4. atu1789 👍 2 Answered 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.
  5. junrun3 👍 2 Answered 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.
Show 6 more comments
  1. damaldon 👍 2
    Ans. C https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSageMakerFullAccess.html
  2. Christina666 👍 1 Answered 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.
  3. mohamedTR 👍 1 Answered B
    B. the engineer needs to assume specific roles to allow interaction between these services. The sts:AssumeRole action is necessary for this purpose
  4. fceb2c1 👍 1
    https://repost.aws/knowledge-center/sagemaker-featuregroup-troubleshooting
  5. LR2023 👍 1
    OPtion A https://docs.aws.amazon.com/glue/latest/dg/glue-is-security.html
  6. lucas_rfsb 👍 3 Answered C
    I will go with C

Reader comments & corrections

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

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Amazon Redshift Compound Sort Key Query Optimization

S-grade

Secure Redshift Spectrum Access with VPC Endpoints

S-grade

Athena Federated Query for Multi-Source Iceberg Pipelines

S-grade

Reclaiming Storage in Amazon Redshift Materialized Views

S-grade

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