[AWS SAA-C03] examtopics 오답 노트

정답 및 해설 드래그

1번

한 회사가 여러 대륙에 걸쳐 있는 도시들의 온도, 습도, 기압 데이터를 수집합니다. 각 사이트에서 매일 수집하는 데이터 양은 평균 500GB입니다. 모든 사이트는 고속 인터넷에 연결되어 있습니다.

이 회사는 전 세계 모든 사이트에서 수집한 데이터를 가능한 한 빨리 하나의 Amazon S3 버킷에 통합하고자 합니다. 솔루션은 운영 복잡성을 최소화해야 합니다.

이러한 요구 사항을 충족하는 솔루션은 무엇일까요?

• A.
• 대상 S3 버킷에서 S3 전송 가속을 활성화합니다. 멀티파트 업로드를 사용하여 사이트 데이터를 대상 S3 버킷에 직접 업로드합니다.
• B.
• 각 사이트의 데이터를 가장 가까운 리전의 S3 버킷에 업로드합니다. S3 리전 간 복제를 사용하여 객체를 대상 S3 버킷으로 복사합니다. 그런 다음 원본 S3 버킷에서 데이터를 삭제합니다.
• C.
• AWS Snowball Edge Storage Optimized 디바이스 작업을 매일 예약하여 각 사이트의 데이터를 가장 가까운 리전으로 전송합니다. S3 교차 리전 복제를 사용하여 객체를 대상 S3 버킷으로 복사합니다.
• D.
• 각 사이트의 데이터를 가장 가까운 리전의 Amazon EC2 인스턴스에 업로드합니다. 데이터를 Amazon Elastic Block Store(Amazon EBS) 볼륨에 저장합니다. 정기적으로 EBS 스냅샷을 생성하여 대상 S3 버킷이 있는 리전으로 복사합니다. 해당 리전에서 EBS 볼륨을 복원합니다.

 

• A 정답
  • 전송 속도 극대화: **S3 Transfer Acceleration(전송 가속)**은 전 세계에 퍼져 있는 AWS Edge Location을 활용함. 데이터가 인터넷 망을 길게 타는 대신, 가장 가까운 Edge Location에 도착하자마자 AWS 전용 고속 백본 네트워크를 타고 S3로 전송됨. '가능한 한 빨리'라는 조건에 가장 부합함.
  • 멀티파트 업로드(Multipart Upload): 500GB는 매우 큰 용량임. 파일을 조각내어 동시에 올리는 멀티파트 업로드를 쓰면 전송 효율과 안정성이 비약적으로 상승함.
  • 운영 복잡성 최소화: 버킷 설정에서 체크박스 하나만 켜면 끝나는 수준임. 별도의 인스턴스 관리나 복제 설정을 할 필요가 없음.
  오답 분석
  1. B (리전 간 복제): 일단 가까운 S3에 올리고 다시 다른 S3로 복제하는 방식은 단계가 두 번이라 시간이 더 걸리고, 원본 삭제 작업까지 관리해야 해서 운영 오버헤드가 발생함.
  2. C (Snowball Edge): Snowball은 장비를 배송받고 다시 보내는 물리적인 시간이 필요함. '고속 인터넷'이 이미 연결되어 있고 '매일 500GB'를 보내야 하는 상황에서는 인터넷 전송이 훨씬 빠름. (Snowball은 보통 인터넷 전송에 수 주가 걸리는 테라바이트/페타바이트급 데이터에 적합함.)
  3. D (EC2 + EBS): EC2 서버를 띄우고, EBS 스냅샷을 찍고, 리전 간 복사하고, 다시 복원하는 과정은 운영상 매우 복잡하며 효율도 최악임.

2번

어떤 회사는 자사 애플리케이션의 로그 파일을 분석할 수 있는 기능이 필요합니다. 로그는 JSON 형식으로 Amazon S3 버킷에 저장되어 있습니다. 쿼리는 간단하며 필요에 따라 실행될 수 있습니다. 솔루션 아키텍트는 기존 아키텍처를 최소한으로 변경하면서 이러한 분석을 수행해야 합니다.

운영 오버헤드를 최소화하면서 이러한 요구 사항을 충족하려면 솔루션 아키텍트는 어떻게 해야 할까요?

• A.
• 아마존 레드시프트를 사용하여 모든 콘텐츠를 한 곳에 로드하고 필요에 따라 SQL 쿼리를 실행합니다.
• B.
• Amazon CloudWatch Logs를 사용하여 로그를 저장합니다. 필요에 따라 Amazon CloudWatch 콘솔에서 SQL 쿼리를 실행합니다.
• C.
• 필요에 따라 쿼리를 실행하려면 Amazon Athena를 Amazon S3와 직접 연결하여 사용하십시오.
• D.
• AWS Glue를 사용하여 로그를 카탈로그화합니다. 필요에 따라 Amazon EMR에서 임시 Apache Spark 클러스터를 사용하여 SQL 쿼리를 실행합니다.

 

• C 정답
  1. 서버리스(Serverless): Athena는 서버를 구축하거나 관리할 필요가 없는 서버리스 서비스임. '운영 오버헤드 최소화' 조건에 가장 완벽하게 부합함.
  2. S3 직접 쿼리: 데이터를 다른 곳으로 옮길(ETL) 필요 없이, S3에 있는 JSON 파일을 그대로 두고 SQL 문법으로 즉시 분석할 수 있음. "기존 아키텍처 최소 변경"에 딱 맞음.
  3. 비용 효율성: 쿼리를 실행한 만큼(스캔한 데이터 양만큼)만 비용을 지불하므로, '필요에 따라 실행(Ad-hoc)'하는 경우 매우 경제적임.

  ---

  오답 분석
  1. A (Amazon Redshift): 데이터 웨어하우스인 Redshift는 성능은 강력하지만, 데이터를 로드하는 과정이 필요하고 서버(클러스터)를 관리해야 함. 운영 오버헤드가 크고 비용도 비쌈.
  2. B (CloudWatch Logs): 이미 S3에 로그가 저장되어 있는데, 이를 분석하기 위해 다시 CloudWatch로 옮기는 것은 비효율적임. (참고: CloudWatch Logs Insights라는 기능이 있지만, S3에 있는 데이터를 직접 쿼리하는 용도는 아님.)
  3. D (Amazon EMR + Spark): 대규모 데이터 처리에 적합하지만, 분석을 위해 Spark 클러스터를 띄우는 것 자체가 엄청난 운영 오버헤드임. 단순 쿼리용으로는 과함.

6번

한 회사가 사내 네트워크 연결 스토리지(NAS)에 대용량 비디오 파일을 저장하기 위해 NFS를 사용하고 있습니다. 각 비디오 파일의 크기는 1MB에서 500GB까지 다양합니다. 총 저장 용량은 70TB이며 더 이상 증가하지 않습니다. 이 회사는 비디오 파일을 Amazon S3로 마이그레이션하기로 결정했습니다. 마이그레이션은 최대한 신속하게 진행하면서 네트워크 대역폭 사용량을 최소화해야 합니다.

이러한 요구 사항을 충족하는 솔루션은 무엇일까요?

• A.
• S3 버킷을 생성합니다. S3 버킷에 쓰기 권한이 있는 IAM 역할을 생성합니다. AWS CLI를 사용하여 로컬의 모든 파일을 S3 버킷으로 복사합니다.
• B.
• AWS Snowball Edge 작업을 생성합니다. 온프레미스에 Snowball Edge 디바이스를 수령합니다. Snowball Edge 클라이언트를 사용하여 디바이스로 데이터를 전송합니다. AWS에서 데이터를 Amazon S3로 가져올 수 있도록 디바이스를 반환합니다.
• C.
• 온프레미스에 S3 파일 게이트웨이를 배포합니다. S3 파일 게이트웨이에 연결하기 위한 공용 서비스 엔드포인트를 생성합니다. S3 버킷을 생성합니다. S3 파일 게이트웨이에 새 NFS 파일 공유를 생성합니다. 새 파일 공유가 S3 버킷을 가리키도록 설정합니다. 기존 NFS 파일 공유의 데이터를 S3 파일 게이트웨이로 전송합니다.
• D.
• 온프레미스 네트워크와 AWS 간에 AWS Direct Connect 연결을 설정합니다. 온프레미스에 S3 파일 게이트웨이를 배포합니다. S3 파일 게이트웨이에 연결하기 위한 공용 가상 인터페이스(VIF)를 생성합니다. S3 버킷을 생성합니다. S3 파일 게이트웨이에 새 NFS 파일 공유를 생성합니다. 새 파일 공유가 S3 버킷을 가리키도록 설정합니다. 기존 NFS 파일 공유의 데이터를 S3 파일 게이트웨이로 전송합니다.

 

---

B가 정답인 이유 (AWS Snowball Edge)

1. 네트워크 대역폭 최소화: 70TB는 매우 큰 용량임. 이를 인터넷이나 전용선을 통해 전송하면 회사의 전체 네트워크가 느려지거나 수일~수주가 소요될 수 있음. Snowball은 물리적인 하드웨어 장치를 배송받아 데이터를 복사한 뒤 다시 보내는 방식이므로 네트워크 대역폭을 거의 사용하지 않음.
2. 신속한 전송: 대역폭이 제한적인 환경에서는 네트워크로 70TB를 쏘는 것보다, 물리 장치에 담아 택배로 보내는 것이 결과적으로 더 빠를 때가 많음. AWS 시험에서 수십 TB 이상의 대용량과 네트워크 대역폭 절약이 동시에 나오면 Snowball이 정답임.

---

오답 분석

1. A (AWS CLI): 인터넷을 통해 직접 복사하는 방식임. 70TB를 일반 네트워크로 올리면 대역폭 점유가 엄청나고 시간도 매우 오래 걸림. "대역폭 최소화" 조건에 어긋남.
2. C, D (S3 파일 게이트웨이): 파일 게이트웨이는 온프레미스에서 S3를 로컬 드라이브처럼 쓰게 해주는 도구이지, 70TB라는 대규모 데이터를 한 번에 마이그레이션하기 위한 최적의 도구가 아님. 특히 D의 Direct Connect는 설치하는 데만 몇 주에서 몇 달이 걸릴 수 있어 "최대한 신속하게"에 맞지 않음.

8번

한 회사가 분산 애플리케이션을 AWS로 마이그레이션하고 있습니다. 이 애플리케이션은 가변적인 워크로드를 처리합니다. 기존 플랫폼은 여러 컴퓨팅 노드에 걸쳐 작업을 조정하는 기본 서버로 구성되어 있습니다. 회사는 복원력과 확장성을 극대화하는 솔루션으로 애플리케이션을 현대화하고자 합니다.

솔루션 아키텍트는 이러한 요구 사항을 충족하는 아키텍처를 어떻게 설계해야 할까요?

• A.
• 작업 대상으로 Amazon Simple Queue Service(Amazon SQS) 큐를 구성합니다. Auto Scaling 그룹에서 관리되는 Amazon EC2 인스턴스를 사용하여 컴퓨팅 노드를 구현합니다. 예약된 스케일링을 사용하도록 EC2 Auto Scaling을 구성합니다.
• B.
• 작업 대상으로 Amazon Simple Queue Service(Amazon SQS) 큐를 구성합니다. Auto Scaling 그룹에서 관리되는 Amazon EC2 인스턴스를 사용하여 컴퓨팅 노드를 구현합니다. 큐 크기에 따라 EC2 Auto Scaling을 구성합니다.
• C.
• AWS Auto Scaling 그룹으로 관리되는 Amazon EC2 인스턴스를 사용하여 기본 서버와 컴퓨팅 노드를 구현합니다. 작업 대상으로 AWS CloudTrail을 구성합니다. 기본 서버의 부하에 따라 EC2 Auto Scaling을 구성합니다.
• D.
• Amazon Auto Scaling 그룹으로 관리되는 Amazon EC2 인스턴스를 사용하여 기본 서버와 컴퓨팅 노드를 구현합니다. Amazon EventBridge(Amazon CloudWatch Events)를 작업 대상으로 구성합니다. 컴퓨팅 노드의 부하에 따라 EC2 Auto Scaling을 구성합니다.

  ---

  B가 정답인 이유 (SQS + Queue 기반 스케일링)
  1. 복원력 극대화(Decoupling): 기존의 '기본 서버(Master)'가 작업을 직접 할당하는 방식은 기본 서버가 죽으면 전체 시스템이 마비됨. Amazon SQS를 도입하면 작업이 큐에 안전하게 보관되므로, 컴퓨팅 노드가 잠시 중단되어도 데이터 유실 없이 나중에 처리할 수 있음. 이를 '결합 해제(Decoupling)'라고 하며 복원력의 핵심임.
  2. 확장성 최적화(Queue-based Scaling): '가변적인 워크로드'에 대응하려면 쌓여 있는 작업량(큐 크기)을 보고 서버를 늘리는 것이 가장 정확함. SQS의 ApproximateNumberOfMessagesVisible 지표를 사용하여 Auto Scaling을 설정하면, 처리할 작업이 많아질 때만 서버를 늘리고 작업이 없으면 줄여서 효율성을 극대화함.
  3. 현대화: 중앙 제어 방식(Master-Slave)에서 이벤트 기반/큐 기반 방식으로 바꾸는 것이 클라우드 네이티브한 현대화의 정석임.

  ---

  오답 분석
  1. A (예약된 스케일링): '가변적인 워크로드'는 언제 트래픽이 튈지 모름. 특정 시간에만 늘리는 예약 방식은 갑작스러운 부하에 대응할 수 없음.
  2. C (CloudTrail): CloudTrail은 API 호출 기록(로그)을 남기는 서비스임. 작업 메시지를 전달하거나 스케일링의 기준으로 삼기에 부적합함.
  3. D (기본 서버 유지): 여전히 기본 서버(Master)가 존재하면 해당 서버가 '단일 장애점(SPOF)'이 됨. 즉, 기본 서버가 죽으면 확장이든 뭐든 아무것도 안 됨. 복원력을 극대화한다는 조건에 어긋남.

11번

한 회사가 Amazon EC2 인스턴스에서 실행되고 Amazon Aurora 데이터베이스를 사용하는 애플리케이션을 보유하고 있습니다. EC2 인스턴스는 로컬 파일에 저장된 사용자 이름과 암호를 사용하여 데이터베이스에 연결합니다. 이 회사는 자격 증명 관리와 관련된 운영 오버헤드를 최소화하고자 합니다.

솔루션 아키텍트는 이 목표를 달성하기 위해 무엇을 해야 할까요?

• A.
• AWS Secrets Manager를 사용하고 자동 순환 기능을 활성화하세요.
• B.
• AWS Systems Manager 파라미터 스토어를 사용하고 자동 로테이션을 활성화합니다.
• C.
• AWS Key Management Service(AWS KMS) 암호화 키로 암호화된 객체를 저장할 Amazon S3 버킷을 생성합니다. 자격 증명 파일을 S3 버킷으로 마이그레이션합니다. 애플리케이션에서 S3 버킷을 가리키도록 설정합니다.
• D.
• 각 EC2 인스턴스에 대해 암호화된 Amazon Elastic Block Store(Amazon EBS) 볼륨을 생성합니다. 새 EBS 볼륨을 각 EC2 인스턴스에 연결합니다. 자격 증명 파일을 새 EBS 볼륨으로 마이그레이션합니다. 애플리케이션이 새 EBS 볼륨을 가리키도록 설정합니다.
• A가 정답인 이유 (AWS Secrets Manager)

1. 보안 및 자동화: AWS Secrets Manager는 DB 암호, API 키 등을 안전하게 저장할 뿐만 아니라, 가장 중요한 기능인 '자동 순환(Rotation)' 기능을 제공함.
2. 운영 오버헤드 최소화: 암호를 주기적으로 직접 바꾸는 수고를 덜어줌. Secrets Manager는 Aurora와 같은 RDS 서비스와 연동되어 암호를 자동으로 변경하고 업데이트할 수 있음.
3. 로컬 파일 제거: 하드코딩된 암호 파일(로컬 파일)을 없애고 AWS SDK를 통해 안전하게 암호를 불러오므로 보안성이 비약적으로 향상됨.

---

오답 분석

1. B (Systems Manager Parameter Store): 파라미터 스토어는 설정값 등을 저장하기 좋고 가격이 저렴(표준 버전 무료)하지만, Secrets Manager와 같은 **'기본적인 자동 로테이션 기능'**이 없음. (람다를 써서 수동으로 구현해야 함.)
2. C (Amazon S3): 단순히 파일을 S3로 옮기는 것은 관리가 여전히 수동적이며, 암호 순환(Rotation) 문제를 해결하지 못함. 운영 오버헤드가 여전히 큼.
3. D (EBS 볼륨): 단순히 암호화된 하드디스크에 파일을 두는 방식임. 관리자가 일일이 파일을 수정해야 하며, 확장성이나 자동화 측면에서 최악의 선택임.

12번

글로벌 기업이 Amazon EC2 인스턴스에 웹 애플리케이션을 호스팅하고 있으며, 애플리케이션 로드 밸런싱(ALB)을 사용하고 있습니다. 이 웹 애플리케이션은 정적 데이터와 동적 데이터를 모두 포함하고 있으며, 정적 데이터는 Amazon S3 버킷에 저장됩니다. 기업은 정적 데이터와 동적 데이터의 성능을 향상시키고 지연 시간을 줄이고자 합니다. 또한, Amazon Route 53에 등록된 자체 도메인 이름을 사용하고 있습니다.

이러한 요구 사항을 충족하기 위해 솔루션 아키텍트는 어떤 조치를 취해야 할까요?

• A.
• S3 버킷과 ALB를 오리진으로 하는 Amazon CloudFront 배포를 생성합니다. Route 53을 구성하여 트래픽을 CloudFront 배포로 라우팅합니다.
• B.
• ALB를 오리진으로 하는 Amazon CloudFront 배포를 생성합니다. S3 버킷을 엔드포인트로 하는 AWS Global Accelerator 표준 가속기를 생성합니다. Route 53을 구성하여 트래픽을 CloudFront 배포로 라우팅합니다.
• C.
• S3 버킷을 오리진으로 하는 Amazon CloudFront 배포를 생성합니다. ALB와 CloudFront 배포를 엔드포인트로 하는 AWS Global Accelerator 표준 가속기를 생성합니다. 가속기 DNS 이름을 가리키는 사용자 지정 도메인 이름을 생성합니다. 웹 애플리케이션의 엔드포인트로 사용자 지정 도메인 이름을 사용합니다.
• D.
• ALB를 오리진으로 하는 Amazon CloudFront 배포를 생성합니다. S3 버킷을 엔드포인트로 하는 AWS Global Accelerator 표준 가속기를 생성합니다. 두 개의 도메인 이름을 생성합니다. 하나의 도메인 이름은 동적 콘텐츠용 CloudFront DNS 이름으로 연결하고, 다른 도메인 이름은 정적 콘텐츠용 가속기 DNS 이름으로 연결합니다. 생성된 도메인 이름을 웹 애플리케이션의 엔드포인트로 사용합니다.

• A가 정답인 이유 (CloudFront 통합정답
  1. 통합 성능 향상: Amazon CloudFront는 정적 콘텐츠(S3)뿐만 아니라 동적 콘텐츠(ALB)에 대해서도 성능을 개선함. 정적 데이터는 캐싱을 통해 지연 시간을 줄이고, 동적 데이터는 AWS 고속 백본 네트워크를 통해 오리진(ALB)까지의 연결을 최적화함.
  2. 단일 엔드포인트: 하나의 CloudFront 배포 내에서 여러 '오리진(Origin)'을 설정할 수 있음. 경로 패턴(예: /static/*은 S3로, 나머지는 ALB로)에 따라 트래픽을 분산 처리하므로 관리가 매우 효율적임.
  3. Route 53 연동: CloudFront 배포 생성 후 생성된 도메인 주소를 Route 53에서 별칭(Alias) 레코드로 등록하면 자체 도메인 사용 요구 사항을 완벽히 충족함.

  ---

  오답 분석
  1. B, C, D (Global Accelerator 혼용): Global Accelerator는 주로 비-HTTP(TCP/UDP) 트래픽 최적화나 고정 IP가 필요한 경우에 강점이 있음. HTTP/HTTPS 기반의 웹 애플리케이션이며 정적 데이터 캐싱이 중요한 이 문제에서는 CloudFront 하나로 처리하는 것이 가장 효율적이고 일반적임.
  2. D (복수 도메인 생성): 도메인을 동적용과 정적용으로 쪼개서 관리하는 것은 운영 복잡성을 크게 높임. CloudFront 하나에서 경로 패턴으로 나누는 것이 정석임.

16번

한 회사가 AWS에 데이터 레이크를 구축했습니다. 이 데이터 레이크는 Amazon S3와 Amazon RDS for PostgreSQL에 저장된 데이터로 구성됩니다. 회사는 데이터 레이크에 있는 모든 데이터 소스를 포함하고 데이터 시각화를 제공하는 보고 솔루션이 필요합니다. 경영진만 모든 시각화 자료에 대한 완전한 접근 권한을 가져야 하며, 나머지 직원들은 제한된 접근 권한만 가져야 합니다.

이러한 요구 사항을 충족하는 솔루션은 무엇일까요?

• A.
• Amazon QuickSight에서 분석을 생성합니다. 모든 데이터 소스를 연결하고 새 데이터 세트를 생성합니다. 데이터를 시각화하기 위해 대시보드를 게시합니다. 적절한 IAM 역할과 대시보드를 공유합니다.
• B.
• Amazon QuickSight에서 분석을 생성합니다. 모든 데이터 소스를 연결하고 새 데이터 세트를 생성합니다. 데이터를 시각화하기 위해 대시보드를 게시합니다. 적절한 사용자 및 그룹과 대시보드를 공유합니다.
• C.
• Amazon S3에 있는 데이터에 대한 AWS Glue 테이블과 크롤러를 생성합니다. 보고서를 생성하는 AWS Glue ETL(추출, 변환, 로드) 작업을 생성합니다. 생성된 보고서를 Amazon S3에 게시합니다. S3 버킷 정책을 사용하여 보고서에 대한 접근을 제한합니다.
• D.
• AWS Glue 테이블을 생성하고 Amazon S3의 데이터에 대한 크롤러를 구축합니다. Amazon Athena 페더레이션 쿼리를 사용하여 Amazon RDS for PostgreSQL 내의 데이터에 접근합니다. Amazon Athena를 사용하여 보고서를 생성하고, 생성된 보고서를 Amazon S3에 게시합니다. S3 버킷 정책을 사용하여 보고서에 대한 접근을 제한합니다.

• B가 정답인 이유 (Amazon QuickSight)

1. 시각화 도구: AWS에서 '보고서', '시각화', '대시보드'라는 단어가 나오면 1순위 후보는 Amazon QuickSight임.
2. 다양한 데이터 소스 통합: QuickSight는 S3와 RDS(PostgreSQL)를 모두 데이터 소스로 연결하여 하나의 분석 화면으로 합칠 수 있음.
3. 사용자 및 그룹별 권한 관리: QuickSight는 자체적으로 사용자(User)와 그룹(Group)을 생성하고, 특정 대시보드를 누구와 공유할지 세밀하게 제어할 수 있음. 경영진 그룹에게는 전체 접근권을, 일반 직원 그룹에게는 제한된 대시보드만 공유하는 식의 운영이 가능함.

---

오답 분석

1. A (IAM 역할 공유): QuickSight 대시보드는 IAM 역할(Role)이 아니라 QuickSight 내부의 사용자 또는 그룹과 공유하는 것이 표준 방식임. 대시보드 공유 설정 화면에서도 IAM 역할을 선택하는 것이 아니라 이메일 주소 기반의 사용자나 그룹을 지정함.
2. C, D (S3 게시 및 버킷 정책): Glue나 Athena를 통해 보고서를 생성하고 S3에 파일(PDF/CSV 등)로 저장하는 방식은 정적인 보고서 전달에는 가능하지만, 문제에서 요구하는 '데이터 시각화(대시보드)' 및 '동적인 분석' 솔루션으로는 QuickSight에 비해 효율성과 기능이 크게 떨어짐.

17번

한 회사가 새로운 비즈니스 애플리케이션을 구축하고 있습니다. 이 애플리케이션은 두 개의 Amazon EC2 인스턴스에서 실행되며 문서 저장을 위해 Amazon S3 버킷을 사용합니다. 솔루션 아키텍트는 EC2 인스턴스가 S3 버킷에 접근할 수 있도록 해야 합니다.

이 요구 사항을 충족하기 위해 솔루션 아키텍트는 무엇을 해야 할까요?

• A.
• S3 버킷에 대한 액세스 권한을 부여하는 IAM 역할을 생성하고, 해당 역할을 EC2 인스턴스에 연결합니다.
• B.
• S3 버킷에 대한 액세스 권한을 부여하는 IAM 정책을 생성하고, 해당 정책을 EC2 인스턴스에 연결합니다.
• C.
• S3 버킷에 대한 액세스 권한을 부여하는 IAM 그룹을 생성합니다. 해당 그룹을 EC2 인스턴스에 연결합니다.
• D.
• S3 버킷에 대한 액세스 권한을 부여하는 IAM 사용자를 생성합니다. 해당 사용자 계정을 EC2 인스턴스에 연결합니다.

• A가 정답인 이유 (IAM 역할 사용)

1. 보안 모범 사례: EC2 인스턴스에 직접 액세스 키(Access Key)나 비밀 키(Secret Key)를 저장하는 것은 매우 위험함. 대신 **IAM 역할(Role)**을 사용하면 AWS가 임시 보안 자격 증명을 자동으로 생성하고 교체해주므로 가장 안전함.
2. 인스턴스 프로파일: 생성한 IAM 역할을 EC2 인스턴스에 부여(Attach)하면, 해당 인스턴스에서 실행되는 모든 애플리케이션은 별도의 로그인 과정 없이 S3에 접근할 수 있게 됨.
3. 운영 효율성: 키 관리(Key Rotation)에 대한 부담이 전혀 없으므로 운영 오버헤드가 최소화됨.

---

오답 분석

1. B (IAM 정책 연결): IAM 정책(Policy)은 권한의 내용을 담은 문서임. 정책 자체를 EC2 인스턴스에 '직접' 연결할 수는 없음. 반드시 **역할(Role)**이라는 그릇에 정책을 담아서 인스턴스에 연결해야 함.
2. C (IAM 그룹): IAM 그룹(Group)은 사용자(User)들을 관리하기 위한 단위임. EC2 인스턴스에 그룹을 연결하는 개념은 존재하지 않음.
3. D (IAM 사용자): 인스턴스 내부에 사용자 계정 정보를 하드코딩하거나 파일로 저장하는 방식은 보안상 권장되지 않음. 키가 유출될 경우 큰 보안 사고로 이어질 수 있음.

18번

애플리케이션 개발팀은 대용량 이미지를 더 작고 압축된 이미지로 변환하는 마이크로서비스를 설계하고 있습니다. 사용자가 웹 인터페이스를 통해 이미지를 업로드하면, 마이크로서비스는 이미지를 Amazon S3 버킷에 저장하고, AWS Lambda 함수를 사용하여 이미지를 처리 및 압축한 후, 압축된 이미지를 다른 S3 버킷에 저장해야 합니다.

솔루션 아키텍트는 내구성이 뛰어나고 상태를 저장하지 않는 구성 요소를 사용하여 이미지를 자동으로 처리하는 솔루션을 설계해야 합니다. 다음 중

어떤 작업 조합이 이러한 요구 사항을 충족할까요? (두 가지를 선택하세요.)

• A.
• Amazon Simple Queue Service(Amazon SQS) 큐를 생성합니다. 이미지가 S3 버킷에 업로드될 때 SQS 큐로 알림을 보내도록 S3 버킷을 구성합니다.
• B.
• Lambda 함수가 Amazon Simple Queue Service(Amazon SQS) 큐를 호출 소스로 사용하도록 구성합니다. SQS 메시지 처리가 완료되면 큐에서 해당 메시지를 삭제합니다.
• C.
• Lambda 함수를 구성하여 S3 버킷에 새 이미지가 업로드되었는지 모니터링합니다. 업로드된 이미지가 감지되면 파일 이름을 메모리의 텍스트 파일에 기록하고, 해당 텍스트 파일을 사용하여 처리된 이미지를 추적합니다.
• D.
• Amazon Simple Queue Service(Amazon SQS) 큐를 모니터링하기 위해 Amazon EC2 인스턴스를 시작합니다. 큐에 항목이 추가되면 파일 이름을 EC2 인스턴스의 텍스트 파일에 기록하고 Lambda 함수를 호출합니다.
• E.
• S3 버킷을 모니터링하도록 Amazon EventBridge(Amazon CloudWatch Events) 이벤트를 구성합니다. 이미지가 업로드되면 애플리케이션 소유자의 이메일 주소를 포함하여 Amazon Sam/Amazon SNS(Amazon Ample Notification Service) 토픽으로 알림을 전송하여 추가 처리를 수행하도록 합니다.
• 정답
  1. 내구성 및 비동기 처리 (A): S3에 파일이 올라오자마자 Lambda를 바로 실행할 수도 있지만, SQS 큐를 중간에 두면 갑자기 수만 장의 이미지가 업로드되어도 메시지가 큐에 안전하게 보관됨. 이는 시스템의 내구성을 크게 높여줌.
  2. 자동화 및 상태 비저장 (B): Lambda가 SQS를 소스로 사용하면 큐에 메시지가 들어올 때마다 자동으로 트리거되어 이미지를 처리함. 처리가 끝나면 메시지를 큐에서 삭제함으로써 '작업 완료' 상태를 관리함. 이는 별도의 데이터베이스 없이도 Stateless하게 설계를 유지하는 표준 방식임.

  ---

  오답 분석
  1. C (메모리에 기록): "메모리의 텍스트 파일"에 기록하는 것은 인스턴스가 꺼지면 데이터가 날아가는 Stateful한 방식임. 문제의 요구 사항인 Stateless와 정면으로 배치됨.
  2. D (EC2 사용): 서버리스(Lambda) 기반 마이크로서비스를 설계하는데 굳이 EC2 인스턴스를 띄워서 모니터링하는 것은 운영 오버헤드를 높이고 자원 낭비임.
  3. E (SNS 이메일): SNS로 이메일을 보내는 것은 사람에게 알림을 주는 용도이지, 이미지를 자동으로 압축 처리하는 로직과는 거리가 멂.

19번

한 회사가 AWS에 배포된 3계층 웹 애플리케이션을 보유하고 있습니다. 웹 서버는 VPC 내의 퍼블릭 서브넷에 배포되어 있으며, 애플리케이션 서버와 데이터베이스 서버는 동일한 VPC 내의 프라이빗 서브넷에 배포되어 있습니다. 또한, 이 회사는 AWS 마켓플레이스에서 구입한 타사 가상 방화벽 어플라이언스를 검사용 VPC에 배포했습니다. 이 어플라이언스는 IP 패킷을 수신할 수 있는 IP 인터페이스로 구성되어 있습니다.

솔루션 아키텍트는 웹 애플리케이션이 웹 서버에 도달하기 전에 모든 트래픽을 검사할 수 있도록 웹 애플리케이션과 이 어플라이언스를 통합해야 합니다.

이러한 요구 사항을 충족하면서 운영 오버헤드를 최소화하는 솔루션은 무엇일까요?

• A.
• 애플리케이션 VPC의 공용 서브넷에 네트워크 로드 밸런서를 생성하여 패킷 검사를 위해 어플라이언스로 트래픽을 라우팅합니다.
• B.
• 애플리케이션 VPC의 공용 서브넷에 애플리케이션 로드 밸런서를 생성하여 패킷 검사를 위해 트래픽을 어플라이언스로 라우팅합니다.
• C.
• 검사 VPC에 트랜짓 게이트웨이를 배포하고, 수신 패킷이 트랜짓 게이트웨이를 통해 라우팅되도록 라우팅 테이블을 구성합니다.
• D.
• 검사 VPC에 게이트웨이 로드 밸런서를 배포합니다. 수신 패킷을 받아 어플라이언스로 전달하는 게이트웨이 로드 밸런서 엔드포인트를 생성합니다.

• D가 정답인 이유 (Gateway Load Balancer)

1. 타사 어플라이언스 전용: **Gateway Load Balancer(GWLB)**는 방화벽, 침입 탐지 시스템(IDS/IPS)과 같은 타사 가상 어플라이언스를 쉽고 확장성 있게 배포하기 위해 만들어진 서비스임.
2. 투명한 검사 (Bump-in-the-wire): GWLB는 3계층(IP 계층)에서 동작하며, 패킷의 원래 소스 및 목적지 IP를 유지한 채 검사 장비로 전달함.
3. GWLB 엔드포인트(GWLBe): 애플리케이션 VPC에 엔드포인트를 생성하고 라우팅 테이블을 수정함으로써, 트래픽을 검사 VPC의 방화벽으로 '투명하게' 보냈다가 다시 받아올 수 있음.
4. 운영 오버헤드 최소화: 여러 방화벽 인스턴스에 대한 부하 분산과 가용성을 AWS가 관리해주므로 직접 구축하는 것보다 훨씬 간편함.

---

오답 분석

1. A, B (NLB, ALB): 일반적인 로드 밸런서는 트래픽의 목적지를 자기 자신으로 바꿔서 전달함(Proxy 방식). 방화벽처럼 패킷을 '검사만 하고 통과'시켜야 하는 용도에는 적합하지 않으며, 원본 IP 보존 등이 까다로움.
2. C (Transit Gateway 전용): Transit Gateway(TGW)는 여러 VPC를 연결하는 훌륭한 도구이지만, 이 문제의 핵심인 '방화벽 어플라이언스'와의 투명한 통합을 위해서는 TGW 단독보다는 GWLB와 조합하는 것이 표준 아키텍처임.