AWS SCS-C03 암기 포인트
시험 직전 이것만 훑기 아래는 문제 유형별 반사적으로 떠올려야 하는 판별 기준 모음
1. IAM 정책 문법
1-1. 조건 연산자 해석 공식
조건이 매치되면 → 그 Statement의
Effect가 적용됨
| 조합 | 실질 의미 |
|---|---|
Allow + StringEquals | 나열된 값일 때만 허용 |
Deny + StringNotEquals | 나열된 값만 통과 (실무 표준 화이트리스트) |
Allow + StringNotEquals | 나열된 값은 허용 안 됨 |
Deny + StringEquals | 나열된 값만 차단 (블랙리스트) |
3단계 치환법
Not계열 발견 → “~가 아니면” 으로 읽기Effect와 합치기 →Deny+ “~가 아니면” = “~만 허용”- 키가 없는 케이스를 대입 →
IfExists유무 확인
1-2. 키 부재 시 동작 ⚠️ 최빈출
| 연산자 | 키가 없을 때 |
|---|---|
Bool + false | 매치 안 됨 |
BoolIfExists + false | 매치됨 → Deny 발동 |
StringEquals | 매치 안 됨 |
StringNotEquals | 매치됨 → Deny 발동 |
StringNotEqualsIfExists | 매치 안 됨 |
IfExists의 유일한 규칙 "키가 없으면 조건을 통과(true 취급)시킨다" 방향이 반대로 보이는 건 원래 연산자의 부재 시 동작이 서로 반대이기 때문
1-3. 다중 값 처리
| 연산자 | 논리 |
|---|---|
StringEquals: [A, B] | OR (A이거나 B) |
StringNotEquals: [A, B] | AND (A도 아니고 B도 아님) |
1-4. NotAction
“~을 하지 않는다”가 아니라 “~을 제외한 나머지 전부”
| 조합 | 의미 |
|---|---|
Deny + NotAction | 예외만 남기고 전부 차단 (화이트리스트) |
Allow + NotAction | 예외만 빼고 전부 허용 (위험, 잘 안 씀) |
- 같은 Statement에
Action과NotAction공존 불가 - MFA 강제 정책 필수 예외:
iam:CreateVirtualMFADevice,iam:EnableMFADevice,iam:ChangePassword,sts:GetSessionToken(안 그러면 신규 사용자가 MFA를 켤 방법이 없는 닭-달걀 문제)
1-5. 평가 순서
Explicit Deny > Allow > Implicit Deny(기본 거부)
→ 확실히 막으려면 Allow를 안 주는 게 아니라 Deny를 명시
1-6. 리소스 기반 정책의 Resource: "*"
키 정책·버킷 정책의
*는 "부착된 그 리소스 하나" IAM 정책의*(모든 리소스)와 의미가 다름
2. ARN 구조와 주체 식별
arn:aws:iam::111122223333:role/ExampleRole
│ │ │ ││ │ │ │ │
│ │ │ ││ │ │ └──────┴─ 리소스 타입/이름
│ │ │ ││ │ └─────────── 계정 ID (12자리 숫자)
│ │ │ │└──────┴────────────────── 리전 (IAM은 글로벌 → 비움, :: 연속)
│ │ └──────────────────────────── 서비스
│ └──────────────────────────────── 파티션 (aws / aws-cn / aws-us-gov)
└──────────────────────────────────── 고정 접두사
주체 ARN 형식 ⚠️ 최빈출
| 진입 경로 | STS API | ARN 형식 |
|---|---|---|
| IAM 사용자 | — | arn:aws:iam::acct:user/Bob |
| 자체 인증 브로커 | GetFederationToken | arn:aws:sts::acct:**federated-user**/Bob |
| SAML IdP / Identity Center | AssumeRoleWithSAML | arn:aws:sts::acct:**assumed-role**/Role/Session |
| Cognito, Google, Facebook | AssumeRoleWithWebIdentity | arn:aws:sts::acct:**assumed-role**/Role/Session |
| 교차 계정 역할 | AssumeRole | arn:aws:sts::acct:**assumed-role**/Role/Session |
역산 판별
federated-user/이름→ GetFederationToken(자체 브로커)assumed-role/역할/세션→ AssumeRole 계열 (SAML, Identity Center, Cognito 전부)iam::...:user/이름→ 순수 IAM 사용자
- 지문에 “SAML” 또는 “Identity Center” 등장 →
assumed-role - 지문에 “페더레이션 사용자”만 등장 + 선지에
federated-user존재 → GetFederationToken - 교차 계정이면 키 정책 + 상대 계정 IAM 정책 양쪽 다 허용 필요
3. 페더레이션 / 인증
3-1. SAML vs SCIM — 별개의 두 채널
IdP ═══ SAML ═══> Identity Center ← 로그인 순간마다 (인증)
IdP ═══ SCIM ═══> Identity Center ← 사용자 변경될 때마다 (명단 동기화)
| SAML | SCIM | |
|---|---|---|
| 언제 | 로그인 시 | 인사 변동 시 |
| 무엇을 | ”이 사람 인증됨” 1회성 통보 | 사용자·그룹 목록 지속 동기화 |
| 경로 | 브라우저 경유 | IdP → Identity Center API 직접 |
3-2. 연동 순서
메타데이터 받기 → ID 소스 설정 → 프로비저닝 활성화
- SAML 메타데이터 교환은 양방향
- IdP 메타데이터: 인증 URL + 공개 서명 인증서
- AWS(SP) 메타데이터: ACS URL + Entity ID
- 인증 연동 전에는 프로비저닝을 켤 수 없음
- SCIM은 Identity Center 전용 — IAM SAML 직접 페더레이션에는 없음 (저장할 명단 자체가 없음)
3-3. MFA CLI 대응
| 상황 | 명령 |
|---|---|
| 같은 계정 내 | sts get-session-token --serial-number --token-code |
| 역할 전환 | sts assume-role + 신뢰 정책에 MFA 조건 |
- 문제에 “역할”이 안 나오면 →
get-session-token aws:MultiFactorAuthPresent는 STS 임시 자격 증명에만 존재
4. 서비스 역할 구분 ⚠️ 최빈출
4-1. 로그·모니터링 4대장
| 질문 | 서비스 |
|---|---|
| 누가 무엇을 했나 (API 호출) | CloudTrail |
| 지금 어떤 상태인가 / 규정 준수 | Config |
| 성능·수치가 임계값을 넘었나 | CloudWatch |
| IP·포트·전송량은 | VPC Flow Logs |
4-2. 보안 서비스 계층
| 서비스 | 시점 | 역할 |
|---|---|---|
| Inspector | 배포 전 | 이미지/인스턴스 취약점(CVE) 스캔 |
| GuardDuty | 런타임 | 위협 탐지 (위협 인텔 + ML) |
| Security Hub | 상시 | findings 집계, 규정 준수 점검 |
| Detective | 사후 | 근본 원인 조사, 다단계 공격 경로 추적 |
| Macie | 상시 | S3 민감 데이터 탐지 |
자주 틀리는 지점
- Security Hub는 스스로 탐지하지 않음 (하위 서비스 findings를 모을 뿐)
- Detective는 탐지가 아니라 조사
- Athena는 감사 데이터를 생성하지 않음 (CloudTrail 로그를 SQL로 분석하는 후속 도구)
- GuardDuty는 탐지지 감사가 아님 (감사 = 정상 활동 포함 전체 기록)
4-3. GuardDuty 보호 기능
| 기능 | 데이터 소스 |
|---|---|
| EKS Protection | EKS 감사 로그 |
| Runtime Monitoring | eBPF 에이전트 → OS/프로세스/파일/네트워크 이벤트 |
| Malware Protection | EBS 볼륨 스캔 |
| S3 Protection | S3 데이터 이벤트 |
| RDS Protection | RDS 로그인 활동 |
지문에 “운영 체제 / 프로세스 / 파일 / 네트워크 이벤트” → Runtime Monitoring
4-4. 탐지 방식 판별
| 지문 표현 | 방식 |
|---|---|
| ”1시간에 50회 이상” (숫자 명시) | CloudWatch 메트릭 필터 + 알람 |
| ”비정상적으로”, “평소와 다른” | 기준선 학습 → CloudTrail Insights / GuardDuty |
| ”자동으로 격리/차단/대응” | EventBridge + Lambda (또는 SSM Automation) 필수 |
| ”여러 탐지 서비스 상호 연관” | Security Hub 집계 / Detective 추적 |
5. KMS
5-1. 키 삭제 3종
| 작업 | 결과 | 되돌리기 |
|---|---|---|
DisableKey | 사용만 중지, 키는 존재 | EnableKey로 즉시 |
ScheduleKeyDeletion | 7~30일 후 영구 삭제 (기본 30일) | 대기 중 CancelKeyDeletion |
| 대기 기간 만료 | 영구 삭제, 복구 불가 | 불가능 |
- 대기 중 상태 =
PendingDeletion(사용 불가) - 이미
PendingDeletion이면 재제출 불가 → 취소 후 재예약 - 비활성화 ≠ 삭제
5-2. 키 저장소 종류
| 방식 | 키 자료 위치 | 언제 |
|---|---|---|
| KMS 기본 | AWS 관리 HSM (멀티테넌트) | 일반 |
| Custom Key Store (CloudHSM) | 내 CloudHSM 클러스터 | 단독 HSM·FIPS 140-2 L3 |
| Custom Key Store (External) | 외부 키 관리자 | 온프레미스 HSM 유지 |
| Import Key Material (BYOK) | 내가 생성해 반입 | 키 생성 주권만 필요 |
5-3. kms:ViaService
“지정 서비스를 경유한 요청만 허용” = 직접 호출 차단 권한을 나눠주는 게 아니라 깎아내는 장치
- 리전까지 하드코딩됨 (
ses.us-west-2.amazonaws.com) - 자격 증명 탈취 시 폭발 반경(blast radius) 축소 목적
5-4. 봉투 암호화
GenerateDataKey → [평문 데이터 키 + 암호화된 데이터 키]
평문 키로 로컬 암호화 → 즉시 메모리 폐기
암호화된 데이터 키는 데이터 옆에 저장
마스터 키는 HSM 밖으로 절대 나오지 않음
6. S3 데이터 보호
6-1. 영구 삭제 방지 계층
버전 관리 → 실수 복구용. 버전 지정 삭제는 못 막음
MFA Delete → 버전 삭제에 MFA 요구. 루트만 설정 가능
Object Lock 거버넌스 → 특정 권한자(BypassGovernanceRetention) 우회 가능
Object Lock 규정준수 → 누구도 불가 (루트·AWS 포함)
6-2. 신호어 → 정답 매핑
| 지문 표현 | 정답 |
|---|---|
| ”실수로 삭제된 경우 복구” | 버전 관리 |
| ”권한 있는 사용자는 예외적으로 삭제 가능” | Governance 모드 |
| ”관리자도 / 루트도 / 어떤 경우에도 삭제 불가” | Compliance 모드 |
| ”규정 준수, 감사 요건, WORM” | Compliance 모드 |
6-3. 복제와 조합
- S3 Replication은 Object Lock 보존 설정까지 복제
- 전제: 양쪽 버킷 버전 관리 + Object Lock 활성화
s3:ReplicateDelete거부는 삭제 마커 전파만 통제 (직접 삭제는 못 막음)
6-4. Resource ARN 구분
| 표기 | 대상 |
|---|---|
arn:aws:s3:::BUCKET | 버킷 레벨 (ListBucket, GetBucketPolicy) |
arn:aws:s3:::BUCKET/* | 객체 레벨 (GetObject, PutObject) |
실무 완전 차단은 둘 다 명시
7. 접근 통제 / 운영
7-1. Session Manager
“SSH 키 관리 없이 / 포트 개방 없이 / 배스천 없이” → 반사적으로 Session Manager
- 인바운드 포트 0개 — 에이전트가 아웃바운드 443으로 SSM 서비스에 먼저 연결
- IAM 인증 — 키 배포·회수·순환 불필요
- 온프레미스 지원 — 하이브리드 활성화(
mi-인스턴스) - 감사 — CloudTrail(접속 이력) + S3/CloudWatch Logs(명령어 전문)
- 프라이빗 서브넷 + NAT 없이 쓰려면 인터페이스 엔드포인트 3종:
ssm/ssmmessages/ec2messages
배스천 호스트 선지는 대부분 오답 AWS 시험은 배스천을 레거시로 취급 (상시 비용 + 인바운드 개방 + SSH 키 2회)
7-2. 온프레미스 등장 시
Systems Manager 계열 의심 — Patch Manager, Run Command, Session Manager, Inventory 모두 하이브리드 지원
7-3. 루트 자격 증명
"루트로 로그인" 선지는 거의 항상 오답 루트가 정답인 경우: 계정 해지, 결제 정보 변경, 루트 액세스 키 삭제, S3 MFA Delete 설정, 잘못 설정된 키 정책 복구
8. IoT Core
8-1. 정책 변수 신뢰도
| 변수 | 검증 |
|---|---|
${iot:ClientId} | ❌ 클라이언트가 보낸 값 그대로 |
${iot:Connection.Thing.ThingName} | ✅ 인증서-사물 연결 검증 |
${iot:Connection.Thing.Attributes[속성]} | ✅ |
${iot:Certificate.Subject.CommonName} | ✅ |
지문에 “스푸핑, 위장, 권한 범위 이탈” →
iot:ClientId쓰는 선지는 오답
8-2. Thing 정책 변수 전제 조건 3가지
- 사물이 IoT 레지스트리에 등록
- 인증서가 그 사물에 연결(attach)
- 클라이언트 ID = 사물 이름
9. 범용 판별 원칙
어떤 문제든 먼저 적용
- 클라이언트 측 검증 선지는 항상 오답 (앱/SDK/디바이스에서 검사 = 공격자 통제 영역)
- 지문이 이미 허용한 권한을 또 주는 선지는 오답 (불필요한 조작 distractor)
- 선지가 2축으로 갈리면 축별로 O/X 채점 (문장 통독 X)
- 요구사항 개수만큼 선지에 기능이 있는지 확인 (요구 2갈래면 둘 다 명시한 선지)
- “여러 리전” 언급 시 리전 확인 선지가 정답 후보
- “가장 운영 효율적” = 관리형 서비스 (직접 구현/Lambda 조합은 후순위)
- 모드·기간 단어 하나만 바꾼 함정 주의 (거버넌스↔규정준수, 7일↔30일, Allow↔Deny)