Answer – B
This example is also given in the AWS Documentation.
Modifying your CloudFormation template to discontinue the use of NAT instances and consume NAT gateways is straightforward. You would:
Allocate an Elastic IP address. However, it would not be directly assigned to an instance.
Create a NAT gateway resource.
Create a route to the Internet, but via the NAT gateway instead of going through a NAT instance. As in the code for NAT instances, this route would then be associated with the route table for the private subnets in the same Availability Zone.
The updated example would look something like this.
{
...
"Resources" : {
...
"NATGateway1EIP" : {
"Type" : "AWS::EC2::EIP",
"Properties" : {
"Domain" : "vpc"
}
},
"NATGateway1" : {
"Type" : "AWS::EC2::NatGateway",
"DependsOn" : "VPCGatewayAttachment",
"Properties" : {
"AllocationId" : {
"Fn::GetAtt" : [
"NATGateway1EIP",
"AllocationId"
]
},
"SubnetId" : {
"Ref" : "PublicSubnetAZ1"
}
}
},
"PrivateRoute1" : {
"Type" : "AWS::EC2::Route",
"Properties" : {
"RouteTableId" : {
"Ref" : "PrivateRouteTable1"
},
"DestinationCidrBlock" : "0.0.0.0/0",
"NatGatewayId" : {
"Ref" : "NATGateway1"
}
}
},
...
}
...
}
Option A is invalid because AWS Config can only check for the configuration of resources.
Option C is invalid because this is used to create stacks of resources. In this case, it is better to use Cloudformation.
Option D is invalid because AWS Inspector is used to scan for the vulnerability of Instances.
For more information on using Cloudformation templates for NAT gateways, one can visit the below URL
https://aws.amazon.com/blogs/apn/taking-nat-to-the-next-level-in-aws-cloudformation-templates/