시험 대비 · 한정어 키워드 사전

한정어 키워드 사전

SAA-C03의 시나리오 문항은 맞는 답과 틀린 답을 고르는 시험이 아닙니다. 선택지 넷 중 셋이 기술적으로 동작하고, 문제문 마지막에 붙은 한 단어가 그중 하나만 정답으로 만듭니다. 서비스를 따로따로 잘 공부하고도 떨어지는 이유가 여기 있습니다. 이 페이지는 그 한 단어 — 한정어(qualifier) — 를 사전처럼 정리합니다.

이 페이지는 특정 도메인에 속하지 않고 4개 도메인 전체에 걸쳐 적용됩니다. 도메인별 지식은 보안 아키텍처 설계 이하 네 페이지에서 다루고, 여기서는 그 지식을 문항에 적용하는 규칙만 다룹니다.

학습 목표

왜 한정어가 정답을 결정하는가

SAA-C03의 채점 문항은 객관식(단일 정답)과 복수 응답 두 가지뿐이고, 거의 전부가 시나리오 형태입니다. 시나리오 문항의 선택지는 대체로 "동작하지 않는 안 하나 + 동작하는 안 셋"으로 구성됩니다. 따라서 "이게 되나?"를 묻는 순간 세 개가 남습니다. 남은 셋을 가르는 것이 한정어입니다.

넷 다 맞는 답처럼 보일 때

예를 들어 "프라이빗 서브넷의 애플리케이션이 Amazon S3의 객체를 읽어야 한다"는 시나리오에서 NAT 게이트웨이를 두는 안, 게이트웨이 VPC 엔드포인트를 만드는 안, 인스턴스를 퍼블릭 서브넷으로 옮기는 안은 모두 객체를 읽게 만듭니다. 셋 중 무엇이 정답인지는 문제문이 MOST cost-effective라고 했는지, traffic must not traverse the internet이라고 했는지에 달려 있습니다. 기술 지식만으로는 이 문항을 풀 수 없습니다.

그래서 이 사이트는 서비스 지식과 한정어 해석을 별개의 기술로 취급합니다. 18개 챕터가 전자를 담당하고, 이 페이지가 후자를 담당합니다. 둘 중 하나만 갖추면 시험장에서 "아는데 틀리는" 상태가 됩니다.

읽는 순서 — 마지막 문장을 먼저 읽는다

시나리오 문항은 대개 배경 서술이 길고 요구사항이 마지막에 붙습니다. 처음부터 순서대로 읽으면 배경을 이해하느라 인지 자원을 다 쓰고, 정작 판단 기준인 마지막 문장을 흐릿하게 읽게 됩니다. 순서를 뒤집으면 배경을 읽는 동안 이미 무엇을 찾을지 알고 있습니다.

시나리오 문항을 읽는 권장 순서
순서 무엇을 읽는가 여기서 얻는 것
1 마지막 문장 — 질문문과 한정어 비용인가 가용성인가 지연인가 운영 부담인가. 판단 축이 하나로 정해집니다
2 본문에서 제약을 나타내는 문장만 골라 읽기 "인터넷을 거치면 안 된다", "코드를 수정할 수 없다", "데이터가 국외로 나갈 수 없다"
3 나머지 배경 서술 규모·트래픽 패턴·현재 구성. 후보를 좁히는 보조 정보입니다
4 선택지 — 제약 위반부터 버린다 동작 여부를 따지기 전에 소거되는 것들이 먼저 빠집니다
5 남은 선택지를 한정어 축 하나로만 비교 비용 문항이면 가용성 비교를 하지 않습니다. 축이 섞이면 다시 헤맵니다

복수 응답 문항에서는 문제문이 선택 개수를 명시합니다. 개수를 확인하지 않고 하나만 고르면 그 문항은 자동으로 오답입니다. 복수 응답은 부분 점수가 없으므로, 두 개를 고르라고 하면 두 개 다 맞아야 합니다.

제약과 한정어는 다르다

둘을 섞으면 판단이 흔들립니다. 제약(constraint)은 통과 여부를 정하는 문턱이고, 한정어(qualifier)는 문턱을 넘은 것들 사이의 순위입니다. 제약은 만족하거나 위반하거나 둘 중 하나이고, 한정어는 정도의 문제입니다.

제약과 한정어의 차이
항목 제약 한정어
문장 형태 "~해야 한다", "~할 수 없다", "~를 유지해야 한다" "가장 ~한", MOST, LEAST, LOWEST
역할 후보를 탈락시킨다 남은 후보를 정렬한다
적용 순서 먼저 나중
예 "데이터는 리전을 벗어날 수 없다" "가장 비용 효율적인 방법은"
위반했을 때 아무리 싸고 빨라도 오답 정답 후보이긴 하지만 순위가 밀린다

한정어 사전 SAA 빈출

영어로 응시하든 한국어로 응시하든 한정어는 같은 자리에 같은 역할로 나옵니다. 한국어 시험지에서는 "가장 비용 효율적인", "운영 오버헤드가 가장 적은", "지연 시간이 가장 짧은"처럼 번역되므로, 영문과 한국어 표현을 함께 외워 둡니다.

아래 표의 배제되는 선택지 열이 실제로는 더 유용합니다. 정답을 찾는 것보다 오답 세 개를 지우는 편이 빠르고 안정적이기 때문입니다.

SAA-C03 시나리오 문항의 주요 한정어 13종 — 신호, 선호되는 선택지, 배제되는 선택지
한정어 신호 — 무엇을 묻는가 선호되는 선택지 배제되는 선택지
MOST cost-effective
가장 비용 효율적인		 기능은 이미 충족되었고 비용이 유일한 판단 축입니다. 계산을 요구하는 것이 아니라 구조적으로 더 싼 안을 고르라는 뜻입니다 스팟 인스턴스, Savings Plans와 예약 인스턴스, S3 Standard-IA와 Glacier 계열, 수명 주기 규칙, 서버리스, 라이트사이징, VPC 엔드포인트로 NAT 경유 제거 상시 가동하는 여분 용량, 요구가 없는데 선택한 Provisioned IOPS 볼륨, 필요 없는 다중 리전 액티브-액티브, 프로비저닝 용량을 최대치로 고정하는 안
LEAST operational overhead
운영 오버헤드가 가장 적은		 누가 관리하는가를 묻습니다. 패치·스케일링·백업·장애 조치를 사람이 하지 않는 쪽이 정답입니다 AWS Lambda, AWS Fargate, Amazon DynamoDB, Amazon S3, Amazon Aurora Serverless v2, AWS Backup, 관리형 서비스 전반 Amazon EC2에 직접 설치해 운영하는 안, 크론 스크립트로 돌리는 배치, 사용자가 직접 패치·백업·장애 조치를 수행하는 안, 자체 관리 데이터베이스
MOST highly available
가용성이 가장 높은		 구성 요소 하나가 죽어도 서비스가 유지되는가. 인스턴스 대수가 아니라 가용 영역 개수를 봅니다 다중 가용 영역 배치, 가용 영역에 걸친 Auto Scaling 그룹, Elastic Load Balancing, Amazon RDS Multi-AZ 배포, 가용 영역마다 하나씩 둔 NAT 게이트웨이 단일 가용 영역에 인스턴스만 늘리는 안, 단일 NAT 게이트웨이, S3 One Zone-IA에 원본을 두는 안, 수동 장애 조치 절차
MOST resilient · disaster recovery
복원력 · 재해 복구		 리전 규모의 사고를 전제합니다. RTO와 RPO 수치가 함께 제시되는 경우가 많습니다 리전 간 복제와 스냅샷 복사, 파일럿 라이트와 웜 스탠바이, Amazon Route 53 장애 조치 라우팅, AWS Backup 교차 리전 백업, S3 교차 리전 복제 같은 리전에만 두는 백업, 복구 절차를 검증하지 않는 안, RTO 요구를 만족하지 못하는 백업·복원 전략, 단일 리전 다중 가용 영역만으로 리전 장애에 대응하려는 안
MOST secure
가장 안전한		 최소 권한과 자격 증명의 수명을 묻습니다. 암호화 여부와 노출 경로도 함께 봅니다 IAM 역할과 임시 자격 증명, AWS KMS 고객 관리형 키, 프라이빗 서브넷 배치, VPC 엔드포인트, 보안 그룹으로 최소 포트만 개방, AWS Secrets Manager EC2에 IAM 사용자 액세스 키를 심는 안, 0.0.0.0/0 인바운드 허용, 퍼블릭 서브넷에 둔 데이터베이스, 버킷을 퍼블릭으로 여는 안, 자격 증명을 코드나 환경 변수에 하드코딩하는 안
LOWEST latency
지연 시간이 가장 짧은		 사용자와 데이터 사이의 거리 또는 반복 조회 비용을 묻습니다. 사용자가 전 세계인지 한 리전인지 확인합니다 Amazon CloudFront, Amazon ElastiCache, Amazon DynamoDB Accelerator(DAX), AWS Global Accelerator, 클러스터 배치 그룹, 읽기 전용 복제본을 사용자 가까운 리전에 배치 배치 처리로 미리 만들어 두는 안, 매 요청마다 원본까지 다녀오는 안, 단일 리전으로 전 세계를 서비스하는 안, 큐를 끼워 넣어 응답을 비동기로 바꾸는 안
MOST scalable · decoupled
확장 가능한 · 느슨하게 결합된		 구성 요소가 서로를 기다리는가. 급증 트래픽을 흡수할 완충 장치가 있는지 봅니다 Amazon SQS, Amazon SNS, Amazon EventBridge, Auto Scaling 그룹, AWS Lambda, 상태 비저장 애플리케이션 계층 동기 호출로 이어 붙인 체인, 인스턴스 타입을 키우는 수직 확장, 인스턴스 로컬 디스크에 세션이나 파일을 저장하는 안, 고정 대수 배포
without changing application code
애플리케이션 코드 수정 없이		 리팩터링을 요구하는 선택지를 전부 배제합니다. 인프라 계층에서만 해결하라는 뜻입니다 Application Load Balancer, Amazon ElastiCache를 투명 캐시 계층으로, Amazon EFS로 공유 파일 시스템 제공, Amazon RDS Proxy, 인스턴스 타입 변경, Auto Scaling 다른 데이터베이스 엔진으로 이관하는 안, SDK 호출을 새로 넣어야 하는 안, 애플리케이션을 서버리스로 재작성하는 안, 스키마 재설계
real-time · near-real-time
실시간 · 준실시간		 데이터가 생기는 즉시 처리해야 하는가. 배치 도구는 이 문항에서 전부 오답입니다 Amazon Kinesis Data Streams, Amazon Managed Streaming for Apache Kafka(MSK), Amazon Data Firehose로의 연속 적재, AWS Lambda 이벤트 소스 매핑 AWS Glue 배치 ETL, 하루 한 번 도는 작업, Amazon S3에 모았다가 나중에 조회하는 안, Amazon Athena로 사후 분석하는 안
must not traverse the internet
인터넷을 경유하지 않고		 패킷의 경로를 묻습니다. 암호화 여부가 아니라 경로가 판단 기준입니다 게이트웨이 VPC 엔드포인트(Amazon S3 · Amazon DynamoDB), 인터페이스 VPC 엔드포인트와 AWS PrivateLink, AWS Direct Connect, VPC 피어링, AWS Transit Gateway NAT 게이트웨이를 거쳐 퍼블릭 엔드포인트로 나가는 안, 인터넷 게이트웨이 경유, 퍼블릭 IP에 소스 IP 허용 목록만 거는 안, 인터넷 회선 위의 사이트 간 VPN을 비공개 경로로 제시하는 안
compliance · audit
규정 준수 · 감사		 증적과 불변성을 묻습니다. 누가 무엇을 했는지 남고, 남은 것이 지워지지 않아야 합니다 AWS CloudTrail, AWS Config, S3 Object Lock과 버전 관리, KMS 고객 관리형 키, 리전을 고정하는 SCP, Amazon Macie 로그를 인스턴스 로컬에만 두는 안, 삭제와 덮어쓰기가 자유로운 저장소, 데이터 레지던시를 위반하는 교차 리전 복제, 콘솔 작업 기록을 사람이 문서로 남기는 안
existing infrastructure
기존 인프라를 활용하며		 통합이지 대체가 아닙니다. 온프레미스를 그대로 두고 AWS를 붙이라는 뜻입니다 AWS Direct Connect, AWS Storage Gateway, AWS DataSync, AWS Outposts, 사이트 간 VPN, AWS Directory Service 연동 온프레미스를 전면 폐기하는 안, 애플리케이션을 재작성해 클라우드 네이티브로 바꾸는 안, 기존 인증 체계를 버리고 새로 만드는 안
minimal downtime (마이그레이션)
다운타임 최소화		 전환 중에도 서비스가 살아 있어야 합니다. 일괄 덤프와 복원은 이 조건을 만족하지 못합니다 AWS Database Migration Service(DMS)의 지속적 복제, AWS Application Migration Service(MGN), 블루/그린 전환, 읽기 전용 복제본을 승격하는 방식 전체 덤프 후 복원, 서비스를 멈추고 복사하는 안, 변경이 계속되는 데이터베이스를 오프라인 장치로만 옮기는 안

한정어가 둘 이상일 때

실제 문항은 한정어를 겹쳐 씁니다. "고가용성을 유지하면서 가장 비용 효율적인", "운영 오버헤드를 최소화하면서 지연 시간을 줄이는" 같은 형태입니다. 이때 앞에 붙은 조건은 대개 제약이고, 뒤에 붙은 최상급이 정렬 기준입니다. 먼저 조건을 만족하지 못하는 선택지를 지우고, 남은 것들만 최상급으로 비교합니다.

겹친 한정어의 해석 순서
문제문 먼저 적용(문턱) 나중 적용(정렬) 전형적인 오답
고가용성을 유지하면서 가장 비용 효율적인 다중 가용 영역 구성이 아닌 선택지를 소거 남은 것 중 상시 가동 자원이 적은 쪽 단일 가용 영역이라 가장 싼 선택지를 고름
운영 오버헤드를 최소화하면서 지연 시간을 줄이는 직접 운영해야 하는 선택지를 소거 남은 관리형 서비스 중 사용자에게 더 가까운 쪽 가장 빠르지만 EC2에 직접 캐시를 구축하는 안을 고름
코드를 수정하지 않고 읽기 성능을 높이는 애플리케이션 변경이 필요한 선택지를 소거 남은 것 중 읽기 처리량이 늘어나는 쪽 성능은 가장 좋지만 재작성이 필요한 안을 고름
데이터가 리전을 벗어나지 않으면서 복원력을 높이는 교차 리전 복제 선택지를 전부 소거 남은 것 중 가용 영역 이중화가 강한 쪽 가장 복원력이 좋아 보이는 다중 리전 안을 고름

오답 유도 패턴

오답 선택지는 무작위로 만들어지지 않습니다. 학습자가 흔히 저지르는 판단 오류를 재현하도록 설계됩니다. 패턴에 이름을 붙여 두면 선택지를 읽는 동안 분류가 되고, 분류되는 순간 소거됩니다.

오답 유도 패턴 여섯 가지와 식별 방법
패턴 어떻게 생겼는가 식별 신호
맞는 서비스, 틀린 티어 서비스 이름은 정답과 같은데 스토리지 클래스·볼륨 타입·용량 모드가 요구와 어긋납니다 선택지 두 개가 같은 서비스인데 세부 옵션만 다르면 그 둘 중 하나가 정답입니다. 세부 옵션을 요구사항과 하나씩 대조합니다
과잉 설계 비용 한정어가 붙은 문항에 가장 튼튼하고 가장 비싼 구성이 들어옵니다 요구사항에 없는 다중 리전, 요구가 없는 Provisioned IOPS, 필요 없는 전용 호스트가 보이면 의심합니다
액세스 키 심기 EC2 인스턴스나 컨테이너에 IAM 사용자와 액세스 키를 만들어 넣는 안입니다 거의 항상 오답입니다. 정답은 IAM 역할입니다. 이 패턴은 보안 도메인에서 가장 자주 재활용됩니다
관리형을 두고 자체 관리 운영 부담 최소화를 요구하는데 EC2 위에 직접 설치·운영하는 안이 들어옵니다 선택지에 "인스턴스를 시작해 ~를 설치하고"가 보이면 LEAST operational overhead 문항에서는 소거합니다
Multi-AZ와 읽기 전용 복제본 혼동 읽기 부하 문제에 Multi-AZ를, 가용성 문제에 읽기 전용 복제본을 답으로 제시합니다 요구가 가용성인지 읽기 확장인지 먼저 확정합니다. 아래 별도 항목에서 자세히 다룹니다
명시된 제약 위반 문제문이 금지한 것을 하는 안입니다. 대개 가장 저렴하거나 가장 단순해 보입니다 가장 먼저 버릴 대상입니다. 제약 문장을 미리 표시해 두면 자동으로 걸립니다

EC2에 액세스 키를 심는 선택지

이 패턴이 유독 자주 쓰이는 이유는, 실무에서 처음 배울 때 실제로 그렇게 하는 사람이 많기 때문입니다. 시험은 이 습관을 정확히 겨냥합니다. 인스턴스나 컨테이너에서 AWS API를 호출해야 한다면 답은 IAM 역할이고, 역할이 선택지에 있는 한 액세스 키 안은 고려 대상이 아닙니다.

IAM 사용자를 만들어 액세스 키를 발급하고, 인스턴스의 자격 증명 파일이나 환경 변수에 넣어 배포합니다. 키에는 만료가 없으므로 유출되면 회수할 때까지 유효합니다.

안티패턴 — 인스턴스에 장기 자격 증명을 저장
aws configure set aws_access_key_id "$APP_KEY" --profile app
aws configure set aws_secret_access_key "$APP_SECRET" --profile app
aws s3 cp ./report.csv s3://example-app-data/ --profile app

인스턴스 프로파일로 IAM 역할을 연결하고, SDK와 CLI의 기본 자격 증명 체인에 맡깁니다. 자격 증명은 임시이고 자동으로 교체되므로 회수 절차 자체가 필요 없습니다.

권장 — 인스턴스 프로파일로 IAM 역할 연결
aws ec2 associate-iam-instance-profile \
  --instance-id i-0123456789abcdef0 \
  --iam-instance-profile Name=AppServerRole
aws s3 cp ./report.csv s3://example-app-data/

같은 판단이 컨테이너에서는 태스크 역할, AWS Lambda에서는 실행 역할, 사내 사용자에게는 AWS IAM Identity Center 페더레이션으로 나타납니다. 형태는 달라도 장기 키 대신 임시 자격 증명이라는 결론은 같습니다. 정책 문서와 평가 로직은 2장 IAM과 자격 증명에서 다룹니다.

Multi-AZ와 읽기 전용 복제본 SAA 빈출

시험이 가장 집요하게 노리는 혼동입니다. 둘 다 "데이터베이스 복사본을 하나 더 둔다"처럼 보이지만 복제 방식도, 목적도, 엔드포인트도 다릅니다. 요구사항이 가용성인지 읽기 확장인지만 확정하면 이 유형은 즉시 갈립니다.

Amazon RDS Multi-AZ 배포와 읽기 전용 복제본 비교
항목 Multi-AZ 배포 읽기 전용 복제본
복제 방식 동기(synchronous) 복제 비동기(asynchronous) 복제
목적 고가용성과 재해 복구 읽기 성능 확장
엔드포인트 동일한 엔드포인트를 유지하고, 장애 조치 시 DNS가 대기 인스턴스를 가리킨다 별도의 읽기 엔드포인트가 생기며 애플리케이션이 읽기를 그쪽으로 보내야 한다
대기·복제본에서 읽기 불가 — 대기 인스턴스는 읽기 트래픽을 받지 않는다 가능 — 읽기 트래픽을 처리한다
배치 범위 같은 리전의 다른 가용 영역 같은 리전 또는 다른 리전
애플리케이션 수정 필요 없음 읽기와 쓰기를 나누도록 수정 필요

연습 — 한정어만 바꾸면 답이 이동한다

여기가 이 페이지의 핵심입니다. 아래 네 세트는 시나리오를 고정하고 한정어만 바꿉니다. 같은 상황에서 정답이 어떻게 이동하는지 눈으로 보고 나면, 시험장에서 문제문의 마지막 문장을 놓칠 수 없게 됩니다.

각 표의 마지막 열은 그 한정어일 때 오답이 되는 선택지입니다. 같은 선택지가 어떤 한정어에서는 정답이고 어떤 한정어에서는 오답이라는 점을 확인하세요.

연습 1 · 정적 콘텐츠를 제공한다

공통 시나리오. 이미지와 스크립트 같은 정적 파일이 Amazon S3 버킷에 있습니다. 지금은 버킷에서 직접 제공하고 있으며, 구성 변경을 검토하는 중입니다.

연습 1 — 같은 정적 콘텐츠 시나리오에서 한정어별 정답 이동
한정어와 추가 조건 정답 방향 근거 이때 오답이 되는 것
LOWEST latency — 사용자가 전 세계에 흩어져 있다 Amazon CloudFront 배포를 앞에 두고 오리진 액세스 제어(OAC)로 버킷을 비공개 유지 엣지 로케이션에서 캐시된 사본으로 응답하므로 사용자와 콘텐츠 사이의 거리가 줄어듭니다 버킷을 사용자 지역마다 복제해 직접 제공하는 안 — 관리 지점이 늘고 라우팅을 직접 풀어야 합니다
MOST cost-effective — 사용자가 한 리전에 몰려 있고 파일은 자주 바뀐다 같은 리전의 S3에서 직접 제공하고, 캐시 계층을 추가하지 않는다 캐시 적중이 거의 없으면 배포 계층은 요청을 그대로 오리진으로 넘깁니다. 얻는 것 없이 구성 요소만 늘어납니다 지연 개선이 필요 없는데도 CloudFront를 넣는 안 — 이 한정어에서는 과잉 설계입니다
MOST secure — 버킷이 인터넷에 직접 노출되면 안 된다 퍼블릭 액세스 차단을 유지한 채 CloudFront와 오리진 액세스 제어로만 접근 버킷 정책이 배포에서 온 요청만 허용하므로 버킷 URL로 직접 접근하는 경로가 사라집니다 버킷을 퍼블릭으로 열고 객체 URL을 공유하는 안, 소스 IP 허용 목록만 거는 안
must not traverse the internet — 같은 VPC의 EC2가 내려받는다 S3 게이트웨이 VPC 엔드포인트를 만들고 라우팅 테이블에 경로를 추가 요청이 AWS 네트워크 안에서 처리되어 인터넷 게이트웨이나 NAT 게이트웨이를 지나지 않습니다 CloudFront를 앞에 두는 안 — 사용자 지연 문제를 푸는 도구이지 경로 제약을 푸는 도구가 아닙니다
MOST cost-effective — 90일이 지난 파일은 거의 조회되지 않는다 수명 주기 규칙으로 오래된 객체를 저비용 스토리지 클래스로 전환 접근 빈도가 낮은 데이터를 표준 클래스에 두는 것이 가장 흔한 낭비 지점입니다 전체 버킷을 한 번에 아카이브 클래스로 옮기는 안 — 최소 저장 기간과 검색 시간 요구를 위반할 수 있습니다

같은 CloudFront가 세 번째 행에서는 정답이고 두 번째와 네 번째 행에서는 오답입니다. 선택지를 외우는 방식이 통하지 않는 이유가 여기 있습니다. 스토리지 클래스 판단은 8장 S3와 오브젝트 스토리지, 엣지 계층은 14장 엣지와 DNS에서 다룹니다.

연습 2 · 데이터베이스가 느려졌다

공통 시나리오. 단일 가용 영역에 Amazon RDS 인스턴스 하나로 운영 중인 애플리케이션이 있습니다. 최근 사용자가 늘면서 응답이 느려졌습니다.

연습 2 — 같은 데이터베이스 시나리오에서 한정어별 정답 이동
한정어와 추가 조건 정답 방향 근거 이때 오답이 되는 것
MOST highly available — 가용 영역 장애에도 서비스가 유지되어야 한다 Multi-AZ 배포로 전환 동기 복제된 대기 인스턴스가 다른 가용 영역에 있고 장애 조치가 자동으로 일어납니다 읽기 전용 복제본을 추가하는 안 — 비동기 복제이고 자동 장애 조치를 목적으로 하지 않습니다
읽기 조회가 급증했다 — 읽기 처리량을 늘려야 한다 읽기 전용 복제본을 추가하고 읽기 트래픽을 읽기 엔드포인트로 보낸다 읽기 전용 복제본은 읽기 트래픽을 실제로 처리하므로 기본 인스턴스의 부하가 내려갑니다 Multi-AZ로 전환하는 안 — 대기 인스턴스는 읽기를 받지 않으므로 읽기 부하가 그대로입니다
LOWEST latency — 같은 조회가 반복해서 들어온다 Amazon ElastiCache로 조회 결과를 캐시 반복 조회를 메모리에서 처리하므로 데이터베이스까지 가지 않습니다 인스턴스 타입을 키우는 안 — 반복 조회 비용 자체는 줄지 않습니다
without changing application code — 코드를 수정할 수 없다 인스턴스 타입 변경, 스토리지 성능 조정, Multi-AZ 전환처럼 엔드포인트가 유지되는 안 연결 문자열이 그대로이므로 애플리케이션이 바뀌지 않습니다 읽기 전용 복제본 추가 — 읽기를 별도 엔드포인트로 보내도록 코드를 고쳐야 합니다
LEAST operational overhead — 부하가 예측하기 어렵게 변한다 Amazon Aurora Serverless v2처럼 용량을 자동으로 조절하는 관리형 구성 용량 계획과 수동 스케일링 작업이 사라집니다 사용량을 보고 사람이 인스턴스 타입을 바꾸는 운영 절차를 만드는 안
연결 수가 폭증해 데이터베이스가 연결을 거절한다 Amazon RDS Proxy로 연결을 풀링 애플리케이션 연결을 모아 데이터베이스 쪽 연결 수를 안정적으로 유지합니다 읽기 전용 복제본 추가 — 연결 폭증은 읽기 처리량 문제와 다른 문제입니다

첫 행과 둘째 행이 정확히 반대라는 점이 이 연습의 핵심입니다. 문제문이 "가용성"을 말하는지 "읽기"를 말하는지 확인하지 않으면 절반의 확률로 틀립니다.

연습 3 · 온프레미스 데이터를 AWS로 옮긴다

공통 시나리오. 자체 데이터센터에서 파일 서버와 데이터베이스를 운영하는 회사가 AWS로 이전을 검토합니다. 데이터센터는 당분간 유지됩니다.

연습 3 — 같은 마이그레이션 시나리오에서 한정어별 정답 이동
한정어와 추가 조건 정답 방향 근거 이때 오답이 되는 것
MOST cost-effective — 데이터가 매우 크고 회선 대역폭으로는 전송 기간이 지나치게 길다 AWS Snow Family 장치로 오프라인 전송 회선을 오래 점유하는 대신 물리 장치로 옮겨 전송 기간과 회선 비용을 함께 줄입니다 전용 회선을 새로 계약해 한 번의 이전에만 쓰는 안
minimal downtime — 데이터베이스가 계속 변경된다 AWS Database Migration Service로 초기 적재 후 변경 사항을 지속적으로 복제하고 전환 원본이 살아 있는 동안 변경분이 따라가므로 전환 시점의 정지 시간이 짧아집니다 전체 덤프를 받아 복원하는 안 — 덤프 시점 이후 변경분을 잃거나 오래 멈춰야 합니다
must not traverse the internet — 전송 구간이 공용망을 지나면 안 된다 AWS Direct Connect 전용 연결을 사용 인터넷을 경유하지 않는 전용 회선으로 온프레미스와 AWS를 연결합니다 인터넷 회선 위의 사이트 간 VPN — 암호화는 되지만 경로는 공용망입니다
existing infrastructure를 유지 — 온프레미스 앱이 파일에 계속 접근해야 한다 AWS Storage Gateway로 온프레미스에서 익숙한 프로토콜을 유지하면서 데이터는 AWS에 저장 기존 애플리케이션을 그대로 두고 저장 위치만 옮기는 통합 방식입니다 애플리케이션을 클라우드 네이티브로 재작성하는 안 — 이 한정어가 배제하는 방향입니다
주기적으로 증분만 동기화해야 한다 AWS DataSync로 예약 동기화 온프레미스와 AWS 스토리지 사이의 반복 전송을 자동화하도록 만들어진 서비스입니다 일회성 오프라인 장치 전송 — 반복 동기화에는 맞지 않습니다

전송 도구 선택은 데이터 크기·회선 대역폭·반복 여부·허용 다운타임 네 가지로 갈립니다. 자세한 비교는 9장 파일 스토리지와 데이터 전송과 18장 비용 최적화·마이그레이션·재해 복구에서 다룹니다.

연습 4 · 트래픽이 급증한다

공통 시나리오. 주문 처리 애플리케이션이 이벤트 시간대에 요청이 몰리면 응답이 느려지고 일부 요청이 실패합니다. 현재는 웹 계층이 처리 계층을 동기로 호출합니다.

연습 4 — 같은 트래픽 급증 시나리오에서 한정어별 정답 이동
한정어와 추가 조건 정답 방향 근거 이때 오답이 되는 것
MOST scalable · decoupled — 급증분을 잃지 않아야 한다 Amazon SQS 큐로 요청을 받아 두고 소비자를 Auto Scaling으로 늘린다 큐가 급증분을 흡수하므로 처리 계층이 따라오지 못해도 요청이 버려지지 않습니다 인스턴스 타입을 키우는 수직 확장 — 상한이 있고 급증 순간에는 이미 늦습니다
주문 처리 순서가 보장되어야 하고 중복 처리를 막아야 한다 SQS FIFO 큐를 사용하고 메시지 그룹을 나눈다 메시지 그룹 안에서 순서가 지켜지고 중복이 제거됩니다 표준 큐 — 순서는 최선 노력이고 같은 메시지가 두 번 전달될 수 있습니다
하나의 주문 이벤트를 여러 시스템이 동시에 받아야 한다 Amazon SNS 주제로 팬아웃하고 각 구독자가 자기 큐로 받는다 발행자가 구독자를 알 필요 없이 동일 메시지가 모든 구독자에게 전달됩니다 구독자마다 직접 호출하는 안 — 구독자가 늘 때마다 발행자를 고쳐야 합니다
이벤트 내용에 따라 다른 대상으로 보내야 한다 Amazon EventBridge 규칙으로 이벤트 패턴에 따라 라우팅 메시지 본문의 속성으로 대상을 고르는 것이 이벤트 버스의 역할입니다 구독자 쪽에서 전부 받아 걸러 내는 안 — 불필요한 호출과 비용이 그대로 발생합니다
LEAST operational overhead — 서버를 관리하고 싶지 않다 큐를 이벤트 소스로 하는 AWS Lambda 소비자 인스턴스 관리 없이 큐 깊이에 따라 처리량이 늘어납니다 EC2 소비자 그룹을 직접 구성하고 스케일링 정책을 운영하는 안
처리에 실패한 메시지를 격리해야 한다 배달 못 한 편지 큐(DLQ)를 지정하고 최대 수신 횟수를 설정 반복 실패 메시지가 큐를 막지 않도록 분리됩니다 실패 시 무한 재시도 — 같은 메시지가 처리 흐름을 계속 점유합니다

느슨한 결합과 큐 완충은 도메인 2의 중심 주제입니다. 서비스별 동작은 12장 서버리스와 애플리케이션 통합에서, 도메인 단위 정리는 복원력 있는 아키텍처 설계에서 이어집니다.

문항 하나를 푸는 순서

위 내용을 시험장에서 쓸 수 있는 형태로 압축하면 다음 여섯 단계입니다. 연습할 때부터 이 순서로 풀어야 시험장에서도 같은 순서가 나옵니다.

시나리오 문항 풀이 루틴 여섯 단계
단계 할 일 여기서 걸리는 것
1 · 한정어 확보 마지막 문장에서 판단 축을 하나로 정한다 비용 문항인지 가용성 문항인지 헷갈리는 상태로 선택지를 읽는 일
2 · 제약 표시 "~할 수 없다", "~를 유지해야 한다" 문장을 찾아 둔다 제약을 위반한 선택지
3 · 위반 소거 제약을 어긴 선택지를 먼저 버린다 대개 한두 개가 바로 빠집니다
4 · 동작 여부 확인 남은 선택지가 요구사항을 실제로 충족하는지 본다 맞는 서비스, 틀린 티어 패턴
5 · 한정어로 정렬 1단계에서 정한 축 하나로만 비교한다 과잉 설계, 자체 관리 패턴
6 · 답 고정 또는 표시 결정되면 넘어가고, 두 개가 팽팽하면 하나를 고른 뒤 표시해 둔다 한 문항에 시간을 쏟다 뒤쪽 문항을 못 읽는 일

6단계에서 비워 두지 않는 것이 중요합니다. 오답 감점이 없으므로 확신이 없어도 반드시 하나를 고르고 표시해 둡니다. 시간 배분과 표시 전략은 시험 당일 전략에서 자세히 다룹니다.

이어서 볼 곳

공식 문서 출처

이 페이지의 시험 정보와 서비스 동작 서술은 아래 문서에서 확인했습니다. 한정어 해석 규칙 자체는 공식 문서에 정의된 개념이 아니라, 시험 가이드의 도메인·과제 진술과 각 서비스의 문서화된 동작을 근거로 정리한 것입니다.