Correct option:

The user will be denied access because the policy has an explicit deny on it - User will be denied access because any explicit deny overrides the allow.

Policy Evaluation explained: 

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html

Incorrect options:

The IAM user stands in an invalid state, because of conflicting policies - This is an incorrect statement. Access policies can have allow and deny permissions on them and based on policy rules they are evaluated. A user account does not get invalid because of policies.

The user will get access because it has an explicit allow - As discussed above, explicit deny overrides all other permissions and hence the user will be denied access.

The order of the policy matters. If policy 1 is before 2, then the user is denied access. If policy 2 is before 1, then the user is allowed access - If policies that apply to a request include an Allow statement and a Deny statement, the Deny statement trumps the Allow statement. The request is explicitly denied.

Reference:

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html

Correct options:

Store the secret as SecureString in SSM Parameter Store

With AWS Systems Manager Parameter Store, you can create SecureString parameters, which are parameters that have a plaintext parameter name and an encrypted parameter value. Parameter Store uses AWS KMS to encrypt and decrypt the parameter values of Secure String parameters. Also, if you are using customer-managed CMKs, you can use IAM policies and key policies to manage to encrypt and decrypt permissions. To retrieve the decrypted value you only need to do one API call.

https://docs.aws.amazon.com/kms/latest/developerguide/services-parameter-store.html

Audit using CloudTrail

AWS CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your AWS account. With CloudTrail, you can log, continuously monitor, and retain account activity related to actions across your AWS infrastructure. CloudTrail provides an event history of your AWS account activity, including actions taken through the AWS Management Console, AWS SDKs, command-line tools, and other AWS services.

CloudTrail will allow you to see all API calls made to SSM and KMS.

Incorrect options:

Encrypt first with KMS then store in SSM Parameter store - This could work but will require two API calls to get the decrypted value instead of one. So this is not the right option.

Store the secret as PlainText in SSM Parameter Store - Plaintext parameters are not secure and shouldn't be used to store secrets.

Audit using SSM Audit Trail - This is a made-up option and has been added as a distractor.

Reference:

https://docs.aws.amazon.com/kms/latest/developerguide/services-parameter-store.html

Correct option:

Use SSE-KMS to encrypt the user data on S3

AWS Key Management Service (AWS KMS) is a service that combines secure, highly available hardware and software to provide a key management system scaled for the cloud. When you use server-side encryption with AWS KMS (SSE-KMS), you can specify a customer-managed CMK that you have already created.

SSE-KMS provides you with an audit trail that shows when your CMK was used and by whom. Therefore SSE-KMS is the correct solution for this use-case.

Server Side Encryption in S3: 

https://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html

Incorrect options:

Use SSE-S3 to encrypt the user data on S3 - When you use Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3), each object is encrypted with a unique key. However, this option does not provide the ability to audit trail the usage of the encryption keys.

Use SSE-C to encrypt the user data on S3 - With Server-Side Encryption with Customer-Provided Keys (SSE-C), you manage the encryption keys and Amazon S3 manages the encryption, as it writes to disks, and decryption when you access your objects. However, this option does not provide the ability to audit trail the usage of the encryption keys.

Use client-side encryption with client provided keys and then upload the encrypted user data to S3 - Using client-side encryption is ruled out as the startup does not want to provide the encryption keys.

References:

https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingKMSEncryption.html

https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingClientSideEncryption.html

https://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html

Correct option:

A security group or network ACL is not allowing traffic from the client

If the load balancer is not responding to client requests, check for the following issues:

1.Your internet-facing load balancer may be attached to a private subnet - You must specify public subnets for your load balancer. A public subnet has a route to the Internet Gateway for your virtual private cloud (VPC).

2.A security group or network ACL does not allow traffic - The security group for the load balancer and any network ACLs for the load balancer subnets must allow inbound traffic from the clients and outbound traffic to the clients on the listener ports.

Incorrect options:

It is an internal server error - HTTP 500 is the error code for internal server error, generated by Load Balancer and sent back to the requesting client. But, in the given use case, the client is unable to connect to the Load Balancer itself.

The target returned the error code of 200 indicating an error on the server side - By default, the success code is 200. So, returning an HTTP 200 indicates a successful message.

The target was incorrectly configured as a Lambda function and not an EC2 instance - An ELB can be configured to have a Lambda Function as its target. This should not result in any access issues or errors.

Reference:

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html

Correct option:

Host the application servers in the public subnet of the VPC and database in the private subnet. The public subnet will connect to the internet using an Internet Gateway configured with the VPC. Database in the private subnet will use Network Address Translation (NAT) gateway, present in the public subnet, to connect to internet

For a multi-tier website, with the application servers in a public subnet and the database servers in a private subnet, you can set up security and routing so that the application servers can communicate with the database servers.

The instances in the public subnet can send outbound traffic directly to the Internet, whereas the instances in the private subnet can't. Instead, the instances in the private subnet can access the Internet by using a network address translation (NAT) gateway that resides in the public subnet. The database servers can connect to the Internet for software updates using the NAT gateway, but the Internet cannot establish connections to the database servers.

Diagramatic representation of the above solution: 

https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html

Incorrect options:

Host the application servers in the public subnet and database in the private subnet of the VPC. Configure Network Address Translation (NAT) gateway to provide access to the internet for both the subnets. The route table of both the subnets will have an entry to NAT gateway - NAT gateway is needed for instances in the private subnet to connect to the internet. NAT gateway is not used in public subnets, that have access to Internet Gateway.

Host the application servers in the public subnet and database in the private subnet of the VPC. The public subnet will connect to the internet using an Internet Gateway configured with the VPC. Use VPC-peering between the private and public subnets to open internet access for the database in private subnet - A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IPv4 addresses or IPv6 addresses. It is a communication channel between VPCs, not between subnets of a VPC.

Host the application servers in the public subnet and database in the private subnet of the VPC. The public subnet will connect to the internet using an Internet Gateway configured with the VPC. The private subnet can connect to the internet if they are configured using IPv6 protocol - IPv6, like IPV4 is an internet protocol, used for communication over the internet. IPV6 does not provide internet access, if your instances use IPV6 for communication, you need to configure egress-only Internet gateway to connect to the internet.

Reference:

https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html

Correct option:

For MySQL-compatible DB clusters, you can enable the slow query log, general log, or audit logs to get a view of the database activity

By design, Aurora Serverless connects to a proxy fleet of DB instances that scales automatically. Because there isn't a direct DB instance to access and host the log files, you can't view the logs directly from the Amazon Relational Database Service (Amazon RDS) console. However, you can view and download logs that are sent to the CloudWatch console.

To enable logs, first modify the cluster parameter groups for an Aurora serverless cluster. For MySQL-compatible DB clusters, you can enable the slow query log, general log, or audit logs.

Complete steps for enabling Aurora serverless logs for MySQL: 

https://aws.amazon.com/premiumsupport/knowledge-center/aurora-serverless-logs-enable-view/

Incorrect options:

You can view the logs directly from the Amazon Relational Database Service (Amazon RDS) console - Because there isn't a direct DB instance to access and host the log files, you can't view the logs directly from the Amazon Relational Database Service (Amazon RDS) console.

Aurora Serverless cluster is integrated with Amazon CloudWatch and logs are sent automatically - Aurora Serverless will automatically publish the logs to CloudWatch if Aurora cluster is configured as mentioned above. They are not enabled by default.

Aurora Serverless connects to a proxy fleet of DB instances and hence you cannot see the log files. You can connect with your AWS support contact to get help on this requirement - As discussed above, there isn't a direct DB instance to access and host the log files. However, Aurora can be configured as above, for MYSQL to push logs to CloudWatch from where they can be accessed and analyzed.

Reference:

https://aws.amazon.com/premiumsupport/knowledge-center/aurora-serverless-logs-enable-view/

Correct option:

A Spot Instance is an unused EC2 instance that is available for less than the On-Demand price. Your Spot Instance runs whenever capacity is available and the maximum price per hour for your request exceeds the Spot price. Any instance present with unused capacity will be allocated.

You can specify that Amazon EC2 should do one of the following when it interrupts a Spot Instance:

1.Stop the Spot Instance

2.Hibernate the Spot Instance

3.Terminate the Spot Instance

The default is to terminate Spot Instances when they are interrupted.

Reboot the Spot Instance - This is an invalid option.

Incorrect options:

It is always possible that Spot Instances might be interrupted. Therefore, you must ensure that your application is prepared for a Spot Instance interruption.

Stop the Spot Instance - This is a valid option. Amazon EC2 can be configured to stop the instance when an interruption occurs on Spot instances.

Hibernate the Spot Instance - This is a valid option. Amazon EC2 can be configured to hibernate the instance when an interruption occurs on Spot instances.

Terminate the Spot Instance - This is a valid option. Amazon EC2 can be configured to hibernate the instance when an interruption occurs on Spot instances. The default behavior is to terminate Spot Instances when they are interrupted.

Reference:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html

Correct option:

A stack policy applies only during stack updates, it doesn't provide access controls. The developer needs to provide access through IAM policies - When you create a stack, all update actions are allowed on all resources. By default, anyone with stack update permissions can update all of the resources in the stack. You can prevent stack resources from being unintentionally updated or deleted during a stack update by using a stack policy. A stack policy is a JSON document that defines the update actions that can be performed on designated resources.

After you set a stack policy, all of the resources in the stack are protected by default. To allow updates on specific resources, you specify an explicit Allow statement for those resources in your stack policy. You can define only one stack policy per stack, but, you can protect multiple resources within a single policy.

A stack policy applies only during stack updates. It doesn't provide access controls like an AWS Identity and Access Management (IAM) policy. Use a stack policy only as a fail-safe mechanism to prevent accidental updates to specific stack resources. To control access to AWS resources or actions, use IAM.

Incorrect options:

The stack policy is invalid and hence the users are not granted any permissions. The developer needs to fix the syntactical errors in the policy - This statement is incorrect and given only as a distractor.

Stack policies do not allow wildcard character value (*) for the Principal element of the policy - The Principal element specifies the entity that the policy applies to. This element is required while creating a policy but supports only the wildcard (*), which means that the policy applies to all principals.

Stack policies are associated with a particular IAM role or an IAM user. Hence, they only work for the users you have explicitly attached the policy to - A stack policy applies to all AWS CloudFormation users who attempt to update the stack. You can't associate different stack policies with different users.

Reference:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/protect-stack-resources.html

Correct option:

For Amazon EC2 service, managing guest operating system (including updates and security patches), application software and Security Groups is the responsibility of the customer

Customer responsibility will be determined by the AWS Cloud services that a customer selects. This determines the amount of configuration work the customer must perform as part of their security responsibilities. For example, a service such as Amazon Elastic Compute Cloud (Amazon EC2) is categorized as Infrastructure as a Service (IaaS) and, as such, requires the customer to perform all of the necessary security configuration and management tasks. Customers that deploy an Amazon EC2 instance are responsible for the management of the guest operating system (including updates and security patches), any application software or utilities installed by the customer on the instances, and the configuration of the AWS-provided firewall (called a security group) on each instance.

AWS Shared Responsibility Model: 

https://aws.amazon.com/compliance/shared-responsibility-model/

Incorrect options:

For Amazon S3 service, managing the operating system and platform is customer responsibility - For abstracted services, such as Amazon S3, AWS operates the infrastructure layer, the operating system, and platforms, and customers access the endpoints to store and retrieve data. Customers are responsible for managing their data (including encryption options), classifying their assets, and using IAM tools to apply the appropriate permissions.

AWS is responsible for patching and fixing flaws within the infrastructure, for patching the guest Operating Systems and applications of the customers - As part of Patch management, AWS is responsible for patching and fixing flaws within the infrastructure, but customers are responsible for patching their guest OS and applications.

AWS is responsible for training their customers and their employees as part of Customer Specific training - As part of Awareness & Training, AWS trains AWS employees, but a customer must train their own employees.

Reference:

https://aws.amazon.com/compliance/shared-responsibility-model/

Correct option:

Create an image of your instance, and then launch a new instance from this image with the instance type that you need. Take any Elastic IP address that you've associated with your original instance and associate it with the new instance for uninterrupted service to your application

When you want to move your application from one instance store-backed instance to an instance store-backed instance with a different instance type, you must migrate it by creating an image from your instance, and then launching a new instance from this image with the instance type that you need. To ensure that your users can continue to use the applications that you're hosting on your instance uninterrupted, you must take any Elastic IP address that you've associated with your original instance and associate it with the new instance. Then you can terminate the original instance.

Complete steps to migrate an instance store-backed instance: 

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html

Incorrect options:

You can't resize an instance store-backed instance. Instead, you choose a new compatible instance and move your application to the new instance - An instance store-backed EC2 instance can be resized, as explained above.

You can't resize an instance store-backed instance. Instead, configure an EBS volume to be the root device for the instance and migrate using the EBS volume - This statement is incorrect.

Create an image of your instance, and then launch a new instance from this image with the instance type that you need. Any public IP address associated with the instance can be moved with the instance for uninterrupted access of services - Public IP addresses are released when an instance is changed. You need an Elastic IP to keep the service uninterrupted for users since these can be moved across instances.

Reference:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html