Incorrect question & answer

[Privat33r]

Question: “A company has multiple VPCs with IPv6 enabled for its suite of web applications. The Solutions Architect tried to deploy a new Amazon EC2 instance but she received an error saying that there is no IP address available on the subnet.

How should the Solutions Architect resolve this problem?”

Question problem: It doesn’t mention which VPC SA used: was it IPv6-enabled or IPv4 only? Let’s assume that it’s VPC with IPv6 support.

“Incorrect” answer: “Set up a new IPv6-only subnet with a large CIDR range. Associate the new subnet with the VPC then launch the instance.“

Explanation for its incorrectness: “is incorrect because you need to add IPv4 subnet first before you can create an IPv6 subnet.”

Have you missed this news? https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-ipv6-only-subnets-and-ec2-instances/

I don’t see this limitation anywhere. In fact I can do it myself in the AWS Management Console. See the screenshots.

[Nikee-TutorialsDojo]

Hi Privat33r,

Thank you for your detailed feedback, and I appreciate you bringing this to our attention.

You are correct that the scenario lacks clarity regarding the type of VPC used, whether it’s IPv4-only or IPv6-enabled. However, the scenario does mention that the company has multiple VPCs with IPv6 enabled for its web applications, which reasonably implies that IPv6 is supported in the current environment.

Additionally, you are correct that AWS now allows creating IPv6-only subnets without first requiring an IPv4 subnet, as highlighted in the blog post you shared. This significant update enables users to deploy EC2 instances in IPv6-only subnets, provided that they are using Nitro EC2 instance type.

However, since the question does not specify the instance type, which is crucial for IPv6-only subnets, and because this feature is limited to Nitro EC2 instance type, the option that says “Set up a new IPv6-only subnet with a large CIDR range. Associate the new subnet with the VPC then launch the instance.“ is incorrect in all cases.

Hence, the option that says “Set up a new IPv4 subnet with a larger CIDR range. Associate the new subnet with the VPC and then launch the instance.” is the correct answer. By expanding the IPv4 subnet’s CIDR range, the Solutions Architect can ensure enough IP addresses are available, regardless of the instance type or IPv6 capabilities.

Thank you again for highlighting these important points, and we appreciate your understanding as we work to keep our content accurate and aligned with the latest AWS developments.

Regards,

Nikee @ Tutorials Dojo

[Privat33r]

In that case explanation is still incorrect.

Also it bothers me that available CIDRs in the VPCs are not mentioned, as they might be exhausted and it might’ve been implied. Normally on VPC allocation, if you plan ahead, you might use all the available addresses by assigning subnets.

Also you say that “because this feature is limited to Nitro EC2 instance type, the option that says <i style=”font-family: inherit; font-size: inherit;”>“Set up a new IPv6-only subnet with a large CIDR range. Associate the new subnet with the VPC then launch the instance.“ is incorrect in all cases.”. You might want to specify instance type or mention that it’s not Nitro, because solution is valid in a subset of cases where Nitro EC2 instance is used.

Also what is even meant by “associate subnet with VPC”? Can you even create a subnet outside of the VPC? You have to specify VPC before creation of the subnet: https://docs.aws.amazon.com/cli/latest/reference/ec2/create-subnet.html

Below are some relevant excerpts from the “AWS Certification Subject Matter Expert (SME) Item Writing” course.

[Nikee-TutorialsDojo]

Hi Privat33r,

Thank you for your continued feedback and attention to detail. You are right that the scenario should include the instance type and the explanation could be clearer about AWS’s recent updates, allowing IPv6-only subnets with Nitro instance types.

Regarding your point about subnet creation, you are correct that every subnet created is automatically associated with the main route table for the VPC. Therefore, the phrase “associate the subnet with the VPC” is redundant and unnecessary. I’ll revise the question accordingly to ensure it accurately reflects these considerations.

Once again, thank you for your valuable feedback, and I appreciate your patience as we refine the content to meet the highest standards.

Regards,

Nikee @ Tutorials Dojo

[Aiqing]

Is the answer to this question right? I don’t feel it right.

[Privat33r]

Can you elaborate on why you don’t feel that the answer is correct?

Let’s start with trust direction:

incoming trust means that AD B will provide access to AD A

outgoing trust means that AD A will provide access to AD B

Simple way to remember: “A trusts B”. E.g. if you trust someone with your money, then you have an outgoing trust to them; if someone trust you with their money then you have an incoming trust.

The question explicitly states “cloud-based users must be contained in a separate authentication domain” (ergo, we are making another AD); “and prevented from accessing on-premises systems”, later it states that there already is existing AD and it is ON-PREM.

Your supposed correct answer will provide access to existing AD ON-PREM to cloud-based users, which violates the condition of the item stem.

I suggest to read an explanation next time. In case if it’s not convincing and you decide to report a supposed mistake, provide more details than “it don’t seem right”, ideally with sources.

[Nikee-TutorialsDojo]

Hello Aiqing,

Thank you for raising this. Yes, you are correct. The second correct answer should be “Set up a one-way trust where the new Active Directory in AWS trusts the existing on-premises Active Directory.”

This setup ensures that users in the on-premises Active Directory can access and manage AWS resources, such as RDS databases and EC2 instances, without allowing AWS-based users access to on-premises systems. This configuration aligns with the organization’s security policy by keeping cloud-based users in a separate authentication domain, thus preventing unauthorized access to sensitive on-premises systems. A one-way trust in this direction provides the necessary control and security, allowing on-premises administrators to manage cloud resources securely.

We have already updated this item, and it should reflect soon. If you need further assistance, please don’t hesitate to contact us.

Regards,

Nikee @ Tutorials Dojo

[Aiqing]

Thank you for the reply. 😀

[Privat33r]

It’s basically a rephrase of the initial correct answer.