Exam AWS Certified Solutions Architect - Professional topic 1 question 815 discussion

I support B

Answer seems to be B. Rather than creating table for each tenant, its better to use partition key in the already available table. This can be achieved with the LEAST operational.

https://aws.amazon.com/blogs/security/how-to-secure-your-saas-tenant-data-in-dynamodb-with-abac-and-client-side-encryption/

answer seems B Following the context above, the tenant id would be created when the user is created "The company will have hundreds of customers within the first year." <- If the answer is A, it would make Table hundreds a year. (operational)

Looks like its Option A: One solution that meets these requirements with the least operational overhead would be to use DynamoDB table partitioning (also known as sharding) to create separate partitions for each tenant. Each partition would have a unique primary key that includes the tenant ID, and all requests for a particular tenant would be directed to the corresponding partition. This would provide stronger isolation between tenants, as each tenant's data would be physically separated in the DynamoDB table. Additionally, by using a custom authorizer in the API Gateway, the Lambda function could easily extract the tenant ID from the JWT token and use it to determine which partition to access in the DynamoDB table. This solution would not require any significant changes to the existing architecture, and would scale easily as the number of tenants increases.

B is correct: https://aws.amazon.com/blogs/apn/multi-tenant-storage-with-amazon-dynamodb/

This Question is very confuse. Maybe is error from admin. "LEAST operational overhead" => if A, seperate by tablename, in the future when need to add more tenant you need create more table, with B you dont need do anymore "a stronger isolation between tenants" i think, for this stituation mean of question: find a soluiton that stronger isolation than current solution, not mean find the best soluiton for isolation.

Partition key is not for isolation. I support A

A. reason "To comply with security standards, the company needs a stronger isolation between tenants." https://aws.amazon.com/blogs/apn/multi-tenant-storage-with-amazon-dynamodb/ 1. Separate database – each tenant has a fully isolated database with its own representation of the data.... best ISOLATION but the question is about multi-tent. 2. Shared database, separate schema (Table Name Partitioning) – tenants all reside in the same database, but each tenant can have its own representation of the data. STRONGEST ISOLATION FOR MULTI-TENANT. but requires more operational than partition. 3. Shared everything (Index Partitioning)– tenants all reside in the same database and all leverage a universal representation of the data....EASIEST TO MANAGE BUT NOT LESS ISOLATION, prone to nosy neighbors.

B. The choice is augmenting partition key with tenant id vs Silo keys in multiple tables (increased overhead) https://aws.amazon.com/blogs/apn/partitioning-pooled-multi-tenant-saas-data-with-amazon-dynamodb/

for those selecting B/D, you cant update the partition key and sort key in an existing table

Qns deals with the implementation of custom permission policies. The details of each policy should be stored in a central table with the client id as the partition key for quick retrival andthe subsequent creation of the custom policy. Much less operational overhead and also side benefit, better for backups

Creating seperate accounts, different tables for tenants has more operational overhead. Partionkey based approach is the right way - Option B.