Stateless and multi-tenant SaaS architectures: SAP-C03 study notes and practice questions
What to know about Stateless and multi-tenant SaaS architectures for the SAP-C03 exam, from the Architecture Design and Implementation Built for the Cloud domain (25% of the exam guide), then 1 free question to test it. Part of the SAP-C03 study guide.
SAP-C03 asks how to make an application horizontally scalable by moving state out of instances, and how a SaaS provider keeps tenants isolated while controlling cost and noisy neighbors.
Stateless with externalized state
Sessions: ElastiCache (Valkey or Redis OSS) or DynamoDB with TTL, not instance memory or sticky sessions.
Files and uploads: S3 (presigned URLs let clients upload directly), not local disks.
Application state and idempotency records: DynamoDB.
Any instance or task can then serve any request, so Auto Scaling, Spot and rolling deployments become safe.
Isolation models
Model
How
Trade-offs
Silo
Dedicated resources per tenant (account, VPC, stack or database)
Strongest isolation and simple per-tenant cost, but highest cost and operational load
Pool
Shared resources, rows tagged with tenant ID
Cheapest and easiest to scale, but isolation must be enforced in code and policy; noisy-neighbor risk
Bridge (mixed)
Shared compute, siloed data, or premium tenants siloed and others pooled
Tiered offerings
Carrying tenant context
Store the tenant ID as a custom attribute in Amazon Cognito and add it to tokens; a pre token generation Lambda trigger can enrich claims.
Services read the tenant ID from the validated JWT, never from a request parameter the client controls.
API Gateway usage plans per tenant tier throttle noisy neighbors.
Enforcing isolation in a pool
Tenant-scoped IAM: assume a role with a session tag for the tenant and policies using ${aws:PrincipalTag/TenantId}, for example a DynamoDB dynamodb:LeadingKeys condition so a request can touch only items whose partition key is its tenant, or an S3 prefix per tenant.
Row-level security in Aurora PostgreSQL or RDS for PostgreSQL: a policy compares each row’s tenant column to a session variable set per connection.
Lake Formation row and cell filters for shared analytics.
Tenant-specific encryption: a KMS key per tenant (or per tier) lets a tenant’s data be crypto-shredded or audited separately; use encryption context with the tenant ID.
A news publisher runs a white-label publishing platform for regional newspapers. Most tenants are small and share one platform stack, but two large regional groups are regulated and need their article data in their own AWS account, encrypted with a customer managed KMS key that only they control.
The platform team wants small tenants to share one DynamoDB table, and no tenant may read another tenant's items, even if an application bug builds the wrong query. Onboarding a small tenant should not need new infrastructure.
Which TWO changes meet these requirements? (Choose two.)
Choose two answers.
AA. Use one shared DynamoDB table keyed by tenant ID, and give each tenant's Lambda functions an IAM policy with a dynamodb:LeadingKeys condition that limits access to that tenant's items.
BB. Use one shared DynamoDB table and one IAM role for all tenants' functions, and have the application code add the tenant ID as a filter to every query it builds.
CC. Encrypt all tenants' data with one shared customer managed KMS key that the platform account controls, and rotate that key every year.
DD. Create one DynamoDB table for every tenant, small or large, and attach a separate customer managed KMS key to each table.
EE. Deploy a separate stack for each of the two regulated groups in its own account, with its own DynamoDB table and a customer managed KMS key that the group's own key policy controls.
Show the answer and explanation
Answers: A, E
A. Right: Correct. The LeadingKeys condition makes IAM enforce the tenant boundary on every request, so a query built with the wrong tenant ID is denied. Small tenants keep sharing the table, and onboarding only adds a key value.
B. Wrong: The tenant boundary then depends on application code being correct. A query that omits the tenant filter would return other tenants' items, which breaks the isolation requirement.
C. Wrong: Rotation does not change who holds the key. The two regulated groups need keys they control, and a shared key in the platform account does not meet that requirement.
D. Wrong: This isolates each tenant, but it adds an infrastructure step for every small tenant at onboarding. The requirement is that small tenants share one table, so this option contradicts it.
E. Right: Correct. A separate account and key for each regulated group gives silo isolation and keeps the group's key under its own control. This is the right answer for the two large tenants only, so it is paired with a shared design for the small ones.
Explanation
Sharing one table is acceptable only when IAM enforces the tenant boundary, which the LeadingKeys condition does. The two regulated groups need silo accounts with their own keys. Shared code-based filtering and one shared key each fail a stated requirement.
Want more on Stateless and multi-tenant SaaS architectures? The 5 full-length practice sets have 6 more Stateless and multi-tenant SaaS architectures questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Stateless and multi-tenant SaaS architectures