Cert Notes/ 출퇴근 학습 노트
로드맵
KOEN
CLF-C02 · FoundationalCloud Practitioner - Foundational
DVA-C02 · AssociateDeveloper - Associate
SAA-C03 · AssociateSolutions Architect - Associate
SOA-C02 · AssociateCloudOps Engineer - Associate
  • Week 1
    • 1.운영자가 보는 AWS 인프라: 리전, AZ, 그리고 책임의 경계선
    • 2.IAM의 운영자 사용설명서: 사용자·그룹·역할·정책 평가 알고리즘
    • 3.IAM 심화: Permission Boundary, SCP, Identity Center로 짓는 가드레일
    • 4.AWS Organizations: 100개 계정을 한 사람이 운영하는 법
    • 5.Week 1 통합 복습: 운영자 시나리오로 다시 보는 첫 주
  • Week 2
    • 1.CloudWatch Metrics의 내부 구조: Namespace, Dimension, Resolution, Cardinality
    • 2.CloudWatch Logs: Log Group의 내부 구조와 Subscription 패턴
    • 3.Logs Insights 쿼리 언어: 운영자의 디버깅 SQL
    • 4.Metric Filter, EMF 심화, Anomaly Detection: 메트릭과 로그를 잇는 세 다리
    • 5.Week 2 통합 복습: CloudWatch 시나리오 12문제
  • Week 3
    • 1.CloudWatch Alarms: M of N 평가 모델과 Composite Alarm의 설계 철학
    • 2.CloudWatch Dashboards: 크로스 계정 집계, 변수, 그리고 관측 가능성의 설계 철학
    • 3.CloudWatch Agent: 내부 동작, StatsD/collectd 통합, procstat 플러그인
    • 4.Synthetics Canary, X-Ray Sampling, ServiceLens: 사용자 관점 모니터링의 설계
    • 5.Week 3 복습: CloudWatch 관측 가능성 스택 종합
  • Week 4
    • 1.CloudTrail: API 감사 로그의 설계 원칙과 Organization Trail
    • 2.CloudTrail Lake 심화: SQL 감사 분석, Insights 이상 탐지, 크로스 계정 쿼리
    • 3.AWS Config 심화: Rule 평가 트리거, Custom Rule Lambda, Conformance Pack, Auto Remediation
    • 4.Audit Manager, License Manager, Resource Explorer: 감사 자동화와 운영 가시성의 설계
    • 5.Week 4 복습: CloudTrail·Config·감사 스택 종합
  • Week 5
    • 1.AWS Systems Manager: 운영자의 중앙 통제탑
    • 2.Run Command, State Manager, Maintenance Window: 운영 자동화 3종 세트
    • 3.Patch Manager: 보안 패치를 안전하고 컴플라이언트하게
    • 4.Parameter Store, Session Manager, Automation Runbook: SSM 자동화 심화
    • 5.Week 5 복습: Systems Manager 종합 시나리오
  • Week 6
    • 1.CloudFormation: 인프라를 코드로, 운영자의 시각으로
    • 2.Change Set, Drift Detection, Rollback Trigger: 안전한 CFn 운영의 3대 기둥
    • 3.Nested Stack, Cross-Stack Reference, StackSets: 대규모 IaC 운영
    • 4.Service Catalog, AppConfig, AppRegistry: 거버넌스와 동적 설정의 기술
    • 5.Week 6 종합 복습: CloudFormation 운영 완전 정복
  • Week 7
    • 1.Elastic Beanstalk과 다섯 가지 배포 정책, 그리고 무중단의 진짜 비용
    • 2.CodeDeploy, 코드만 배포한다는 결정과 AppSpec hook의 13단계
    • 3.EC2 Image Builder, Golden AMI라는 운영 미덕
    • 4.OpsWorks의 EOL과 Launch Template, 그리고 Mixed Instances Policy의 진짜 가치
    • 5.Week 7 종합, 시나리오로 다시 보는 배포·프로비저닝 선택의 감각
  • Week 8
    • 1.VPC라는 가상 데이터센터, 그리고 운영자가 매일 헷갈리는 다섯 가지
    • 2.VPC 트래픽을 들여다보는 세 가지 도구, 그리고 메타데이터의 한계
    • 3.NAT Gateway, VPC Endpoint, PrivateLink — VPC가 외부와 만나는 세 가지 방식
    • 4.Transit Gateway, VPN, Direct Connect, Route 53 — 멀티 VPC와 하이브리드의 큰 그림
    • 5.Week 8 종합 복습과 시나리오 12문제
  • Week 9
    • 1.KMS, 키를 한 번도 보지 않고 키를 관리하는 법
    • 2.Secrets Manager, 살아있는 시스템의 비밀번호를 무중단으로 바꾸는 법
    • 3.IAM Access Analyzer와 Trusted Advisor, 권한을 코드로 증명하는 법
    • 4.위협을 탐지하는 네 개의 눈, 그리고 그것들을 하나로 모으는 법
    • 5.Week 9 종합 복습, 키워드가 답을 가리키는 법
  • Week 10
    • 1.EBS Snapshot, 변경된 블록만 기억하는 백업의 내부
    • 2.AWS Backup, 백업을 관리자조차 지울 수 없게 만드는 법
    • 3.RDS Multi-AZ vs Read Replica, 동기와 비동기 사이의 선택
    • 4.S3 복제, Storage Gateway, Elastic DR — 파일과 워크로드를 옮기는 법
    • 5.Week 10 종합 복습 — 백업·DR·고가용성을 하나의 그림으로
  • Week 11
    • 1.Compute Optimizer, 14일치 메트릭이 인스턴스 크기를 다시 정하는 법
    • 2.Trusted Advisor, AWS가 당신 계정을 대신 점검하는 다섯 개의 눈
    • 3.Cost Explorer와 Budgets, 청구서를 읽고 통제하는 법
    • 4.Savings Plans와 Spot, 컴퓨팅 비용을 70% 깎는 약정과 도박의 경제학
    • 5.Week 11 복습, 비용·성능 운영을 하나의 의사결정 흐름으로
  • Week 12
    • 1.도메인 1·2 다시 읽기, 관측과 복원력이 한 흐름이 되는 자리
    • 2.도메인 3·4 다시 읽기, 자동으로 배포하고 최소 권한으로 막는다
    • 3.도메인 5·6 다시 읽기, 패킷의 길과 청구서의 길
    • 4.전체 모의고사 50문항, 그리고 오답이 알려주는 것
    • 5.D-Day 체크리스트, 시험이라는 마지막 시스템을 운영하기
SAP-C02 · ProfessionalSolutions Architect - Professional
DOP-C02 · ProfessionalDevOps Engineer - Professional
SCS-C03 · SpecialtySecurity - Specialty
MLA-C01 · AssociateMachine Learning Engineer - Associate
AIF-C01 · FoundationalAI Practitioner - Foundational
DEA-C01 · AssociateData Engineer - Associate
MLS-C01 · SpecialtyMachine Learning - Specialty
합격 후기
← SOA-C02/Week 1/Day 5
SOA-C02· AssociateWeek 1 · Day 5읽기 약 23분

Day 5 - Week 1 통합 복습: 운영자 시나리오로 다시 보는 첫 주

한 주 동안 본 그림은 AWS의 물리 지도(Region / AZ / Edge), 그 위에서 누가 무엇을 책임지는가(Shared Responsibility), 누가 무엇을 할 수 있게 할까(IAM의 6단계 평가 알고리즘), 그리고 수십·수백 개 계정을 한 거버넌스 아래 묶는 법(Organizations / SCP / Identity Center) 네 가지였다. 이 네 그림이 SOA-C02 모든 시나리오의 배경이다. 시험 문제를 풀 때 답이 바로 안 보이면 "이 시나리오는 네 개 중 어디를 묻는가"부터 분류하는 습관을 들이면, 보기에서 정답이 자연스럽게 떠오른다.

이 주의 내용이 머릿속에 깔려 있어야 다음 주의 CloudWatch·Config·CloudTrail이 자연스럽게 위에 얹힌다. 알람이 울렸을 때 "어느 리전의 어느 AZ에서, 누구(IAM principal)가, 어떤 권한 평가 경로로, 어떤 계정에서, 어떤 SCP·boundary 한도 안에서" 일을 했는지를 거꾸로 추적하는 게 운영자의 일상이다. 그 추적을 가능하게 만드는 인프라가 이 주의 주제였다.

운영자의 머릿속 지도: 한 장으로 다시 보기

┌─────────────────────────────────────────────────────────┐
│         [AWS Global Infrastructure]                     │
│  Region > AZ > Edge / Local Zones / Outposts            │
│  - Control plane은 us-east-1에 자주 묶임 (IAM/R53/CF)   │
│  - AZ는 격리 최소 단위. NAT GW / EBS / RDS Standby는 AZ │
│  - ZoneId(apne2-az1)만 계정 간 일치, ZoneName은 셔플    │
├─────────────────────────────────────────────────────────┤
│         [Shared Responsibility]                         │
│  AWS: Security OF the Cloud                             │
│  Customer: Security IN the Cloud                        │
│  - 추상화 레벨↑ ⇒ 책임 경계선↑ (EC2 < ECS < Fargate < L)│
│  - 데이터 분류·IAM·암호화 키 정책은 늘 고객                │
├─────────────────────────────────────────────────────────┤
│         [IAM Evaluation 6-step]                         │
│  Explicit Deny → Org SCP → Resource Policy →            │
│   Identity Policy → Permission Boundary →               │
│   Session Policy → 최종 Allow/Deny                      │
│  - Deny는 어디서든 한 번이라도 나오면 즉시 차단            │
│  - Cross-Account는 양쪽 다 Allow가 필요                  │
├─────────────────────────────────────────────────────────┤
│         [Multi-Account Governance]                      │
│  Organizations / SCP / RAM / Control Tower / IdC        │
│  - Management Account엔 SCP 안 통함 (워크로드 두지 말 것)│
│  - Delegated Administrator로 보안 서비스 중앙화         │
│  - Identity Center + IdP 페더레이션 = IAM User 없는 운영 │
└─────────────────────────────────────────────────────────┘

운영자의 일상 디버깅 흐름은 이 그림 위에서 다음 순서로 흐른다.

  1. 증상 포착: CloudWatch alarm / Health Dashboard / 사용자 클레임
  2. 원인 후보 좁히기: CloudTrail에서 직전 5~30분의 write API 이벤트
  3. 권한 문제 의심: IAM Policy Simulator + Access Analyzer + errorMessage 정독
  4. 인프라 문제 의심: AWS Health(SHD/PHD) + Service Quotas
  5. 계정 단위 보안 위반 의심: Config + GuardDuty + Security Hub finding
  6. 복구 후 사후 점검: TAM·support 케이스 / RCA 문서화 / Config 룰 보강

이 흐름이 머릿속에 있으면 "장애 났다"는 한 줄에서 "5분 안에 콘솔의 어느 화면을 열어야 하는가"가 자동으로 결정된다. 시험에서 "처음에 봐야 할 도구는?" 같은 문제는 거의 이 표에서 답이 나온다.

함정 모음: 운영자가 같은 실수를 반복하는 6가지

이 주의 내용을 종합하면 다음 6가지가 운영자가 같은 사고를 반복하는 패턴이다.

  1. Management Account에 워크로드 두기: SCP가 안 통하는 계정인데 EC2·RDS를 띄워두면 root 키 유출 시 무방비. AWS Landing Zone 표준은 management = 결제·org 관리만, 워크로드는 별도 OU의 member 계정.
  2. 단일 AZ에 NAT GW / RDS Single-AZ / NLB 단일 AZ 등록: 비용을 아끼려다 AZ 하나가 흔들리면 전체 down. NAT GW는 AZ 단위 리소스이고 자동 페일오버가 없다.
  3. IAM User + access key 영구 발급: 회전 누락·offboarding 누락이 사고 1순위. 2019년 Capital One, 2022년 Uber 사건 모두 자격증명 관리의 실패였다. 답은 Identity Center + IdP 페더레이션.
  4. us-east-1 의존성 무시: IAM·Route 53 public zone·CloudFront·Organizations의 write는 us-east-1 컨트롤 플레인에 의존한다. 글로벌 서비스라고 안심하면 2021년 12월 같은 장애에 휘말린다.
  5. IMDSv1을 명시적으로 끄지 않음: 신규 EC2도 launch template / SCP / Config로 강제하지 않으면 운영자가 실수로 v1을 띄울 수 있다. SSRF 공격의 진입점.
  6. CloudTrail / Config을 member 계정에서 개별 관리: 누가 비활성화했는지를 그 계정 trail로 확인해야 하는 자기참조 문제. 답은 Organization Trail + Log Archive Account + S3 Object Lock.

이 여섯 가지를 다 피하는 게 운영자의 출발선이다. 시험은 이 함정들을 시나리오로 변형해서 묻는다.

운영자 한 줄 명령어 카드: 시험 직전 한 번 더

콘솔이 아니라 CLI로 한 번씩 쳐본 명령은 시험장에서도 기억난다. Week 1 핵심 CLI를 한 카드로 모은다.

# 1) ZoneId 확인 — cross-account 비용 최적화의 출발점
aws ec2 describe-availability-zones --region ap-northeast-2 \
  --query 'AvailabilityZones[*].[ZoneName,ZoneId,State]' --output table
 
# 2) Health 이벤트 — 진행 중 / 예정된 이벤트 모두
aws health describe-events \
  --filter "eventStatusCodes=open,upcoming" --region us-east-1
aws health describe-events \
  --filter "eventStatusCodes=open,upcoming" --region us-west-2
 
# 3) IAM 최근 사용 — 90일 이상 안 쓴 access key 찾기
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text \
  | base64 --decode
 
# 4) IAM Access Analyzer — 외부 노출 리소스 점검
aws accessanalyzer list-analyzers
aws accessanalyzer list-findings --analyzer-arn arn:aws:access-analyzer:...
 
# 5) Organizations 구조 보기
aws organizations list-roots
aws organizations list-organizational-units-for-parent --parent-id r-xxxx
aws organizations list-accounts-for-parent --parent-id ou-xxxx-yyyy
 
# 6) SCP 효과 확인 — 특정 계정에 적용된 정책 모두
aws organizations list-policies-for-target \
  --target-id 123456789012 --filter SERVICE_CONTROL_POLICY
 
# 7) Identity Center Permission Set 할당 조회
aws sso-admin list-permission-sets --instance-arn arn:aws:sso:::instance/...
 
# 8) Policy Simulator — 사전 검증
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111:user/alice \
  --action-names s3:PutObject \
  --resource-arns arn:aws:s3:::my-bucket/key

여기서 가장 자주 잊는 게 generate-credential-report → get-credential-report 두 단계라는 점이다. 첫 호출은 비동기 생성 트리거이고 두 번째 호출이 실제 다운로드다.

🔍 더 깊이: simulate-principal-policy는 SCP, Permission Boundary, Resource Policy까지 한 번에 평가해 실제 운영의 권한 거부 원인을 찾아준다. CloudTrail의 errorMessage에 "explicit deny from SCP"라고 찍히는 경우가 가장 친절한 케이스이고, 그렇지 않을 땐 simulator로 한 단계씩 좁혀야 한다. Simulator는 --context-entries로 MFA·SourceIp 같은 조건도 흉내 낼 수 있어 IP 화이트리스트 조건 디버깅에도 쓴다.

💡 암기 팁: 운영자의 "권한 문제 1차 진단 3단 콤보"는 ① CloudTrail의 errorCode / errorMessage → ② simulate-principal-policy → ③ Access Analyzer "Reachable from outside"이다. 이 순서가 머리에 박혀 있으면 어떤 IAM 시나리오 문제도 푼다.

Week 1 자기진단 체크리스트

다음 11개 질문에 모두 "예"라고 답할 수 있어야 Week 2로 넘어가도 무리가 없다.

  • Region / AZ / Edge의 차이와 NAT GW가 AZ 단위 리소스라는 점을 설명할 수 있는가?
  • us-east-1 컨트롤 플레인 의존성이 왜 IAM·Route 53·CloudFront에까지 영향을 주는지 설명할 수 있는가?
  • ZoneName과 ZoneId의 차이와, 두 계정 간 cross-AZ 데이터 전송 비용을 줄이는 매칭 방법을 안다?
  • 공동 책임 모델에서 EC2 / ECS Fargate / Lambda / S3 각각의 책임 경계 차이를 설명할 수 있는가?
  • IAM 정책 평가 6단계 알고리즘(Deny→SCP→Resource→Identity→Boundary→Session)을 순서대로 떠올릴 수 있는가?
  • SCP와 Permission Boundary와 Session Policy의 차이를 한 줄씩 설명할 수 있는가?
  • Identity Center의 Permission Set이 내부적으로 어떤 IAM Role로 실현되는지 안다?
  • AWS Health Dashboard와 EventBridge aws.health 룰을 어느 리전에 둬야 하는지 안다?
  • Organization Trail + Log Archive Account + S3 Object Lock 패턴의 PCI-DSS 가치 설명 가능?
  • IMDSv2 + hop limit 1 + Config rule + SCP 4중 방어가 SSRF를 어떻게 차단하는지 설명 가능?
  • Delegated Administrator로 GuardDuty·Security Hub·Inspector·Macie를 보안 계정에 위임하는 표준 패턴을 안다?

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

한국 사용자 대상 게임 회사가 ap-northeast-2에서 운영 중이다. 운영팀이 us-east-1 장애 중에도 "콘솔 로그인은 가능, 단 새 IAM 사용자 생성·Route 53 레코드 변경 같은 write는 못 할 수 있다"는 사실을 미리 알고 대비하려고 한다. SDK·CLI 측에서 추가로 해야 할 가장 적절한 조치는?

문제 2

한 운영팀이 ASG로 운영 중인 웹 서비스에서 AZ-a 장애 발생 시 모든 트래픽이 끊겼다. 원인 분석 결과 NAT GW가 AZ-a 한 곳에만 있었고, AZ-b·AZ-c의 private subnet 라우팅 테이블도 모두 AZ-a NAT GW를 가리키고 있었다. 정답은?

문제 3

EC2 인스턴스가 KMS CMK로 SSE-KMS 암호화된 S3 버킷에 PUT을 시도하는데 AccessDenied. IAM Policy에 `s3:PutObject Allow`가 있고 Bucket Policy에도 Allow가 있다. CloudTrail에는 `s3.amazonaws.com` 이벤트와 `kms.amazonaws.com` 이벤트 두 줄이 모두 실패로 찍혔다. 가장 가능성 높은 원인은?

문제 4

회사가 200명 직원에 60개 AWS 계정을 운영 중이다. 직원이 매주 입·퇴사하며, 보안팀은 access key 회전과 offboarding 누락에 지쳤다. 가장 효율적인 변경은?

문제 5

한 회사가 Organizations로 50개 계정을 운영 중이고, 모든 계정에서 `us-east-1`과 `ap-northeast-2` 외 리전을 사용 못하게 강제하려고 한다. 데이터 주권 준수가 목적. 가장 효율적인 방법은?

문제 6

운영자가 개발자에게 IAM Role 생성을 위임하되, 그 Role의 effective permission이 회사 표준 정책 범위를 넘지 못하게 강제하려고 한다. 어떤 조합이 정답인가?

문제 7

한 회사가 50개 member 계정의 CloudTrail 로그를 한 곳에 모으고, 운영자가 그 로그를 수정·삭제하지 못하게 하려고 한다. PCI-DSS 10.5.5 요구사항 충족이 목적. 표준 패턴은?

문제 8

운영팀이 EC2 인스턴스의 메타데이터 SSRF 공격을 막으려고 한다. 가장 강력한 운영 표준 4중 방어는?

문제 9

운영자가 100개 계정의 EC2 인스턴스 인벤토리를 한 번에 보고 싶다. 보안팀은 OS 패치 적용 현황·태그·인스턴스 타입을 알고 싶어 한다. 가장 효율적인 방법은?

문제 10

한 운영팀이 새벽 3시 us-east-1 장애 알림을 받기 위해 EventBridge `aws.health` 룰을 만들었다. 누락 없이 모든 이벤트를 받기 위한 표준 패턴은?

문제 11

보안 운영자가 5개 부서별로 200대 EC2의 시작/중지 권한을 분리해야 한다. 100명 직원과 200대 EC2가 있고, 직원이 매주 입·퇴사하며 부서 이동도 잦다. 가장 확장성 있는 방식은?

문제 12

보안 운영자가 100개 계정의 GuardDuty finding·Security Hub 점수·Inspector vulnerability·Macie 데이터 분류 결과를 한 곳에서 보려고 한다. 표준 패턴은?

다음 주 예고: Week 2 — CloudWatch의 내부 구조

다음 주는 운영자 도구 중 가장 자주 쓰는 CloudWatch Metrics와 Logs의 내부 구조다. 모든 알람과 디버깅의 출발점.

  • Day 1: Metrics 데이터 모델 — Namespace, Dimension, Resolution(1초 vs 60초), cardinality explosion
  • Day 2: Logs Group/Stream/Event 구조와 Subscription Filter, VPC Flow Logs 비용 함정
  • Day 3: Logs Insights 쿼리 언어 — 운영자의 SQL, parse / filter / stats 패턴 라이브러리
  • Day 4: Metric Filter, EMF 심화, Anomaly Detection의 ML 베이스라인
  • Day 5: Week 2 복습 + 시나리오 10문제

Week 2를 다 보고 나면 콘솔의 그래프 더미를 보고 5초 안에 "지금 우리 서비스가 죽고 있는가"를 판단하는 감각이 생긴다. 그 감각이 SOA-C02 시험과 실무 운영의 50%다.

이전AWS Organizations: 100개 계정을 한 사람이 운영하는 법Week 1 · Day 4다음 CloudWatch Metrics의 내부 구조: Namespace, Dimension, Resolution, CardinalityWeek 2 · Day 1

이 페이지

  • 운영자의 머릿속 지도: 한 장으로 다시 보기
  • 함정 모음: 운영자가 같은 실수를 반복하는 6가지
  • 운영자 한 줄 명령어 카드: 시험 직전 한 번 더
  • Week 1 자기진단 체크리스트
  • 연습 문제 (시나리오 12문항)
  • 다음 주 예고: Week 2 — CloudWatch의 내부 구조