A user has configured a VPC with a new subnet. The user has created a security group. The user wants to
configure that instances of the same subnet communicate with each other. How can the user configure this
with the security group?
A.
There is no need for a security group modification as all the instances can communicate with each other
inside the same subnet
B.
Configure the subnet as the source in the security group and allow traffic on all the protocols and ports
C.
Configure the security group itself as the source and allow traffic on all the protocols and ports
D.
The user has to use VPC peering to configure this
Explanation:
A Virtual Private Cloud (VPC. is a virtual network dedicated to the user’s AWS account. AWS provides two
features that the user can use to increase security in VPC: security groups and network ACLs. Security groups
work at the instance level. If the user is using the default security group it will have a rule which allows the
instances to communicate with other. For a new security group the user has to specify the rule, add it to define
the source as the security group itself, and select all the protocols and ports for that source.
I think the answer is B because the question says about subnet as a source.
Answer is A. Default is they can communicate already.
I will agree with Justin.
The reason is when you create a custom VPC and subnets, route table will be configured such that the instance launched in the subnets can communicate with each other. There won’t be any restrictions or blocking for the instances.
The answer is C.
The reason is user has created another Security Group which by default has nothing configured, so he has to set the sources as itself when he uses this Security Group with the created VPC.
If the user has only created a custom VPC then a custom SG will be created and which has a rule to allow itself. In this way the subnets can communicate with each other
Good point about the SG, Venkat. I think it’s C.
When the new subnet is created, default routing enables the communicating within the instances of subnet is enabled by default.
So, I go with A
I will take it back. I go with B
By Default EC2 instances within the same subnet can communicate with each other using the default routing policy. But only thing is security group must be created to open the port for communication. so I will go with B
Something is off with this questions, I just tested and both B and C are correct.
Type Protocol Port Range Source
B. All traffic All All sg-70f09519 (SG itself as source)
Type Protocol Port Range Source
C. ll traffic All All 192.0.0.0/24 (subnet as source)
A. is not correct, this is only valid for the default VPC.
D. is not correct, as VPC peering is for connecting VPCs
C is correct.
Both A and C is WRONG. The correct answer is B.
I setup 2 hosts and EC2 on a new subnet and new security group (with default settings). Neither host could ping either other on their internal IP by default. I had to edit the inbound Security Group to allow traffic traffic between the two EC2 instances. Both instances are on the same subnet and same security group.
I tried both B and C in this actual AWS environment and both options worked in real life for sending traffic between the EC2 instances in this scenario.
However the questions ask that “instances of the same subnet communicate with each other.” B allows instances of the same subnet to communicate with each other. C only allows instances of the same security group to communicate. In this scenario the EC2 instances are in the same subnet and security group but the question specifically ask for communication on the subnet level.
The correct answer is B.
C is correct in my opinion.
“Instances associated with a security group can’t talk to each other unless you add rules allowing it (exception: the default security group has these rules by default).”
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html#VPCSecurityGroups
I feel B is the correct answer .
The reason not C is any subnet instances can be configured to use the affected security group and if you added SG as the source then this may not match to the requirement raised in question “The user wants to
configure that instances of the same subnet communicate with each other”
Agree with Aneesh Mohan logic.
I did the same test as Gig: actually, both B and C work for instances to communicate between each other within a subnet. But because question mentions “The user wants to configure that instances of the same subnet communicate with each other.” – I believe the correct answer is B: subnet as a source. Not security group.
By Default EC2 instances within the same subnet can communicate with each other using the default routing policy. But only thing is security group must be created to open the port for communication. so I will go with B
Answer is C. Please read question carefully as they mentioned user created new SG.
Security groups work at the instance level. If the user is using the default security group it will have a rule which allows the instances to communicate with other. For a new security group the user has to specify the rule, add it to define the source as the security group itself, and select all the protocols and ports for that source.
C
c
The perfect answer is B.
Though the options B and C would be possible answers, but option B makes more sense as per the question.
B – In this case, if we add subnet as the source to the security group then any other instance in that subnet can communicate with the instance owning this security group. But important consideration here is, we need to add subnet as the source to each individual instance security groups.
C – In this case, if we add security group itself as the source then it allow traffic from other instances assigned to this security group only. Even if the instances launched in the different subnets uses this security group can also communicate.
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario3.html
One more point in the question to be consider is “instances of the same subnet communicate with each other”(optin B fits).
If there is a scenario where “the instances of the same security group communicate with each other”(Option C fits).
Security Groups are nothing to do with subnet level(network level) but NACL does and applies to all instances launched with that subnet.
B is correct Answer
Chongo
C – for this reason
When you create a security group, it has no inbound rules. Therefore, no inbound traffic is allowed until you add inbound rules to the security group.
Mate, that isn’t a valid reason at all. Sure it needs inbound rules, but from WHAT SOURCE? SG or Subnet? SG if you want instances of the same SG to talk to each other, or subnet if you want instances of the same subnet to talk to each other.
c
Option B is the ONLY Correct answer.
Reason: Its a NEW security Group being created, even though its similar to default security group. Now unless NEW Security Group is created …you will not get Security Group ID to configure as Source, so only option left is to use Subnet as SOURCE
Both B and C allows it but i would go with B, C allows instances from different subnets but in the same SG to communicate.
b