Exam AWS Certified Developer - Associate DVA-C02 topic 1 question 1 discussion

The correct answer is C. https://aws.amazon.com/premiumsupport/knowledge-center/secrets-manager-share-between-accounts/ https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples_cross.html Option A is wrong. It seems to be a good solution. However, AWS managed keys cannot be used for cross account accessing.

For cross-account access, the AWS managed key (Option A) will be difficult to manage because it doesn't allow you to directly manage cross-account access. Therefore, Option C (AWS Secrets Manager with a customer-managed KMS key) is the recommended solution for cross-account access and security.

keywords: LEAST management overhead ==> Discard B, D: you must do many steps to config with Storage, DB with KMS, IAM Role ==> Discard A: Pretty correct, but in use, you may write some script. It can work but requires additional configuration and doesn't offer some of the benefits tailored for secrets management like automatic rotation. D: The solution with AWS Secrets Manager (option C) provides the least management overhead because: Secrets Manager is specifically designed for storing and managing sensitive information like access tokens. It natively integrates with AWS KMS for encryption and decryption. It simplifies access control and auditing. By adding a resource-based policy, cross-account access is easily managed without the need for additional configurations like DynamoDB tables or S3 bucket policies.

Use an AWS Systems Manager Parameter Store SecureString parameter that uses an AWS Key Management Service (AWS KMS) AWS managed key to store the access token. This option allows you to securely store the access token in the Parameter Store, which automatically encrypts the data at rest and in transit. By adding a resource-based policy, you can also grant access to the access token from other AWS accounts. The IAM role of the EC2 instances can be updated to allow permissions to access the Parameter Store, and the access token can be retrieved with the decrypt flag enabled for use in sending the chat message. This option requires minimal setup and management compared to the other choices.

By default, AWS Systems Manager Parameter Store does not natively support cross-account access for SecureString parameters. However, you can configure cross-account access to SecureString parameters by sharing the KMS key with the target AWS accounts. To do this, you need to create a resource-based KMS key policy that allows access to the key by the external AWS account(s). After configuring the KMS key policy to allow the necessary cross-account access, you can grant IAM roles in the target accounts permission to access the SecureString parameters that are encrypted using that KMS key.

AWS Secrets Manager (Option C) is designed for exactly this kind of use case, providing built-in functionality for secure storage and retrieval of secrets with minimal management overhead, especially for managing access tokens and cross-account access. Amazon S3 with KMS (Option D), while familiar and powerful, requires more manual work to set up and manage the security aspects, which can lead to increased overhead in comparison to Secrets Manager. Given that the goal is to have the least management overhead, Option C is the best fit because it is purpose-built for managing secrets and automates much of the complexity involved in secure storage and retrieval.

https://docs.aws.amazon.com/secretsmanager/latest/userguide/data-protection.html https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_resource-policies.html https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html

C is the correct answer as the Secrets Manager supports resource-based policies, allowing you to grant access to other AWS accounts easily.

C is correct answer.

C is the correct answer.

This is the correct answer for lease overhead to manage the secret key

It is C

- Option A involves using AWS Systems Manager Parameter Store, which can work but requires additional configuration and doesn't offer some of the benefits tailored for secrets management like automatic rotation. - Option B involves storing the access token in DynamoDB, which is not specifically designed for secrets management, and managing encryption and decryption manually using AWS KMS. - Option D involves using S3, which again is not designed for secrets management, and adds complexity in managing access policies and permissions. Additionally, accessing the token would involve reading from S3, decrypting it, and then using it, which is less straightforward compared to using a service like Secrets Manager.

I think this would be A as this is cheaper than C. Any reason why A can not be the answer?

The answer would be C if an AWS-managed key was used, as Secrets Manager and KMS are good for situations like this. However, the use of a customer-managed key increases management overhead. So the best answer is D, not C.

You cannot use a resource-based policy with a parameter in the Parameter Store. The stephen answser Option C is correct Practise paper3

customer managed key , its an extra work. So I am confused with option A and C