CertNote/ 출퇴근 학습 노트
로드맵
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
  • Week 3
  • Week 4
  • Week 5
  • Week 6
  • Week 7
  • Week 8
  • Week 9
  • Week 10
  • Week 11
  • Week 12
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
합격 후기

© CertNote · 주간랩스

  • 소개
  • 수정 기록
  • 문의
  • 이용약관
  • 개인정보처리방침
← SOA-C02/Week 1/Day 5

기준: SOA-C02 시험 가이드·오류 제보

SOA-C02· AssociateWeek 1 · Day 5읽기 약 22분

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순위. 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

참고 공식 자료

  • SOA-C02 공식 시험 안내(새 탭에서 열림)
  • AWS IAM 공식 문서(새 탭에서 열림)
  • AWS Organizations 공식 문서(새 탭에서 열림)
  • Amazon S3 공식 문서(새 탭에서 열림)
  • Amazon EC2 공식 문서(새 탭에서 열림)
  • Amazon CloudWatch 공식 문서(새 탭에서 열림)

이 페이지

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