AWSAWS Certified Generative AI Developer - Professional2026-100 Prerequisites
Trace permissions from principal to request
Completed by the knowledge check
Learning objective
Use IAM principals, roles, policies, temporary credentials, and least privilege.
Core idea
AWS Identity and Access Management (IAM) answers whether a particular principal can perform a particular action on a particular resource under the request’s conditions. A principal is the identity making the request. Credentials identify that caller; policies determine its permissions. Possessing valid credentials does not imply permission to invoke every model or read every document.
For a GenAI application, distinguish the engineer deploying infrastructure from the workload invoking a model. Give each identity permissions for its own job. An application’s runtime role should not inherit the engineer’s ability to change access policies merely because both identities participate in the same product.
IAM roles provide temporary credentials when assumed. Their trust policies define who can assume them, while their permissions policies define what a session using the role can do. These are separate decisions, and a failure in either can prevent the intended request.
How it works
Identify the principal and role
IAM principals include account root users, IAM users, and roles. A service principal represents an AWS service. In a role trust policy, the Principal element identifies the trusted caller, which can include an AWS account, role, user, or service. A role is not a person and does not have standard long-term access keys or a password associated with it.
When code runs using an assumed role, reason about the role session making the AWS request. Do not assume the request carries the permissions of the human who originally deployed that code. Assuming a role changes the permission context; it does not add the role’s permissions to every permission the original caller already had.
AWS recommends federated access with temporary credentials for people, with IAM Identity Center providing centralized account access. For workloads running on AWS compute such as EC2 or Lambda, AWS delivers role credentials, and AWS SDKs can discover and use them. This avoids embedding an IAM user’s long-term keys in application configuration. Enterprise federation choices belong to 2.3.6.
Separate trust from authorization
The AWS Security Token Service (AWS STS) AssumeRole operation returns temporary credentials for a role session. For cross-account role assumption, the target role must trust the caller, and the caller must have permission to call sts:AssumeRole on that role’s Amazon Resource Name (ARN). A permissions policy that allows model inference does not, by itself, establish this trust.
After the role is assumed, AWS evaluates the subsequent model request using the session’s applicable policies. The role’s trust policy does not grant the bedrock:InvokeModel permission. That permission belongs in an applicable permissions policy. Conversely, adding bedrock:InvokeModel to a role does not make an otherwise untrusted caller able to assume it.
Trust is checked when the role is assumed, and permissions are checked when the session calls the model.
Avoid turning the cross-account rule into a universal requirement for two identity-policy grants. Within the same account, a role trust policy can grant an IAM user permission to assume the role directly. Policy evaluation depends on the principal and policy type, so inspect the actual request rather than counting how many policies contain an allow.
Read policy statements as request constraints
Most IAM policies use JSON statements. Effect specifies Allow or Deny; Action identifies operations; Resource identifies the resources affected; and Condition restricts when a statement applies. Resource-based policies, including role trust policies, also identify a Principal.
Resource scope must match the operation. For example, an s3:ListBucket grant names a bucket ARN. A grant intended for objects is not interchangeable with that bucket-level grant. Bedrock foundation-model resources use arn:aws:bedrock:REGION::foundation-model/MODEL_ID; system-defined and application profiles use arn:aws:bedrock:REGION:ACCOUNT_ID:inference-profile/PROFILE_ID and arn:aws:bedrock:REGION:ACCOUNT_ID:application-inference-profile/PROFILE_ID, where the uppercase fields identify the Region, model, account, and profile. A grant naming a profile must also include its foundation model in each associated Region; see 1.2.4 for routing authorization.
Requests without an applicable grant are denied. An applicable explicit deny overrides an allow. Permissions boundaries limit what identity-based policies can grant; they do not grant permissions themselves. AWS Organizations service control policies (SCPs) and resource control policies (RCPs) also establish permission guardrails rather than supplying the workload’s grant. Detailed enforcement-layer analysis belongs to 3.2.2.
Use temporary credentials within their lifetime
AssumeRole returns credentials containing AccessKeyId, SecretAccessKey, SessionToken, and Expiration. The session token is part of the credential set; copying only the access key ID and secret is incomplete. After credentials expire, they no longer authorize API requests. Use a credential provider that obtains replacement credentials instead of treating the first response as permanent.
DurationSeconds controls an AssumeRole session within the role’s configured maximum. Role chaining limits the resulting session to one hour. Increasing an application’s own timeout cannot extend that credential lifetime. Optional session policies further restrict the assumed role’s identity-based permissions; they cannot grant more than those policies allow.
Make least privilege concrete
Least privilege means selecting the required actions, resources, and conditions for each task. It is not synonymous with selecting an AWS managed policy whose name sounds relevant. AWS managed policies serve broad use cases; customer managed policies can narrow grants to your workload.
Use IAM Access Analyzer policy generation from CloudTrail activity as evidence for refinement, then test the resulting policy. Exercise infrequent but required paths as well as the happy path. A policy derived from a period that contained no recovery activity can omit recovery permissions. Policy validation and access review are separate checks; see 3.2.3 for their boundaries.
Key distinctions and trade-offs
Authentication versus authorization: Credentials identify the request’s principal. An applicable permission grant still has to allow its action and resource. Successful role assumption proves neither model access nor permission to retrieve application data.
Trust policy versus permissions policy: Trust governs entry into a role. Permissions govern actions performed using it. Repair the layer that rejected the request rather than widening both policies.
Temporary credentials versus least privilege: Short-lived administrator credentials remain powerful administrator credentials. Expiration reduces the lifetime of exposure; policy scope reduces what an exposed session can do.
AWS permissions versus user entitlements: A backend role authorized to invoke Bedrock is not evidence that a particular employee can access every document the backend can retrieve. Application authorization remains a separate decision; see 2.3.7.
Architecture / decision scenario
An engineering team deploys a support assistant into a workload account. Its deployment identity assumes a deployment role through sts:AssumeRole; the target trust policy admits that identity. The application’s runtime role has permission to invoke its approved Bedrock resource, without permission to edit the deployment role or IAM policies.
AWS supplies temporary runtime credentials through the compute environment, and the SDK uses the complete credential set. For a nonstreaming InvokeModel call, the required action is bedrock:InvokeModel. If the product adds streaming, the team reviews bedrock:InvokeModelWithResponseStream explicitly instead of granting all Bedrock actions.
The team tests the trusted deployment path, an untrusted caller, an approved model invocation, and a disallowed resource. When a request fails, it identifies the calling session and applicable denies before changing a policy. Access Analyzer activity helps narrow grants, while application checks independently determine which support records each end user may access.
Common exam traps
- Treating a role’s trust policy as permission to invoke a model.
- Assuming temporary credentials automatically enforce least privilege.
- Expecting an additional allow to override an explicit deny.
- Treating a permissions boundary or SCP as a permission grant.
- Supplying two credential fields while omitting
SessionToken. - Giving the runtime the deployer’s permissions to resolve an access failure.
What to remember
Trace the principal, role assumption, credential lifetime, action, resource, and applicable policies separately. Trust lets a caller enter a role; permission policies authorize its requests. Temporary credentials and least privilege solve different problems, and both belong in a production workload.
Knowledge check
A caller in another account assumes a workload role successfully, but the next bedrock:InvokeModel request made with the role session is denied. Which policy should the team inspect first?
sts:AssumeRolests:AssumeRole are working, and a trust policy never grants model inference.A workload session uses temporary credentials for an administrator role that expire after one hour. The workload needs to invoke one approved model. Which change reduces what an exposed session could do?
A runtime role has an identity policy allowing bedrock:InvokeModel on a model, but a service control policy in the organization explicitly denies that model. A teammate proposes adding the model to the role’s permissions boundary. What should the team do?
bedrock:InvokeModel to the role’s trust policyA developer copies the AccessKeyId and SecretAccessKey from an AssumeRole response into a client’s configuration, and its requests fail to authenticate. What should the client use?
DurationSeconds valueSessionToken , from a refreshing providerExpiration . A credential provider that obtains replacements handles both, without falling back to long-term IAM user keys.