시험 대비 · 함정 사전

함정 사전

SAA-C03의 오답 선택지는 대부분 존재하지 않는 서비스가 아니라 옆자리 서비스입니다. Multi-AZ 자리에 읽기 전용 복제본을, 인터페이스 엔드포인트 자리에 게이트웨이 엔드포인트를 놓아 둡니다. 그래서 두 개념을 각각 아는 것으로는 부족하고, 둘을 가르는 한 문장을 가지고 있어야 합니다. 이 페이지는 그 한 문장을 쌍 단위로 모아 놓은 사전입니다.

수록한 쌍은 44개이며 일곱 갈래로 묶었습니다. 한정어 해석은 한정어 키워드 사전이, 시험장에서의 소거 절차는 시험 당일 전략이 담당합니다.

학습 목표

이 사전을 읽는 방법

표의 네 열은 각각 다른 일을 합니다. 결정적 차이는 두 개념을 가르는 구조적 사실이고, 어느 쪽이 언제는 요구사항에서 그 사실을 끌어내는 신호이며, 시험이 노리는 지점은 오답 선택지가 실제로 뒤집는 부분입니다.

공부할 때는 왼쪽에서 오른쪽으로 읽고, 복습할 때는 쌍 이름만 보고 나머지 세 칸을 스스로 말해 본 뒤 대조하십시오. 세 칸 중 하나라도 막히면 그 행의 담당 개념이 아직 판단 가능한 상태가 아닙니다.

데이터베이스와 캐시

이 갈래는 가용성 요구와 성능 요구를 섞어 놓는 방식으로 함정을 만듭니다. 문제문에서 "장애가 나도 계속 동작해야 한다"인지 "느려서 못 쓰겠다"인지를 먼저 확정하면 후보가 절반으로 줄어듭니다.

데이터베이스와 캐시에서 혼동되는 쌍 일곱 개
쌍 결정적 차이 어느 쪽이 언제 시험이 노리는 지점
1. RDS Multi-AZ 배포 vs 읽기 전용 복제본 Multi-AZ는 동기(synchronous) 복제로 가용성을, 읽기 전용 복제본은 비동기(asynchronous) 복제로 읽기 확장을 담당합니다. Multi-AZ의 대기 인스턴스는 읽기 트래픽을 받지 않습니다 가용 영역 장애를 견디고 자동 장애 조치가 필요하면 Multi-AZ, 읽기 부하로 응답이 느려졌으면 읽기 전용 복제본. 요구가 둘 다면 둘 다 구성합니다 "Multi-AZ 대기 인스턴스로 읽기를 분산한다"는 선택지. 표준 Multi-AZ 인스턴스 배포에서는 틀립니다
2. Multi-AZ 인스턴스 배포 vs Multi-AZ DB 클러스터 배포 같은 이름을 쓰지만 별개의 아키텍처입니다. DB 클러스터 배포는 읽기 가능한 대기 인스턴스를 둡니다 문제문이 어느 배포를 말하는지 그대로 따릅니다. 명시가 없으면 표준 인스턴스 배포로 읽습니다 둘을 뒤섞어 "Multi-AZ면 언제나 대기에서 읽을 수 있다"로 일반화하게 만드는 서술
3. Amazon Aurora vs Amazon RDS Aurora는 여러 가용 영역에 걸친 공유 스토리지 계층 위에서 동작하고, 복제본이 읽기 처리와 장애 조치 대상을 겸합니다. RDS의 읽기 전용 복제본은 별도 인스턴스로 비동기 복제됩니다 읽기 확장과 빠른 장애 조치를 함께 요구하면 Aurora, 특정 엔진 버전이나 기존 구성을 그대로 옮기는 것이 목적이면 RDS Aurora에 RDS 방식의 읽기 전용 복제본 생성을 적용하는 선택지. Aurora는 클러스터에 인스턴스를 추가하는 방식입니다
4. DynamoDB LSI vs GSI 로컬 보조 인덱스(Local Secondary Index, LSI)는 테이블과 같은 파티션 키를 써야 하고, 글로벌 보조 인덱스(Global Secondary Index, GSI)는 다른 파티션 키를 쓸 수 있습니다 같은 파티션 키 안에서 다른 정렬 기준이 필요하면 LSI, 완전히 다른 속성으로 조회해야 하면 GSI 개수 상한을 뒤집는 선택지. LSI는 최대 5개, GSI는 최대 20개이고, LSI에는 파티션 키 값당 10GB 제한이 있습니다
5. DynamoDB 온디맨드 vs 프로비저닝된 용량 모드 온디맨드는 요청 단위로 처리하고, 프로비저닝은 읽기·쓰기 용량을 미리 지정합니다. 모드는 나중에 변경할 수 있습니다 트래픽을 예측할 수 없거나 급증이 잦으면 온디맨드, 안정적이고 예측 가능한 부하면 프로비저닝(오토 스케일링 병용) "용량 모드는 생성 후 바꿀 수 없다"는 서술. 바꿀 수 있습니다
6. DynamoDB Accelerator(DAX) vs Amazon ElastiCache DAX는 DynamoDB 전용 캐시이며 DynamoDB API와 호환됩니다. ElastiCache는 범용 캐시이고 캐시 적재·무효화를 애플리케이션이 구현합니다 DynamoDB 읽기 지연을 코드 변경 없이 줄이려면 DAX, 관계형 데이터베이스 결과나 세션·리더보드 같은 임의의 데이터를 캐싱하려면 ElastiCache 관계형 데이터베이스 부하 문항에 DAX를 넣는 선택지, 반대로 DynamoDB 문항에 "코드를 고쳐 캐시를 붙인다"를 넣는 선택지
7. ElastiCache Redis 엔진 vs Memcached 엔진 Redis 엔진은 복제·영속성·자료 구조를 제공하고, Memcached 엔진은 단순 키-값 캐시를 여러 노드에 수평 분할합니다 장애 조치나 데이터 구조가 필요하면 Redis 엔진, 순수 캐시를 노드 추가로 넓히기만 하면 되면 Memcached 엔진 "고가용성이 필요하다"고 해 놓고 Memcached를 답으로 유도하는 구성

네트워크와 접근 경로

이 갈래의 판단 기준은 거의 언제나 계층과 경로입니다. 어느 계층에서 막는가, 트래픽이 어디를 지나는가 두 가지만 확인하면 암호화 여부나 관리 편의 같은 부차적 서술에 끌려가지 않습니다.

네트워크와 접근 경로에서 혼동되는 쌍 일곱 개
쌍 결정적 차이 어느 쪽이 언제 시험이 노리는 지점
8. 보안 그룹 vs 네트워크 ACL 보안 그룹은 인스턴스 수준 · 상태 저장(stateful) · 허용 규칙만, 네트워크 ACL은 서브넷 수준 · 상태 비저장(stateless) · 허용과 거부 모두입니다 계층 간 접근을 여는 것은 보안 그룹, 서브넷 단위로 특정 대역을 막는 것은 네트워크 ACL "보안 그룹으로 특정 IP를 차단한다" — 보안 그룹에는 거부 규칙이 없으므로 항상 오답입니다
9. 게이트웨이 엔드포인트 vs 인터페이스 엔드포인트 게이트웨이 엔드포인트는 라우팅 테이블의 경로이고 Amazon S3와 Amazon DynamoDB 전용입니다. 인터페이스 엔드포인트(AWS PrivateLink)는 서브넷에 네트워크 인터페이스를 만듭니다 대상이 S3나 DynamoDB면 게이트웨이 엔드포인트, 그 밖의 서비스나 온프레미스에서의 접근이 필요하면 인터페이스 엔드포인트 S3 접근에 인터페이스 엔드포인트를 답으로 놓는 구성, 그리고 게이트웨이 엔드포인트에 보안 그룹을 연결한다는 서술
10. NAT 게이트웨이 vs NAT 인스턴스 NAT 게이트웨이는 AWS 관리형이고 보안 그룹을 연결할 수 없습니다. NAT 인스턴스는 사용자가 운영하는 EC2 인스턴스라 보안 그룹·포트 포워딩·배스천 겸용이 가능합니다 운영 부담을 줄이는 것이 요구면 NAT 게이트웨이. 포트 포워딩이나 배스천 겸용처럼 인스턴스여야 가능한 요구가 명시되면 NAT 인스턴스 "관리형이니 자동으로 다중 가용 영역"이라는 서술. NAT 게이트웨이는 지정한 서브넷의 가용 영역 안에서만 동작하므로 이중화는 가용 영역마다 하나씩 두어야 합니다
11. VPC 피어링 vs AWS Transit Gateway 피어링은 두 VPC를 일대일로 잇고 전이적 라우팅이 없습니다. Transit Gateway는 허브 역할을 하며 다수 VPC와 온프레미스를 한 지점에 모읍니다 VPC가 둘뿐이면 피어링, 수가 늘어 연결 조합이 급증하거나 온프레미스까지 함께 묶어야 하면 Transit Gateway "피어링을 여러 개 만들면 전이적으로 통신된다"는 서술. 피어링은 전이되지 않습니다
12. AWS Direct Connect vs Site-to-Site VPN Direct Connect는 전용 회선이라 공용 인터넷을 지나지 않습니다. VPN은 인터넷 위에 IPsec 터널을 세우므로 암호화되지만 경로는 공용망입니다 일관된 대역폭과 비공개 경로가 요구면 Direct Connect, 빠르게 구축하거나 백업 경로가 목적이면 VPN "인터넷을 경유하면 안 된다"는 제약에 VPN을 답으로 놓는 구성. 암호화는 경로 제약을 대신하지 못합니다
13. Application Load Balancer vs Network Load Balancer ALB는 L7에서 HTTP·HTTPS를 처리하고 경로·호스트 기반 라우팅을 합니다. NLB는 L4에서 TCP·TLS·UDP를 처리합니다 HTTP 헤더나 경로로 라우팅해야 하면 ALB. TCP·UDP 프로토콜이거나 고정 IP 주소가 필요하면 NLB UDP 트래픽이나 고정 IP 요구에 ALB를 놓는 구성. ALB는 HTTP 계열만 처리합니다
14. Network Load Balancer vs Gateway Load Balancer GWLB는 GENEVE 프로토콜로 서드파티 가상 어플라이언스에 트래픽을 투명하게 넘깁니다. 애플리케이션 부하 분산이 목적이 아닙니다 방화벽·침입 탐지 같은 인라인 검사 어플라이언스를 배치하는 요구면 GWLB, 그 밖의 L4 부하 분산은 NLB 어플라이언스 삽입 요구에 NLB를, 일반 TCP 부하 분산에 GWLB를 놓는 맞바꾸기

엣지와 DNS

엣지 서비스는 이름이 비슷하고 효과가 겹쳐 보여서 혼동을 만듭니다. 캐싱인가 경로 최적화인가, 질의의 출발지인가 리소스의 위치인가 두 질문이 이 갈래의 대부분을 가릅니다.

엣지와 DNS에서 혼동되는 쌍 네 개
쌍 결정적 차이 어느 쪽이 언제 시험이 노리는 지점
15. Amazon CloudFront vs AWS Global Accelerator CloudFront는 엣지에서 콘텐츠를 캐싱하는 HTTP 계열 서비스이고, Global Accelerator는 고정 애니캐스트 IP로 AWS 백본까지의 경로를 앞당기며 TCP·UDP를 다룹니다 정적·동적 웹 콘텐츠 가속이면 CloudFront. 게임·음성 같은 비HTTP 프로토콜이거나 고정 IP와 빠른 리전 장애 조치가 필요하면 Global Accelerator UDP 워크로드에 CloudFront를 놓는 구성. 반대로 이미지·동영상 배포에 Global Accelerator를 놓는 구성
16. 지연 시간 vs 지리적 위치 vs 지리 근접 라우팅 지연 시간 기반은 측정된 지연이 가장 낮은 리전으로, 지리적 위치는 질의가 어디서 왔는가로, 지리 근접은 리소스의 위치와 편향(bias) 값으로 응답합니다 성능이 목적이면 지연 시간 기반. 규정·저작권·언어처럼 사용자 위치로 콘텐츠를 갈라야 하면 지리적 위치. 리소스 쪽 위치를 기준으로 트래픽 비중을 조정하려면 지리 근접 "유럽 사용자에게는 유럽 데이터만 제공해야 한다"는 규정 요구에 지연 시간 기반을 놓는 구성
17. 장애 조치 라우팅 vs 다중값 응답 라우팅 장애 조치는 기본과 보조를 정해 상태 확인 실패 시 전환합니다. 다중값 응답은 여러 레코드를 거의 무작위로 함께 돌려줍니다 재해 복구용 대기 사이트로 넘기는 요구면 장애 조치. 여러 정상 대상에 요청을 흩뿌리는 정도면 다중값 응답 다중값 응답을 로드 밸런서 대체재로 서술하는 선택지. 부하 분산 알고리즘도 세션 처리도 제공하지 않습니다
18. AWS WAF vs AWS Shield WAF는 HTTP 요청의 내용을 규칙으로 검사합니다. Shield는 디도스(DDoS) 공격 대응이며 표준 보호는 기본 제공, 상위 보호는 별도 구독입니다 SQL 삽입·특정 경로·요청 비율 같은 L7 규칙이면 WAF. 대규모 볼륨 공격 대응과 대응 팀 지원이 요구면 Shield 상위 보호 애플리케이션 계층 규칙 요구에 Shield를, 볼륨 공격 대응에 WAF만을 답으로 놓는 맞바꾸기

스토리지

스토리지 갈래의 함정은 같은 서비스의 다른 티어에서 나옵니다. 서비스 이름이 정답과 같아서 안심하고 고르게 만드는 것이 이 유형의 설계 의도입니다. 클래스·타입·복제 범위를 요구사항과 하나씩 대조해야 합니다.

스토리지에서 혼동되는 쌍 일곱 개
쌍 결정적 차이 어느 쪽이 언제 시험이 노리는 지점
19. S3 Standard-IA vs S3 One Zone-IA 저장하는 가용 영역 수가 다릅니다. Standard-IA는 3개 이상, One Zone-IA는 1개입니다. 최소 저장 기간 30일과 최소 청구 크기 128KB는 둘 다 같습니다 재생성할 수 있는 사본이나 이차 백업이면 One Zone-IA, 원본이거나 가용 영역 장애를 견뎌야 하면 Standard-IA "더 저렴하니까 One Zone-IA"로 유도한 뒤 가용 영역 장애 내성 요구를 문제문에 숨겨 두는 구성
20. S3 Glacier Flexible Retrieval vs Deep Archive 최소 저장 기간이 90일과 180일로 다르고, 검색 시간도 다릅니다. Deep Archive의 기본 검색 시간은 12시간입니다 몇 시간 안에 꺼내야 할 가능성이 있으면 Flexible Retrieval, 규정상 장기 보관이고 꺼낼 일이 거의 없으면 Deep Archive "수 분 안에 복원"이 요구인데 Deep Archive를 답으로 놓는 구성. 반대로 10년 보관 요구에 Standard를 놓는 구성
21. S3 버킷 정책 vs ACL 버킷 정책은 리소스 기반 정책이고, ACL은 객체·버킷 단위의 옛 접근 제어 방식입니다. 신규 버킷은 ACL이 비활성 상태로 만들어집니다 접근 제어는 버킷 정책과 IAM 정책으로 합니다. ACL은 개별 객체마다 소유자를 달리해야 하는 드문 경우에만 남습니다 "ACL로 퍼블릭 읽기를 준다"는 선택지. 현행 기본 구성에서는 ACL 자체가 꺼져 있습니다
22. 교차 리전 복제(CRR) vs 동일 리전 복제(SRR) 복제 대상 버킷이 다른 리전인가 같은 리전인가입니다. 두 복제 모두 원본 버킷에 버전 관리가 켜져 있어야 합니다 리전 장애 대비나 사용자 근접 배치면 CRR, 로그 집계·계정 분리·데이터 주권 요구가 같은 리전 안에서 해결되면 SRR 복제만 켜면 기존 객체까지 자동으로 복사된다고 서술하는 선택지, 그리고 버전 관리 전제 조건을 빼놓는 구성
23. Amazon EBS vs 인스턴스 스토어 EBS는 네트워크로 연결된 영속 볼륨이고, 인스턴스 스토어는 호스트에 물리적으로 붙은 임시 저장소로 인스턴스를 중지·종료하면 사라집니다 데이터가 인스턴스보다 오래 살아야 하면 EBS. 캐시·스크래치·임시 처리 공간이면 인스턴스 스토어 인스턴스 스토어를 데이터베이스 데이터 파일 위치로 제안하는 선택지. 중지 한 번으로 데이터가 사라집니다
24. EBS 스냅샷 vs AMI 스냅샷은 볼륨 하나의 시점 백업이고, AMI는 인스턴스를 시작하기 위한 템플릿으로 루트 볼륨 스냅샷과 블록 디바이스 매핑을 함께 담습니다 데이터 볼륨만 되살리면 스냅샷, 같은 구성의 인스턴스를 다시 띄우거나 다른 리전에 배포하면 AMI "스냅샷으로 다른 리전에 인스턴스를 시작한다"는 선택지. 인스턴스를 시작하려면 AMI가 필요합니다
25. Amazon EFS vs Amazon FSx EFS는 Linux용 NFS 공유 파일 시스템으로 여러 가용 영역에서 동시에 마운트됩니다. FSx는 용도별 파일 시스템 제품군으로, Windows File Server는 SMB와 Active Directory 통합을, Lustre는 고성능 컴퓨팅용 처리량을 담당합니다 여러 Linux 인스턴스가 같은 파일을 봐야 하면 EFS. Windows 애플리케이션의 SMB 공유면 FSx for Windows File Server, 대규모 병렬 분석이면 FSx for Lustre Windows 워크로드에 EFS를, Linux 공유에 FSx for Windows File Server를 놓는 맞바꾸기

애플리케이션 통합과 컴퓨팅

이 갈래는 대립이 아닌 것을 대립처럼 보이게 만드는 함정이 많습니다. AWS Fargate는 Amazon ECS·Amazon EKS의 경쟁자가 아니라 실행 방식이고, Amazon SNS와 Amazon SQS는 조합해서 쓰는 것이 정답인 경우가 많습니다.

애플리케이션 통합과 컴퓨팅에서 혼동되는 쌍 여섯 개
쌍 결정적 차이 어느 쪽이 언제 시험이 노리는 지점
26. Amazon SQS vs Amazon SNS vs Amazon EventBridge SQS는 한 메시지를 한 소비자가 가져가는 큐, SNS는 모든 구독자에게 팬아웃, EventBridge는 이벤트 내용에 따른 규칙 라우팅입니다 급증분 완충과 재시도면 SQS, 하나의 사건을 여러 시스템이 받아야 하면 SNS, 이벤트 종류별로 다른 대상에 보내거나 AWS 서비스 이벤트에 반응해야 하면 EventBridge 팬아웃과 완충을 동시에 요구하는 문항. 정답은 SNS 주제에 여러 SQS 큐를 구독시키는 조합인데, 셋 중 하나만 고르게 유도합니다
27. SQS 표준 큐 vs FIFO 큐 표준 큐는 순서를 보장하지 않는 대신 처리량이 거의 무제한이고, FIFO 큐는 메시지 그룹 안에서 엄격한 순서와 중복 제거를 제공합니다 순서나 중복 제거가 명시되면 FIFO, 그렇지 않으면 표준 "표준 큐를 FIFO로 전환한다"는 선택지. 큐 타입은 생성 후 변경할 수 없습니다. 또한 FIFO 큐는 MessageGroupId 없이 전송하면 실패합니다
28. Kinesis Data Streams vs Data Firehose Data Streams는 샤드에 데이터를 보관해 여러 소비자가 각자 읽고 재처리할 수 있게 합니다. Firehose는 버퍼링해 대상으로 전달하는 관리형 배달 경로입니다 소비자를 직접 구현하고 재생·다중 소비가 필요하면 Data Streams. Amazon S3나 OpenSearch 같은 대상으로 코드 없이 적재하면 Firehose "실시간"이라는 한정어를 붙여 놓고 배치 도구를 답으로 놓는 구성. 반대로 단순 적재 요구에 소비자 구현이 필요한 Data Streams를 놓는 과잉 설계
29. Amazon ECS vs Amazon EKS vs AWS Fargate Fargate는 오케스트레이터가 아니라 서버리스 실행 모드이며 ECS와 EKS 양쪽에서 쓸 수 있습니다. ECS는 AWS 자체 오케스트레이터, EKS는 관리형 Kubernetes입니다 Kubernetes 생태계나 기존 매니페스트를 그대로 써야 하면 EKS, AWS 안에서 단순하게 컨테이너를 돌리면 ECS. 어느 쪽이든 노드 운영 부담을 없애려면 Fargate "ECS와 Fargate 중 무엇을 고르는가"처럼 층위가 다른 셋을 나란히 세우는 선택지 배열
30. 수직 확장 vs 수평 확장 수직 확장은 인스턴스를 더 큰 타입으로 바꾸는 것이라 상한이 있고 교체 시 중단이 따릅니다. 수평 확장은 대수를 늘리는 것이라 상한이 훨씬 넓습니다 탄력성·내결함성·비용 최적화가 요구면 수평 확장. 단일 스레드 성능처럼 나눌 수 없는 요구에만 수직 확장 급증 대응 문항에서 "더 큰 인스턴스로 변경한다"를 정답처럼 놓는 구성. 상태 비저장 설계가 전제되면 거의 언제나 수평 확장이 답입니다
31. 배치 그룹 — 클러스터 vs 분산 vs 파티션 클러스터는 한 가용 영역에 몰아 지연을 줄이고, 분산은 서로 다른 하드웨어로 흩어 동시 장애를 막으며, 파티션은 파티션 단위로 하드웨어를 분리합니다 노드 간 통신 지연이 병목이면 클러스터, 소수의 중요 인스턴스를 격리하려면 분산, 분산 데이터 플랫폼처럼 그룹 단위 격리가 필요하면 파티션 고가용성 요구에 클러스터 배치 그룹을 답으로 놓는 구성. 클러스터는 오히려 장애 범위를 좁은 곳에 모읍니다

보안과 거버넌스

이 갈래에서는 무엇을 하는 서비스인가보다 어떤 질문에 답하는 서비스인가로 구분하는 편이 빠릅니다. 문제문의 동사가 "감사한다", "탐지한다", "찾는다" 중 무엇인지 보면 대체로 하나만 남습니다.

보안과 거버넌스에서 혼동되는 쌍 여섯 개
쌍 결정적 차이 어느 쪽이 언제 시험이 노리는 지점
32. SCP vs 권한 경계 서비스 제어 정책(Service Control Policy, SCP)은 조직·계정 단위 상한이고 멤버 계정의 루트 사용자에게도 적용됩니다. 권한 경계는 개별 IAM 주체에 거는 상한입니다 계정 전체에서 특정 리전이나 서비스를 금지하면 SCP, 개발자가 자기보다 큰 권한의 역할을 만들지 못하게 하면 권한 경계 "SCP로 권한을 부여한다"는 서술. SCP는 권한을 부여하지 않습니다. 실제 허용은 여전히 IAM 정책이 해야 합니다
33. 자격 증명 기반 정책 vs 리소스 기반 정책 자격 증명 기반 정책은 주체에 붙고, 리소스 기반 정책은 리소스에 붙으며 Principal 요소를 가집니다 동일 계정 안에서는 둘 중 하나만 허용해도 통과합니다(합집합). 교차 계정에서는 양쪽 모두 허용해야 합니다 교차 계정 접근 문항에서 한쪽만 고치는 선택지. 그리고 권한 경계·SCP·세션 정책까지 합집합으로 착각하게 만드는 서술 — 이 셋은 교집합입니다
34. AWS Secrets Manager vs Parameter Store Secrets Manager는 자동 교체(rotation)가 내장되어 있고, AWS Systems Manager Parameter Store에는 그 기능이 없습니다. Parameter Store는 SecureString으로 비밀도 저장할 수 있습니다 자격 증명을 주기적으로 교체해야 하면 Secrets Manager, 설정값을 계층 구조로 관리하고 교체 요구가 없으면 Parameter Store 교체 요구가 문제문에 있는데 Parameter Store를 답으로 놓는 구성. 반대로 단순 설정값 관리에 Secrets Manager를 놓는 과잉 설계
35. KMS 고객 관리형 키 vs AWS 관리형 키 고객 관리형 키는 키 정책·별칭·교체·삭제 일정을 직접 통제하고 교차 계정 공유가 가능합니다. AWS 관리형 키는 서비스가 자동으로 만들어 쓰며 키 정책을 직접 편집하지 않습니다 키 정책으로 접근을 따로 제한하거나 다른 계정과 공유해야 하면 고객 관리형 키. 암호화 사실만 필요하면 AWS 관리형 키로 충분합니다 "IAM 정책만 열면 복호화된다"는 서술. 키 정책과 IAM 정책이 함께 허용해야 복호화됩니다
36. GuardDuty vs Inspector vs Macie Amazon GuardDuty는 이상 행위와 위협을 탐지하고, Amazon Inspector는 워크로드의 취약점을 점검하며, Amazon Macie는 민감 데이터의 위치를 찾습니다 계정에서 수상한 활동이 보인다면 GuardDuty, 인스턴스·컨테이너 이미지의 취약점 점검이면 Inspector, S3에 개인정보가 있는지 확인하면 Macie "S3에서 민감 정보를 찾아라"에 GuardDuty를 놓는 구성. 여러 서비스의 결과를 모아 보는 요구라면 AWS Security Hub입니다
37. CloudTrail vs Config vs CloudWatch AWS CloudTrail은 누가 어떤 API를 호출했는가, AWS Config는 리소스 구성이 규칙에 맞는가, Amazon CloudWatch는 지표·로그·알람을 담당합니다 감사 추적이면 CloudTrail, 구성 준수와 변경 이력이면 Config, 성능 감시와 임계값 알림이면 CloudWatch "누가 이 보안 그룹을 열었는지 찾아라"에 Config를, "규정 위반 구성을 지속적으로 평가하라"에 CloudTrail을 놓는 맞바꾸기

비용 · 확장 · 복구 · 운영

비용과 복구 갈래는 교환 조건을 감추는 방식으로 함정을 만듭니다. 더 싼 안에는 더 긴 복구 시간이나 더 좁은 유연성이 붙어 있고, 문제문은 그 교환 조건 중 한쪽만 명시합니다.

비용·확장·복구·운영에서 혼동되는 쌍 일곱 개
쌍 결정적 차이 어느 쪽이 언제 시험이 노리는 지점
38. 예약 인스턴스 vs Savings Plans 예약 인스턴스(Reserved Instance, RI)는 인스턴스 속성에 대한 약정이고, Savings Plans는 시간당 지출 금액에 대한 약정이라 조건을 만족하는 사용량에 자동 적용됩니다 인스턴스 타입이 고정되어 있고 용량 예약까지 필요하면 존 단위 RI. 인스턴스 패밀리나 리전이 바뀔 여지가 있으면 Savings Plans "Savings Plans가 용량을 예약해 준다"는 서술. 지출 약정이지 용량 확보 수단이 아닙니다
39. 스팟 인스턴스 vs 온디맨드 스팟 인스턴스는 AWS가 회수하면 중단됩니다. 온디맨드는 중단되지 않는 대신 약정 할인이 없습니다 중단되어도 되는 배치·렌더링·스테이트리스 작업이면 스팟. 중단이 곧 장애인 워크로드면 온디맨드나 약정 옵션 데이터베이스나 상태를 가진 계층에 스팟을 답으로 놓는 구성. "비용 최적화"라는 한정어만 보고 고르게 만듭니다
40. 대상 추적 vs 단계별 스케일링 대상 추적은 지표의 목표값을 유지하도록 AWS가 알아서 조정하고, 단계별 스케일링은 알람을 얼마나 초과했는지에 따라 단계별 조정량을 사용자가 정합니다 평균 CPU 사용률 같은 단일 지표를 일정하게 유지하면 대상 추적. 위반 크기에 따라 다르게 반응해야 하면 단계별 스케일링 "규칙을 세밀히 정의해야 한다"는 요구에 대상 추적을, 단순 유지 요구에 단계별 정책을 놓는 맞바꾸기. 시각이 정해진 트래픽이면 예약 스케일링이 답입니다
41. 파일럿 라이트 vs 웜 스탠바이 파일럿 라이트는 데이터 복제와 핵심 요소만 준비해 두고 대부분을 꺼 둡니다. 웜 스탠바이는 축소된 규모로 항상 가동하며 트래픽을 받을 수 있는 상태입니다 복구 시간을 시간 단위로 허용하면 파일럿 라이트, 분 단위로 줄여야 하면 웜 스탠바이. 무중단이 요구면 다중 사이트 액티브-액티브 RTO 요구를 명시해 놓고 상시 가동 범위가 요구보다 작거나 큰 전략을 답으로 놓는 구성
42. Snow Family vs AWS DataSync Snow Family는 물리 장비를 배송해 오프라인으로 옮기고, DataSync는 네트워크로 전송하는 에이전트 기반 서비스입니다 대역폭이 부족하거나 회선이 없어 기한 안에 못 옮기면 Snow Family. 회선이 충분하고 주기적 동기화가 필요하면 DataSync 대역폭과 기한을 문제문에 숨겨 두고 반대쪽을 고르게 만드는 구성. 상시 하이브리드 접근이 목적이면 AWS Storage Gateway가 답입니다
43. Cost Explorer vs AWS Budgets Cost Explorer는 이미 발생한 비용을 분석하고, AWS Budgets는 한도를 정해 초과를 알립니다. 상세 원장이 필요하면 AWS Cost and Usage Report입니다 어디에 얼마를 썼는지 파악하면 Cost Explorer, 초과 시 알림을 받아야 하면 Budgets, 청구 항목 단위 원본 데이터가 필요하면 Cost and Usage Report "예산 초과 시 알림"이라는 요구에 Cost Explorer를 놓는 구성
44. AWS CloudFormation vs AWS CDK CloudFormation은 템플릿으로 인프라를 선언하는 시험 범위 안 서비스입니다. AWS CDK는 시험 범위 밖입니다 인프라를 코드로 정의·재배포하는 요구는 CloudFormation으로 답합니다 학습 자료에서 둘을 나란히 소개하는 습관 때문에 생기는 혼동입니다. 시험에서 판단 대상이 되는 것은 CloudFormation뿐입니다

쌍이 아닌 쌍

마지막으로, 대립 구도 자체가 잘못된 세 가지를 따로 모았습니다. 이 유형은 선택지 배열만으로 오해를 만들기 때문에, 문제를 읽는 순간 "이 둘은 층위가 다르다"고 알아차리는 것이 유일한 방어입니다.

대립처럼 배열되지만 층위가 다른 세 가지
잘못된 대립 실제 관계 문항에서의 대처
ECS vs Fargate Fargate는 ECS(그리고 EKS)의 실행 방식입니다. 경쟁 서비스가 아닙니다 고를 것은 오케스트레이터(ECS인가 EKS인가)와 실행 방식(EC2인가 Fargate인가) 두 가지입니다
SQS vs SNS 완충과 팬아웃은 함께 쓸 수 있습니다. SNS 주제에 여러 SQS 큐를 구독시키는 구성이 표준 패턴입니다 둘 다 포함한 선택지가 있으면 그쪽을 먼저 검토합니다
Multi-AZ vs 다중 리전 가용 영역 이중화와 리전 이중화는 다루는 장애의 크기가 다릅니다. 대체 관계가 아닙니다 문제문의 장애 시나리오가 가용 영역 규모인지 리전 규모인지 먼저 확정합니다

이어서 볼 곳

공식 문서 출처