#81번
솔루션 아키텍트가 AWS에 배포할 새 애플리케이션을 위한 클라우드 아키텍처를 설계하고 있습니다. 이 프로세스는 처리할 작업 수에 따라 필요에 따라 애플리케이션 노드를 추가 및 제거하면서 병렬로 실행되어야 합니다. 프로세서 애플리케이션은 상태 비저장형입니다. 솔루션 설계자는 애플리케이션이 느슨하게 결합되어 있고 작업 항목이 내구성 있게 저장되어 있는지 확인해야 합니다. 솔루션 설계자는 어떤 설계를 사용해야 하나요?
A. 처리해야 할 작업을 전송할 아마존 SNS 토픽을 생성합니다. 프로세서 애플리케이션으로 구성된 아마존 머신 이미지(AMI)를 생성합니다. AMI를 사용하는 실행 구성을 생성합니다. 시작 구성을 사용하여 자동 스케일링 그룹을 생성합니다. 자동 스케일링 그룹에 대한 스케일링 정책을 설정하여 CPU 사용량에 따라 노드를 추가 및 제거합니다.
B. 처리해야 하는 작업을 보관할 Amazon SQS 대기열을 만듭니다. 프로세서 애플리케이션으로 구성된 Amazon 머신 이미지(AMI)를 생성합니다. AMI를 사용하는 시작 구성을 생성합니다. 시작 구성을 사용하여 자동 스케일링 그룹을 만듭니다. 네트워크 사용량에 따라 노드를 추가 및 제거하도록 자동 스케일링 그룹의 스케일링 정책을 설정합니다.네트워크 사용량(Network Usage)은 좋은 스케일링 기준이 아님
C. 처리해야 하는 작업을 보관할 Amazon SQS 대기열을 만듭니다. 프로세서 애플리케이션으로 구성된 Amazon 머신 이미지(AMI)를 생성합니다. AMI를 사용하는 시작 템플릿을 만듭니다. 시작 템플릿을 사용하여 자동 스케일링 그룹을 만듭니다. 자동 스케일링 그룹에 대한 스케일링 정책을 설정하여 SQS 큐의 항목 수에 따라 노드를 추가 및 제거합니다.
D. 처리해야 할 작업을 전송할 Amazon SNS 토픽을 생성합니다. 프로세서 애플리케이션으로 구성된 Amazon 머신 이미지(AMI)를 생성합니다. AMI를 사용하는 시작 템플릿을 생성합니다. 시작 템플릿을 사용하여 자동 스케일링 그룹을 생성합니다. SNS 토픽에 게시된 메시지 수에 따라 노드를 추가 및 제거하도록 자동 스케일링 그룹에 대한 스케일링 정책을 설정합니다.
✅ 정답: C
C.
처리해야 하는 작업을 보관할 Amazon SQS 대기열을 만듭니다.
프로세서 애플리케이션으로 구성된 Amazon 머신 이미지(AMI)를 생성합니다.
AMI를 사용하는 시작 템플릿을 만듭니다.
시작 템플릿을 사용하여 자동 스케일링 그룹을 만듭니다.
자동 스케일링 그룹에 대한 스케일링 정책을 설정하여 SQS 큐의 항목 수에 따라 노드를 추가 및 제거합니다.
✅ 정답 이유
• Amazon SQS: 메시지를 내구성 있게 저장하고, 비동기 처리를 위한 이상적인 서비스입니다.
• Auto Scaling Group: 트래픽 및 작업량에 따라 애플리케이션 노드를 자동으로 조절할 수 있습니다.
• 큐 메시지 수 기반 스케일링: 처리할 작업량을 정확히 반영하므로, 적절한 기준입니다.
• Stateless 구조 + 느슨한 결합: SQS를 통해 프로듀서와 컨슈머가 직접 연결되지 않으므로 느슨한 결합 구조가 형성됩니다.
❌ 오답 해설
A. SNS + CPU 사용량 기반 Auto Scaling
오답 이유:
• SNS는 메시지를 저장하지 않음 → 수신자가 즉시 받아야 함.
• 메시지 유실 위험 존재 → “작업 항목을 내구성 있게 저장” 조건을 만족하지 못함.
• CPU 사용량 기준 스케일링은 비효율적
• 대기 중인 작업이 많아도 CPU 사용률이 낮으면 스케일링 안 됨.
• 작업이 적어도 CPU가 순간적으로 높으면 불필요한 인스턴스가 생성될 수 있음.
• 느슨한 결합이 아님 → SNS는 실시간 전송 구조로 프로듀서와 컨슈머가 타이트하게 연결됨.
B. SQS + 네트워크 사용량 기반 Auto Scaling
오답 이유:
• SQS 사용은 올바른 선택 → 메시지의 내구성과 비동기 처리 가능.
• 하지만 네트워크 사용량은 스케일링 기준으로 부적절
• 네트워크 트래픽이 많다고 작업이 많은 것은 아님.
• 네트워크 트래픽이 낮더라도 대기 중인 작업이 많을 수 있음.
• 작업량 기반 스케일링이 아닌 지표를 사용 → 실제 작업 처리량과 불일치.
D. SNS + SNS 메시지 수 기반 Auto Scaling
오답 이유:
• SNS는 메시지를 저장하지 않음 → 메시지가 수신되지 않으면 유실 가능성 있음.
• SNS 메시지 수는 정확한 작업량 지표가 아님
• 같은 메시지가 여러 구독자에게 전송될 수 있음 (Fan-out)
• 메시지 전송량 = 실제 작업량 아님
• 작업 항목이 내구성 있게 저장되어야 한다는 조건 미충족
• 애플리케이션 간의 결합이 느슨하지 않음
✅ 요약 정리
택지메시지 저장 방식스케일링 기준결합성내구성적절성
| A | SNS (X) | CPU 사용량 (X) | 느슨하지 않음 | X | ❌ |
| B | SQS (O) | 네트워크 사용량 (X) | 느슨함 | O | ❌ |
| ✅ C | SQS (O) | 메시지 수 (O) | 느슨함 | O | ✅ |
| D | SNS (X) | 메시지 수 (X) | 느슨하지 않음 | X | ❌ |
#82번
한 회사가 AWS 클라우드에서 웹 애플리케이션을 호스팅합니다.
이 회사는 AWS Certificate Manager(ACM) 으로 가져온 인증서를 사용하도록 Elastic Load Balancer를 구성합니다.
각 인증서가 만료되기 30일 전에 회사의 보안 팀에 알려야 합니다.
솔루션 아키텍트는 이 요구 사항을 충족하기 위해 무엇을 권장해야 합니까?
- A. 인증서가 만료되기 30일 전부터 매일 Amazon Simple Notification Service(Amazon SNS) 주제에 사용자 정의 메시지를 게시하는 규칙을 ACM에 추가합니다.AWS 공식 문서에서도 ACM은 이메일 알림을 기본 제공하지만, SNS 통합은 제공하지 않음.
- B. 30일 이내에 만료되는 인증서를 확인하는 AWS Config 규칙을 만듭니다. AWS Config가 비준수 리소스를 보고하면 Amazon Simple Notification Service(Amazon SNS)를 통해 사용자 지정 알림을 호출하도록 Amazon EventBridge(Amazon CloudWatch Events)를 구성합니다.
- C. AWS Trusted Advisor를 사용하여 30일 이내에 만료되는 인증서를 확인합니다. Trusted Advisor 지표를 기반으로 하는 Amazon CloudWatch 알람을 생성하여 상태 변경을 확인합니다. Amazon Simple Notification Service(Amazon SNS)를 통해 사용자 지정 알림을 보내도록 알람을 구성합니다.
- D. 30일 이내에 만료되는 인증서를 감지하는 Amazon EventBridge(Amazon CloudWatch Events) 규칙을 만듭니다. AWS Lambda 함수를 호출하도록 규칙을 구성합니다. Amazon Simple Notification Service(Amazon SNS)를 통해 사용자 지정 알림을 보내도록 Lambda 함수를 구성합니다.
✅ 핵심 요구 사항 요약
1. ACM 인증서 만료 30일 전 알림 전송
2. SNS를 통해 보안팀에 알림 전달
3. 자동화된 방식으로 감지 및 알림 구성
✅ 정답: B
B.
30일 이내에 만료되는 인증서를 확인하는 AWS Config 규칙을 만듭니다.
AWS Config가 비준수 리소스를 보고하면
Amazon Simple Notification Service(Amazon SNS) 를 통해 사용자 지정 알림을 호출하도록
Amazon EventBridge(Amazon CloudWatch Events) 를 구성합니다.
✅ 정답 해설
• AWS Config는 ACM 인증서의 상태(예: 만료 여부)를 지속적으로 평가할 수 있습니다.
• 인증서가 30일 이내로 남았을 경우, 비준수(Non-compliant) 상태로 판단할 수 있습니다.
• 이 상태를 트리거로 Amazon EventBridge 이벤트가 발생합니다.
• EventBridge는 이를 감지하고 SNS 주제에 연결하여 보안팀에 알림을 자동 전송할 수 있습니다.
• 이 방식은 서버리스하고 자동화된 모니터링 및 알림 구성 방식으로, 요구 사항을 완벽히 충족합니다.
❌ 오답 해설
A. ACM에 사용자 정의 SNS 알림을 게시하는 규칙 추가
오답 이유:
• ACM 자체적으로 SNS 알림을 설정하는 기능은 제공하지 않음
• ACM은 만료 알림을 기본 이메일로만 전송
• SNS 주제에 직접 연결하거나 사용자 정의 메시지를 보낼 수 있는 기능은 없음
• 결과적으로 SNS와 직접적인 통합은 불가능하므로 이 방식은 구현 불가
C. AWS Trusted Advisor + CloudWatch 알람 + SNS
오답 이유:
• Trusted Advisor는 인증서 만료 확인 기능을 제공하지만,
• 비즈니스 또는 엔터프라이즈 서포트 플랜을 사용 중인 계정에서만 해당 기능을 사용할 수 있음
• 기본 지원 플랜에서는 해당 기능 사용 불가
• 또한 Trusted Advisor는 CloudWatch와 직접 통합되기 어려우며, 지속적인 자동화 구성에는 적합하지 않음
D. EventBridge 규칙 + Lambda + SNS
오답 이유:
• EventBridge는 기본적으로 ACM 인증서 만료 이벤트를 감지하지 않음
• 즉, ACM 관련 이벤트 자체를 트리거로 사용할 수 없음
• 따라서 Lambda가 주기적으로 ACM API를 호출해서 직접 인증서 상태를 조회해야 함
• 이는 불필요한 Lambda 구성과 운영 부담을 야기함
• 반면, AWS Config를 사용하면 Lambda 없이도 자동으로 리소스 평가 가능
✅ 요약 정리표
선택지사용 서비스자동 감지SNS 알림오답 이유
| A | ACM + SNS | ❌ | ⭕ | ACM은 SNS 직접 통합 불가 |
| ✅ B | Config + EventBridge + SNS | ⭕ | ⭕ | 자동화 가능, 요구사항 충족 |
| C | Trusted Advisor + CloudWatch + SNS | ❌ | ⭕ | 유료 플랜 필요, 제한적 통합 |
| D | EventBridge + Lambda + SNS | ❌ | ⭕ | ACM 만료 이벤트 감지 불가, Lambda 필요 |
#83번
회사의 동적 웹사이트는 미국에 있는 온프레미스 서버를 사용하여 호스팅됩니다. 이 회사는 유럽에서 제품을 출시하고 있으며, 새로운 유럽 사용자를 위해 사이트 로딩 시간을 최적화하려고 합니다. 사이트의 백엔드는 미국에 남아야 합니다. 이 제품은 며칠 안에 출시되며 즉각적인 솔루션이 필요합니다.
솔루션 아키텍트는 무엇을 추천해야 합니까?
A. us-east-1에서 Amazon EC2 인스턴스를 시작하고 사이트를 여기로 마이그레이션합니다.
B. 웹사이트를 Amazon S3로 이동합니다. 지역 간 크로스 리전 복제를 사용합니다.
C. 온프레미스 서버를 가리키는 사용자 지정 원본과 함께 Amazon CloudFront를 사용합니다.
D. 온프레미스 서버를 가리키는 Amazon Route 53 지리적 근접 라우팅 정책을 사용합니다.
✅ 정답: C
C. 온프레미스 서버를 가리키는 사용자 지정 원본과 함께 Amazon CloudFront를 사용합니다.
✅ 정답 해설
• Amazon CloudFront는 AWS의 글로벌 CDN(Content Delivery Network) 서비스입니다.
• Custom origin 기능을 통해 온프레미스 서버를 CloudFront 배포의 원본으로 지정할 수 있습니다.
• 이를 통해:
• 유럽 사용자의 요청은 가까운 엣지 로케이션에서 캐시된 정적 콘텐츠(예: 이미지, JS, CSS 등) 를 제공받을 수 있고,
• 동적 요청은 미국의 온프레미스 서버로 라우팅되지만, 전반적인 로딩 속도는 개선됩니다.
• 즉각 적용 가능하고, 백엔드 변경 없이 성능 향상 가능 → 요구 사항에 가장 부합하는 선택지입니다.
❌ 오답 해설
A. us-east-1에서 Amazon EC2 인스턴스를 시작하고 사이트를 여기로 마이그레이션
오답 이유:
• 미국 동부 리전에 EC2를 두더라도, 여전히 유럽 사용자와 물리적으로 멀어 지연이 큼.
• 또한 마이그레이션 작업(코드 이전, 데이터베이스 마이그레이션 등)은 며칠 안에 완료하기 어렵고 리스크가 큼.
• 즉각적인 성능 개선이 불가능하며, 현재 요구 사항(즉각적인 해결책, 유럽 대상 최적화)에 적합하지 않음.
B. 웹사이트를 Amazon S3로 이동하고 크로스 리전 복제를 사용
오답 이유:
• Amazon S3는 정적 웹사이트 호스팅에 적합하지만, 문제 지문에서는 동적 웹사이트임.
• 크로스 리전 복제는 S3 버킷 간의 데이터 복사 기능일 뿐, 웹사이트의 로딩 속도나 사용자 경험을 개선하지 않음.
• 또한 백엔드는 미국 온프레미스에 남겨야 하므로, S3로의 이전 자체가 부적절함.
D. 온프레미스 서버를 가리키는 Amazon Route 53 지리적 근접 라우팅 정책 사용
오답 이유:
• 지리적 근접 라우팅은 여러 위치에 서버가 있을 때, 사용자를 가장 가까운 리소스로 라우팅할 수 있도록 도와줌.
• 하지만 이 문제에서는 유럽에 서버가 없음 → 라우팅의 효과 없음.
• 게다가 Route 53은 DNS 수준의 라우팅만 가능하고, 콘텐츠 캐싱이나 성능 최적화 기능은 없음.
• 따라서 사이트 로딩 속도 개선에는 직접적인 효과가 없음.
✅ 요약 정리
선택지설명문제 해결 적합성이유
| A | EC2로 마이그레이션 | ❌ | 시간 부족, 성능 개선 미흡 |
| B | S3 + 크로스 리전 복제 | ❌ | 동적 사이트 부적합, 캐싱 없음 |
| ✅ C | CloudFront + 온프레미스 서버 (Custom origin) | ⭕ |
최적의 즉각적 해결책
| D | Route 53 근접 라우팅 | ❌ | 유럽 서버 없음, 캐싱 불가 |
#84번
한 회사에서 기존 3계층 웹 아키텍처의 비용을 절감하고자 합니다. 웹, 애플리케이션 및 데이터베이스 서버는 개발, 테스트 및 프로덕션 환경을 위해 Amazon EC2 인스턴스에서 실행됩니다. EC2 인스턴스는 피크 시간에 평균 30%의 CPU 사용률을 보이고 비피크 시간에는 10%의 CPU 사용률을 보입니다.
프로덕션 EC2 인스턴스는 하루 24시간 실행됩니다. 개발 및 테스트 EC2 인스턴스는 매일 최소 8시간 실행됩니다. 이 회사는 개발 및 테스트 EC2 인스턴스가 사용되지 않을 때 중단하기 위한 자동화를 구현할 계획입니다.
어떤 EC2 인스턴스 구매 솔루션이 회사의 요구 사항을 가장 비용 효율적으로 충족할까요?
A. 프로덕션 EC2 인스턴스에는 Spot Instances를 사용합니다. 개발 및 테스트 EC2 인스턴스에는 Reserved Instances를 사용합니다.
B. 프로덕션 EC2 인스턴스에는 예약 인스턴스를 사용합니다. 개발 및 테스트 EC2 인스턴스에는 온디맨드 인스턴스를 사용합니다.
C. 프로덕션 EC2 인스턴스에는 Spot 블록을 사용합니다. 개발 및 테스트 EC2 인스턴스에는 Reserved Instances를 사용합니다.
D. 프로덕션 EC2 인스턴스에는 온디맨드 인스턴스를 사용합니다. 개발 및 테스트 EC2 인스턴스에는 스팟 블록을 사용합니다.
✅ 정답: B
B.
프로덕션 EC2 인스턴스에는 예약 인스턴스(Reserved Instances) 를 사용합니다.
개발 및 테스트 EC2 인스턴스에는 온디맨드 인스턴스(On-Demand Instances) 를 사용합니다.
✅ 정답 해설
🔹 프로덕션 인스턴스 → Reserved Instances (RI)
• 하루 24시간 연중무휴 실행되므로, 지속적으로 고정된 워크로드에 해당
• Reserved Instances는 1년 또는 3년 약정으로 최대 72%까지 비용 절감
• 예측 가능한 장기 사용에는 가장 비용 효율적인 옵션
🔹 개발 및 테스트 인스턴스 → On-Demand + 자동화로 중단
• 하루에 최소 8시간만 사용되고 나머지 시간에는 자동 중단 예정
• 사용량이 유동적이고 짧은 시간만 실행되므로 RI는 비효율적
• On-Demand는 유연성 있고 과금 방식이 시간 단위이므로, 중단 자동화와 함께 사용 시 매우 효율적
❌ 오답 해설
A. 프로덕션 → Spot, 개발/테스트 → Reserved Instances
오답 이유:
• Spot Instances는 AWS가 언제든 회수할 수 있음
→ 프로덕션 환경에 안정성이 요구되므로 부적합
• 개발/테스트 환경은 가변적인데 Reserved Instances는 장기 약정이 필요함
→ 자주 중단/시작되는 환경에는 유연하지 않음 → 비효율
C. 프로덕션 → Spot 블록, 개발/테스트 → Reserved Instances
오답 이유:
• Spot 블록은 최대 6시간까지 실행 가능한 예약된 Spot
→ 프로덕션처럼 24시간 가동이 필요한 환경에 적합하지 않음
• 마찬가지로 개발/테스트에 RI는 고정된 약정이 필요해 유연하지 않음
D. 프로덕션 → On-Demand, 개발/테스트 → Spot 블록
오답 이유:
• 프로덕션 환경에 On-Demand 인스턴스를 장기적으로 사용하면 가장 비쌈
→ Reserved Instances보다 훨씬 비용이 큼
• Spot 블록은 고정 시간 실행 전제로 예약됨
→ 개발/테스트처럼 자동화로 중단하려는 환경에 비유연하고 제한적
✅ 요약 정리
선택지프로덕션 인스턴스개발/테스트 인스턴스적합성주요 오답 이유
| A | Spot | Reserved | ❌ | Spot은 회수 가능, RI는 고정 약정 |
| ✅ B | Reserved | On-Demand | ✅ | 안정성과 유연성 모두 충족 |
| C | Spot 블록 | Reserved | ❌ | Spot 블록은 시간 제한, RI는 비효율 |
| D | On-Demand | Spot 블록 | ❌ | 온디맨드는 장기 사용 시 비쌈, Spot 블록은 유연성 부족 |
#85번
어떤 회사에는 사용자가 웹 인터페이스나 모바일 앱을 통해 문서를 업로드하는 프로덕션 웹 애플리케이션이 있습니다. 새로운 규제 요건에 따라, 새로운 문서는 저장된 후에는 수정하거나 삭제할 수 없습니다.
솔루션 아키텍트는 이 요건을 충족하기 위해 무엇을 해야 합니까?
A. S3 버전 관리 및 S3 객체 잠금이 활성화된 Amazon S3 버킷에 업로드된 문서를 저장합니다.
B. 업로드된 문서를 Amazon S3 버킷에 저장합니다. S3 Lifecycle 정책을 구성하여 주기적으로 문서를 보관합니다.
C. S3 버전 관리가 활성화된 Amazon S3 버킷에 업로드된 문서를 저장합니다. 모든 액세스를 읽기 전용으로 제한하도록 ACL을 구성합니다.
D. 업로드된 문서를 Amazon Elastic File System(Amazon EFS) 볼륨에 저장합니다. 볼륨을 읽기 전용 모드로 마운트하여 데이터에 액세스합니다.
✅ 핵심 요구 사항
• 데이터 무결성 보장 (Immutable Storage)
• 문서 저장 후 수정/삭제 불가 (WORM: Write Once Read Many)
✅ 정답: A
A.
S3 버전 관리 및 S3 객체 잠금이 활성화된 Amazon S3 버킷에 업로드된 문서를 저장합니다.
✅ 정답 해설
• Amazon S3 Object Lock을 사용하면 객체를 WORM 모드(Write Once Read Many) 로 저장할 수 있습니다.
• 즉, 한 번 저장된 객체는 설정된 보존 기간 동안 수정하거나 삭제할 수 없습니다.
• S3 버전 관리(Versioning) 를 함께 사용하면 실수로 객체를 덮어쓰더라도 이전 버전을 보존할 수 있습니다.
• Object Lock 모드
• Governance Mode: 관리자 권한이 있는 사용자만 삭제 가능
• Compliance Mode: 모든 사용자(루트 포함)가 삭제 및 수정 불가 → 규제 요건 충족에 적합
✅ 규제 요건을 충족하기 위해선 S3 객체 잠금 + 버전 관리 조합이 가장 강력하고 권장되는 방식입니다.
❌ 오답 해설
B. S3 Lifecycle 정책을 구성하여 주기적으로 문서를 보관
오답 이유:
• S3 Lifecycle 정책은 객체를 다른 스토리지 클래스로 이동하거나 삭제하는 기능
• 객체 삭제 방지는 하지 않음
• 예를 들어, 객체를 Glacier로 옮길 수는 있지만, 삭제 자체를 방지할 수는 없음
• 따라서 문서의 불변성 보장에는 부적합
C. S3 버전 관리 활성화 + ACL을 읽기 전용으로 설정
오답 이유:
• 버전 관리는 덮어쓰기 방지에는 유용하지만, 삭제는 가능
• 버전 관리가 켜져 있어도, 사용자가 delete marker를 추가하거나 버전별 삭제할 수 있음
• ACL(액세스 제어 목록) 은 취약함
• IAM 사용자나 정책을 가진 관리자가 ACL을 변경 가능
• 보안 수준이 낮고, 규제 수준의 데이터 무결성을 보장할 수 없음
D. Amazon EFS + 읽기 전용 마운트
오답 이유:
• Amazon EFS는 일반적인 파일 시스템으로, POSIX 권한 모델을 사용함
• 루트 권한 또는 권한 변경이 가능한 사용자가 있으면, 파일을 삭제하거나 수정할 수 있음
• S3 Object Lock처럼 불변성(immutable)을 강제하는 기능이 없음
• 따라서 규제 요건(수정 및 삭제 금지)을 충족하지 못함
✅ 요약 정리
선택지설명수정/삭제 방지적합성이유
| ✅ A | S3 버전 관리 + 객체 잠금 | ⭕ |
(Compliance 모드 사용 시 완전 차단)
| ✅ | 규제 준수를 위한 WORM 스토리지 |
| B | S3 Lifecycle 정책 | ❌ | ❌ | 삭제 방지 기능 없음 |
| C | 버전 관리 + ACL 읽기 전용 | ❌ | ❌ | 삭제 가능, 보안 취약 |
| D | EFS 읽기 전용 마운트 | ❌ | ❌ | 루트로 변경 가능, 무결성 보장 안 됨 |