A transit authority's CI/CD pipeline deploys SageMaker models automatically, and the deployment role currently has access to every model package group in the account instead of just the one it manages. What is the appropriate fix?
Select an answer to reveal the explanation.
Short Explanation
A deployment role that can touch every model package group is a master key handed out for a single-door job. Scoping its policy down to the one package group it actually deploys keeps automation fast without widening the blast radius if that role is ever misused. Least privilege applies to pipelines too, not just people.
Full Explanation
Scoping the deployment role's IAM policy to the specific model package group it manages, using resource-level permissions on the package group's ARN, limits what the automated pipeline can touch to exactly what its job requires — if the pipeline or its credentials are ever compromised, the blast radius is contained to that one package group instead of every model in the account. Leaving the broader access in place because a shared role is simpler to maintain accepts a larger attack surface for a modest convenience, and resource-scoped policies can still be maintained with standard infrastructure-as-code practices. Granting administrator-level access to other teams' package groups moves further in the wrong direction, extending one pipeline's blast radius across the whole organization's model deployments. Removing IAM permissions and replacing them with a manual approval gate doesn't scope automation — it just adds a human bottleneck in front of the same over-broad access, without shrinking what the role itself can do once approved. Scope caveat: as new package groups are introduced, extend the policy deliberately for each one rather than defaulting back to a wildcard resource match for convenience. Operational check: attempt a deployment against a package group outside the role's scope and confirm the pipeline's action is denied.