Een applicatie wordt geïmplementeerd op EC2-instances achter een ALB. De applicatiecode bevindt zich in CodeCommit. Wanneer code wordt samengevoegd naar main, triggert een Lambda-functie een CodeBuild-project dat de code verpakt, artefacten opslaat in CodeArtifact en Systems Manager Run Command gebruikt om het pakket naar EC2 te implementeren. Eerdere implementaties produceerden defecten, inconsistente versies over instances heen en instances die niet de nieuwste code uitvoerden. Welke acties zullen een betrouwbaarder implementatieproces creëren? (Kies twee.)

De huidige implementatiemethode met een Lambda-functie die CodeBuild triggert en Systems Manager Run Command gebruikt, is vatbaar voor de beschreven problemen (defecten, inconsistente versies). De eerste correcte optie, het opzetten van een CodePipeline met sequentiële stages voor bouwen, testen en vervolgens CodeDeploy, biedt een robuust en geautomatiseerd CI/CD-proces. CodePipeline zorgt voor consistentie en traceerbaarheid. Sequentiële stages garanderen dat testen plaatsvindt na het bouwen en vóór de implementatie. De tweede correcte optie, het maken van een AWS CodeDeploy-applicatie en deployment group, is essentieel voor een betrouwbare implementatie naar EC2-instances. CodeDeploy is ontworpen voor geautomatiseerde en veilige implementaties, inclusief rollback-mogelijkheden en integratie met ALB's voor blauw/groen of canary-implementaties, wat de inconsistenties en defecten die in de vraag worden genoemd, oplost. De optie om CodeBuild parallel uit te voeren voor builds en tests is onjuist omdat testen doorgaans afhankelijk is van een voltooide build. Het vervangen door individuele Lambda-functies zou de complexiteit verhogen zonder de voordelen van een geïntegreerde CI/CD-service. Het opslaan van pakketten in S3 in plaats van CodeArtifact is geen verbetering voor pakketbeheer en lost de implementatieproblemen niet op.