Day 5 - Week 5 복습: CodePipeline 통합 시나리오

Tooling 계정의 CodePipeline이 Prod 계정에 ECS 서비스를 배포한다. "배포 Action이 IAM Policy 에러 없이 시작됐는데, Artifact 다운로드 단계에서 다음 오류가 발생한다: Client error: KMS key access denied when decrypting artifact". 원인과 해결책은?

• APipeline Service Role에 sts:AssumeRole 권한이 없다 → Spoke Role ARN에 대한 AssumeRole을 허용하는 Identity Policy를 Pipeline Service Role에 추가
• BArtifact S3 버킷 정책에 Prod 계정 CrossAccountDeployRole이 Principal로 없다 → 버킷 정책에 GetObject/PutObject 허용 Principal 추가
• CTooling 계정의 KMS Key Policy에 Prod 계정 CrossAccountDeployRole에 대한 kms:Decrypt 허용이 없다 → KMS Key Policy 수정
• DECS Task Execution Role과 배포 대상 클러스터의 Security Group이 같은 VPC/서브넷에 정렬되지 않았다 → 네트워킹 재구성

한 회사가 100개의 마이크로서비스를 단일 Git 저장소(모노레포)에서 관리한다. 각 서비스는 독립적인 CodePipeline을 가지고 있다. shared/auth/의 변경이 모든 100개 파이프라인을 트리거해야 하고, services/checkout/의 변경은 checkout 파이프라인만 트리거해야 한다. 가장 적절한 V2 트리거 구성은?

• A단일 파이프라인에서 Lambda로 변경 파일을 분석해 해당 서비스 파이프라인을 시작
• B각 서비스 파이프라인의 filePaths.includes에 해당 서비스 경로와 shared/auth/**를 함께 포함
• CCodeBuild에서 변경 파일을 분석하고 해당 파이프라인을 start-pipeline-execution으로 시작
• DGit branch를 서비스별로 분리

금융 서비스 회사가 "모든 prod 배포는 두 단계의 자동 게이트를 통과해야 한다: (1) 배포 전 error rate 알람이 OK 상태여야 함, (2) 배포 후 5분 동안 error rate 알람이 OK 상태를 유지해야 함. 어느 게이트라도 실패하면 자동 롤백"이라는 요구사항이 있다. 가장 적절한 구현은?

• AManual Approval Action × 2로 사람이 양쪽 확인
• BDeploy Stage의 beforeEntry에 CloudWatch Alarm Rule(배포 전), onSuccess에 CloudWatch Alarm Rule(배포 후) 설정, 둘 다 result: ROLLBACK
• CLambda Invoke Action × 2를 Deploy Action 앞뒤에 배치
• DEventBridge Rule로 알람 상태를 모니터링하고 실패 시 수동 롤백

한 팀이 "prod 배포를 승인할 수 있는 권한을 시니어 엔지니어에게만 부여하고, 승인은 Slack에서 진행"하는 패턴을 구현하려 한다. AWS Chatbot을 사용할 때 승인 권한을 사용자 수준에서 세밀하게 제어하는 방법은?

• ASNS Topic의 구독을 시니어 엔지니어 이메일만으로 제한
• BChatbot IAM Role에 codepipeline:PutApprovalResult 권한을 주되, Condition으로 특정 파이프라인 ARN만 허용
• CAWS Chatbot이 Slack 사용자를 IAM과 직접 매핑하므로 시니어 엔지니어의 IAM User에 권한 부여
• D커스텀 Slack 봇 Lambda를 구현해 Slack 사용자 ID를 사내 인사 시스템과 대조한 후 시니어 엔지니어인 경우에만 PutApprovalResult 호출

CodePipeline에서 Step Functions Action을 사용하는 State Machine이 실행 중 "외부 변경 관리 시스템(ServiceNow)의 Change Request가 승인될 때까지 배포를 일시 중단"해야 한다. State Machine이 이 대기를 구현하는 가장 적절한 방법은?

• AState Machine 안에 Task 상태에서 WaitSeconds를 설정해 1시간마다 재시도
• BwaitForTaskToken 패턴 — TaskToken을 ServiceNow에 전달하고 ServiceNow가 승인 시 SendTaskSuccess 호출
• CLambda Invoke Action과 Step Functions Action을 교대로 실행
• DManual Approval Action을 파이프라인에 추가

CDK Pipelines로 파이프라인을 관리하는 팀이 "프로덕션 배포 전 반드시 Manual Approval이 필요하다"는 요구사항과 "스테이징 배포는 완전 자동"이라는 요구사항을 동시에 만족시키려 한다. CDK Pipelines 코드에서 어떻게 구현하는가?

• A두 개의 별도 CDK Pipelines 스택 생성 (스테이징용, 프로덕션용)
• Bpipeline.addStage(StagingStage) + pipeline.addStage(ProdStage, { pre: [new ManualApprovalStep('Approve')] })
• CCloudFormation 조건으로 환경별 분기
• DLambda Invoke Action으로 환경을 확인하고 prod인 경우에만 Manual Approval 트리거

현재 Pipeline이 SUPERSEDED 모드로 동작 중이다. 10개의 commit이 빠르게 push되면 어떤 현상이 발생하는가?

• A10개 commit이 각각 별도 실행을 만들어 순서를 보장하며 10번 모두 빌드·배포된다 (QUEUED 모드의 동작)
• B마지막 push가 진행 중인 이전 실행을 ABANDONED 상태로 취소하고 자신이 실행된다. 결과적으로 마지막 commit만 실행 완료된다
• C10개가 큐에 순서대로 쌓여 하나씩 직렬로 실행되며 모든 commit 이력이 보존된다 (QUEUED 모드의 동작)
• D동시에 10개 실행이 병렬로 시작되어 독립적으로 완료된다 (PARALLEL 모드의 동작, 독립 대상 필요)

한 팀이 멀티 리전 파이프라인을 구성했다. ap-northeast-2에서 빌드하고 us-east-1과 eu-west-1에 동시에 배포한다. 두 리전 배포 Action이 실패하는 경우 확인해야 할 사항은?

• Aus-east-1과 eu-west-1에 각각 Artifact S3 버킷과 KMS 키가 ArtifactStores 배열에 구성되어 있는지 확인
• BVPC Peering이 리전 간 구성되어 있는지 확인
• CRoute 53이 세 리전에 모두 있는지 확인
• DLambda 함수가 세 리전에 모두 배포되어 있는지 확인

한 파이프라인에서 Build Action이 여러 마이크로서비스 Docker 이미지를 빌드하고 각 이미지의 태그를 후속 Deploy Action에서 사용해야 한다. V2 Pipeline에서 가장 적절한 방법은?

• A각 서비스별 별도 파이프라인 생성
• BCodeBuild의 exported-variables에 SERVICE1_TAG, SERVICE2_TAG 등을 선언하고 Deploy Action에서 #{BuildVariables.SERVICE1_TAG} 형태로 각각 참조
• CArtifact zip 파일 안에 tags.json을 포함시키고 Deploy Action이 읽음
• D환경 변수를 SSM Parameter Store에 저장하고 Deploy Action이 읽음

"GitHub Actions로 PR 빌드와 테스트를 실행하고, main 브랜치 머지 시에만 CodePipeline으로 prod 배포"하는 하이브리드 패턴에서 GitHub Actions에서 CodePipeline으로의 핸드오프를 구현하는 가장 보안적이고 단순한 방법은?

• AGitHub Actions에서 AWS CLI로 start-pipeline-execution 직접 호출 (IAM User 액세스 키 사용)
• BGitHub Actions에서 OIDC Provider를 통해 IAM Role을 AssumeRole → start-pipeline-execution 호출 (임시 자격 증명)
• CECR에 이미지 push → CodePipeline의 Source Stage가 ECR 이벤트 감지 → 파이프라인 자동 시작
• DGitHub Actions에서 SNS Topic에 메시지 publish → Lambda가 start-pipeline-execution 호출

StackSets의 SERVICE_MANAGED 모드로 50개 계정에 배포 중 다음 에러가 발생한다: "You must be an administrator of an Organization to use this operation." 원인은?

• AStackSet 템플릿에 IAM CAPABILITY_NAMED_IAM 미지정 등 검증 오류가 있어 Organizations 권한 검사 이전에 실패한다
• BSERVICE_MANAGED StackSet은 Organizations 관리 계정(Management Account) 또는 Delegated Admin 계정에서만 실행할 수 있는데, 현재 실행 계정이 이 중 어느 쪽도 아니다
• C대상 계정이 Organizations에 속하지 않아 trusted access가 활성화되지 않았고, StackSets와 Organizations 간 연동이 끊겨 있다
• DStackSet의 MaxConcurrentPercentage가 너무 높아 동시 배포 한도를 초과하며 권한 오류로 표면화된다

한 팀이 "Lambda Invoke Action에서 외부 배포 시스템을 호출하고 완료까지 45분이 걸린다"는 문제에 직면했다. Lambda의 15분 한도를 우회하면서 파이프라인이 45분 완료를 기다리게 하는 방법으로 잘못된 것은?

• AStep Functions Action으로 전환 — State Machine 안에서 45분 작업을 처리
• BLambda timeout을 45분으로 설정 후 기존 방식 유지
• CLambda가 즉시 SQS에 작업을 디스패치하고 put_job_success_result를 호출 → 별도 Worker가 완료 후 파이프라인 외부 시스템을 통해 알림 (단방향, 파이프라인은 성공으로 처리)
• DLambda가 즉시 Step Functions WaitForTaskToken 실행을 시작하고 put_job_success_result 호출 → 45분 후 외부 시스템이 Step Functions의 SendTaskSuccess 호출