AWS DevOps Engineer Professional 자격 시험 응시 후기
최근 약 2주동안 AWS DevOps Engineer Professional 자격 취득을 위한 학습을 진행하여, 어제 시험을 치르고 다행히 합격하여 자격증을 취득했는데요. 자격 시험 준비하며 체크했던 부분과 실제 시험을 치렀던 경험에 대한 후기를 공유하고자 합니다. 도움이 될지는 모르겠지만 혹시라도 AWS DevOps Engineer Professional 자격증 취득에 관심이 있으신 분은 한번 읽어보시면 좋을 것 같습니다.
1. AWS DevOps Engineer Professional 자격 시험 관련 공식 안내
자격 시험과 관련된 공식적인 내용은 아래 페이지에서 확인이 가능합니다. 시험 안내서에도 나와있듯 AWS DevOps Engineer Professional 시험은 6개 도메인으로 구성되어 있고, 각 도메인에 해당하는 AWS 서비스에 대한 이해도 및 목적 달성 방법에 대해 물어보는 내용으로 되어 있습니다.
도메인 1: SDLC 자동화 22%
도메인 2: 구성 관리 및 Infrastructure as Code 19%
도메인 3: 모니터링 및 로깅 15%
도메인 4: 정책 및 표준 자동화 10%
도메인 5: 인시던트 및 이벤트 대응 18%
도메인 6: 고가용성, 내결함성 및 재해 복구 16%
합계 100%
자격 시험 안내 공식 페이지
https://aws.amazon.com/ko/certification/certified-devops-engineer-professional/
공식 시험 안내서
https://d1.awsstatic.com/ko_KR/training-and-certification/docs-devops-pro/AWS-Certified-DevOps-Engineer-Professional_Exam-Guide.pdf
공식 샘플 문제
https://d1.awsstatic.com/ko_KR/training-and-certification/docs-devops-pro/AWS-Certified-DevOps-Engineer-Professional_Sample-Questions.pdf
2. AWS DevOps Engineer Professional 자격 시험 관련 주요 AWS 서비스
기억에 남아있는 내용 안에서 시험 문제 및 기출 문제에 많이 보인 순서대로 AWS 서비스 및 물어보는 내용을 간략히 적어보았습니다.
1) AWS Code 시리즈(Codecommit, Codebuild, Codedeploy, Codepipeline)
첫 번째 도메인이 SDLC(소프트웨어 개발 수명 주기) 자동화인만큼 코드 시리즈를 통한 CI/CD 자동화에 대한 내용이 가장 많이 나왔습니다. 개발 단계와 프로덕션 단계를 구분하여 브랜치(분기)를 생성하고 개발이 완료된 커밋을 마스터 브랜치에 병합하는 내용으로 전반적인 Code 버전 관리에 대한 내용이 있었으며, Github와 같이 외부 시스템을 코드 저장소로 활용하여 파이프라인을 구성하는 방법, 파이프라인을 통한 자동 배포 간 수동 승인 단계를 추가하는 방법, Codebuild 단계에서 Lambda 혹은 jenkins를 통한 테스트 수행, Codedeploy 를 통해 배포 후 트래픽을 허용하기 전 사용자 스크립트 활용하여 테스트 수행 등의 내용이 있었습니다. 또한 배포 단계에서 Codedeploy.default.OneAtOnce 등과 같이 한번에 얼마나 많은 대상에 배포를 수행할지, 혹은 인플레이스 배포 - 블루/그린배포와 같이 배포 그룹을 어떻게 설정할지에 대한 이해도를 묻는 문제들도 있었습니다.(각 배포 전략의 장/단점에 따라 선택)
2) CloudWatch Events(혹은 규칙) + Lambda 를 통한 자동화
AWS DevOps Engineer Professional 시험의 큰 흐름이 자동화에 대한 내용이기 때문에 CloudWatch Events + Lambda 를 활용하여 AWS 리소스에 특정 이벤트 발생 시 Lambda를 통해 해당 이벤트를 해결하거나, SNS를 통해 관리자에게 알림을 보내는 등의 자동화 내용이 많이 있었습니다. 특히 Lambda 의 경우 API Gateway를 통해 외부에서 접근하는 API로 사용하는 방법도 있으나, 해당 유형보다는 Lambda만을 활용하여 여러 AWS 서비스 간 작업을 연결해주는 역할이 주요했습니다.
3) Cloudformation
두 번째 도메인의 내용과 같이 Infrastructure As a Code 관련 서비스인 Cloudformation 에 대한 내용이 더러 있었습니다. 특히 한 계정이 아닌 다수 계정에 대해 Cloudformation을 통해 스택을 배포하거나, 여러 리전에 걸쳐 Cloudformation 스택을 배포하는 등의 내용이 있었습니다. 또한 중첩 스택, StackSets 와 같이 Cloudformation의 하위 개념들도 숙지하면 좋을 것으로 생각됩니다. 추가로 서로 다른 여러 역할(개발자, 관리자, 초보자 등)을 가진 IAM 그룹간 Cloudformation 권한 및 AWS 리소스에 대한 권한을 달리 부여하여 리소스를 제한하도록 하는 방법에 대한 내용도 있었습니다.
4) Elastic Beanstalk
Cloudformation 을 통해 인프라 관리도 가능하지만 조금 더 작은 단위인 애플리케이션(EC2 인스턴스) 및 기타 리소스(AutoScaling, ALB)를 Elastic Beanstalk 을 통해 적은 오버헤드로 관리할 수 있는 방법에 대해 물어보는 문제도 있었습니다. Elastic Beanstalk 의 경우 2티어(앱 + DB) 환경에서 사용이 가능하며, 3티어(웹 + 앱 + DB) 환경에서는 적용이 불가하니 이 점을 참고하면 좋을 것 같습니다. 특히 Elastic Beanstalk 의 배포 전략(블루/그린, 롤링 업데이트, 대체 불가능 배포, 선형 배포, 카나리아 배포 등)에 대한 이해도를 물어보는 질문도 있었습니다. 각 배포 전략의 차이는 공식 문서를 통해 한번 숙지해보는 것이 좋을 것으로 생각됩니다.
5) AutoScaling 그룹
자동화와 함께 서비스의 탄력성 및 내구성을 높이기 위해 AutoScaling 에 대한 내용을 물어보는 질문들도 있었습니다. 특히 AutoScaling 수명 주기 후크를 활용하여 인스턴스 스케일 아웃 혹은 스케일 인이 발생할 때, 인스턴스 pending/terminate 단계에서 특정 Lambda 함수 혹은 스크립트를 실행하여 인스턴스에서 파일 혹은 정보를 확인하는 등의 내용이 종종 있었습니다.
6) RDS, Route53 을 활용한 DR 구성
여섯 번째 도메인의 내용으로 특정 RPO, RTO를 제시하고 해당 조건에 맞는 가장 비용 효율적인 리전 간 DR 구성 방법을 물어보는 질문들이 있었습니다. 예를 들어 리전 간 읽기 전용 복제본은 RPO가 짧거나(10분 등) RTO가 짧은(30분 등) 경우 사용이 가능하며, Lambda 함수를 통한 수동 스냅샷 생성 및 리전간 스냅샷 복사를 자동화하여 장애 시 DB 인스턴스를 생성하는 방법은 RPO가 한 시간 이상이거나, RTO가 두 시간~네 시간 이상인 경우 사용이 가능합니다. 물론 리전간 읽기 전용 복제본을 생성하여 장애 시 독립 DB 인스턴스로 승격하는 것이 RPO는 가장 짧으나, 목표로하는 RPO가 긴 경우에는 비용 효율적인 측면에서 스냅샷 생성 및 복사 자동화가 더 정답에 가깝다고 할 수 있습니다. RDS 중 AWS Aurora에 대한 대한 내용은 간혹 있었으나, 주된 내용은 아니었습니다. 또한 Route53 의 상태 확인 및 장애조치 레코드, 지연시간 레코드, 가중치 기반 레코드 등을 활용하여 각 상황에 맞게 레코드를 구성하는 방법에 대한 문제도 더러 있었습니다. 각 레코드의 특징을 이해하는 것이 도움이 되며, 해당 유형의 문제는 대체로 쉬운 편입니다.
7) AWS Config, AWS Trusted Advisor, AWS Inspector, AWS Personal Health Dashboard
위에 나열된 서비스 모두 AWS 리소스를 효과적으로 관리하거나 보안적인 지표를 확인하는 등의 서비스입니다. 디테일하게 가면 끝이 없지만(잘 모르기도 하고 실무 활용 경험도 없어서) 각 서비스가 대표적으로 어떤 목적을 위해 사용되는지 알아두면 좋을 것 같습니다.
AWS Config - "규정을 준수하는 지 확인해야한다.", "모든 EBS 볼륨(혹은 S3 버킷)이 암호화 되었는지 확인해야한다" 등의 내용이 나오면 거의 config가 정답이었습니다.
AWS Trusted Advisor - 미사용 리소스를 확인하거나, 하위 서비스인 AWS Limit Monitor 를 통해 리소스 사용량을 추적하는 등의 내용이 나왔습니다.
AWS Inspector - 어플리케이션(EC2 인스턴스)의 보안 검사 관련 내용이 나오는 경우가 있었습니다.
AWS Personal Health Dashboard - 간혹 AWS 계정 관련 이벤트를 확인하는 등의 활동에 대해 물어보는 경우가 있었습니다.
8) AWS Systems Manager, AWS Secrets Manager
대규모 환경에서의 다수 인스턴스를 관리하는 데에 효과적인 서비스이며, 여러 하위 항목을 가지고 있기 때문에 문제가 많이 나왔습니다. Run Command 를 통해 다수 인스턴스에 커맨드를 실행하거나, Patch Manager 를 통해 유지관리 기간을 설정하고 다수 인스턴스에 패치를 적용하거나, Parameter Store 를 통해 배포 파일에 포함되면 보안상 좋지 않은 민감 정보에 대한 파라미터를 저장하며 변수로 활용하거나 하는 등의 내용이 있었습니다. 또한 Parameter Store 와 함께 RDS의 비밀번호를 저장하기 위해 AWS Secrets Manager를 함께 활용하는 등의 보기도 있었습니다. AWS Secrets Manager의 경우 KMS를 통해 암호화되므로, 해당 암호화 키에 대한 권한을 부여하는 IAM 정책 설정 관련 보기도 있었습니다.
9) AWS DynamoDB
NoSQL 데이터베이스이며, 서버리스 서비스이기 때문에 API Gateway + Lambda 서비스와 함께 많이 쓰입니다. 여러 리전에 데이터 동기화가 필요한 경우 글로벌 테이블이 거의 정답입니다.
10) ECS
컨테이너 환경에 대한 설명으로 문제가 시작되는 경우 ECS를 활용하는 경우가 많았습니다. 이 때, AutoScaling 및 서비스 AutoScaling 등을 활용하여 탄력적으로 구성하는 것에 대한 내용이 종종 있었으며, Copdepipeline을 통해 ECR에 빌드된 이미지를 업로드하는 등의 CI/CD 관련 내용이 있었습니다. 반면에 Kubernetes(혹은 EKS) 관련 문제는 거의 없었습니다. 1문제 보긴 했는데 EKS의 로그를 S3로 내보내는 설정 관련 내용이었습니다.
11) S3
AWS DevOps Engineer Professional 시험에서는 다른 AWS 서비스에서 S3로 로그를 내보내고 Athena 등을 활용하여 로그를 분석하는 등의 용도로 쓰였습니다. S3 버킷에 대한 버킷 정책 구성 및 암호화 관련 내용도 조금 있었습니다.
12) CloudTrail
문제가 거의 안나오긴 했는데 종종 보기로 CloudTrail 을 통해 AWS API 이벤트를 확인하고 로그를 추적/필터하는 등의 내용이 있었습니다. 하지만 유사한 문제에서 거의 CloudWatch Events가 정답이 경우가 많고 CloudTrail 은 오답인 경우가 많았습니다.(아마 동일한 목적을 달성하기 위해 더 복잡하게 구성해야하기 때문인 것 같습니다.)
13) Kinesis Data Stream, Kinesis Data Firehose
대체로 실시간으로 로그 혹은 데이터를 스트리밍하거나, 스티리밍된 데이터를 S3 혹은 RedShift(데이터 웨어하우스), Elastic Search(데이터 분석) 등의 서비스로 로드하는 역할로 쓰이는데 저도 실무 적용 경험이 없는 서비스라 개념적인 부분만 이해하였습니다. 종종 보기로 나오며 해당 보기가 정답인 경우도 종종 있었습니다.
14) API Gateway
Codedeploy의 배포 대상으로 종종 등장합니다. API Gateway 환경에서도 카나리아 배포 등의 배포 전략이 사용 가능하여 배포 전략에 대해 물어보는 문제가 간혹 있었습니다.
3. 학습 및 시험 팁
기출 문제 풀이 사이트(https://www.examtopics.com/exams/amazon/aws-devops-engineer-professional/view/)에서 기출 문제를 풀며 학습을 진행했습니다. 다만, 사이트에서 제공하는 솔루션(정답)이 정답이 아닌 경우가 거의 절반이라 모든 문제를 풀어볼 때, Discussion 버튼을 눌러 댓글로 달린 유저들의 의견을 참고해야합니다. 사이트에 문제는 대략 500개 이상 준비되어 있는데 300문제 이상 넘어가면 문제가 오래되기도 했고, Discussion에 달려있는 댓글 수가 거의 적어서 정답임을 확신하기가 매우 힘듭니다. 그래서 1~200번 혹은 1~300번정도를 풀고 다시 1번으로 돌아가서 문제를 복습하는 방법으로 진행했습니다. 실제 시험에서 기출 문제의 비중은 체감상 50% 혹은 50% 이상으로 느껴졌습니다. 다만, 답만 외우는 것보단 유저들이 달아놓은 AWS 공식 문서 혹은 AWS 공식 블로그 링크를 통해 간략하게나마 이해하고 넘어가는 것이 도움이 될 것으로 생각됩니다.
시험에서 물어보는 것은 대체로 어떤 상황을 제시하고 해당 구성을 자동화하기 위해서는 어떻게 해야하는지 물어보는 내용이 많았습니다. CI/CD 자동화 혹은 보안 및 규정 준수 자동화, 알림 등의 내용이 주를 이뤘습니다. 또한 문제 말미에 "가장 적은 오버헤드로", "가장 비용 효율적으로", "가장 변경 사항을 적게 발생시키면서" 등의 내용이 붙어있는 경우 목적을 달성하는 것이 가능한 보기가 2개 이상일 수 있습니다. 해당 경우 위에서 언급한 "가장 XX하게" 라는 조건에 가까운 보기를 골라야 정답입니다.
4. 마치며
두서없이 적었는데 AWS DevOps Engineer Professional 자격 시험에 관심 있으신 분에게 도움이 되었으면 좋겠습니다.