An agent is only as trustworthy as the identity that acts for it, and only as useful as the data it can reach. AWS just added two free, hands-on microcredentials that test those two foundations in a live account: AWS Securing Agent Identities Demonstrated and AWS Databases for Agentic AI Demonstrated.
They sit in the same family as the existing Demonstrated labs on Skill Builder. You get a timed scenario, a real AWS environment, and tasks you have to finish. There are no multiple-choice questions. Pass, and you earn a Credly badge you can put on your Skills Profile, LinkedIn, or a resume. Access is free. A Skill Builder subscription is not required.
AWS announced both on September 29, 2026. The interesting part is what they chose to test.
Why these two, and not another model exam
Most agent write-ups stop at the prompt and the tool call. Production work starts after that.
The agent needs an identity of its own. A shared IAM user, a long-lived access key checked into a repo, or a token that can call every API in the account will work in a demo and fail an audit. Self-hosted agents, inbound callers, and AWS APIs do not authenticate the same way. Someone has to decide which caller gets SigV4 and which gets a scoped JWT, then prove later who minted which token.
The agent also needs a data layer that matches how it behaves. Short-term memory, durable state, and document retrieval are different jobs. Aurora PostgreSQL with pgvector, a Bedrock Knowledge Base, and DynamoDB can all be "the database" in a diagram. In a running system they answer different questions, and a bad query or a leaked secret shows up as a confused agent, a slow agent, or an agent that should not have seen that row.
These labs are aimed at that gap. A certification still proves breadth across a domain. A microcredential proves you can repair a specific system while the clock is running. AWS's general microcredential rules keep the badge valid for 12 months, open renewal nine months after you pass, and impose a 25-day wait after a failed attempt. The security lab is listed as intermediate and runs about 135 minutes. Plan an uninterrupted block either way.
Securing agent identities
AWS Securing Agent Identities Demonstrated is for people who already secure workloads and now have agents in the account. Cloud security engineers and solutions architects are the audience AWS names.
The scenario is a fleet of Amazon Bedrock AgentCore agents with identity gaps. The work, at the level AWS describes it, is:
- Provision workload identities for self-hosted agents, so an agent running outside the managed path still has a credential you can scope and revoke.
- Restrict who can manage those identities with tag-based access control, so identity administration itself is not a wide-open IAM permission.
- Lock inbound access down to scoped JWT authorization.
- Pick the authentication method per caller. SigV4 fits AWS-native callers that already have IAM credentials. JWT fits callers that present a token from an identity provider. Using one for every path is how agents end up over-privileged.
- Move agents onto production-grade JWT verification.
- Leave an audit trail for token operations.
The services in play are AgentCore, Amazon Cognito, IAM, CloudTrail, CloudWatch, and Systems Manager. That mix is the point. Identity for agents is not an IAM policy in isolation. Cognito issues and validates tokens, IAM still decides what those identities can touch, Systems Manager shows up when you have to reach or configure the workload without opening a back door, and CloudTrail plus CloudWatch are how you notice a token being minted, assumed, or denied.
If you have spent time on Session Manager instead of SSH keys, the instinct is the same: prefer a managed identity path, log every session, and avoid a credential you cannot rotate. Agents just multiply the number of non-human callers.
Earners of the badge have remediated those gaps in the lab. The public criteria live on the Credly badge.
Databases for agentic AI
AWS Databases for Agentic AI Demonstrated is the other half. Database engineers, database solutions engineers, solutions architects, and AI/ML engineers who own the data path are the audience.
The tasks AWS lists are practical, and they map cleanly onto how an agent actually stores and reads state:
- Configure Amazon Aurora PostgreSQL and Amazon DynamoDB for agent access and memory. Relational state and key-value memory fail in different ways. Aurora is where you want transactions, joins, and a schema the agent must respect. DynamoDB is where session memory and high-churn agent state usually belong.
- Set up
pgvectorand Amazon Bedrock Knowledge Bases so the agent can retrieve documents. Keyword search over a blob column is not retrieval. The embedding, the index, and the knowledge base configuration decide whether the agent quotes the right passage. - Stand up MCP servers so you can see what the agent is doing to the database. Model Context Protocol is the debug surface here: which tool ran, which query it sent, and where it stalled.
- Tune the queries the agent issues. An agent that "works" can still table-scan Aurora on every turn. CloudWatch is how you see that. AWS Secrets Manager is how the agent gets a database credential without a password in the prompt or the function env in plain text. Lambda sits in the middle when a tool needs a small, controlled function between the agent and the store.
If you have already moved a workload from RDS to Aurora, you know the database choice changes failover, cost, and how the application connects. An agent adds a second client that writes its own SQL, holds its own memory, and must not see another tenant's rows. That is the system this lab is built around.
Which one to take
Take the identity lab if your job is deciding who an agent is allowed to be. Take the database lab if your job is deciding what an agent is allowed to remember and retrieve. Take both if you own the platform other teams build agents on. They share almost no services, and that is useful: identity work and data-layer work are often split across teams, and both teams can show a badge for their half.
They also sit next to the broader AWS Agentic AI Demonstrated microcredential, plus the existing labs for serverless, incident response, MLOps, streaming, lakehouse, networking, and visualization. The new pair is narrower on purpose. Agentic AI Demonstrated is the wider build. These two are the controls and the stores underneath it.
AWS points the same skills at people preparing for deeper generative AI certifications. The labs are practice in a real account, with a badge at the end, at no charge. They are also a reasonable way to rehearse the kind of timed environment some interviews already use.
How to go in
Read the Skill Builder page for the lab you want before you start the clock. The listing includes the scenario and the recommended preparation. The assessment gives procedural guidance and withholds hints, so the afternoon of the exam is a bad time to learn what a workload identity is or how pgvector is enabled.
A useful prep loop, short of spoiling the tasks:
- Build a tiny AgentCore or Bedrock agent that calls one tool, then give that tool its own IAM role. Break the role on purpose and watch the denial in CloudTrail.
- Issue a Cognito JWT, call something with it, and call the same API with SigV4. Write down which caller each method is for.
- Put one table in Aurora PostgreSQL and one in DynamoDB. Store conversation memory in DynamoDB. Store records the agent must query in Aurora.
- Enable
pgvector, embed a handful of documents, and attach them to a Knowledge Base. Ask a question you know is in the documents and one you know is not. - Put the database password in Secrets Manager and read it from Lambda. Confirm it never lands in the prompt.
Then book a quiet 135 minutes for the security lab, and a similar uninterrupted window for the database lab. You either repair the environment or you do not. That is the whole format, and it is a better signal than another multiple-choice score in the same topic.
Both are on AWS Skill Builder now, free to start: