지속적 배포, 자동화, 보안 거버넌스 등 고도화된 DevOps 역량을 검증.
AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CodeCommit, CI/CD 파이프라인, Amazon ECR
AWS CloudFormation, AWS CDK, AWS Systems Manager, AWS OpsWorks, Amazon EC2 Image Builder, AWS Service Catalog
Multi-AZ·Multi-Region 설계, Auto Scaling, Amazon Route 53 장애 조치, AWS Backup, RTO·RPO 전략, 재해 복구 패턴
Amazon CloudWatch, AWS CloudTrail, Amazon EventBridge, AWS X-Ray, Amazon OpenSearch Service, VPC Flow Logs
Amazon EventBridge 규칙, AWS Lambda 자동 복구, AWS Systems Manager 자동화, Amazon SNS 알림, AWS Health Dashboard, Amazon GuardDuty 대응
AWS IAM·SCP·권한 경계, AWS KMS·Secrets Manager, AWS Config 규칙, AWS Security Hub, Amazon Inspector, AWS CloudTrail 거버넌스
무료 샘플 세트의 실전형 문제를 바로 풀어보세요. 모든 정답에 상세 해설이 제공됩니다.
한 미디어 스타트업이 여러 개의 모놀리식 애플리케이션을 EC2 인스턴스에서 수동으로 배포하고 운영하고 있습니다.
배포 시마다 운영 엔지니어가 서버에 직접 접속하여 패키지를 설치하고 설정 파일을 수정하며, 배포 실패 시 수동으로 롤백하는 데 수 시간이 소요됩니다. 경영진은 이 애플리케이션들을 컨테이너화하여 배포 일관성을 확보하고, 코드 변경 시 빌드부터 테스트, 프로덕션 배포까지 자동화된 CI/CD 파이프라인을 구축하기를 요구하고 있습니다. 동시에 운영팀의 인원이 제한되어 있어 컨테이너 오케스트레이션 인프라의 관리 부담을 최소화해야 합니다.
이 요구사항을 충족하면서 운영 오버헤드를 최소화하는 컨테이너 기반 CI/CD 현대화 방안으로 가장 적절한 것은 무엇입니까?
정답: C. ECS Fargate + CodePipeline + CodeBuild
정답을 고르려면 먼저 ECS Fargate와 ECS EC2, 그리고 EKS의 운영 오버헤드 차이를 이해해야 합니다. 이 시나리오에서 핵심 조건은 '컨테이너화', '빌드부터 프로덕션 배포까지 자동화된 CI/CD', '컨테이너 오케스트레이션 인프라 관리 부담 최소화'입니다. ECS Fargate + CodePipeline + CodeBuild 조합은 Fargate가 EC2 인스턴스 프로비저닝·패치·스케일링을 AWS에 완전 위임하고, CodePipeline이 코드 커밋부터 빌드, 테스트, 배포까지 파이프라인을 오케스트레이션하며, CodeBuild가 서버리스 빌드 환경에서 Docker 이미지를 빌드해 ECR에 푸시합니다.
ECS Fargate는 컨테이너 실행에 필요한 기반 EC2 인스턴스를 AWS가 완전히 관리하는 서버리스 컨테이너 실행 모드로, 태스크 정의에서 vCPU(0.25~16 vCPU)와 메모리(512MB~120GB) 조합만 지정하면 전용 격리 환경이 자동 프로비저닝됩니다. CodePipeline은 Source → Build → Test → Deploy 단계를 정의하고 각 단계에서 CodeBuild, ECR, ECS와 통합됩니다. CodeBuild는 buildspec.yml의 명령어로 이미지를 빌드하여 ECR에 푸시하고, ECS 서비스에 CodeDeploy 블루/그린 배포를 연동하면 트래픽 전환과 롤백이 자동화됩니다.
보기 1의 ECS EC2는 EC2 인스턴스 클러스터를 직접 관리해야 하므로 AMI 패치, 인스턴스 확장 정책 관리 등 추가 운영 오버헤드가 발생합니다. 보기 2의 EKS + Jenkins + Helm은 EKS 클러스터 노드 그룹, Jenkins 마스터·에이전트 서버, Helm 차트 세 계층의 관리 부담이 발생하여 '운영 부담 최소화' 조건과 가장 거리가 멉니다. 보기 4의 Lambda 컨테이너 이미지는 최대 15분 실행 시간 제한과 이미지 크기 10GB 제한으로 장시간 실행되는 모놀리식 웹 애플리케이션에 적합하지 않습니다. 시험에서 '컨테이너화 + CI/CD 자동화 + 관리 오버헤드 최소화'가 함께 나오면 Fargate + CodePipeline + CodeBuild를 먼저 선택하세요.
한 온라인 교육 기업이 CloudFormation으로 관리되는 Auto Scaling 그룹에서 웹 애플리케이션을 운영하고 있습니다.
새로운 AMI가 릴리스될 때마다 런치 템플릿을 업데이트하고 기존 인스턴스를 교체해야 하지만, 교체 과정에서 동시에 너무 많은 인스턴스가 종료되면 서비스 용량이 부족해져 사용자 응답 시간이 급격히 증가합니다. 운영팀은 CloudFormation 스택 업데이트 시 항상 최소 수의 정상 인스턴스를 유지하면서 점진적으로 인스턴스를 교체하기를 원하며, 이 과정을 수동 개입 없이 자동으로 수행해야 합니다.
이 요구사항을 충족하는 CloudFormation 기반의 가장 적절한 업데이트 전략은 무엇입니까?
정답: B. AutoScalingRollingUpdate
이 시나리오에서 가장 중요한 조건은 'CloudFormation 스택 업데이트 시', '점진적 인스턴스 교체', '최소 정상 인스턴스 유지', '수동 개입 없이 자동'입니다. CloudFormation의 AutoScalingRollingUpdate 정책은 UpdatePolicy 속성 아래에 정의되며, MaxBatchSize로 한 번에 교체할 최대 인스턴스 수를, MinInstancesInService로 교체 중 유지해야 할 최소 정상 인스턴스 수를 선언적으로 지정할 수 있습니다. 이는 CloudFormation 네이티브 기능으로 추가 도구 없이 스택 업데이트만으로 점진적 교체가 자동 수행됩니다.
AutoScalingRollingUpdate 정책의 핵심 파라미터는 세 가지입니다. MaxBatchSize는 동시에 교체할 최대 인스턴스 수이고, MinInstancesInService는 교체 진행 중 서비스 상태를 유지해야 하는 최소 인스턴스 수이며, WaitOnResourceSignals를 true로 설정하면 새 인스턴스에서 cfn-signal이 수신될 때까지 다음 배치 교체를 대기합니다. CloudFormation은 이 파라미터에 따라 인스턴스를 배치 단위로 순차 교체하면서 MinInstancesInService 수 아래로 내려가지 않도록 자동으로 속도를 조절합니다.
시험에서 'CloudFormation', '인스턴스 점진적 교체', '최소 정상 인스턴스 유지'가 함께 언급되면 AutoScalingRollingUpdate를 먼저 선택하세요. AutoScalingReplacingUpdate는 기존 그룹 전체를 새 그룹으로 교체하는 방식으로 교체 중 두 배 용량이 필요하므로 '점진적 교체'가 아닙니다. CloudFormation StackSets는 멀티 계정·멀티 리전 배포에 특화되어 있어 단일 스택의 Auto Scaling 그룹 내 인스턴스 교체와 무관합니다.
한 핀테크 기업이 ALB 뒤에서 다수의 EC2 인스턴스로 구성된 웹 애플리케이션을 운영하고 있습니다.
이 애플리케이션은 백엔드 데이터베이스와 외부 결제 API에 의존하고 있으며, 최근 데이터베이스 연결 장애 시에도 ALB의 기본 TCP 헬스 체크가 인스턴스를 정상으로 판단하여 사용자에게 오류 응답이 전달되는 문제가 발생했습니다. 운영팀은 인스턴스 자체뿐 아니라 해당 인스턴스의 핵심 종속 서비스 연결 상태까지 반영하는 헬스 체크를 구현하여, 종속 서비스 장애 시 해당 인스턴스로의 트래픽이 자동으로 차단되기를 원합니다.
기존 인프라 변경을 최소화하면서 이 요구사항을 충족하는 가장 적절한 방법은 무엇입니까?
정답: C. ALB HTTP 심층 헬스 체크 엔드포인트
정답을 고르려면 먼저 ALB의 TCP 헬스 체크와 HTTP 헬스 체크의 차이를 이해해야 합니다. TCP 헬스 체크는 포트가 열려 있는지만 확인하므로 데이터베이스 연결이 끊겨도 애플리케이션 프로세스가 살아있으면 인스턴스를 정상으로 판단합니다. ALB HTTP 심층 헬스 체크는 애플리케이션이 구현한 특정 경로의 HTTP 응답 코드를 기반으로 인스턴스 정상 여부를 판단하며, /health 엔드포인트에서 데이터베이스 및 결제 API 연결 상태를 확인하여 장애 시 503을 반환하면 ALB가 해당 인스턴스를 대상 그룹에서 자동 제외합니다. 기존 ALB 인프라 변경 없이 Target Group의 헬스 체크 방식만 HTTP로 전환하고 애플리케이션에 /health 엔드포인트를 추가하면 되므로 '기존 인프라 변경 최소화' 요구사항을 충족합니다.
ALB HTTP 헬스 체크는 Target Group 설정에서 경로, 정상 HTTP 상태 코드 범위, 점검 간격(Interval), 정상·비정상 임계값(Healthy/Unhealthy threshold), 타임아웃을 구성합니다. 정상 임계값을 2~3으로 설정하면 일시적 연결 불안정에 의한 오탐을 방지하고, 비정상 임계값에 도달한 인스턴스는 Target Group에서 자동 제외됩니다. 이후 헬스 체크가 정상 임계값을 회복하면 인스턴스가 자동으로 재편입되어 자가 복구 메커니즘을 구현합니다.
시험에서 Route 53 Failover(보기 1)와 혼동하기 쉬운데, Route 53은 DNS 수준 장애 조치로 개별 인스턴스 단위 세밀한 트래픽 제어가 불가능하고 DNS TTL로 즉각 차단이 어렵습니다. CloudWatch Alarm + Auto Scaling 교체(보기 2)는 비정상 인스턴스를 새 인스턴스로 교체하므로 수 분이 소요되며 종속 서비스 장애 원인이 지속되는 한 새 인스턴스도 동일 문제가 발생합니다. 'ALB 기반 + 종속 서비스 상태 감지 + 즉각 차단' 요구사항이 나오면 HTTP 심층 헬스 체크 엔드포인트가 핵심 패턴입니다.
한 금융 기관이 CodePipeline과 CodeBuild를 사용하여 CI/CD 파이프라인을 운영하고 있습니다.
빌드 단계에서 CodeBuild 프로젝트가 특정 S3 버킷에서 서드파티 라이브러리 아카이브를 다운로드해야 하지만, 보안팀은 해당 빌드 환경이 다른 S3 버킷이나 AWS 리소스에는 접근할 수 없도록 최소 권한 원칙을 엄격하게 적용할 것을 요구하고 있습니다. 또한 빌드 환경에 장기 자격 증명을 저장하는 것은 감사 정책상 금지되어 있습니다.
이 요구사항을 충족하면서 CodeBuild가 해당 S3 버킷에 안전하게 접근하도록 구성하는 가장 적절한 방법은 무엇입니까?
정답: C. CodeBuild Service Role 최소 권한
한 금융 기관의 CodeBuild 프로젝트가 특정 S3 버킷에 접근해야 하는 상황에서 두 가지 핵심 제약이 있습니다. 특정 버킷 외 다른 리소스 접근을 차단하는 최소 권한 원칙과, 장기 자격 증명을 빌드 환경에 저장하지 않아야 하는 감사 정책입니다. 보기 3의 CodeBuild Service Role에 최소 권한 IAM 정책을 부여하는 방식이 두 조건을 동시에 충족합니다. CodeBuild는 빌드 실행 시 지정된 Service Role의 권한으로 AWS STS에서 임시 자격 증명을 자동 발급받아 사용하므로 장기 자격 증명이 빌드 환경에 저장되지 않습니다.
CodeBuild Service Role은 IAM 역할로, 빌드 실행 중 AWS STS(Security Token Service)가 임시 자격 증명을 동적으로 발급하여 CodeBuild가 AWS 리소스에 접근할 수 있도록 합니다. 이 역할의 IAM 정책에서 Resource 필드를 특정 S3 버킷 ARN(arn:aws:s3:::my-libs-bucket/*)으로 제한하고 s3:GetObject 권한만 부여하면 다른 모든 S3 버킷과 AWS 리소스 접근이 차단됩니다. 임시 자격 증명은 빌드 세션에만 유효하며 빌드 완료 후 자동 만료되어 유출 위험이 최소화됩니다.
시험에서 CodeBuild의 AWS 리소스 접근 문제는 반드시 Service Role + IAM 정책으로 해결합니다. '최소 권한'과 '장기 자격 증명 금지'가 함께 나오면 Service Role이 유일한 정답입니다. 환경변수 Access Key는 장기 자격 증명 저장 위반이고, Secrets Manager에 저장된 자격 증명도 결국 장기 자격 증명이므로 감사 정책을 완전히 해결하지 못합니다.
한 대형 전자상거래 기업이 수백 대의 EC2 인스턴스를 운영하고 있으며, 정기적인 비용 검토에서 상당수 인스턴스가 평균 CPU 사용률 5% 미만으로 과다 프로비저닝되어 있다는 보고가 있었습니다.
운영팀은 수동으로 각 인스턴스의 CloudWatch 지표를 분석하여 적절한 인스턴스 타입을 결정하고 있으나, 인스턴스 수가 많아 이 작업에 수주가 소요되고 있습니다. 경영진은 비용 절감을 위해 워크로드 특성에 맞는 인스턴스 사이징 권장 사항을 자동으로 도출하되, 성능 저하 없이 적용할 수 있어야 한다고 요구하고 있습니다.
운영 오버헤드를 최소화하면서 이 요구사항을 충족하는 가장 적절한 방법은 무엇입니까?
정답: B. AWS Compute Optimizer 권장 사항
AWS Compute Optimizer는 이 시나리오의 자동화·성능 위험 없는 사이징·최소 운영 오버헤드 세 가지 요구사항을 동시에 충족합니다. Compute Optimizer는 CloudWatch 지표(CPU 사용률, 네트워크 I/O, 디스크 I/O, 메모리 — CloudWatch 에이전트 필요)를 머신러닝으로 분석하여 각 인스턴스별 최적 타입 권장 사항과 성능 위험 수준(낮음·중간·높음)을 자동 도출합니다. 수백 대 인스턴스를 수주 동안 수동 분석할 필요 없이 즉시 조직 전체 현황을 파악하고 성능 저하 없이 다운사이징 가능한 인스턴스를 정확히 식별합니다.
Compute Optimizer는 기본 14일 이상의 지표를 분석하며 향상된 인프라 지표(Enhanced Infrastructure Metrics) 옵션으로 최대 93일까지 확장하여 주기적 워크로드 패턴도 포착합니다. 권장 결과는 현재 타입, 권장 타입, 예상 비용 절감액, 성능 위험 수준을 인스턴스별로 제공하며 '과다 프로비저닝·최적·과소 프로비저닝·데이터 없음' 4가지 등급으로 분류합니다. AWS Organizations 차원의 opt-in으로 조직 전체 계정에 일괄 적용할 수 있어 멀티 계정 환경에서도 중앙화된 권장 사항 관리가 가능합니다.
시험에서 Trusted Advisor(보기 3)와 Cost Explorer Rightsizing(보기 4)을 구분해야 합니다. Trusted Advisor는 14일 평균 CPU 10% 미만 기준의 단순 임계값 규칙으로 구체적 대체 인스턴스 타입을 권장하지 않으며 Business 이상 Support 플랜이 필요합니다. Cost Explorer Rightsizing은 비용 중심 분석으로 성능 위험 분류가 덜 정교합니다. '대규모 EC2 + ML 기반 자동 사이징 + 성능 위험 분류 + 최소 운영' 키워드 조합이 나오면 Compute Optimizer가 정답입니다.
AWS Certified DevOps Engineer - Professional (DOP-C02) 시험은 총 75문항으로 구성되어 있으며, 시험 시간은 180분입니다.
DOP-C02 시험의 합격 점수는 1000점 만점 중 750점 이상입니다.
DOP-C02 샘플 세트 20문항은 해설까지 포함해 무료로 풀 수 있습니다. 280문항 이상의 전체 문제 세트는 CloudMasterIT 구독으로 이용할 수 있습니다.
DOP-C02 자격증은 취득 후 3년간 유효하며, 이후 재인증이 필요합니다.