You create the Todo.io database

Follow an admin request through Identity Center, a role, an SCP, IAM, a service-linked role and CloudTrail.

Text version of this diagram.

What sits where:

AWS Organization · Todo.io: A group of AWS accounts with one owner (the management account) and one combined bill. contains:
- Management account · 111111111111: The account that owns the organization and pays the bill. Keep apps out of it. The 12-digit number is its account ID. contains:
  - IAM Identity Center (everyday sign-in): Where people sign in to AWS every day: one login with MFA, then you pick an account and get a role in it.
  - AWS Organizations (accounts + SCPs): Groups many AWS accounts under one owner and one bill. SCPs (service control policies) are rules that cap what those accounts are allowed to do.
  - CloudTrail (organization trail): AWS's activity log: who did what, when and from where. An organization trail records every account in one place.
  - S3 bucket (todoio-org-trail): A named container for files in Amazon S3, AWS's file storage. This one holds the audit trail's log files.
- Prod account · 222222222222: Production: the AWS account where the real Todo.io runs for real users. The 12-digit number is its account ID. contains:
  - us-east-1 · N. Virginia: A Region is a part of the world where AWS has data centers. Most things you build live in one Region. us-east-1 is in northern Virginia. contains:
    - RDS (CreateDBInstance): Relational Database Service: AWS runs a database (MySQL, PostgreSQL…) for you, so there's no server to look after. CreateDBInstance is the request that asks for a new one.
    - Todo.io stack (VPC, app, database (tab 2)): Everything that runs Todo.io: its private network (VPC), the app and the database. The Design Todo.io tab walks through it.
  - Admin role (AdministratorAccess): A role is a set of permissions you step into for a while, with temporary keys. AdministratorAccess is AWS's ready-made policy that allows everything.
  - Service-linked role (AWSServiceRoleForRDS): A role that belongs to an AWS service, so the service can work in your account. RDS uses this one to manage the database and its network cards.
- Dev account · 333333333333: Development: a separate AWS account for experiments, so a mistake there can't touch Prod. contains:
  - Same setup (for trying things safely): Dev gets the same pieces as Prod, so you can try changes without risking the real app.
You (Ryan) (laptop + browser)

Steps, in order:

Sign in. Path: You (Ryan) → IAM Identity Center. You open Todo.io's IAM Identity Center access portal and sign in as ryan with a password and MFA. Not as root. Checks: setting: MFA code accepted → allow.
Step into Prod. Path: IAM Identity Center → Admin role. You pick the Prod account. Identity Center gives you temporary credentials for an IAM role there, built from the AdministratorAccess permission set. Checks: iam: ryan is assigned AdministratorAccess in Prod → allow.
Ask for a database. Path: Admin role → RDS. In the console, in us-east-1, you click Create database. The console turns that click into an API call: rds:CreateDBInstance.
Guardrail check. Path: RDS → AWS Organizations. Before RDS does anything, IAM makes one allow-or-deny decision that reads every policy that applies. The arrows show what it reads, not network calls. First, the organization's SCPs. The request is in us-east-1, so the Region guardrail doesn't block it. Checks: scp: OnlyUsEast1: us-east-1 is allowed → allow.
Permission check. Path: RDS → Admin role. In the same decision, IAM reads your role's policy. AdministratorAccess allows rds:CreateDBInstance. Checks: iam: AWSReservedSSO_AdministratorAccess_7a1b2c3d: rds:CreateDBInstance → allow.
RDS uses its own role. Path: RDS → Service-linked role. To place network cards in your VPC and watch the instance, RDS acts through a service-linked role it created the first time you used it.
The database exists. Path: RDS → Todo.io stack. todoio-db is built in us-east-1 and becomes part of the Todo.io stack you designed in tab 2.
It's on the record. Path: RDS → CloudTrail → S3 bucket. CloudTrail records who asked, when, from where, in which account and Region. The organization trail delivers it to the bucket, usually within about 5 minutes.

Step 1 of 8

You open Todo.io's IAM Identity Center access portal and sign in as ryan with a password and MFA. Not as root.
- ⚙Setting MFA code acceptedAllowed
You pick the Prod account. Identity Center gives you temporary credentials for an IAM role there, built from the AdministratorAccess permission set.
- 🔑IAM ryan is assigned AdministratorAccess in ProdAllowed
Show me the real thing
Who AWS thinks you are now
```
arn:aws:sts::222222222222:assumed-role/AWSReservedSSO_AdministratorAccess_7a1b2c3d/ryan
```
Exam tipBehind the scenes this is sts:AssumeRole. People never get long-lived keys; they borrow a role for a few hours.
In the console, in us-east-1, you click Create database. The console turns that click into an API call: rds:CreateDBInstance.
Show me the real thing
The API call the console makes (trimmed)
```
{
  "Action": "CreateDBInstance",
  "DBInstanceIdentifier": "todoio-db",
  "Engine": "mysql",
  "DBInstanceClass": "db.t4g.micro",
  "Region": "us-east-1"
}
```
Exam tipConsole, CLI and SDK all end up as the same signed API call. That is why CloudTrail can record all of them.
Before RDS does anything, IAM makes one allow-or-deny decision that reads every policy that applies. The arrows show what it reads, not network calls. First, the organization's SCPs. The request is in us-east-1, so the Region guardrail doesn't block it.
- 🧱SCP OnlyUsEast1: us-east-1 is allowedAllowed
In the same decision, IAM reads your role's policy. AdministratorAccess allows rds:CreateDBInstance.
- 🔑IAM AWSReservedSSO_AdministratorAccess_7a1b2c3d: rds:CreateDBInstanceAllowed
Exam tipIf you hand the database a role (say, for Enhanced Monitoring), you also need iam:PassRole on that role. PassRole stops people giving a service more power than they have themselves.
To place network cards in your VPC and watch the instance, RDS acts through a service-linked role it created the first time you used it.
Show me the real thing
The role, in Prod
```
arn:aws:iam::222222222222:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS
```
Exam tipA service-linked role is defined and owned by the service. You can't edit its permissions, and you can only delete it once the service no longer needs it.
todoio-db is built in us-east-1 and becomes part of the Todo.io stack you designed in tab 2.

CloudTrail records who asked, when, from where, in which account and Region. The organization trail delivers it to the bucket, usually within about 5 minutes.

Show me the real thing

The CloudTrail event (trimmed)

{
  "eventTime": "2026-10-11T18:40:12Z",
  "eventSource": "rds.amazonaws.com",
  "eventName": "CreateDBInstance",
  "awsRegion": "us-east-1",
  "recipientAccountId": "222222222222",
  "userIdentity": {
    "type": "AssumedRole",
    "arn": "arn:aws:sts::222222222222:assumed-role/AWSReservedSSO_AdministratorAccess_7a1b2c3d/ryan"
  },
  "sourceIPAddress": "203.0.113.24"
}

Exam tipCloudTrail records control-plane calls like CreateDBInstance. It never sees the SQL inside the database.

What to notice

Every console click is an API call, and every API call is checked and recorded.
Two separate gates had to say yes: the SCP (the most the account may do) and IAM (what your role may do).
RDS acted with its own service-linked role, not with yours.
CloudTrail saw the CreateDBInstance call. It will never see the SQL you later send to the database.