기준: SOA-C02 시험 가이드오류 제보
Week 5는 AWS Systems Manager라는 거대한 운영 플랫폼 전체를 훑었다. Managed Instance의 등록 조건에서 시작해, 명령 자동화(Run Command), 상태 관리(State Manager), 예약 작업(Maintenance Window), 패치 자동화(Patch Manager), 설정 중앙화(Parameter Store), 키 없는 접속(Session Manager), 그리고 복잡한 운영 워크플로(Automation Runbook)까지. 이 모든 도구들은 하나의 목표로 수렴한다: 운영자가 반복적이고 위험한 수동 작업에서 벗어나 중요한 것에 집중할 수 있게 하는 것.
오늘은 실제 시험에서 나오는 시나리오 형식으로 Week 5 전체를 복습한다. 각 문제는 단순히 "어떤 도구인가"를 묻는 것이 아니라 "왜 이 도구인가"를 논리적으로 추론하는 훈련이다. SOA-C02는 선택지 네 개 모두가 SSM 도구인 경우가 많아, 정확한 역할 구분이 합격을 가른다.
AmazonSSMManagedInstanceCore) + 네트워크 도달mi-xxx ID로 EC2와 동일하게💡 관련 이론: SSM은 분산 시스템의 "Control Plane vs Data Plane" 분리 아키텍처를 정확히 구현한다. SSM API 계층(명령 등록, 상태 조회)이 Control Plane이고, SSM Agent(실제 명령 실행, heartbeat)가 Data Plane이다. Control Plane 장애(SSM 서비스 이슈)는 이미 진행 중인 Agent 작업에 영향을 주지 않는다. Werner Vogels(AWS CTO)가 re:Invent에서 반복하는 "control plane/data plane separation"의 실제 구현 사례다.
명령 실행 도구 비교:
| 특성 | Run Command | State Manager | Maintenance Window |
|---|---|---|---|
| 실행 방식 | 수동 트리거 (일회성) | 스케줄 + 신규 인스턴스 자동 | 예약 시간에 자동 |
| Drift 교정 | X | O | X |
| 신규 인스턴스 자동 포함 | X | O (태그 기반) | 태그 기반 |
| 복수 Task 순서 보장 | X | X | O (Priority) |
| 즉시 실행 가능 | O | O (start-associations-once) | 수동 트리거 가능 |
| 주 사용 시나리오 | 긴급 일괄 명령 | 설정 표준화 유지 | 패치/백업/유지보수 |
시크릿 관리 도구 비교:
| 특성 | Parameter Store Standard | Parameter Store Advanced | Secrets Manager |
|---|---|---|---|
| 비용 | 무료 | $0.05/파라미터/월 | $0.40/시크릿/월 |
| 최대 값 크기 | 4KB | 8KB | 64KB |
| 자동 회전 | X | X | O (RDS/Redshift/Lambda) |
| 크로스 리전 복제 | X | X | O |
| Parameter Policy (만료/알림) | X | O | X |
| 버전 관리 | O | O | O |
| CFn/Lambda/EC2 통합 | O | O | O |
접속 방식 비교:
| 특성 | SSH + Bastion | Session Manager | EC2 Instance Connect |
|---|---|---|---|
| 포트 22 필요 | O | X | O |
| SSH 키 관리 | O (키 분배) | X (IAM 기반) | X (일시적 키) |
| 자동 세션 로깅 | 별도 구성 필요 | O (S3/CW Logs) | X |
| 사설 VPC 접속 | VPN/DX 필요 | VPC Endpoint | VPC Endpoint |
| MFA 강제 | 어려움 | IAM 정책으로 쉬움 | X |
| 포트 포워딩 | O (수동) | O (document 지원) | X |
Session Manager의 IAM 기반 접근 제어는 단순히 "누가 접속할 수 있는가"를 넘어 "어느 인스턴스에, 어느 시간에, 어떤 명령만" 허용하는 세밀한 정책이 가능하다. 예를 들어 ssm:startSession 조건에 ssm:resourceTag/Environment=prod를 추가하면 prod 태그 인스턴스에만 세션을 허용한다. aws:MultiFactorAuthPresent: true 조건으로 MFA 강제도 가능하다. 기존 SSH 키 방식으로는 이런 세밀한 제어가 매우 어렵다. IAM Identity Center(SSO)와 연계하면 중앙 디렉터리 기반 접근 제어까지 가능하다.
Patch Manager 핵심 비교:
| 항목 | AWS 기본 Baseline | 커스텀 Baseline |
|---|---|---|
| 적용 분류 | Security만 | 선택 가능 |
| 승인 기간 | OS마다 다름 (보통 7일) | 직접 설정 |
| Compliance Level | 설정 불가 | CRITICAL/HIGH/MEDIUM 선택 |
| 거부 패치 | 설정 불가 | 명시적 BLOCK 가능 |
| 멀티 OS | 각 OS별 별도 기본 Baseline | OS별 별도 생성 필요 |
Patch Manager의 "Approval Rules → Maintenance Window → Compliance" 파이프라인은 ISO 27001 A.12.6.1(기술적 취약점 관리) 요건을 자동으로 충족하는 구조다. ISO 27001 인증 감사에서 "취약점 패치 프로세스 자동화 증빙"으로 Patch Compliance 보고서를 직접 제출할 수 있다. CIS Controls v8의 Control 7(취약점 관리)도 같은 맥락이다. AWS Audit Manager의 ISO 27001 및 NIST 800-53 프레임워크가 Patch Manager 데이터를 자동으로 증빙으로 수집한다.
운영 현장에서 반복되는 실수들을 알아두면 시험 함정 문제를 쉽게 피한다.
| 실수 | 증상 | 올바른 방법 |
|---|---|---|
PatchGroup으로 태그 생성 | 패치 그룹이 인식되지 않음 | Patch Group (공백 포함) |
| Baseline만 만들고 Patch Group 연결 안 함 | 기본 Baseline으로 패치됨 | register-patch-baseline-for-patch-group 필수 |
RebootIfNeeded 모르고 NoReboot 사용 | InstalledPendingRebootCount 누적 | Maintenance Window에서 재부팅 포함 |
| Scan과 Install 혼동 | 실제 패치 없이 Compliance만 업데이트 | Install이 실제 적용 |
| 기본 Baseline이 Important 포함한다고 착각 | 보안 감사에서 지적 | 기본 Baseline = Security/Critical만 |
| ApproveAfterDays=0이 즉시 적용 의미하지 않음 | 이해 오류 | =0은 승인 즉시 (릴리즈 당일부터) |
⚠️ 함정:
ApproveAfterDays=0은 "패치가 릴리즈된 당일부터 승인"을 의미한다. 즉 Patch Manager가 다음 번 패치를 실행할 때 그 패치가 이미 릴리즈됐다면 즉시 적용된다. Maintenance Window가 주 1회이면 최대 7일 후에 적용된다. "0일이면 실시간 즉시 적용"이 아니라 "다음 Maintenance Window 실행 시 릴리즈 당일 이후 패치 전부 적용"이다.
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
운영팀이 사설 VPC(인터넷 게이트웨이 없음)에서 EC2 인스턴스를 SSM으로 관리하고 있다. 인스턴스에 AmazonSSMManagedInstanceCore IAM Role이 부착되어 있고 SSM Agent도 실행 중이지만, SSM 콘솔의 Fleet Manager에 인스턴스가 보이지 않는다. 원인은?
문제 2
회사가 Auto Scaling Group을 사용해 웹 서버 용량을 유동적으로 조정한다. 새 EC2 인스턴스가 ASG로 시작될 때마다 자동으로 CloudWatch Agent 설정이 적용되어야 한다. 운영팀이 직접 개입할 필요가 없어야 한다. 가장 적합한 구성은?
문제 3
회사의 패치 정책은 다음과 같다: "prod 환경의 Web 서버(Linux)에는 Security 분류의 Critical 패치만, 공개 후 14일이 지난 것만 적용한다. Patch Group 기반으로 관리한다." 이를 구현하기 위한 최소한의 구성 단계를 올바른 순서로 나열하면?
문제 4
보안팀이 다음 요구사항을 제시했다. "모든 EC2 접속 세션을 감사 가능하게 보관해야 한다. 접속자의 모든 명령어가 로깅되어야 한다. 포트 22는 보안 그룹에서 허용하지 않는다." 운영팀이 개발자들의 접속 요구도 충족시키면서 이 요구사항을 구현할 수 있는 방법은?
문제 5
운영자가 실행 중인 Maintenance Window에서 패치 Task가 Window Duration을 초과할 것 같다. Cutoff가 1시간으로 설정되어 있다. 현재 Window 종료 30분 전이고, 새로운 Task 실행 요청이 왔다. 어떻게 되는가?
문제 6
Lambda 함수가 Production RDS에 접근하기 위해 비밀번호가 필요하다. 현재 Lambda 환경변수에 평문 비밀번호가 저장되어 있다. 보안팀이 개선을 요구했다. 90일마다 자동으로 비밀번호가 변경되어야 하고, Lambda 코드 변경 없이 새 비밀번호가 사용되어야 한다. 가장 적합한 솔루션은?
문제 7
운영팀이 Config Rule을 통해 "공개 S3 버킷"을 감지하고, 감지 즉시 자동으로 버킷의 공개 접근을 차단하려 한다. 어떤 SSM 기능이 가장 적합한가?
문제 8
개발팀이 "설치된 Node.js 버전을 14.x에서 18.x로 전환하는 과정에서, 현재 14.x를 사용하는 prod 서버 목록을 뽑아달라"고 요청했다. 어떤 SSM 기능으로 가장 효율적으로 답할 수 있는가?
문제 9
회사가 Hybrid Activations를 사용해 온프레미스 서버 50대를 SSM으로 관리하고 있다. 이 서버들에 매주 보안 패치를 적용하고 싶다. 어떤 Patch Manager 기능을 사용해야 하며, 온프레미스 서버의 SSM 식별자는 어떤 형식인가?
문제 10
Maintenance Window에서 패치 Task가 실패했다. Concurrency를 10%, Error Tolerance를 5%로 설정했는데 6%의 인스턴스에서 실패가 발생했다. 어떻게 되는가?
문제 11
Parameter Store의 파라미터 /myapp/prod/db/password가 90일 동안 변경되지 않았을 때 자동 알림을 보내고, 이 파라미터가 2027년 1월 1일에 자동으로 삭제되도록 설정하려 한다. 어떤 구성이 필요한가?
문제 12
다음 중 Session Manager가 기존 SSH/Bastion 방식보다 우수한 이유로 올바르지 않은 것은?
Week 6는 IaC 운영의 핵심인 CloudFormation을 중심으로 다룬다.
CloudFormation은 SOA-C02에서 "배포·프로비저닝·자동화" 도메인의 핵심이다. Drift Detection, Change Set, StackSets가 특히 시험에 자주 출제된다. Week 5의 SSM Automation이 "인스턴스 수준 자동화"라면, CloudFormation은 "인프라 수준 자동화"다. 두 계층이 합쳐져 완전한 운영 자동화 스택이 완성된다.