If you have multiple VPN connections, you can provide secure communication between sites using the AWS VPN CloudHub. This enables your remote sites to communicate with each other, and not just with the VPC. The VPN CloudHub operates on a simple hub-and-spoke model that you can use with or without a VPC. This design is suitable for customers with multiple branch offices and existing internet connections who’d like to implement a convenient, potentially low-cost hub-and-spoke model for primary or backup connectivity between these remote offices.

References:
https://docs.aws.amazon.com/vpc/latest/userguide/VPN_CloudHub.html
https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html

To restrict access to content that you serve from Amazon S3 buckets, you create CloudFront signed URLs or signed cookies to limit access to files in your Amazon S3 bucket, and then you create a special CloudFront user called an origin access identity (OAI) and associate it with your distribution. Then you configure permissions so that CloudFront can use the OAI to access and serve files to your users, but users can’t use a direct URL to the S3 bucket to access a file there. Taking these steps helps you maintain secure access to the files that you serve through CloudFront.
In general, if you’re using an Amazon S3 bucket as the origin for a CloudFront distribution, you can either allow everyone to have access to the files there, or you can restrict access. If you limit access by using, for example, CloudFront signed URLs or signed cookies, you also won’t want people to be able to view files by simply using the direct URL for the file. Instead, you want them to only access the files by using the CloudFront URL, so your protections work.

Typically, if you’re using an Amazon S3 bucket as the origin for a CloudFront distribution, you grant everyone permission to read the objects in your bucket. This allows anyone to access your objects either through CloudFront or using the Amazon S3 URL. CloudFront doesn’t expose Amazon S3 URLs, but your users might have those URLs if your application serves any objects directly from Amazon S3 or if anyone gives out direct links to specific objects in Amazon S3.
The option that says: Create an Origin Access Identity (OAI) and associate it with your CloudFront distribution. Change the permissions on your Amazon S3 bucket so that only the origin access identity has read permission is correct because it gives CloudFront the exclusive access to S3 bucket, and prevents other users from accessing the public content of S3 directly via S3 URL.
Writing an S3 bucket policy that assigns the CloudFront distribution ID as the Principal and the target bucket as the Amazon Resource Name (ARN) is incorrect because creating a bucket policy is unnecessary and it does not prevent other users from accessing the public content of S3 directly via S3 URL.
Assigning an IAM user that is granted access to objects in the S3 bucket to CloudFront is incorrect because it does not give CloudFront exclusive access to the S3 bucket.
Writing individual polices for each S3 bucket containing the confidential documents that would grant CloudFront access is incorrect because you do not need to create any individual policies for each bucket.

Reference:
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html

Proxy servers usually act as a relay between internal resources (servers, workstations, etc.) and the Internet, and to filter, accelerate and log network activities leaving the private network. One must not confuse proxy servers (also called forwarding proxy servers) with reverse proxy servers, which are used to control and sometimes load-balance network activities entering the private network.

Launching a new web proxy server that only allow outbound access to the URLs provided by the proprietary e-commerce platform in your VPC is correct because it launches a proxy server which filters requests from the client and then only allows certain URLs provided by the proprietary e-commerce platform.
The option that says: Create a new NAT Instance in your VPC. Place the EC2 instances to the private subnet and connect it to a NAT Instance which will handle the outbound URL restriction is absolutely wrong considering that the EC2 instances are used as public facing web servers and thus, must be deployed in the public subnet. An instance in private subnet and connected to a NAT Instance will not be able to accept inbound connections to the online shopping website.
The option that says: Create a new NAT Gateway in your VPC. Place the EC2 instances to the private subnet and connect it to a NAT Gateway which will handle the outbound URL restriction is incorrect with the same reason as the above option. An instance in private subnet and connected to a NAT Gateway will not be able to accept inbound connections to the online shopping website.
Implementing a Network ACL to all specific URLs by the e-commerce platform with an implicit deny rule is incorrect because a network access control list (Network ACL) has limited functionality and cannot filter requests based on URLs.

References:
https://aws.amazon.com/articles/using-squid-proxy-instances-for-web-service-access-in-amazon-vpc-another-example-with-aws-codedeploy-and-amazon-cloudwatch/
https://aws.amazon.com/blogs/security/how-to-set-up-an-outbound-vpc-proxy-with-domain-whitelisting-and-content-filtering/

AWS provides two features that you can use to increase security in your VPC: security groups and network ACLs. Security groups control inbound and outbound traffic for your instances, and network ACLs control inbound and outbound traffic for your subnets. In most cases, security groups can meet your needs; however, you can also use network ACLs if you want an additional layer of security for your VPC.

AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. Config continuously monitors and records your AWS resource configurations and allows you to automate the evaluation of recorded configurations against desired configurations. With Config, you can review changes in configurations and relationships between AWS resources, dive into detailed resource configuration histories, and determine your overall compliance against the configurations specified in your internal guidelines. This enables you to simplify compliance auditing, security analysis, change management, and operational troubleshooting.
Using Route 53 to ensure that there is proper routing between the two subnets is incorrect because Route 53 can’t be used to connect two subnets. You should use Network ACLs and Security Groups instead.
Ensuring that the default route is set to NAT instance or Internet Gateway (IGW) is incorrect because neither a NAT instance nor an Internet gateway is needed for the two EC2 instances to communicate.
Using AWS Systems Manager to track historical changes to the security configurations associated to your instances is incorrect because using AWS Systems Manager is not suitable to track historical changes to the security configurations associated to your instances. You have to use AWS Config instead.

References:
https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html

Reserved Instances are best to use for these scenarios:
Applications that have been in use for years and that you plan to continue to use.
Applications with steady state or predictable usage.
Applications that require reserved capacity.
Users who want to make upfront payments to further reduce their total computing costs.
Since the game company is planning to use this application for 3 years or more, the best and the most cost-effective type of EC2 to use is a Reserved Instance. Hence, using Reserved EC2 Instances to host the GraphQL API and CloudFront for web distribution of the static assets is correct. You cannot use a Spot instance here as you need to provide a consistent service to your users without any interruption. An On-Demand instance is a valid option but it costs more than Reserved instance which is why it is incorrect.

Reference:
https://aws.amazon.com/ec2/pricing/reserved-instances/

Lightweight Directory Access Protocol (LDAP) is a standard communications protocol used to read and write data to and from Active Directory. You can manage your user identities in an external system outside of AWS and grant users who sign in from those systems access to perform AWS tasks and access your AWS resources. The distinction is where the external system resides—in your data center or an external third party on the web.

For enterprise identity federation, you can authenticate users in your organization’s network, and then provide those users access to AWS without creating new AWS identities for them and requiring them to sign in with a separate user name and password. This is known as the single sign-on (SSO) approach to temporary access. AWS STS supports open standards like Security Assertion Markup Language (SAML) 2.0, with which you can use Microsoft AD FS to leverage your Microsoft Active Directory.
The option that says: Authenticate against LDAP using an identity broker you created, and have it call IAM Security Token Service (STS) to retrieve IAM federated user credentials. The application then gets the IAM federated user credentials of the identity broker to access the appropriate S3 bucket is correct because it follows the correct sequence. It develops an identity broker that authenticates users against LDAP, gets the security token from STS, and then accesses the S3 bucket using the IAM federated user credentials.
The option that says: The application first authenticates against LDAP to retrieve the name of an IAM role associated with the user. It then assumes that role via call to IAM Security Token Service (STS). Afterwards, the application can now use the temporary credentials from the role to access the appropriate S3 bucket is correct because it follows the correct sequence. It authenticates users using LDAP, gets the security token from STS, and then accesses the S3 bucket using the temporary credentials.
The option that says: Create an identity broker that assumes an IAM role, and retrieve temporary AWS security credentials via IAM Security Token Service (STS). The application gets the AWS temporary security credentials from the identity broker to gain access to the appropriate S3 bucket is incorrect because the users need to be authenticated using LDAP first, not STS. Also, the temporary credentials to log into AWS are provided by STS, not identity broker.
The option that says: The application first authenticates against LDAP, and then uses the LDAP credentials to log in to IAM service. Finally, it can now use the IAM temporary credentials to access the appropriate S3 bucket is incorrect because you cannot use the LDAP credentials to log into IAM.
The option that says: Use a Direct Connect Gateway instead of a single Direct Connect connection. Set up a Transit VPC which will authenticate against their on-premises LDAP server is incorrect because using a Direct Connect Gateway will only improve the availability of your on-premises network connection and using a transit VPC is just a common strategy for connecting multiple, geographically disperse VPCs and remote networks in order to create a global network transit center. These two things will not meet the requirement.

Reference:
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html

You can create a network interface, attach it to an instance, detach it from an instance, and attach it to another instance. The attributes of a network interface follow it as it’s attached or detached from an instance and reattached to another instance.
When you move a network interface from one instance to another, network traffic is redirected to the new instance. You can also modify the attributes of your network interface, including changing its security groups and managing its IP addresses. Every instance in a VPC has a default network interface, called the primary network interface (eth0). You cannot detach a primary network interface from an instance. You can create and attach additional network interfaces. The maximum number of network interfaces that you can use varies by instance type.

In this scenario, you basically need to provide multiple IP addresses to a single EC2 instance. This can be easily achieved by using an Elastic Network Interface (ENI). An elastic network interface is a logical networking component in a VPC that represents a virtual network card.
Creating an EC2 instance with multiple security groups attached to it which contain separate rules of each IP address, including custom rules in the Network ACL is incorrect because a security group is mainly used to control the incoming or outgoing traffic to the instance and doesn’t provide multiple IP addresses to an EC2 instance.
Creating an EC2 instance that has multiple subnets in two separate Availability Zones attached to it and each will have a separate IP address is incorrect because you cannot place the same EC2 instance in two separate Availability Zones.
Creating an EC2 instance with a NAT address is incorrect because a NAT address doesn’t provide multiple IP addresses to an EC2 instance.

References:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/MultipleIP.html

In this scenario, the best option to use is a WAF instead of IDS/IPS, as it provides more protection against common cyber attack patterns. IDS is mostly concerned about detection of unauthorized access and IPS is basically similar to IDS, but provides a prevention mechanism for your network.
AWS WAF is a web application firewall that helps protect your web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources. AWS WAF gives you control over which traffic to allow or block to your web applications by defining customizable web security rules. You can use AWS WAF to create custom rules that block common attack patterns, such as SQL injection or cross-site scripting, and rules that are designed for your specific application. New rules can be deployed within minutes, letting you respond quickly to changing traffic patterns.
Intrusion Detection Systems (IDS) monitor networks and/or systems for malicious activity or policy violation, and report them to systems administrators or to a security information and event management (SIEM) system. Intrusion Prevention Systems (IPS) are positioned behind firewalls and provide an additional layer of security by scanning and analyzing suspicious content for potential threats. Placed in the direct communication path, an IPS will take automatic action on suspicious traffic within the network.
Implementing an AWS WAF (Web Application Firewall) is correct as AWS WAF provides protection against common attack patterns, such as SQL injection, DDoS or cross-site scripting.
Implementing an Intrusion Detection Systems (IDS) is incorrect as IDS alone is not enough to provide protection against cyber attacks. It only detects malicious activities or policy violations in your network but it doesn’t do anything about those security flaws. WAF is a better option to choose for this scenario.
Implementing an Intrusion Prevention Systems (IPS) is incorrect as IPS is also not enough to provide complete protection against cyber attacks. It only prevents malicious activities or policy violations in your network and you need to have WAF to fully secure your network. WAF is a better option to choose for this scenario.
Implementing both Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) is incorrect as even though you have both IDS and IPS, you still need a WAF for better security against cyber attacks.

References:
https://aws.amazon.com/waf/
https://d1.awsstatic.com/Marketplace/scenarios/security/SEC_01_TSB_Final.pdf

Amazon EC2 now allows peering relationships to be established between Virtual Private Clouds (VPCs) across different AWS regions. Inter-Region VPC Peering allows VPC resources like EC2 instances, RDS databases, and Lambda functions running in different AWS regions to communicate with each other using private IP addresses, without requiring gateways, VPN connections or separate network appliances.
Inter-Region VPC Peering provides a simple and cost-effective way to share resources between regions or replicate data for geographic redundancy. Built on the same horizontally scaled, redundant, and highly available technology that powers VPC today, Inter-Region VPC Peering encrypts inter-region traffic with no single point of failure or bandwidth bottleneck. Traffic using Inter-Region VPC Peering always stays on the global AWS backbone and never traverses the public Internet, thereby reducing threat vectors, such as common exploits and DDoS attacks.
Hence, the correct answer is setting up an Inter-Region VPC Peering.
Setting up an SSL VPN Connection to all VPCs is incorrect because an SSL VPN Connection only provides a secure VPN connection but doesn’t establish a VPC to VPC peering connection.
Setting up an IPSec VPN Connection to all VPCs is incorrect because an IPSec VPN Connection only provides a secure VPN connection but doesn’t establish a VPC to VPC peering connection.
The option that says: This is currently not possible in AWS is incorrect because this statement is false. It can be done in AWS by using Inter-Region VPC Peering.

Reference:
https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/Welcome.html

When users or services interact with an application, they will often perform a series of interactions that form a session. A session is unique data for users that persists between requests while they use the application. A stateless application is an application that does not need knowledge of previous interactions and does not store session information.

For example, an application that, given the same input, provides the same response to any end user, is a stateless application. Stateless applications can scale horizontally because any of the available compute resources (such as EC2 instances and AWS Lambda functions) can service any request. Without stored session data, you can simply add more compute resources as needed. When that capacity is no longer required, you can safely terminate those individual resources, after running tasks have been drained. Those resources do not need to be aware of the presence of their peers—all that is required is a way to distribute the workload to them.
In this scenario, the best option is to use a combination of Elasticache, Cloudwatch, and RDS Read Replica.
The option that says: Run your web and application tiers in stateless instances in an autoscaling group, using Elasticache Memcached for tier synchronization and CloudWatch for monitoring and running your database tier using RDS with read replicas is correct because it uses stateless instances. The web server uses ElastiCache for read operations and CloudWatch which monitors fluctuations in the traffic and notifies the autoscaling group to scale in/scale out accordingly. In addition, it uses read replicas for RDS to handle the read-heavy workload.
The option that says: Run your web and application tiers in stateful instances in an autoscaling group, using CloudWatch for monitoring and running your database tier using RDS with Multi-AZ enabled is incorrect because it uses stateful instances. It also does not use any caching mechanism for web and application tier, and multi-AZ RDS does not improve read performance.
The option that says: Run your web and application tiers in stateful instances in an autoscaling group, using CloudWatch for monitoring and running your database tier using RDS with read replicas is incorrect because it uses stateful instances and it does not use any caching mechanism for web and application tier.
The option that says: Run your web and application tiers in stateless instances in an autoscaling group, using Elasticache Memcached for tier synchronization and CloudWatch for monitoring and running your database tier using RDS with Multi-AZ enabled is incorrect because multi-AZ RDS does not improve read performance.

Reference:
https://aws.amazon.com/elasticache/
https://aws.amazon.com/rds/details/read-replicas/
https://d1.awsstatic.com/whitepapers/AWS_Cloud_Best_Practices.pdf