LEARN. PRACTICE. GROW.1. Map the path before investigating
Imagine a fund-reconciliation application whose support team enters through an IdP, assumes a diagnostic role, and then a role in a recovery account. Map each hop: presented credential, STS operation, target trust policy, and resource action. A failure at the second hop requires a different investigation from a GetObject failure after obtaining the session. GetCallerIdentity helps establish which principal the process actually uses, including cases where the shell profile differs from the service profile. Success on that call does not establish authorization for the business operation. Also record account, Region, time, and request identifier. Use fictional data in the exercise and protect real identifiers at work.
2. Persistent origin and controlled attribution
SourceIdentity can retain origin through role chaining, but evidence quality starts where its value is set. Text any operator can choose does not prove authorship. Decide which controlled IdP attribute supplies origin and who may change that mapping. For cross-account chaining, check SetSourceIdentity permission on the caller and in target trust. Do not confuse that control with session naming. Also avoid promising that every subsequent AWS service action will carry the attribute: actions on the user’s behalf through services and service-linked roles have documented limitations. During an incident, correlate events and explicitly retain any relationships that remain unproven.
3. Session attributes and validity
A session tag used by ABAC is a security input. If the caller may choose Department=Finance, a static Operations tag on the role is insufficient protection against that override. Restrict TagSession and authorized values and keys. When Project must accompany a chain, configure its key as transitive; the initial tag’s existence alone does not guarantee transport. Perform a positive check and another with a prohibited value. If a batch takes two hours, do not assume MaxSessionDuration=12h solves an STS chain: that path has a one-hour limit. Plan authorized renewal, expiration handling, and safe work retries without storing permanent credentials as a shortcut.
4. Permission sets and account differences
Identity Center can provision a permission set’s inline policy. A customer managed policy reference requires the policy to exist in the account with the matching name and path. This creates an operational task: distribute and control the local document. In a four-account rollout, three documents might permit reads only while the fourth includes writes. The same name does not establish equivalence. Before handover, compare approved versions, inspect other applicable policies, and exercise representative allowed and prohibited actions. Keep an owner for distribution and a way to detect drift. Acceptance should state which accounts were observed and which exceptions remain open, rather than using a login screenshot as global proof.
5. Pipeline and external workload identities
For GitHub OIDC, trust should delimit audience and subject. In the standard branch flow, subject identifies organization, repository, and reference; using an environment changes the format and required protection. Apply that environment’s protection rules to limit permitted deployments. For an external workload using Roles Anywhere, a trusted CA alone does not distinguish all consumers of that CA. Evaluate approved certificate attributes such as subject or SAN and certificate-issuance governance. On this path, aws:SourceArn refers to the trust anchor specified in CreateSession. Do not replace it with the ARN of the resource the application wants to query later. Resource authorization remains a separate decision.
6. Guided exercise and RUN handover
The Python model below compares a policy reference with a fictional inventory and flags a missing or divergent approved document. It does not evaluate IAM: matching hashes for one document do not include SCPs, resource policies, or session context. Predict the result before running it: pilot should be ready, recovery should be drift, and new should be missing. Then change recovery to the approved hash and repeat. Explain why that resolves only document comparison. At work, combine the result with an access matrix, behavioral test evidence, escalation contacts, and credential-renewal procedures. The committee summary should distinguish access preparation, access validation, and attribution limitations.
# Local document-inventory exercise; not an IAM evaluator.
# No credentials, network calls, or AWS mutations.
reference = ("/support/", "APSRead")
approved = "reviewed-document-v3"
accounts = {
"pilot": {reference: approved},
"recovery": {reference: "local-write-variant"},
"new": {},
}
def compare(inventory):
actual = inventory.get(reference)
if actual is None:
return "missing"
return "ready" if actual == approved else "drift"
result = {name: compare(policies) for name, policies in accounts.items}
assert result == {"pilot": "ready", "recovery": "drift", "new": "missing"}
print(result)
One account receives APSRead with writes because of local drift. Handover remains conditional until allowed reads and denied writes are demonstrated.
Common pitfalls
Persistence as authenticity; name as document; static tag as boundary; STS success as resource authorization.
Related topics: Policies, tags, and access analysis · Response and evidence preservation
Confirm origin, trust, attributes, and effective action; close handover with evidence in each account.
Reference: Monitor and control actions taken with assumed roles · SCS-C03