Exam AWS Certified Security - Specialty topic 1 question 232 discussion

I think C , why add inbound rule for Database on application instance. Create SG on Application instance so we can add SG to the database SH rules i.e allow traffic to database port from SG of application instance.

C is the right answer. The question says that EC2s will be created in the VPC, but not all need access to the database. By creating an empty SG and attaching it only to the EC2s that need access to the database, you can set that SG name as the source address for an inbound rule on the database SG. The others are all too permissive, as they will allow all EC2s to access the database.

Long question with annoying long options, and the only purpose of it to test you on: 1. reference SG in another SG rule(s) 2. SG reference can work through VPC peering 3. you noticed "EC2 instances will regularly be created and terminated in the application VPC" in the question, therefore IP list is not practical and better use SG reference. Option C.

The VPCs are peered, so you *can* reference security groups in other VPCs: https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html and it would likely be deemed best practise, rather than opening up an SG to an entire IP range. I'd eliminate both B and D, since the application doesn't require inbound 1521 (it's making outbound requests, and SGs are stateful). It would be between C and A. I'd then eliminate A, since it shoudn't require a Network ACL rule (they allow all access by default), and using security groups for access is just better.

C. Create a new security group in the application VPC with no inbound rules. Create a new security group in the database VPC with an inbound rule that allows TCP port 1521 from the new application security group in the application VPC. Attach the application security group to the application instances that need database access, and attach the database security group to the database instances. To restrict access to the databases in the peered VPC, the security engineer should create a new security group in the application VPC with no inbound rules. In the database VPC, a new security group should be created allowing TCP port 1521 from the application security group in the application VPC. The application instances that require database access should be associated with the application security group, while the database instances should be associated with the database security group. This ensures that only the designated application instances can access the databases on TCP port 1521, while blocking access from other instances in the application VPC.

In this approach, a new security group is created in the application VPC without any inbound rules. This security group will be attached to the EC2 instances that require access to the databases. Another new security group is created in the database VPC, specifically for the database instances. This security group will have an inbound rule that allows TCP port 1521, which is the database access port, from the newly created application security group in the application VPC. By attaching the application security group to the application instances and the database security group to the database instances, the necessary access control is achieved. Only the EC2 instances associated with the application security group will be able to access the database instances on TCP port 1521. This solution ensures that the access is restricted to the required instances and follows the principle of least privilege, reducing the attack surface and enhancing security.

As per AWS documentation: You can update the inbound or outbound rules for your VPC security groups to reference security groups in the peered VPC. Doing so allows traffic to flow to and from instances that are associated with the referenced security group in the peered VPC. Therefore we can safely eliminate D and A from the equation. By default, a security group includes an outbound rule that allows all outbound traffic. Creating a new security group for the application tier essentially allows outbound communication to the database servers. Now we must configure an inbound access to the database tier in the other VPC. C

A is right, you can configure ip range to allow let's say ping from prod vpc or to dev or/and vice versa C is wrong you can't add SG id from VPC from another account, just tried.

C. Since we can use SG across peered VPC, I think it would be easier to do C rather than A. You can update the inbound or outbound rules for your VPC security groups to reference security groups in the peered VPC. Reference: https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html

C ti is not complete but it's the only meningfull answer.

A is the Best Answer, You cannot attach SG from another VPC, someone says you need epheramal ports but you don´t, you just modify the acl inbound for dst port 1521 the acl out has permit all by default

A is the only correct answer I can see many people voted for C - Now note this part in Option C "Create a new security group in the database VPC with an inbound rule that allows TCP port 1521 from the new application security group in the application VPC". Question is - Is it possible to select a SG which is in a different VPC, as a source, in a SG rule which is in an another VPC?

C The following inbound rules are examples of rules you might add for database access, depending on what type of database you're running on your instance. TCP 6 1521 (Oracle) The default port to access an Oracle database, for example, on an Amazon RDS instance https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules-reference.html#sg-rules-db-server

C not only works, it is the more elegant option

A cannot work because it needs additional allow ACL for ephemeral ports.

Least permissive option

I agree with dlenehan...