# Hf Cloud Sagemaker Iam Preflight

Ensure a usable SageMaker execution role exists before deploying or training.

- Repository: https://github.com/huggingface/skills (11249 stars)
- Category: Writing
- License: Apache-2.0
- Last updated: 2026-10-30
- Runs scripts: yes, review before use

## Install

Claude Code: `npx skills add huggingface/skills --skill hf-cloud-sagemaker-iam-preflight -g -a claude-code -y`
Codex: `npx skills add huggingface/skills --skill hf-cloud-sagemaker-iam-preflight -g -a codex -y`
Cursor: `npx skills add huggingface/skills --skill hf-cloud-sagemaker-iam-preflight -g -a cursor -y`
Gemini CLI: `npx skills add huggingface/skills --skill hf-cloud-sagemaker-iam-preflight -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add huggingface/skills`

## Description

Ensure a usable SageMaker execution role exists before deploying or training. Use this skill whenever about to create a SageMaker endpoint, model, training job, or any resource that requires an execution role. Use it especially when the user has not provided a role ARN explicitly, when scripts are about to call `iam:CreateRole`, or when an AccessDenied error mentions an IAM action. Never blindly call `iam:CreateRole`, always check for existing roles first. This skill prevents the most common SageMaker deployment failure: trying to create IAM resources from an SSO principal that has no IAM write permissions.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# SageMaker IAM Preflight

Every SageMaker resource needs an **execution role**, the IAM role SageMaker assumes to read model artifacts from S3, pull serving containers from ECR, and write logs. Most deployments fail here because the script tried to create a new role without checking if a usable one already existed, then blew up because the caller is an SSO principal.

This skill encodes the right order: discover, validate, only create if necessary.

## Running the helpers (cross-platform)

The helpers are Python so they run identically on Windows, macOS, and Linux:

```bash
python3 scripts/check_role.py        # macOS / Linux
python  scripts/check_role.py        # Windows (PowerShell / cmd)
```

**Run them from the shell where the AWS CLI already works**, i.e. wherever `aws sts get-caller-identity` succeeds. The script shells out to that same `aws` binary and inherits the shell's profile, region, SSO session, proxy, and credential chain.

> **Windows / WSL / Git Bash caveat.** Do **not** invoke these through a Bash shim (WSL, Git Bash, MSYS) on Windows. Those Bash environments frequently do **not** share the Windows AWS config, credentials, SSO sessions, environment variables, or proxy settings, so `aws sts get-caller-identity` fails inside Bash even when it works natively in PowerShell. (This is exactly why the old `.sh` helpers failed on Windows and were replaced with Python.) If you're in PowerShell, run `python ...\check_role.py` directly in PowerShell. If the helper still can't see your identity, run the same discovery natively (see "Native AWS CLI equivalent" below) in the shell where `aws sts get-caller-identity` returns your ARN.

## Order of operations

### Step 1, Did the user provide a role?

Validate that one specifically:

```bash
python3 scripts/check_role.py "<role-name-or-arn>"
```

On success it prints the ARN to stdout (exit 0). On failure it logs why on stderr. Don't try to silently fix a broken role, surface the problem.

The rest: https://github.com/huggingface/skills/blob/HEAD/skills/hf-cloud-sagemaker-iam-preflight/SKILL.md