1. Right Answer: B,C
Explanation:
2. Right Answer: D
Explanation: The AWS(Amazon Web Service) Documentation mentions the series of steps that are followed when EBS uses KMS for Encryption The following explains how Amazon EBS uses your CMK: 1. When you create an encrypted EBS volume, Amazon EBS sends a GenerateDataKeyWithoutPlaintext request to AWS(Amazon Web Service) KMS, specifying the CMK that you chose for EBS volume encryption. 2. AWS(Amazon Web Service) KMS generates a new data key, encrypts it under the specified CMK, and then sends the encrypted data key to Amazon EBS to store with the volume metadata. 3. When you attach the encrypted volume to an EC2 instance, Amazon EC2 sends the encrypted data key to AWS(Amazon Web Service) KMS with a Decryptrequest. 4. AWS(Amazon Web Service) KMS decrypts the encrypted data key and then sends the decrypted (plaintext) data key to Amazon EC2. 5. Amazon EC2 uses the plaintext data key in hypervisor memory to encrypt disk I/O to the EBS volume. The data key persists in memory as long as the EBS volume is attached to the EC2 instance. Option A is invalid because you cannot attach customer master keys after the volume is encrypted https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html
3. Right Answer: A
Explanation: The AWS(Amazon Web Service) Documentation mentions the following You can optionally secure the content in your Amazon S3 bucket so users can access it through CloudFront but cannot access it directly by using Amazon S3 URLs. This prevents anyone from bypassing CloudFront and using the Amazon S3 URL to get content that you want to restrict access to. This step isn't required to use signed URLs, but we recommend it. To require that users access your content through CloudFront URLs, you perform the following tasks: Create a special CloudFront user called an origin access identity. Give the origin access identity permission to read the objects in your bucket. Remove permission for anyone else to use Amazon S3 URLs to read the objects. Option B,C and D are all automatically invalid , because the right way is to ensure to create Origin Access Identity (OAI) for CloudFront and grant access accordingly. For more information on serving private content via Cloudfront, please visit the following url https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html
4. Right Answer: A
Explanation:
5. Right Answer: A
Explanation: The AWS(Amazon Web Service) Documentation gives an example on such a case Inline policies are useful if you want to maintain a strict one-to-one relationship between a policy and the principal entity that it's applied to. For example, you want to be sure that the permissions in a policy are not inadvertently assigned to a principal entity other than the one they're intended for. When you use an inline policy, the permissions in the policy cannot be inadvertently attached to the wrong principal entity. In addition, when you use the AWS(Amazon Web Service) Management Console to delete that principal entity, the policies embedded in the principal entity are deleted as well. That's because they are part of the principal entity. Option A is invalid because AWS(Amazon Web Service) Managed Polices are ok for a group of users , but for individual users , inline policies are better. Option C and D are invalid because they are specifically meant for access to S3 buckets For more information on policies, please visit the following url https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html
Leave a comment