Zespół sieciowy zarządza zasobami VPC i podsieci za pośrednictwem CloudFormation i eksportuje wartości wyjściowe stosu. Środowiska deweloperskie wymagają wspólnych komponentów (ALB, Auto Scaling, grupy bezpieczeństwa, DynamoDB) i muszą być tworzone szybko oraz łatwo aktualizowane. Które podejście CloudFormation zapewni spójne, możliwe do aktualizacji środowiska deweloperskie, wykorzystując wyeksportowane dane wyjściowe VPC/podsieci?

Poprawna odpowiedź to użycie zagnieżdżonych stosów, aby zdefiniować wspólne komponenty infrastruktury. Fn::ImportValue jest używane w zasobach zagnieżdżonego stosu do pobierania wartości VPC i podsieci, co pozwala na ponowne wykorzystanie eksportowanych danych wyjściowych z szablonu zespołu sieciowego. Użycie CreateChangeSet i ExecuteChangeSet to standardowa praktyka aktualizowania istniejących środowisk CloudFormation, zapewniająca kontrolę nad zmianami. Opcja z Fn::ImportValue w sekcji Resources szablonu i CloudFormation StackSets jest niepoprawna, ponieważ Fn::ImportValue nie jest używane w sekcji Resources, a StackSets są bardziej odpowiednie do wdrażania w wielu kontach lub regionach, a nie do tworzenia wielu środowisk w ramach jednego konta, które wymagają współdzielonych komponentów. Opcja z Fn::ImportValue w sekcji Parameters głównego szablonu i odwołaniem do szablonu zespołu sieciowego za pomocą TemplateURL jest niepoprawna, ponieważ Fn::ImportValue nie jest używane w sekcji Parameters. Zagnieżdżone stosy są prawidłowym podejściem, ale sposób importowania wartości jest błędny. Opcja z Fn::ImportValue w sekcji Parameters głównego szablonu i organizowaniem zasobów w zagnieżdżone stosy jest niepoprawna, ponieważ Fn::ImportValue nie jest używane w sekcji Parameters.