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

Is it 'D' because it mentions about 'AssumeRole' function with STS Service and not 'E' because tho' it also uses STS service it does not explicitly mention the 'AssumeRole' function. Except for that , i feel even DynamoDB can the scenario better.

I would go with DynamoDB. I don't think "AssumeRole" statement is important as for STS this is almost the only function. Also it say use STS to generate the credential. My point is RDS vs DynamoDB For this App, it's read heavy. From scaling out perspective DynamoDB is better.

D is the correct one

E. Record the user's information in Amazon DynamoDB. When the user uses their mobile app, create temporary credentials using AWS Security Token Service with appropriate permissions. Store these credentials in the mobile app's memory and use them to access Amazon S3. Generate new credentials the next time the user runs the mobile app.

D. Record the user's information in Amazon RDS...create temporary credentials using the AWS Security Token Service "AssumeRole" function... This approach is more secure as it uses temporary credentials provided by STS. However, using RDS just to store user information might be overkill for this use case. E. Record the user's information in Amazon DynamoDB...create temporary credentials using AWS Security Token Service... This approach is similar to option D but uses DynamoDB, which is a more scalable and cost-effective solution for storing user information compared to RDS. It also uses temporary credentials provided by STS, which is the recommended approach for mobile apps. Given the options, the best and most secure approach for handling potentially millions of users in a photo-sharing mobile app is

The answer is E according to me. Longterm credentials are a strict NO fron a security standpoint. Also, the application needs to scale for a large user base. This makes Dynamo DB a more suitable option

keywords = Amazon DynamoDB && AWS STS Then D

In this case, option D would be the better option. This is because it uses temporary credentials generated by the AWS Security Token Service's AssumeRole function, which are short-lived and rotated frequently. This reduces the risk of credential theft or misuse, which is important in a large-scale application with potentially millions of users. Additionally, by recording user information in Amazon RDS, it provides a centralized and secure way to manage user information and access control.

The correct answer is defiantly E. here is why A,B and C are wrong for all the reasons mentioned in other comments As for D and E. AIM users are not designed for application users, and you will not create them for each user... It is mostly used for console/cli users and backend applications. this is also supported by AWS documentation: For temp creds The AWS STS API operations create a new session with temporary security credentials that include an access key pair and a session token. The access key pair consists of an access key ID and a secret key. Users (or an application that the user runs) can use these credentials to access your resources. You can create a role session and pass session policies and session tags programmatically using AWS STS API operations for assuming role: The AssumeRole API operation is useful for allowing existing IAM users to access AWS resources that they don't already have access to. For example, the user might need access to resources in another AWS account. As you can see, there is a difference in narrative and intent

D is definitely WRONG and deceptive, Why? - The Question asked under condition of 'when a new user registers ' , and what your app will do, only the first sentence will answer to this. You WILL NOT create an IAM role on the basis of your end user. Same reason, You will not create an IAM user on the basis of end user , this rules out A, B ; Long term credential is not the most secure way, rules out C.

D is definitely WRONG and deceptive, The Question asked under condition of 'when a new user registers ' , You WILL NOT create an IAM user on the basis of your end user. It takes cover under assume role. Well done, AWS.

I wuld go with D as that is the only one that makes it clear that the Assume Role would be used

There is a limit to the number of IAM roles (yes this can be raised via support tickets a couple of times). The question is stating millions of users. You do not want to have millions of IAM roles, although this would be the most secure way to make sure a user will not access different files in this single S3 bucket.

I would go for E. User information is better to be stored in DynamoDB plus its high performance in read/write than RDS

Why not D: “ Record the user's information in Amazon RDS AND create a role in IAM with appropriate permissions” So for every new user an IAM role is created?! That going to be a hole lot of roles. Better to create one role and let it be assumed (temp credentials) by every user as needed.

E. DynamoDB, simpler than RDS, and Cognito, with IAM role through STS to get temporary credentials.

I go for D IAM role + AssumeRole make perfect sense here Only 1 IAM role could used for all users with a variable https://youtu.be/-1gkwLBfBCo Finally RDS is perfectly fine with millions of records, isn’t it..?