Day 4 - 전체 모의고사 페이스: 6개 도메인 종합 시나리오 점검

오늘은 학습이 아니라 실전 페이스 훈련이다. 실제 SCS-C03은 65문항, 170분 — 문항당 약 2.6분이다. 길고 복합적인 시나리오를 빠르게 분해하는 근육을 만든다. 짧은 복습 후 6개 도메인을 가로지르는 종합 문제를 풀이 중심으로 다룬다. 문제 비중이 오늘의 핵심이다.

시간 배분: 숫자를 몸에 새긴다

시험 중에 산수를 하면 안 된다. 미리 체크포인트를 외워 두고, 지날 때마다 앞섰는지 뒤졌는지만 확인한다.

핵심 설계는 이것이다 — 1패스를 150분 안에 끝내고 20분을 표시 문항에 남긴다. 문항당 평균 2.6분이지만, 실제로는 1분 안에 끝나는 문항과 4분이 필요한 문항이 섞여 있다. 짧은 문항에서 번 시간을 긴 문항에 쓰는 것이 페이스의 전부다.

시험이 65문항이지만 채점되지 않는 문항이 일부 섞여 있다(AWS 시험 공통 방식으로, 향후 출제를 위한 사전 검증용이다). 이것이 실전에 주는 함의는 하나다 — 유난히 낯설고 어려운 문항 한둘에 시간을 쏟는 것은 기대값이 낮다. 그 문항이 채점 대상이 아닐 수도 있고, 채점 대상이더라도 한 문항의 배점은 전체의 2% 미만이다. 한 문항의 완벽함보다 전체 페이스가 점수를 만든다는 말은 감정적 위로가 아니라 산술이다.

3-버킷 전략

1패스에서 모든 문항을 세 통 중 하나에 넣는다. 이 분류를 즉시 하는 것이 핵심이다.

문항을 읽는다 (마지막 문장 → 본문 → 보기)
   │
   ├─[A] 확신 있음 ───────► 답하고 넘어간다. 되돌아보지 않는다.
   │                          (1패스의 60~70%가 여기여야 정상)
   │
   ├─[B] 2개로 좁혔으나 못 고름 ─► **잠정 답을 마킹하고** flag → 2패스
   │                          (빈칸으로 두지 않는다 — 시간이 모자랄 수 있다)
   │
   └─[C] 아예 모르겠음 ───► 명백한 오답만 지우고 찍은 뒤 flag → 3패스(시간 남으면)
                              여기서 2분 이상 쓰면 손해다

두 가지 규칙만 지키면 된다. ① 어떤 버킷이든 답은 반드시 채운다(오답 감점이 없다). ② [C]에 4분을 쓰느니 [A] 네 문항을 더 정확히 푸는 게 낫다.

2패스에서는 [B]만 본다. 이때 효과가 큰 습관이 하나 있다 — 1패스의 판단을 기억하려 하지 말고 요구 문장부터 다시 읽는다. [B]에 빠진 대부분의 원인은 지식 부족이 아니라 요구를 잘못 읽은 것이고, 다시 읽으면 풀리는 경우가 있다. 반대로 다시 읽어도 같은 자리에서 막히면, 그건 지식의 공백이므로 선호 위계로 가르고 즉시 나온다.

⚠️ 함정: 2패스에서 근거 없이 답을 바꾸는 것이 가장 흔한 실점 경로다. 바꿔도 되는 경우는 셋뿐이다 — ① 1패스에서 놓친 제약 조건("multi-account", "existing", "no internet")을 발견했을 때, ② 보기의 서술에 사실 오류를 찾았을 때, ③ 다른 문항이 정답의 근거를 상기시켜 줬을 때. "왠지 저쪽이 나은 것 같다"는 근거가 아니다.

페이스 전략: 시나리오 분해 6단계

긴 지문은 다음 순서로 1분 안에 뼈대를 추린다.

1. 마지막 문장을 먼저 읽는다 — 실제로 묻는 것이 거기 있다. 본문은 그다음에 읽어야 노이즈가 걸러진다.
2. 요구의 핵심 동사 찾기 — "automatically(자동)", "without managing servers(서버리스)", "least privilege(최소권한)", "cannot be deleted(불변)", "centrally(중앙)", "private(비공개)", "prevent(차단)", "detect(발견)", "investigate(조사)". 동사가 답의 패턴을 결정한다.
3. 제약 조건 표시 — "multi-account", "no internet", "regulatory", "cost-effective", "existing application(기존 소프트웨어 교체 불가)", "minimal operational overhead", "no downtime". 오답을 거르는 필터다.
4. 한정어를 확인한다 — MOST / LEAST / BEST가 붙었으면 동작 여부가 아니라 정도를 묻는 문항이다(아래 표).
5. 명백한 오답 2개 제거 — 요구를 정면으로 어기는 보기(키 하드코딩, 퍼블릭화, 수동 절차, 극단적 서술)는 즉시 탈락.
6. 남은 2개에서 "best" 선택 — 더 자동화·더 관리형·더 최소권한·더 우회불가능한 쪽.

Specialty 문제는 대개 "틀린 답"이 아니라 "덜 좋은 답"을 가린다. 두 보기가 모두 작동해도, AWS는 managed > self-managed, automated > manual, defense in depth > 단일 통제, prevent > detect > respond를 선호한다. 이는 취향이 아니라 Well-Architected 보안 기둥의 원칙(최소 권한, 다계층 방어, 추적 가능성, 자동화된 보안, 전송·저장 데이터 보호)이 답안에 반영된 결과다. 막판 2지선다에서는 이 선호 위계를 떠올린다.

한정어(qualifier) 해석법

문항 끝의 한 단어가 정답을 반대편으로 옮긴다. 이 표는 외워 두면 그대로 점수가 된다.

한정어가 둘 이상 붙으면(예: "MOST cost-effective way to privately access S3") 더 뒤에 붙은 제약이 강한 필터인 경우가 많다. 위 사례는 "private"이 후보를 엔드포인트로 좁히고, "cost-effective"가 그중 Gateway를 고른다.

⚠️ 함정: 한정어가 있는데 한정어를 무시하고 "가장 안전해 보이는 답"을 고르는 것이 대표적 실점이다. MOST cost-effective가 붙은 문항에서 Interface Endpoint(유료)나 CloudHSM(고비용)을 고르면, 그 보기가 보안적으로 더 강해도 오답이다. 반대로 MOST secure가 붙으면 비용을 이유로 약한 통제를 고르면 안 된다. 한정어는 채점 기준을 명시한 것이다.

오답이 만들어지는 여섯 패턴

보기를 읽는 속도는 정답을 아는 것만큼 중요하다. 오답의 제작 방식은 좁다.

1. 순서를 한 칸 뒤집는다. "종료 → 스냅샷", "복구 → 근절", "삭제 → 추적". → 증거를 없애는 조치가 앞에 있으면 버린다.
2. 반쪽만 조치한다. "인스턴스를 격리한다"까지만 있고 자격증명 회수가 없다. "엔드포인트를 만든다"까지만 있고 정책이 없다. → 봉쇄만 있고 추적·근절이 없는 보기는 대개 오답.
3. 강제력 없는 수단으로 강제를 요구한다. "탐지 도구로 차단한다", "IAM 정책으로 루트를 제한한다", "Tag Policy로 무태그 생성을 막는다". → 요구 동사가 차단이면 예방 통제(SCP·정책 Deny)를 고른다.
4. 범위를 잘못 잡는다. "계정마다 사람이 콘솔로 확인", "한 리전에 규칙 하나로 전체 보호". → 다계정·다리전이면 조직 도구와 집계.
5. 극단을 제시한다. "모두 자동화", "모두 수동", "탐지를 끈다", "모든 권한을 회수한다". → 극단적 서술은 대개 오답이다. 정답은 대개 경계를 나누는 형태다(가역이면 자동, 비가역이면 승인).
6. "AWS가 알아서 해 준다". "지원팀이 처리해 준다", "기본 설정으로 충분하다". → 책임 공유 모델에서 자격증명·구성·데이터는 고객 영역이므로 이 형태는 오답이다.

도메인별 출제 지도

한 문항이 어느 도메인인지 알면 후보 서비스가 즉시 좁아진다. 비중·대표 형태·정답 후보를 한 장으로 묶는다.

읽는 요령 하나. 문항에 "모든 계정", "조직 전체", "앞으로 만들어질", "신규 계정"이 등장하면 도메인이 무엇이든 거버넌스 도구가 정답 자리에 들어온다. 계정 단위 도구(개별 WAF 연결, 계정별 수동 활성화, 개별 Config 규칙)는 이때 대개 오답이다.

문항 유형별로 "먼저 보는 축"

문항의 마지막 문장이 무엇을 묻는가?
   │
   ├─ "무엇을 가장 먼저 하는가" ────► 축: **가역성 · 증거 보존**
   │     증거 파괴 조치는 뒤로, 가역 조치는 앞으로,
   │     확산의 원인(자격증명·로깅)은 결과(리소스)보다 먼저
   │
   ├─ "왜 동작하지 않는가" ─────────► 축: **평가 순서 · 전제 조건**
   │     명시적 Deny → SCP → 교차계정 양쪽 Allow → KMS 키 정책 → 조건 키
   │     (네트워크면) 라우팅 → 엔드포인트 정책 → SG/NACL → 임시 포트
   │
   ├─ "가장 적절한 설계는" ─────────► 축: **요구 동사 + 한정어**
   │     prevent/detect/respond 중 어디인가 → 그 계층의 도구
   │     한정어(cost/overhead/secure)로 남은 둘을 가른다
   │
   ├─ "어느 서비스인가" ────────────► 축: **답하는 질문**
   │     위협=GuardDuty, 약점=Inspector, 데이터=Macie,
   │     노출=Access Analyzer, 관계=Detective, 집계=Security Hub
   │
   ├─ "사실이 아닌 것은" ───────────► 축: **함정 목록 대조**
   │     ACM us-east-1 / 데이터 이벤트 / NACL 임시 포트 /
   │     SCP 비부여 / KMS 대기 기간 / Gateway Endpoint는 S3·DDB만
   │
   └─ "조직 전체에" ────────────────► 축: **예방 > 탐지 > 대응**
         SCP(예방) · Config(탐지) · 자동 교정(대응) · Firewall Manager(강제 배포)

교차 도메인 케이스로 감각 맞추기

실제 문항은 도메인을 가로지른다. 아래 세 케이스는 지문 형태와 분해 과정을 그대로 보여 준다(정답 후보까지만 짚고, 자세한 풀이는 아래 연습에서 다룬다).

🎯 케이스 1 (도메인 1·5·6 교차): "규제 기관이 지난 3년간 모든 계정의 관리자 활동을 요구했다. 회사는 로그를 S3에 보관해 왔지만, 한 계정의 관리자가 6개월 전 자신의 trail을 삭제한 정황이 있다." → 분해하면 축이 셋이다. ① 증명 축 — 과거 기간의 증거는 소급 생성이 불가능하므로, 지금 할 수 있는 것은 남아 있는 조직 trail과 log file validation digest로 무결성이 보장된 구간을 확정하는 것이다. ② 원인 축 — 멤버 계정 관리자가 trail을 지울 수 있었다는 것 자체가 설계 결함이다. 조직 trail은 멤버가 소유자가 아니므로 지울 수 없다. ③ 재발 방지 축 — SCP로 StopLogging·DeleteTrail Deny, Log Archive 계정 분리, Object Lock. 이 케이스의 오답 보기는 대개 "지금부터 로그를 켠다"(과거를 증명하지 못함)거나 "CloudWatch Logs 보존을 늘린다"(원인이 아님)다.

🎯 케이스 2 (도메인 2·3·4 교차): "프라이빗 서브넷의 애플리케이션이 침해됐고, 인스턴스 역할의 자격증명이 외부 IP에서 사용된 정황이 GuardDuty에 잡혔다. 애플리케이션은 교체할 수 없다." → "교체할 수 없다"가 결정적 제약이다. 코드 수정이 필요한 답(SDK 변경, 자격증명 주입 방식 변경)은 전부 탈락하고, 인프라 계층 해결만 남는다. ① 봉쇄는 격리 SG + 프로파일 분리 + aws:TokenIssueTime Deny(네트워크 격리만으로는 외부에서 쓰이는 토큰을 못 막는다). ② 재발 방지는 IMDSv2 강제 + hop limit, 역할 권한 축소, aws:SourceVpce 조건. ③ 조사는 CloudTrail에서 그 세션 ARN을 축으로 전수 추적. 세 도메인이 한 사건에서 각자 한 겹씩 맡는 전형이다.

🎯 케이스 3 (도메인 3·6 교차): "200개 계정에 걸쳐 인터넷에 노출된 ALB가 계속 늘고 있다. 표준 WAF 규칙을 모든 ALB에 적용하고, 앞으로 만들어질 것에도 자동 적용하며, 기존 서비스는 중단시키지 않아야 한다." → 단서가 셋이다. "모든 계정"·"앞으로 만들어질" → Firewall Manager(계정별 수동 연결은 오답). "중단시키지 않아야" → 처음엔 count 모드로 배포해 오탐을 관측한 뒤 block으로 전환. 그리고 Firewall Manager는 Config가 전제이며 RemediationEnabled가 꺼져 있으면 보고만 한다는 점이 보기의 함정으로 쓰인다.

자기 진단: 틀린 유형 → 돌아갈 곳

모의 풀이의 목적은 점수가 아니라 어느 축이 비었는지 아는 것이다.

모의 풀이에서 가장 낭비되는 시간은 맞힌 문항의 해설을 읽는 것이다. 반대로 가장 값이 큰 시간은 "[B] 버킷에 넣었지만 결국 맞힌 문항"을 복기하는 것이다. 그 문항들은 지식이 있으나 판단 경로가 아직 자동화되지 않은 지점이고, 시험장에서 시간을 잡아먹을 후보이며, 컨디션이 나쁜 날 틀릴 문항이다. 맞은 것과 틀린 것만 세는 채점은 이 층을 보이지 않게 만든다. 모의를 풀 때 [A]/[B]/[C] 표시를 남기는 이유가 이것이다 — 점수는 결과를 알려 주지만, 버킷 분포는 다음에 무엇을 고칠지를 알려 준다.

빠른 키워드 → 도메인 매핑(워밍업)

"us-east-1에서만 발급"(CloudFront용 ACM), "데이터 이벤트 별도 활성화"(S3 객체 추적), "NACL 임시 포트"(stateless 응답), "SCP는 권한을 주지 않음", "KMS 키 정책이 root를 신뢰해야 IAM 위임 가능" — 이 다섯은 마지막 2지선다를 가르는 구분이다. 여기에 두 개를 더 붙이면 거의 다 막힌다: Gateway Endpoint는 S3·DynamoDB뿐, Object Lock Compliance는 루트도 못 지운다.

자격증 준비생들이 오답 노트를 정리할 때 반복해 확인되는 사실이 하나 있다 — 실전에서 놓치는 문항의 상당수는 처음 보는 서비스가 아니라 아는 서비스를 잘못된 자리에 놓은 것이다. GuardDuty를 취약점 스캔 자리에, Inspector를 침해 대응 자리에, Config를 차단 자리에, Tag Policy를 강제 자리에 놓는 식이다. 이것이 시사하는 학습 전략은 분명하다. 남은 시간에 새 서비스를 더 외우는 것보다 이미 아는 서비스들의 경계를 다시 긋는 것의 기대값이 훨씬 크다. 오늘과 내일의 대조표들이 새 지식이 아니라 경계선으로만 채워져 있는 이유가 이것이다.

정리

오늘은 지식을 늘리는 날이 아니라 지식을 점수로 바꾸는 변환 효율을 올리는 날이다.

세 가지만 몸에 남기면 된다. ① 체크포인트 — 33번에서 85분. 앞섰는지 뒤졌는지만 본다. ② 3버킷 — 확신/좁힘/모름을 즉시 분류하고, 어떤 경우에도 답은 채운다. ③ 한정어 — MOST/LEAST가 붙으면 채점 기준이 명시된 것이므로 그 축으로 가른다.

그리고 모의를 푼 뒤에는 점수가 아니라 버킷 분포와 틀린 유형을 본다. [C]가 많으면 지식의 공백이고, [B]가 많으면 판단 경로가 아직 자동화되지 않은 것이며, [A]인데 틀렸다면 요구 문장을 잘못 읽은 것이다. 세 원인은 처방이 전부 다르다 — 각각 해당 주차 복습, 대조표 반복, 지문 읽는 순서 교정이다.

📝 연습 문제

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

문제 1

(도메인 1·6) 한 기업이 200개 계정의 모든 API 활동을 변조 불가능하게 중앙 보관하고, 어떤 계정도 로깅을 끄지 못하게 하며, 신규 계정에도 자동 적용되길 원한다. 가장 적절한 설계는?

• A각 계정 관리자가 개별 trail을 만들고 로컬 S3에 저장
• BOrganization trail로 중앙 S3(다른 계정·log file validation·Object Lock) + SCP로 StopLogging/DeleteTrail Deny + Control Tower로 신규 계정 자동 적용
• CCloudWatch Logs에 90일 보관 후 자동 삭제
• D계정마다 Lambda로 로그를 수집

문제 2

(도메인 1·2) GuardDuty가 EC2의 암호화폐 채굴 멀웨어 통신을 탐지했다. 보안팀은 (1) 즉시 인스턴스를 격리하고 (2) 침해 범위를 조사하며 (3) 향후 같은 finding을 사람 개입 없이 자동 격리하길 원한다. 가장 적절한 조합은?

• A인스턴스를 종료하고 수동으로 로그를 뒤진다
• B격리 보안 그룹으로 교체(+스냅샷) → Detective로 범위 조사 → EventBridge가 해당 finding 타입을 Lambda/SSM 자동 격리에 라우팅
• CNACL로 모든 트래픽을 차단하고 끝낸다
• DInspector로 취약점만 스캔한다

문제 3

(도메인 3·4) 프라이빗 서브넷의 Lambda가 DynamoDB와 특정 S3 버킷에 인터넷 경유 없이 접근해야 하고, 자격증명 하드코딩은 금지다. 비용도 최소화하려 한다. 가장 적절한 설계는?

• ALambda를 퍼블릭 서브넷에 두고 NAT Gateway로 접근
• BVPC에 S3·DynamoDB Gateway Endpoint(무료) 구성 + Lambda 실행 역할에 해당 리소스 최소 권한 부여 + 버킷 정책 SourceVpce 조건
• CLambda 환경 변수에 IAM 액세스 키 저장
• DInterface Endpoint를 S3·DynamoDB에 사용

문제 4

(도메인 5) 의료 규제 데이터를 S3에 저장하며, (1) 저장·전송 모두 암호화, (2) 키 사용 감사, (3) 7년간 누구도(관리자 포함) 삭제·변조 불가를 요구한다. 가장 적절한 조합은?

• ASSE-S3 + 버전 관리만
• BSSE-KMS(CMK, 키 정책) + 버킷 정책 aws:SecureTransport 강제 + CloudTrail KMS 감사 + S3 Object Lock(Compliance 모드, 7년 보존)
• CSSE-C + MFA Delete
• D클라이언트 측 암호화만

문제 5

(도메인 4·6) 서드파티 보안 감사 업체가 조직의 50개 계정을 읽기 전용으로 점검해야 한다. 장기 키 공유 없이, confused deputy를 방지하며, 중앙에서 관리하려 한다. 가장 적절한 방법은?

• A각 계정에 IAM 사용자를 만들어 액세스 키를 업체에 이메일로 전달
• B교차 계정 읽기 전용 역할 + trust policy에 업체 계정 Principal·External ID 조건, CloudFormation StackSets로 50개 계정 일괄 배포
• C루트 자격증명을 공유
• D버킷을 퍼블릭으로 공개

문제 6

(도메인 3) 글로벌 웹앱이 (1) SQLi 시도, (2) 로그인 무차별 대입, (3) 간헐적 L3/4 대규모 flood를 받는다. 오리진 직접 접근도 차단해야 한다. 가장 적절한 통합 설계는?

• AALB에만 WAF를 붙인다
• BCloudFront 전면 + CLOUDFRONT scope WAF(SQLi managed + /login rate-based) + Shield Advanced + 오리진 직접 접근 차단(prefix list/비밀 헤더)
• CEC2 보안 그룹만 강화
• DRoute 53 라우팅으로 트래픽 분산

문제 7

(도메인 1·5) 보안팀이 "어느 S3 버킷에 신용카드 번호·주민번호 등 민감 데이터가 있는지" 자동으로 발견·분류하고, 결과를 중앙 보안 대시보드에 모으려 한다. 가장 적절한 조합은?

• A직접 스크립트로 모든 객체를 다운로드해 정규식 검사
• BAmazon Macie로 S3 민감 데이터 자동 발견·분류 → finding을 Security Hub로 집약
• CGuardDuty를 S3 버킷에 설치
• DConfig 규칙으로 객체 내용을 검사

문제 8

(도메인 6) 조직 전체에서 모든 ALB·CloudFront에 표준 WAF 규칙을 강제하고, 신규로 생성되는 리소스에도 자동 적용하며, 위반을 중앙에서 가시화하려 한다. 가장 적절한 서비스는?

• A각 계정에서 WAF를 수동으로 구성
• BAWS Firewall Manager로 조직 차원 WAF 정책을 정의·강제(신규 리소스 자동 적용)
• CSCP로 WAF를 강제
• DConfig 규칙으로 탐지만

문제 9

(도메인 3·4) EC2 애플리케이션이 RDS 자격증명을 사용해야 한다. 자격증명은 정기적으로 자동 로테이션되어야 하고 코드에 박지 않아야 한다. 가장 적절한 조합은?

• ARDS 비밀번호를 환경 변수에 저장
• BSecrets Manager에 RDS 자격증명 저장(Lambda 로테이터로 자동 로테이션) + EC2 인스턴스 역할에 해당 시크릿 GetSecretValue 권한
• CSSM Parameter Store String(평문)에 저장
• D코드에 하드코딩 후 정기 수동 변경

문제 10

(도메인 1) 한 팀이 "S3 객체가 누구에 의해 다운로드됐는지"를 못 찾고 있다. 기본 CloudTrail은 켜져 있다. 원인은?

• AVPC Flow Logs가 꺼져 있다
• BS3 객체 수준 접근은 CloudTrail 데이터 이벤트를 별도로 활성화해야 기록된다(관리 이벤트는 미기록)
• CGuardDuty가 비활성
• D버킷 로깅이 KMS로 암호화돼 보이지 않는다