Firma definiuje swoją aplikację za pomocą AWS Cloud Development Kit (CDK) i wdraża ją przy użyciu potoku zbudowanego z AWS CodePipeline i AWS CodeBuild. Chcą dodać testy jednostkowe do potoku i upewnić się, że wdrożenie będzie kontynuowane tylko wtedy, gdy żaden z testów jednostkowych nie zakończy się niepowodzeniem. Które dwa kroki wymuszą ten wymóg?

Poprawne odpowiedzi to: "Zmodyfikuj komendy fazy build CodeBuild, aby najpierw uruchomić testy, a następnie wdrożyć aplikację CDK. Skonfiguruj właściwość OnFailure fazy CodeBuild na ABORT." oraz "Napisz testy jednostkowe przy użyciu biblioteki AWS CDK assertions i użyj asercji template.hasResourceProperties, aby sprawdzić, czy zasoby mają oczekiwane właściwości." Pierwsza opcja jest poprawna, ponieważ umieszczenie testów jednostkowych przed wdrożeniem w fazie budowania CodeBuild i skonfigurowanie OnFailure na ABORT zapewni, że wdrożenie nie nastąpi, jeśli testy jednostkowe zakończą się niepowodzeniem. Druga opcja jest poprawna, ponieważ biblioteka AWS CDK assertions jest przeznaczona do testowania szablonów CloudFormation generowanych przez CDK, w tym sprawdzania właściwości zasobów. Jest to standardowa praktyka testowania jednostkowego dla aplikacji CDK. Opcja z --rollback true jest niepoprawna, ponieważ rollback nastąpiłby po nieudanym wdrożeniu, a celem jest zapobieżenie wdrożeniu, jeśli testy jednostkowe zawiodą. Opcja z --require-approval any-change jest niepoprawna, ponieważ wymagałaby ręcznej interwencji, a nie automatycznego zatrzymania na podstawie wyników testów. Opcja z cdk diff jest niepoprawna, ponieważ cdk diff pokazuje tylko różnice w szablonie, a nie testuje logiki aplikacji ani poprawności konfiguracji zasobów.