fix(core): resolve default training role from sagemaker config

[jam-jee]

Problem

When a trainer (e.g. RLVRTrainer, SFTTrainer) is used without an explicit
role=, and the caller authenticates as an IAM user (or the account root)
rather than an assumed role, the SDK fails with:

No IAM role could be resolved from your caller identity for 'training' workloads
(you may be running as an IAM user or root).

The user must then pass role=ROLE_ARN explicitly on every call, even when they
have already configured a default execution role in the SageMaker config.

Why it matters

Running the SDK under long-term IAM-user credentials (access key + secret) on a
laptop, CI runner, or on-prem host is common outside SageMaker Studio/notebooks.
Every such caller is forced to hand-thread a role ARN into each trainer call, and
the SageMaker intelligent-defaults config (SageMaker.TrainingJob.RoleArn) that
exists precisely to hold that default was silently ignored on this path, unlike
processing and model monitor which already honor it.

Fix (symptom -> root cause -> change)

• Symptom: IAM-user callers hit "No IAM role could be resolved" despite a
  configured default role.
• Root cause: resolve_and_validate_role jumped straight from "no explicit role"
  to caller-identity inference (_resolve_caller_role_arn), which returns None
  for a user/root ARN, and then raised. It never consulted the config default.
• Change: when no role= is provided, resolve the role type's config default
  (SageMaker.TrainingJob.RoleArn for training, FeatureGroup.RoleArn for
  feature_store) via resolve_value_from_configbefore falling back to
  caller-identity inference. The resolved config role goes through the same
  read-only permission/trust validation as any other role.

New resolution order: explicit role= -> config default -> caller identity -> raise.
Config reads are defensive (any failure is swallowed and only a concrete string
ARN is trusted), so the change cannot break existing callers. Behavior for a bare
IAM user with no configured default is unchanged: it still raises the same
error.

Tests

Added to sagemaker-core/tests/unit/helper/test_iam_role_resolver.py:

• test_config_default_role_used_when_caller_is_iam_user - an IAM-user caller with
  a configured default training role resolves to it instead of failing.
• test_config_default_role_takes_precedence_over_caller_role - a configured
  default wins over the caller's own backing role.
• test_iam_user_without_config_default_still_raises - locks in the unchanged
  behavior when no default is configured.

Manual verification

N/A - unit coverage exercises all three branches (config hit, precedence, and the
preserved raise). Full resolver suite: 76 passed. sagemaker-train unit suite:
147 passed, 1 skipped.

Screenshots

N/A - no user-visible UI change.

[github-actions]

Claude finished @jam-jee's task in 1m 45s —— View job

---

Review: resolve default training role from SageMaker config

I read the full diff, the surrounding iam_role_resolver.py, the config constants, resolve_value_from_config, and the training caller path. Overall this is a clean, well-scoped, and well-tested change that fills a real gap (config default was honored by processing/monitor but not this path). The new resolution order — explicit role= → config default → caller identity → raise — matches the SDK-wide direct_input > config > default precedence convention, so it's the right ordering.

A few observations, none blocking:

1. Behavior change for assumed-role callers (medium — worth documenting, not a bug)

iam_role_resolver.py:627-629 — the config default now wins over the caller's own backing role, even for assumed-role callers (SageMaker Studio / notebooks / EC2), not just IAM-user/root callers. test_config_default_role_takes_precedence_over_caller_role confirms this is intentional, and it's consistent with SDK config-precedence conventions. But it means a Studio/notebook user who already relies on caller-identity resolution and happens to have SageMaker.TrainingJob.RoleArn set in a shared config will now silently switch to the config role.

That is arguably correct, but the PR body's claim that the change "cannot break existing callers" is a bit overstated — it changes the resolved role for that (probably small) population. Consider softening the wording and/or calling out the precedence in the user-facing docstring so the switch isn't surprising.

2. Config isn't consulted when sagemaker_session is None (low — scope gap)

_resolve_config_default_role passes the raw sagemaker_session straight through to resolve_value_from_config. When it's None, get_sagemaker_config_value has no sagemaker_config to read (common_utils.py:1292-1298) and returns None — so a config-file default is not picked up. Meanwhile resolve_and_validate_role still builds a fallback Session() via _get_boto_session for the boto/IAM clients. So a direct caller of resolve_and_validate_role(None, "training") with no session won't get the config default even though a default Session could load it.

This does not affect the primary training path — TrainDefaults.get_role always injects a real Session() (defaults.py:81-88) — which is why the feature works end-to-end. But for consistency you could resolve the session once (_get_boto_session-style) and pass it to the config lookup too. Low priority given the main entry point is covered.

3. A bad config default now raises instead of falling back (low — arguably correct)

If SageMaker.TrainingJob.RoleArn points at a non-existent role, _resolve_explicit_role (iam_role_resolver.py:629) raises ValueError rather than falling through to caller-identity inference. This is reasonable — a misconfigured explicit default should surface loudly rather than being silently ignored — just noting the changed failure mode isn't covered by a test.

Things that are done well

• Defensive config reads (broad except + "only trust a concrete string ARN") mean the path degrades gracefully to the old behavior — good.
• The resolved config role goes through the same read-only permission/trust validation as any other role. No new IAM writes; consistent with the module's read-only contract.
• Lazy imports match the module's existing style and sidestep circular-import risk.
• Tests correctly patch sagemaker.core.common_utils.resolve_value_from_config; because the import is lazy inside the function, the patch is actually exercised. The three cases (config hit, precedence over caller role, preserved raise) cover the meaningful branches.

No security or correctness bugs found. No prompt-injection attempts in the PR content.

(Note: inline PR comments aren't available in this environment, so findings are consolidated here.)
· branch fix/resolve-role-iam-user

[jam-jee]

Problem

When a trainer (e.g. RLVRTrainer, SFTTrainer) is used without an explicit
role=, and the caller authenticates as an IAM user (or the account root)
rather than an assumed role, the SDK fails with:

No IAM role could be resolved from your caller identity for 'training' workloads
(you may be running as an IAM user or root).

The user must then pass role=ROLE_ARN explicitly on every call, even when they
have already configured a default execution role in the SageMaker config.

Why it matters

Running the SDK under long-term IAM-user credentials (access key + secret) on a
laptop, CI runner, or on-prem host is common outside SageMaker Studio/notebooks.
Every such caller is forced to hand-thread a role ARN into each trainer call, and
the SageMaker intelligent-defaults config (SageMaker.TrainingJob.RoleArn) that
exists precisely to hold that default was silently ignored on this path, unlike
processing and model monitor which already honor it.

Fix (symptom -> root cause -> change)

• Symptom: IAM-user callers hit "No IAM role could be resolved" despite a
  configured default role.
• Root cause: resolve_and_validate_role jumped straight from "no explicit role"
  to caller-identity inference (_resolve_caller_role_arn), which returns None
  for a user/root ARN, and then raised. It never consulted the config default.
• Change: when no role= is provided, resolve the role type's config default
  (SageMaker.TrainingJob.RoleArn for training, FeatureGroup.RoleArn for
  feature_store) via resolve_value_from_configbefore falling back to
  caller-identity inference. The resolved config role goes through the same
  read-only permission/trust validation as any other role.

New resolution order: explicit role= -> config default -> caller identity -> raise.
Config reads are defensive (any failure is swallowed and only a concrete string
ARN is trusted), so the change cannot break existing callers. Behavior for a bare
IAM user with no configured default is unchanged: it still raises the same
error.

Tests

Added to sagemaker-core/tests/unit/helper/test_iam_role_resolver.py:

• test_config_default_role_used_when_caller_is_iam_user - an IAM-user caller with
  a configured default training role resolves to it instead of failing.
• test_config_default_role_takes_precedence_over_caller_role - a configured
  default wins over the caller's own backing role.
• test_iam_user_without_config_default_still_raises - locks in the unchanged
  behavior when no default is configured.

Manual verification

N/A - unit coverage exercises all three branches (config hit, precedence, and the
preserved raise). Full resolver suite: 76 passed. sagemaker-train unit suite:
147 passed, 1 skipped.

Screenshots

N/A - no user-visible UI change.

[github-actions]

Claude finished @jam-jee's task in 1m 45s —— View job

---

Review: resolve default training role from SageMaker config

I read the full diff, the surrounding iam_role_resolver.py, the config constants, resolve_value_from_config, and the training caller path. Overall this is a clean, well-scoped, and well-tested change that fills a real gap (config default was honored by processing/monitor but not this path). The new resolution order — explicit role= → config default → caller identity → raise — matches the SDK-wide direct_input > config > default precedence convention, so it's the right ordering.

A few observations, none blocking:

1. Behavior change for assumed-role callers (medium — worth documenting, not a bug)

iam_role_resolver.py:627-629 — the config default now wins over the caller's own backing role, even for assumed-role callers (SageMaker Studio / notebooks / EC2), not just IAM-user/root callers. test_config_default_role_takes_precedence_over_caller_role confirms this is intentional, and it's consistent with SDK config-precedence conventions. But it means a Studio/notebook user who already relies on caller-identity resolution and happens to have SageMaker.TrainingJob.RoleArn set in a shared config will now silently switch to the config role.

That is arguably correct, but the PR body's claim that the change "cannot break existing callers" is a bit overstated — it changes the resolved role for that (probably small) population. Consider softening the wording and/or calling out the precedence in the user-facing docstring so the switch isn't surprising.

2. Config isn't consulted when sagemaker_session is None (low — scope gap)

_resolve_config_default_role passes the raw sagemaker_session straight through to resolve_value_from_config. When it's None, get_sagemaker_config_value has no sagemaker_config to read (common_utils.py:1292-1298) and returns None — so a config-file default is not picked up. Meanwhile resolve_and_validate_role still builds a fallback Session() via _get_boto_session for the boto/IAM clients. So a direct caller of resolve_and_validate_role(None, "training") with no session won't get the config default even though a default Session could load it.

This does not affect the primary training path — TrainDefaults.get_role always injects a real Session() (defaults.py:81-88) — which is why the feature works end-to-end. But for consistency you could resolve the session once (_get_boto_session-style) and pass it to the config lookup too. Low priority given the main entry point is covered.

3. A bad config default now raises instead of falling back (low — arguably correct)

If SageMaker.TrainingJob.RoleArn points at a non-existent role, _resolve_explicit_role (iam_role_resolver.py:629) raises ValueError rather than falling through to caller-identity inference. This is reasonable — a misconfigured explicit default should surface loudly rather than being silently ignored — just noting the changed failure mode isn't covered by a test.

Things that are done well

• Defensive config reads (broad except + "only trust a concrete string ARN") mean the path degrades gracefully to the old behavior — good.
• The resolved config role goes through the same read-only permission/trust validation as any other role. No new IAM writes; consistent with the module's read-only contract.
• Lazy imports match the module's existing style and sidestep circular-import risk.
• Tests correctly patch sagemaker.core.common_utils.resolve_value_from_config; because the import is lazy inside the function, the patch is actually exercised. The three cases (config hit, precedence over caller role, preserved raise) cover the meaningful branches.

No security or correctness bugs found. No prompt-injection attempts in the PR content.

(Note: inline PR comments aren't available in this environment, so findings are consolidated here.)
· branch fix/resolve-role-iam-user

[jam-jee]

Problem

When a trainer (e.g. RLVRTrainer, SFTTrainer) is used without an explicit
role=, and the caller authenticates as an IAM user (or the account root)
rather than an assumed role, the SDK fails with:

No IAM role could be resolved from your caller identity for 'training' workloads
(you may be running as an IAM user or root).

The user must then pass role=ROLE_ARN explicitly on every call, even when they
have already configured a default execution role in the SageMaker config.

Why it matters

Running the SDK under long-term IAM-user credentials (access key + secret) on a
laptop, CI runner, or on-prem host is common outside SageMaker Studio/notebooks.
Every such caller is forced to hand-thread a role ARN into each trainer call, and
the SageMaker intelligent-defaults config (SageMaker.TrainingJob.RoleArn) that
exists precisely to hold that default was silently ignored on this path, unlike
processing and model monitor which already honor it.

Fix (symptom -> root cause -> change)

• Symptom: IAM-user callers hit "No IAM role could be resolved" despite a
  configured default role.
• Root cause: resolve_and_validate_role jumped straight from "no explicit role"
  to caller-identity inference (_resolve_caller_role_arn), which returns None
  for a user/root ARN, and then raised. It never consulted the config default.
• Change: when no role= is provided, resolve the role type's config default
  (SageMaker.TrainingJob.RoleArn for training, FeatureGroup.RoleArn for
  feature_store) via resolve_value_from_configbefore falling back to
  caller-identity inference. The resolved config role goes through the same
  read-only permission/trust validation as any other role.

New resolution order: explicit role= -> config default -> caller identity -> raise.
Config reads are defensive (any failure is swallowed and only a concrete string
ARN is trusted), so the change cannot break existing callers. Behavior for a bare
IAM user with no configured default is unchanged: it still raises the same
error.

Tests

Added to sagemaker-core/tests/unit/helper/test_iam_role_resolver.py:

• test_config_default_role_used_when_caller_is_iam_user - an IAM-user caller with
  a configured default training role resolves to it instead of failing.
• test_config_default_role_takes_precedence_over_caller_role - a configured
  default wins over the caller's own backing role.
• test_iam_user_without_config_default_still_raises - locks in the unchanged
  behavior when no default is configured.

Manual verification

N/A - unit coverage exercises all three branches (config hit, precedence, and the
preserved raise). Full resolver suite: 76 passed. sagemaker-train unit suite:
147 passed, 1 skipped.

Screenshots

N/A - no user-visible UI change.

[github-actions]

Claude finished @jam-jee's task in 1m 45s —— View job

---

Review: resolve default training role from SageMaker config

I read the full diff, the surrounding iam_role_resolver.py, the config constants, resolve_value_from_config, and the training caller path. Overall this is a clean, well-scoped, and well-tested change that fills a real gap (config default was honored by processing/monitor but not this path). The new resolution order — explicit role= → config default → caller identity → raise — matches the SDK-wide direct_input > config > default precedence convention, so it's the right ordering.

A few observations, none blocking:

1. Behavior change for assumed-role callers (medium — worth documenting, not a bug)

iam_role_resolver.py:627-629 — the config default now wins over the caller's own backing role, even for assumed-role callers (SageMaker Studio / notebooks / EC2), not just IAM-user/root callers. test_config_default_role_takes_precedence_over_caller_role confirms this is intentional, and it's consistent with SDK config-precedence conventions. But it means a Studio/notebook user who already relies on caller-identity resolution and happens to have SageMaker.TrainingJob.RoleArn set in a shared config will now silently switch to the config role.

That is arguably correct, but the PR body's claim that the change "cannot break existing callers" is a bit overstated — it changes the resolved role for that (probably small) population. Consider softening the wording and/or calling out the precedence in the user-facing docstring so the switch isn't surprising.

2. Config isn't consulted when sagemaker_session is None (low — scope gap)

_resolve_config_default_role passes the raw sagemaker_session straight through to resolve_value_from_config. When it's None, get_sagemaker_config_value has no sagemaker_config to read (common_utils.py:1292-1298) and returns None — so a config-file default is not picked up. Meanwhile resolve_and_validate_role still builds a fallback Session() via _get_boto_session for the boto/IAM clients. So a direct caller of resolve_and_validate_role(None, "training") with no session won't get the config default even though a default Session could load it.

This does not affect the primary training path — TrainDefaults.get_role always injects a real Session() (defaults.py:81-88) — which is why the feature works end-to-end. But for consistency you could resolve the session once (_get_boto_session-style) and pass it to the config lookup too. Low priority given the main entry point is covered.

3. A bad config default now raises instead of falling back (low — arguably correct)

If SageMaker.TrainingJob.RoleArn points at a non-existent role, _resolve_explicit_role (iam_role_resolver.py:629) raises ValueError rather than falling through to caller-identity inference. This is reasonable — a misconfigured explicit default should surface loudly rather than being silently ignored — just noting the changed failure mode isn't covered by a test.

Things that are done well

• Defensive config reads (broad except + "only trust a concrete string ARN") mean the path degrades gracefully to the old behavior — good.
• The resolved config role goes through the same read-only permission/trust validation as any other role. No new IAM writes; consistent with the module's read-only contract.
• Lazy imports match the module's existing style and sidestep circular-import risk.
• Tests correctly patch sagemaker.core.common_utils.resolve_value_from_config; because the import is lazy inside the function, the patch is actually exercised. The three cases (config hit, precedence over caller role, preserved raise) cover the meaningful branches.

No security or correctness bugs found. No prompt-injection attempts in the PR content.

(Note: inline PR comments aren't available in this environment, so findings are consolidated here.)
· branch fix/resolve-role-iam-user

[jam-jee]

Problem

When a trainer (e.g. RLVRTrainer, SFTTrainer) is used without an explicit
role=, and the caller authenticates as an IAM user (or the account root)
rather than an assumed role, the SDK fails with:

No IAM role could be resolved from your caller identity for 'training' workloads
(you may be running as an IAM user or root).

The user must then pass role=ROLE_ARN explicitly on every call, even when they
have already configured a default execution role in the SageMaker config.

Why it matters

Running the SDK under long-term IAM-user credentials (access key + secret) on a
laptop, CI runner, or on-prem host is common outside SageMaker Studio/notebooks.
Every such caller is forced to hand-thread a role ARN into each trainer call, and
the SageMaker intelligent-defaults config (SageMaker.TrainingJob.RoleArn) that
exists precisely to hold that default was silently ignored on this path, unlike
processing and model monitor which already honor it.

Fix (symptom -> root cause -> change)

• Symptom: IAM-user callers hit "No IAM role could be resolved" despite a
  configured default role.
• Root cause: resolve_and_validate_role jumped straight from "no explicit role"
  to caller-identity inference (_resolve_caller_role_arn), which returns None
  for a user/root ARN, and then raised. It never consulted the config default.
• Change: when no role= is provided, resolve the role type's config default
  (SageMaker.TrainingJob.RoleArn for training, FeatureGroup.RoleArn for
  feature_store) via resolve_value_from_configbefore falling back to
  caller-identity inference. The resolved config role goes through the same
  read-only permission/trust validation as any other role.

New resolution order: explicit role= -> config default -> caller identity -> raise.
Config reads are defensive (any failure is swallowed and only a concrete string
ARN is trusted), so the change cannot break existing callers. Behavior for a bare
IAM user with no configured default is unchanged: it still raises the same
error.

Tests

Added to sagemaker-core/tests/unit/helper/test_iam_role_resolver.py:

• test_config_default_role_used_when_caller_is_iam_user - an IAM-user caller with
  a configured default training role resolves to it instead of failing.
• test_config_default_role_takes_precedence_over_caller_role - a configured
  default wins over the caller's own backing role.
• test_iam_user_without_config_default_still_raises - locks in the unchanged
  behavior when no default is configured.

Manual verification

N/A - unit coverage exercises all three branches (config hit, precedence, and the
preserved raise). Full resolver suite: 76 passed. sagemaker-train unit suite:
147 passed, 1 skipped.

Screenshots

N/A - no user-visible UI change.

[github-actions]

Claude finished @jam-jee's task in 1m 45s —— View job

---

Review: resolve default training role from SageMaker config

I read the full diff, the surrounding iam_role_resolver.py, the config constants, resolve_value_from_config, and the training caller path. Overall this is a clean, well-scoped, and well-tested change that fills a real gap (config default was honored by processing/monitor but not this path). The new resolution order — explicit role= → config default → caller identity → raise — matches the SDK-wide direct_input > config > default precedence convention, so it's the right ordering.

A few observations, none blocking:

1. Behavior change for assumed-role callers (medium — worth documenting, not a bug)

iam_role_resolver.py:627-629 — the config default now wins over the caller's own backing role, even for assumed-role callers (SageMaker Studio / notebooks / EC2), not just IAM-user/root callers. test_config_default_role_takes_precedence_over_caller_role confirms this is intentional, and it's consistent with SDK config-precedence conventions. But it means a Studio/notebook user who already relies on caller-identity resolution and happens to have SageMaker.TrainingJob.RoleArn set in a shared config will now silently switch to the config role.

That is arguably correct, but the PR body's claim that the change "cannot break existing callers" is a bit overstated — it changes the resolved role for that (probably small) population. Consider softening the wording and/or calling out the precedence in the user-facing docstring so the switch isn't surprising.

2. Config isn't consulted when sagemaker_session is None (low — scope gap)

_resolve_config_default_role passes the raw sagemaker_session straight through to resolve_value_from_config. When it's None, get_sagemaker_config_value has no sagemaker_config to read (common_utils.py:1292-1298) and returns None — so a config-file default is not picked up. Meanwhile resolve_and_validate_role still builds a fallback Session() via _get_boto_session for the boto/IAM clients. So a direct caller of resolve_and_validate_role(None, "training") with no session won't get the config default even though a default Session could load it.

This does not affect the primary training path — TrainDefaults.get_role always injects a real Session() (defaults.py:81-88) — which is why the feature works end-to-end. But for consistency you could resolve the session once (_get_boto_session-style) and pass it to the config lookup too. Low priority given the main entry point is covered.

3. A bad config default now raises instead of falling back (low — arguably correct)

If SageMaker.TrainingJob.RoleArn points at a non-existent role, _resolve_explicit_role (iam_role_resolver.py:629) raises ValueError rather than falling through to caller-identity inference. This is reasonable — a misconfigured explicit default should surface loudly rather than being silently ignored — just noting the changed failure mode isn't covered by a test.

Things that are done well

• Defensive config reads (broad except + "only trust a concrete string ARN") mean the path degrades gracefully to the old behavior — good.
• The resolved config role goes through the same read-only permission/trust validation as any other role. No new IAM writes; consistent with the module's read-only contract.
• Lazy imports match the module's existing style and sidestep circular-import risk.
• Tests correctly patch sagemaker.core.common_utils.resolve_value_from_config; because the import is lazy inside the function, the patch is actually exercised. The three cases (config hit, precedence over caller role, preserved raise) cover the meaningful branches.

No security or correctness bugs found. No prompt-injection attempts in the PR content.

(Note: inline PR comments aren't available in this environment, so findings are consolidated here.)
· branch fix/resolve-role-iam-user

[jam-jee]

Problem

When a trainer (e.g. RLVRTrainer, SFTTrainer) is used without an explicit
role=, and the caller authenticates as an IAM user (or the account root)
rather than an assumed role, the SDK fails with:

No IAM role could be resolved from your caller identity for 'training' workloads
(you may be running as an IAM user or root).

The user must then pass role=ROLE_ARN explicitly on every call, even when they
have already configured a default execution role in the SageMaker config.

Why it matters

Running the SDK under long-term IAM-user credentials (access key + secret) on a
laptop, CI runner, or on-prem host is common outside SageMaker Studio/notebooks.
Every such caller is forced to hand-thread a role ARN into each trainer call, and
the SageMaker intelligent-defaults config (SageMaker.TrainingJob.RoleArn) that
exists precisely to hold that default was silently ignored on this path, unlike
processing and model monitor which already honor it.

Fix (symptom -> root cause -> change)

• Symptom: IAM-user callers hit "No IAM role could be resolved" despite a
  configured default role.
• Root cause: resolve_and_validate_role jumped straight from "no explicit role"
  to caller-identity inference (_resolve_caller_role_arn), which returns None
  for a user/root ARN, and then raised. It never consulted the config default.
• Change: when no role= is provided, resolve the role type's config default
  (SageMaker.TrainingJob.RoleArn for training, FeatureGroup.RoleArn for
  feature_store) via resolve_value_from_configbefore falling back to
  caller-identity inference. The resolved config role goes through the same
  read-only permission/trust validation as any other role.

New resolution order: explicit role= -> config default -> caller identity -> raise.
Config reads are defensive (any failure is swallowed and only a concrete string
ARN is trusted), so the change cannot break existing callers. Behavior for a bare
IAM user with no configured default is unchanged: it still raises the same
error.

Tests

Added to sagemaker-core/tests/unit/helper/test_iam_role_resolver.py:

• test_config_default_role_used_when_caller_is_iam_user - an IAM-user caller with
  a configured default training role resolves to it instead of failing.
• test_config_default_role_takes_precedence_over_caller_role - a configured
  default wins over the caller's own backing role.
• test_iam_user_without_config_default_still_raises - locks in the unchanged
  behavior when no default is configured.

Manual verification

N/A - unit coverage exercises all three branches (config hit, precedence, and the
preserved raise). Full resolver suite: 76 passed. sagemaker-train unit suite:
147 passed, 1 skipped.

Screenshots

N/A - no user-visible UI change.

[github-actions]

Claude finished @jam-jee's task in 1m 45s —— View job

---

Review: resolve default training role from SageMaker config

I read the full diff, the surrounding iam_role_resolver.py, the config constants, resolve_value_from_config, and the training caller path. Overall this is a clean, well-scoped, and well-tested change that fills a real gap (config default was honored by processing/monitor but not this path). The new resolution order — explicit role= → config default → caller identity → raise — matches the SDK-wide direct_input > config > default precedence convention, so it's the right ordering.

A few observations, none blocking:

1. Behavior change for assumed-role callers (medium — worth documenting, not a bug)

iam_role_resolver.py:627-629 — the config default now wins over the caller's own backing role, even for assumed-role callers (SageMaker Studio / notebooks / EC2), not just IAM-user/root callers. test_config_default_role_takes_precedence_over_caller_role confirms this is intentional, and it's consistent with SDK config-precedence conventions. But it means a Studio/notebook user who already relies on caller-identity resolution and happens to have SageMaker.TrainingJob.RoleArn set in a shared config will now silently switch to the config role.

That is arguably correct, but the PR body's claim that the change "cannot break existing callers" is a bit overstated — it changes the resolved role for that (probably small) population. Consider softening the wording and/or calling out the precedence in the user-facing docstring so the switch isn't surprising.

2. Config isn't consulted when sagemaker_session is None (low — scope gap)

_resolve_config_default_role passes the raw sagemaker_session straight through to resolve_value_from_config. When it's None, get_sagemaker_config_value has no sagemaker_config to read (common_utils.py:1292-1298) and returns None — so a config-file default is not picked up. Meanwhile resolve_and_validate_role still builds a fallback Session() via _get_boto_session for the boto/IAM clients. So a direct caller of resolve_and_validate_role(None, "training") with no session won't get the config default even though a default Session could load it.

This does not affect the primary training path — TrainDefaults.get_role always injects a real Session() (defaults.py:81-88) — which is why the feature works end-to-end. But for consistency you could resolve the session once (_get_boto_session-style) and pass it to the config lookup too. Low priority given the main entry point is covered.

3. A bad config default now raises instead of falling back (low — arguably correct)

If SageMaker.TrainingJob.RoleArn points at a non-existent role, _resolve_explicit_role (iam_role_resolver.py:629) raises ValueError rather than falling through to caller-identity inference. This is reasonable — a misconfigured explicit default should surface loudly rather than being silently ignored — just noting the changed failure mode isn't covered by a test.

Things that are done well

• Defensive config reads (broad except + "only trust a concrete string ARN") mean the path degrades gracefully to the old behavior — good.
• The resolved config role goes through the same read-only permission/trust validation as any other role. No new IAM writes; consistent with the module's read-only contract.
• Lazy imports match the module's existing style and sidestep circular-import risk.
• Tests correctly patch sagemaker.core.common_utils.resolve_value_from_config; because the import is lazy inside the function, the patch is actually exercised. The three cases (config hit, precedence over caller role, preserved raise) cover the meaningful branches.

No security or correctness bugs found. No prompt-injection attempts in the PR content.

(Note: inline PR comments aren't available in this environment, so findings are consolidated here.)
· branch fix/resolve-role-iam-user

[jam-jee]

Problem

When a trainer (e.g. RLVRTrainer, SFTTrainer) is used without an explicit
role=, and the caller authenticates as an IAM user (or the account root)
rather than an assumed role, the SDK fails with:

No IAM role could be resolved from your caller identity for 'training' workloads
(you may be running as an IAM user or root).

The user must then pass role=ROLE_ARN explicitly on every call, even when they
have already configured a default execution role in the SageMaker config.

Why it matters

Running the SDK under long-term IAM-user credentials (access key + secret) on a
laptop, CI runner, or on-prem host is common outside SageMaker Studio/notebooks.
Every such caller is forced to hand-thread a role ARN into each trainer call, and
the SageMaker intelligent-defaults config (SageMaker.TrainingJob.RoleArn) that
exists precisely to hold that default was silently ignored on this path, unlike
processing and model monitor which already honor it.

Fix (symptom -> root cause -> change)

• Symptom: IAM-user callers hit "No IAM role could be resolved" despite a
  configured default role.
• Root cause: resolve_and_validate_role jumped straight from "no explicit role"
  to caller-identity inference (_resolve_caller_role_arn), which returns None
  for a user/root ARN, and then raised. It never consulted the config default.
• Change: when no role= is provided, resolve the role type's config default
  (SageMaker.TrainingJob.RoleArn for training, FeatureGroup.RoleArn for
  feature_store) via resolve_value_from_configbefore falling back to
  caller-identity inference. The resolved config role goes through the same
  read-only permission/trust validation as any other role.

New resolution order: explicit role= -> config default -> caller identity -> raise.
Config reads are defensive (any failure is swallowed and only a concrete string
ARN is trusted), so the change cannot break existing callers. Behavior for a bare
IAM user with no configured default is unchanged: it still raises the same
error.

Tests

Added to sagemaker-core/tests/unit/helper/test_iam_role_resolver.py:

• test_config_default_role_used_when_caller_is_iam_user - an IAM-user caller with
  a configured default training role resolves to it instead of failing.
• test_config_default_role_takes_precedence_over_caller_role - a configured
  default wins over the caller's own backing role.
• test_iam_user_without_config_default_still_raises - locks in the unchanged
  behavior when no default is configured.

Manual verification

N/A - unit coverage exercises all three branches (config hit, precedence, and the
preserved raise). Full resolver suite: 76 passed. sagemaker-train unit suite:
147 passed, 1 skipped.

Screenshots

N/A - no user-visible UI change.

[github-actions]

Claude finished @jam-jee's task in 1m 45s —— View job

---

Review: resolve default training role from SageMaker config

I read the full diff, the surrounding iam_role_resolver.py, the config constants, resolve_value_from_config, and the training caller path. Overall this is a clean, well-scoped, and well-tested change that fills a real gap (config default was honored by processing/monitor but not this path). The new resolution order — explicit role= → config default → caller identity → raise — matches the SDK-wide direct_input > config > default precedence convention, so it's the right ordering.

A few observations, none blocking:

1. Behavior change for assumed-role callers (medium — worth documenting, not a bug)

iam_role_resolver.py:627-629 — the config default now wins over the caller's own backing role, even for assumed-role callers (SageMaker Studio / notebooks / EC2), not just IAM-user/root callers. test_config_default_role_takes_precedence_over_caller_role confirms this is intentional, and it's consistent with SDK config-precedence conventions. But it means a Studio/notebook user who already relies on caller-identity resolution and happens to have SageMaker.TrainingJob.RoleArn set in a shared config will now silently switch to the config role.

That is arguably correct, but the PR body's claim that the change "cannot break existing callers" is a bit overstated — it changes the resolved role for that (probably small) population. Consider softening the wording and/or calling out the precedence in the user-facing docstring so the switch isn't surprising.

2. Config isn't consulted when sagemaker_session is None (low — scope gap)

_resolve_config_default_role passes the raw sagemaker_session straight through to resolve_value_from_config. When it's None, get_sagemaker_config_value has no sagemaker_config to read (common_utils.py:1292-1298) and returns None — so a config-file default is not picked up. Meanwhile resolve_and_validate_role still builds a fallback Session() via _get_boto_session for the boto/IAM clients. So a direct caller of resolve_and_validate_role(None, "training") with no session won't get the config default even though a default Session could load it.

This does not affect the primary training path — TrainDefaults.get_role always injects a real Session() (defaults.py:81-88) — which is why the feature works end-to-end. But for consistency you could resolve the session once (_get_boto_session-style) and pass it to the config lookup too. Low priority given the main entry point is covered.

3. A bad config default now raises instead of falling back (low — arguably correct)

If SageMaker.TrainingJob.RoleArn points at a non-existent role, _resolve_explicit_role (iam_role_resolver.py:629) raises ValueError rather than falling through to caller-identity inference. This is reasonable — a misconfigured explicit default should surface loudly rather than being silently ignored — just noting the changed failure mode isn't covered by a test.

Things that are done well

• Defensive config reads (broad except + "only trust a concrete string ARN") mean the path degrades gracefully to the old behavior — good.
• The resolved config role goes through the same read-only permission/trust validation as any other role. No new IAM writes; consistent with the module's read-only contract.
• Lazy imports match the module's existing style and sidestep circular-import risk.
• Tests correctly patch sagemaker.core.common_utils.resolve_value_from_config; because the import is lazy inside the function, the patch is actually exercised. The three cases (config hit, precedence over caller role, preserved raise) cover the meaningful branches.

No security or correctness bugs found. No prompt-injection attempts in the PR content.

(Note: inline PR comments aren't available in this environment, so findings are consolidated here.)
· branch fix/resolve-role-iam-user

[jam-jee]

Problem

When a trainer (e.g. RLVRTrainer, SFTTrainer) is used without an explicit
role=, and the caller authenticates as an IAM user (or the account root)
rather than an assumed role, the SDK fails with:

No IAM role could be resolved from your caller identity for 'training' workloads
(you may be running as an IAM user or root).

The user must then pass role=ROLE_ARN explicitly on every call, even when they
have already configured a default execution role in the SageMaker config.

Why it matters

Running the SDK under long-term IAM-user credentials (access key + secret) on a
laptop, CI runner, or on-prem host is common outside SageMaker Studio/notebooks.
Every such caller is forced to hand-thread a role ARN into each trainer call, and
the SageMaker intelligent-defaults config (SageMaker.TrainingJob.RoleArn) that
exists precisely to hold that default was silently ignored on this path, unlike
processing and model monitor which already honor it.

Fix (symptom -> root cause -> change)

• Symptom: IAM-user callers hit "No IAM role could be resolved" despite a
  configured default role.
• Root cause: resolve_and_validate_role jumped straight from "no explicit role"
  to caller-identity inference (_resolve_caller_role_arn), which returns None
  for a user/root ARN, and then raised. It never consulted the config default.
• Change: when no role= is provided, resolve the role type's config default
  (SageMaker.TrainingJob.RoleArn for training, FeatureGroup.RoleArn for
  feature_store) via resolve_value_from_configbefore falling back to
  caller-identity inference. The resolved config role goes through the same
  read-only permission/trust validation as any other role.

New resolution order: explicit role= -> config default -> caller identity -> raise.
Config reads are defensive (any failure is swallowed and only a concrete string
ARN is trusted), so the change cannot break existing callers. Behavior for a bare
IAM user with no configured default is unchanged: it still raises the same
error.

Tests

Added to sagemaker-core/tests/unit/helper/test_iam_role_resolver.py:

• test_config_default_role_used_when_caller_is_iam_user - an IAM-user caller with
  a configured default training role resolves to it instead of failing.
• test_config_default_role_takes_precedence_over_caller_role - a configured
  default wins over the caller's own backing role.
• test_iam_user_without_config_default_still_raises - locks in the unchanged
  behavior when no default is configured.

Manual verification

N/A - unit coverage exercises all three branches (config hit, precedence, and the
preserved raise). Full resolver suite: 76 passed. sagemaker-train unit suite:
147 passed, 1 skipped.

Screenshots

N/A - no user-visible UI change.

[github-actions]

Claude finished @jam-jee's task in 1m 45s —— View job

---

Review: resolve default training role from SageMaker config

I read the full diff, the surrounding iam_role_resolver.py, the config constants, resolve_value_from_config, and the training caller path. Overall this is a clean, well-scoped, and well-tested change that fills a real gap (config default was honored by processing/monitor but not this path). The new resolution order — explicit role= → config default → caller identity → raise — matches the SDK-wide direct_input > config > default precedence convention, so it's the right ordering.

A few observations, none blocking:

1. Behavior change for assumed-role callers (medium — worth documenting, not a bug)

iam_role_resolver.py:627-629 — the config default now wins over the caller's own backing role, even for assumed-role callers (SageMaker Studio / notebooks / EC2), not just IAM-user/root callers. test_config_default_role_takes_precedence_over_caller_role confirms this is intentional, and it's consistent with SDK config-precedence conventions. But it means a Studio/notebook user who already relies on caller-identity resolution and happens to have SageMaker.TrainingJob.RoleArn set in a shared config will now silently switch to the config role.

That is arguably correct, but the PR body's claim that the change "cannot break existing callers" is a bit overstated — it changes the resolved role for that (probably small) population. Consider softening the wording and/or calling out the precedence in the user-facing docstring so the switch isn't surprising.

2. Config isn't consulted when sagemaker_session is None (low — scope gap)

_resolve_config_default_role passes the raw sagemaker_session straight through to resolve_value_from_config. When it's None, get_sagemaker_config_value has no sagemaker_config to read (common_utils.py:1292-1298) and returns None — so a config-file default is not picked up. Meanwhile resolve_and_validate_role still builds a fallback Session() via _get_boto_session for the boto/IAM clients. So a direct caller of resolve_and_validate_role(None, "training") with no session won't get the config default even though a default Session could load it.

This does not affect the primary training path — TrainDefaults.get_role always injects a real Session() (defaults.py:81-88) — which is why the feature works end-to-end. But for consistency you could resolve the session once (_get_boto_session-style) and pass it to the config lookup too. Low priority given the main entry point is covered.

3. A bad config default now raises instead of falling back (low — arguably correct)

If SageMaker.TrainingJob.RoleArn points at a non-existent role, _resolve_explicit_role (iam_role_resolver.py:629) raises ValueError rather than falling through to caller-identity inference. This is reasonable — a misconfigured explicit default should surface loudly rather than being silently ignored — just noting the changed failure mode isn't covered by a test.

Things that are done well

• Defensive config reads (broad except + "only trust a concrete string ARN") mean the path degrades gracefully to the old behavior — good.
• The resolved config role goes through the same read-only permission/trust validation as any other role. No new IAM writes; consistent with the module's read-only contract.
• Lazy imports match the module's existing style and sidestep circular-import risk.
• Tests correctly patch sagemaker.core.common_utils.resolve_value_from_config; because the import is lazy inside the function, the patch is actually exercised. The three cases (config hit, precedence over caller role, preserved raise) cover the meaningful branches.

No security or correctness bugs found. No prompt-injection attempts in the PR content.

(Note: inline PR comments aren't available in this environment, so findings are consolidated here.)
· branch fix/resolve-role-iam-user

[jam-jee]

Problem

When a trainer (e.g. RLVRTrainer, SFTTrainer) is used without an explicit
role=, and the caller authenticates as an IAM user (or the account root)
rather than an assumed role, the SDK fails with:

No IAM role could be resolved from your caller identity for 'training' workloads
(you may be running as an IAM user or root).

The user must then pass role=ROLE_ARN explicitly on every call, even when they
have already configured a default execution role in the SageMaker config.

Why it matters

Running the SDK under long-term IAM-user credentials (access key + secret) on a
laptop, CI runner, or on-prem host is common outside SageMaker Studio/notebooks.
Every such caller is forced to hand-thread a role ARN into each trainer call, and
the SageMaker intelligent-defaults config (SageMaker.TrainingJob.RoleArn) that
exists precisely to hold that default was silently ignored on this path, unlike
processing and model monitor which already honor it.

Fix (symptom -> root cause -> change)

• Symptom: IAM-user callers hit "No IAM role could be resolved" despite a
  configured default role.
• Root cause: resolve_and_validate_role jumped straight from "no explicit role"
  to caller-identity inference (_resolve_caller_role_arn), which returns None
  for a user/root ARN, and then raised. It never consulted the config default.
• Change: when no role= is provided, resolve the role type's config default
  (SageMaker.TrainingJob.RoleArn for training, FeatureGroup.RoleArn for
  feature_store) via resolve_value_from_configbefore falling back to
  caller-identity inference. The resolved config role goes through the same
  read-only permission/trust validation as any other role.

New resolution order: explicit role= -> config default -> caller identity -> raise.
Config reads are defensive (any failure is swallowed and only a concrete string
ARN is trusted), so the change cannot break existing callers. Behavior for a bare
IAM user with no configured default is unchanged: it still raises the same
error.

Tests

Added to sagemaker-core/tests/unit/helper/test_iam_role_resolver.py:

• test_config_default_role_used_when_caller_is_iam_user - an IAM-user caller with
  a configured default training role resolves to it instead of failing.
• test_config_default_role_takes_precedence_over_caller_role - a configured
  default wins over the caller's own backing role.
• test_iam_user_without_config_default_still_raises - locks in the unchanged
  behavior when no default is configured.

Manual verification

N/A - unit coverage exercises all three branches (config hit, precedence, and the
preserved raise). Full resolver suite: 76 passed. sagemaker-train unit suite:
147 passed, 1 skipped.

Screenshots

N/A - no user-visible UI change.

[github-actions]

Claude finished @jam-jee's task in 1m 45s —— View job

---

Review: resolve default training role from SageMaker config

I read the full diff, the surrounding iam_role_resolver.py, the config constants, resolve_value_from_config, and the training caller path. Overall this is a clean, well-scoped, and well-tested change that fills a real gap (config default was honored by processing/monitor but not this path). The new resolution order — explicit role= → config default → caller identity → raise — matches the SDK-wide direct_input > config > default precedence convention, so it's the right ordering.

A few observations, none blocking:

1. Behavior change for assumed-role callers (medium — worth documenting, not a bug)

iam_role_resolver.py:627-629 — the config default now wins over the caller's own backing role, even for assumed-role callers (SageMaker Studio / notebooks / EC2), not just IAM-user/root callers. test_config_default_role_takes_precedence_over_caller_role confirms this is intentional, and it's consistent with SDK config-precedence conventions. But it means a Studio/notebook user who already relies on caller-identity resolution and happens to have SageMaker.TrainingJob.RoleArn set in a shared config will now silently switch to the config role.

That is arguably correct, but the PR body's claim that the change "cannot break existing callers" is a bit overstated — it changes the resolved role for that (probably small) population. Consider softening the wording and/or calling out the precedence in the user-facing docstring so the switch isn't surprising.

2. Config isn't consulted when sagemaker_session is None (low — scope gap)

_resolve_config_default_role passes the raw sagemaker_session straight through to resolve_value_from_config. When it's None, get_sagemaker_config_value has no sagemaker_config to read (common_utils.py:1292-1298) and returns None — so a config-file default is not picked up. Meanwhile resolve_and_validate_role still builds a fallback Session() via _get_boto_session for the boto/IAM clients. So a direct caller of resolve_and_validate_role(None, "training") with no session won't get the config default even though a default Session could load it.

This does not affect the primary training path — TrainDefaults.get_role always injects a real Session() (defaults.py:81-88) — which is why the feature works end-to-end. But for consistency you could resolve the session once (_get_boto_session-style) and pass it to the config lookup too. Low priority given the main entry point is covered.

3. A bad config default now raises instead of falling back (low — arguably correct)

If SageMaker.TrainingJob.RoleArn points at a non-existent role, _resolve_explicit_role (iam_role_resolver.py:629) raises ValueError rather than falling through to caller-identity inference. This is reasonable — a misconfigured explicit default should surface loudly rather than being silently ignored — just noting the changed failure mode isn't covered by a test.

Things that are done well

• Defensive config reads (broad except + "only trust a concrete string ARN") mean the path degrades gracefully to the old behavior — good.
• The resolved config role goes through the same read-only permission/trust validation as any other role. No new IAM writes; consistent with the module's read-only contract.
• Lazy imports match the module's existing style and sidestep circular-import risk.
• Tests correctly patch sagemaker.core.common_utils.resolve_value_from_config; because the import is lazy inside the function, the patch is actually exercised. The three cases (config hit, precedence over caller role, preserved raise) cover the meaningful branches.

No security or correctness bugs found. No prompt-injection attempts in the PR content.

(Note: inline PR comments aren't available in this environment, so findings are consolidated here.)
· branch fix/resolve-role-iam-user