#101
솔루션 아키텍트는 퍼블릭 및 프라이빗 서브넷이 있는 VPC를 설계하고 있습니다. VPC와 서브넷은 IPv4 CIDR 블록을 사용합니다. 고가용성을 위해 3개의 가용성 영역(AZ) 각각에 퍼블릭 서브넷 1개와 프라이빗 서브넷 1개가 있습니다. 인터넷 게이트웨이는 퍼블릭 서브넷에 대한 인터넷 액세스를 제공하는 데 사용됩니다. 프라이빗 서브넷은 Amazon EC2 인스턴스가 소프트웨어 업데이트를 다운로드할 수 있도록 인터넷에 액세스할 수 있어야 합니다. 솔루션 아키텍트는 프라이빗 서브넷에 대한 인터넷 액세스를 활성화하기 위해 무엇을 해야 합니까?
- A. 각 AZ의 각 퍼블릭 서브넷에 대해 하나씩 총 세 개의 NAT 게이트웨이를 만듭니다. 각 AZ에 대해 VPC가 아닌 트래픽을 해당 AZ의 NAT 게이트웨이로 전달하는 개인 경로 테이블을 만듭니다.
- B. 각 AZ의 각 프라이빗 서브넷에 대해 하나씩 총 세 개의 NAT 인스턴스를 만듭니다. 각 AZ에 대해 VPC가 아닌 트래픽을 해당 AZ의 NAT 인스턴스로 전달하는 프라이빗 경로 테이블을 만듭니다.
- C. 프라이빗 서브넷 중 하나에 두 번째 인터넷 게이트웨이를 만듭니다. 프라이빗 인터넷 게이트웨이로 VPC가 아닌 트래픽을 전달하는 프라이빗 서브넷의 경로 테이블을 업데이트합니다.
- D. 퍼블릭 서브넷 중 하나에 이그레스 전용 인터넷 게이트웨이를 만듭니다. 이그레스 전용 인터넷 게이트웨이로 VPC가 아닌 트래픽을 전달하는 프라이빗 서브넷의 경로 테이블을 업데이트합니다.
✅ 정답 해설:
- 프라이빗 서브넷은 직접 인터넷 게이트웨이(IGW)를 통해 인터넷에 접근할 수 없습니다.
- 인터넷 액세스를 위해서는 NAT(Network Address Translation) 서비스를 사용해야 하며, AWS에서는 NAT 게이트웨이 또는 NAT 인스턴스를 사용할 수 있습니다.
- 고가용성을 위해 각 가용성 영역(AZ)에 하나씩 NAT 게이트웨이를 배포하는 것이 권장됩니다. 즉, 3개의 AZ가 있다면 3개의 NAT 게이트웨이가 필요합니다.
- 각 프라이빗 서브넷의 라우팅 테이블은 해당 AZ의 NAT 게이트웨이를 통해 인터넷으로 나가도록 설정해야 합니다.
- 퍼블릭 서브넷에는 NAT 게이트웨이를 배치하며, 해당 퍼블릭 서브넷은 인터넷 게이트웨이를 통해 외부와 연결되어야 합니다.
- 이 구조는 고가용성과 내결함성을 제공하며, AWS 모범 사례입니다.
❌ 오답 해설:
B. 각 AZ의 각 프라이빗 서브넷에 대해 하나씩 총 세 개의 NAT 인스턴스를 만듭니다. 각 AZ에 대해 VPC가 아닌 트래픽을 해당 AZ의 NAT 인스턴스로 전달하는 프라이빗 경로 테이블을 만듭니다.
- NAT 인스턴스는 예전 방식으로, 현재는 NAT 게이트웨이 사용이 권장됩니다.
- NAT 인스턴스는 수동으로 관리해야 하며, 고가용성과 성능 면에서 NAT 게이트웨이에 비해 열등합니다.
- NAT 인스턴스를 사용하려면 적절한 보안 그룹, 소스/대상 검사 비활성화 등 추가 설정이 필요합니다.
- 따라서 이 옵션은 기술적으로 가능하지만, 현재 AWS 모범 사례에 부합하지 않습니다.
C. 프라이빗 서브넷 중 하나에 두 번째 인터넷 게이트웨이를 만듭니다. 프라이빗 인터넷 게이트웨이로 VPC가 아닌 트래픽을 전달하는 프라이빗 서브넷의 경로 테이블을 업데이트합니다.
- VPC에는 하나의 인터넷 게이트웨이만 연결할 수 있습니다. "두 번째 인터넷 게이트웨이"라는 개념은 AWS에서 허용되지 않습니다.
- 또한, 인터넷 게이트웨이는 퍼블릭 서브넷과 연결되어야 하며, 프라이빗 서브넷에는 직접 연결할 수 없습니다.
- "프라이빗 인터넷 게이트웨이"라는 용어도 AWS에서 존재하지 않습니다.
- 따라서 이 옵션은 잘못된 정보입니다.
D. 퍼블릭 서브넷 중 하나에 이그레스 전용 인터넷 게이트웨이를 만듭니다. 이그레스 전용 인터넷 게이트웨이로 VPC가 아닌 트래픽을 전달하는 프라이빗 서브넷의 경로 테이블을 업데이트합니다.
- 이그레스 전용 인터넷 게이트웨이(Egress-only Internet Gateway)는 IPv6 트래픽 전용입니다.
- 질문에서는 VPC와 서브넷이 IPv4 CIDR 블록을 사용한다고 명시되어 있으므로, 이그레스 전용 IGW는 적용되지 않습니다.
- IPv4 트래픽에 대해서는 NAT 게이트웨이나 NAT 인스턴스를 사용해야 합니다.
- 따라서 이 옵션은 조건과 맞지 않으며 오답입니다.
📌 요약:
| A | 각 AZ에 NAT GW 배치 및 라우팅 구성 | ✅ 정답 | 모범 사례 |
| B | NAT 인스턴스 사용 | ❌ 오답 | 가능하나 비권장 |
| C | 두 번째 IGW 생성 시도 | ❌ 오답 | 불가능한 구성 |
| D | 이그레스 전용 IGW 사용 | ❌ 오답 | IPv6 전용이며 조건 불일치 |
결론: 고가용성과 안정적인 프라이빗 서브넷의 인터넷 접근을 위해서는 A. 각 AZ에 NAT 게이트웨이를 배치하고 적절한 라우팅 구성이 필요합니다.
#102
한 회사가 온프레미스 데이터 센터를 AWS로 마이그레이션하려고 합니다. 데이터 센터는 NFS 기반 파일 시스템에 데이터를 저장하는 SFTP 서버를 호스팅합니다. 이 서버는 전송해야 하는 200GB의 데이터를 보관합니다. 이 서버는 Amazon Elastic File System(Amazon EFS) 파일 시스템을 사용하는 Amazon EC2 인스턴스에 호스팅되어야 합니다.
솔루션 아키텍트는 이 작업을 자동화하기 위해 어떤 단계 조합을 취해야 합니까? (두 가지를 선택하세요.)
- A. EFS 파일 시스템과 동일한 가용성 영역에서 EC2 인스턴스를 시작합니다.
- B. 온프레미스 데이터 센터에 AWS DataSync 에이전트를 설치합니다.
- C. EC2 인스턴스에 데이터용 보조 Amazon Elastic Block Store(Amazon EBS) 볼륨을 생성합니다.
- D. 운영 체제 복사 명령을 수동으로 사용하여 데이터를 EC2 인스턴스로 푸시합니다.
- E. AWS DataSync를 사용하여 온프레미스 SFTP 서버에 적합한 위치 구성을 생성합니다.
핵심 요건:
- 온프레미스 NFS 기반 스토리지
- 네트워크를 통해 파일 및 디렉토리를 공유하기 위한 시스템이다.
즉, 다른 컴퓨터의 파일 시스템을 마치 자기 것처럼 사용할 수 있는 것이다.
- AWS 대상: EC2 인스턴스 + Amazon EFS
- 전송해야 하는 데이터: 200GB
- 자동화 필요
- https://jibinary.tistory.com/67
정답:
✅ B. 온프레미스 데이터 센터에 AWS DataSync 에이전트를 설치합니다.
✅ E. AWS DataSync를 사용하여 온프레미스 SFTP 서버에 적합한 위치 구성을 생성합니다.
🟩 정답 해설:
B. 온프레미스 데이터 센터에 AWS DataSync 에이전트를 설치합니다.
- DataSync는 온프레미스 스토리지에서 AWS로 데이터를 자동으로 복사할 수 있는 서비스입니다.
- 온프레미스 환경에서는 DataSync 에이전트를 VMware, Hyper-V 또는 Linux VM에 설치해야 합니다.
- 이 에이전트는 AWS와 통신하여 데이터를 전송하는 역할을 하므로 필수적인 구성 요소입니다.
- 따라서 자동화된 데이터 전송을 위해 반드시 필요한 단계입니다.
E. AWS DataSync를 사용하여 온프레미스 SFTP 서버에 적합한 위치 구성을 생성합니다.
- DataSync는 "로케이션(Location)"이라는 개념을 사용하여 출발지와 도착지를 정의합니다.
- 출발지는 SFTP 서버이므로 "SFTP 로케이션"을 설정해야 합니다.
- DataSync는 NFS, SMB(Windows), S3, EFS, SFTP 등 다양한 로케이션을 지원합니다.
- 출발지로 사용할 SFTP 서버에 대한 로케이션 구성이 필요하므로 이 옵션은 정답입니다.
🟥 오답 해설:
A. EFS 파일 시스템과 동일한 가용성 영역에서 EC2 인스턴스를 시작합니다.
- Amazon EFS는 여러 가용 영역(AZ)에서 사용할 수 있도록 설계된 완전관리형 NFS 파일 시스템입니다.
- EC2 인스턴스는 반드시 같은 AZ에서 실행될 필요는 없습니다. EFS는 VPC 내에서 여러 AZ에 걸쳐 마운트할 수 있습니다.
- 따라서 이 옵션은 필요 조건이 아니며 오답입니다.
C. EC2 인스턴스에 데이터용 보조 Amazon Elastic Block Store(Amazon EBS) 볼륨을 생성합니다.
- EBS는 블록 스토리지이며, 문제의 요구사항은 EFS를 사용하는 것입니다.
- 데이터를 저장할 대상은 Amazon EFS이고, EBS는 필요하지 않습니다.
- 따라서 이 옵션은 오답입니다.
D. 운영 체제 복사 명령을 수동으로 사용하여 데이터를 EC2 인스턴스로 푸시합니다.
- 질문에서는 작업을 자동화하려고 한다고 명시되어 있습니다.
- 수동 복사는 자동화가 아니며, 사람이 직접 명령어(cp, scp, rsync 등)를 실행해야 합니다.
- 또한, 대역폭이나 일관성 측면에서도 DataSync보다 비효율적입니다.
- 따라서 자동화라는 조건과 맞지 않으므로 오답입니다.
📌 요약
옵션설명정오 판단비고
| A | EFS와 동일 AZ에서 EC2 실행 | ❌ 오답 | EFS는 멀티 AZ 지원 |
| B | 온프레미스에 DataSync 에이전트 설치 | ✅ 정답 | 필수 구성 요소 |
| C | EBS 볼륨 생성 | ❌ 오답 | 대상은 EFS |
| D | 수동 복사 명령 사용 | ❌ 오답 | 자동화 아님 |
| E | SFTP 서버용 로케이션 구성 | ✅ 정답 | DataSync 설정 단계 |
✅ 최종 정답:
B. 온프레미스 데이터 센터에 AWS DataSync 에이전트를 설치합니다.
E. AWS DataSync를 사용하여 온프레미스 SFTP 서버에 적합한 위치 구성을 생성합니다.
#103번
한 회사에는 매일 같은 시간에 실행되는 AWS Glue 추출, 변환 및 로드(ETL) 작업이 있습니다. 이 작업은 Amazon S3 버킷에 있는 XML 데이터를 처리합니다. 매일 S3 버킷에 새 데이터가 추가됩니다. 솔루션 아키텍트는 AWS Glue가 각 실행 중에 모든 데이터를 처리하고 있다는 것을 알아챘습니다. 솔루션 아키텍트는
AWS Glue가 이전 데이터를 다시 처리하지 못하도록 어떻게 해야 합니까?
- A. 작업 북마크를 사용하여 작업을 편집합니다.
- B. 데이터 처리가 완료된 후 데이터를 삭제하기 위해 작업을 편집합니다.
- C. NumberOfWorkers 필드를 1로 설정하여 작업을 편집합니다.
- D. FindMatches 머신 러닝(ML) 변환을 사용합니다
📌 질문 핵심 요약:
- Amazon S3에 매일 새 XML 데이터가 추가됨
- AWS Glue ETL 작업이 매일 실행됨
- 하지만 이전 데이터도 계속 다시 처리되고 있음 → 비효율적
- 요구사항: 이전 데이터를 다시 처리하지 않도록 설정해야 함
✅ 정답: A. 작업 북마크를 사용하여 작업을 편집합니다.
🟩 정답 해설:
A. 작업 북마크(Job bookmarks)를 사용하여 작업을 편집합니다.
- AWS Glue의 "작업 북마크"는 이전에 처리된 데이터를 추적하고, 다음 실행 시 중복 처리를 피할 수 있도록 도와주는 기능입니다.
- Glue는 S3, JDBC 등의 소스에서 데이터를 읽을 때, 마지막 처리 시점 이후의 새로운 데이터만 처리하도록 구성할 수 있습니다.
- 이 기능은 반복적으로 실행되는 ETL 작업에 매우 유용하며, 바로 이 시나리오에 적합합니다.
- 따라서 이 옵션은 정확한 해결책입니다.
🟥 오답 해설:
B. 데이터 처리가 완료된 후 데이터를 삭제하기 위해 작업을 편집합니다.
- 이 방법은 기술적으로 가능하지만, 매우 위험하고 권장되지 않는 방식입니다.
- 원시 데이터를 완전히 삭제하면 추후 오류 발생 시 복구가 불가능합니다.
- 컴플라이언스 또는 감사 요구사항이 있는 경우에도 문제가 됩니다.
- Glue에서는 작업 북마크를 사용하는 것이 훨씬 안전하고 효과적인 방법입니다.
C. NumberOfWorkers 필드를 1로 설정하여 작업을 편집합니다.
- NumberOfWorkers는 Glue 작업의 병렬 처리 성능(즉, 워커 수)을 조정하는 값입니다.
- 이 값은 성능, 비용과 관련이 있으며 데이터 재처리 여부와는 무관합니다.
- 따라서 이 옵션은 문제 해결과 관련이 없습니다.
D. FindMatches 머신 러닝(ML) 변환을 사용합니다.
- FindMatches는 AWS Glue에서 제공하는 ML 기반 디듀플리케이션(중복 제거) 기능입니다.
- 이는 동일한 엔터티를 식별하는 데 사용되며, 주로 고객 정보 중복 제거 등에 사용됩니다.
- 이 기능은 "이전 실행에서 처리된 파일"을 자동으로 건너뛰는 기능과는 관련 없습니다.
- 따라서 이 옵션도 오답입니다.
📌 요약:
| A | Glue 작업 북마크 사용 | ✅ 정답 | 이전 실행 추적하여 중복 방지 |
| B | 처리 후 데이터 삭제 | ❌ 오답 | 위험 & 비권장 |
| C | 워커 수 1로 설정 | ❌ 오답 | 성능 관련 옵션 |
| D | FindMatches ML 사용 | ❌ 오답 | 중복 엔터티 탐지, 재처리 방지 아님 |
✅ 최종 정답:
A. 작업 북마크를 사용하여 작업을 편집합니다.
#104
솔루션 아키텍트는 웹사이트를 위한 고가용성 인프라를 설계해야 합니다. 웹사이트는 Amazon EC2 인스턴스에서 실행되는 Windows 웹 서버로 구동됩니다. 솔루션 아키텍트는 수천 개의 IP 주소에서 발생하는 대규모 DDoS 공격을 완화할 수 있는 솔루션을 구현해야 합니다. 웹사이트에 다운타임은 허용되지 않습니다.
솔루션 아키텍트는 이러한 공격으로부터 웹사이트를 보호하기 위해 어떤 조치를 취해야 합니까? (두 가지를 선택하세요.)
- A. AWS Shield Advanced를 사용하여 DDoS 공격을 차단하세요.
- B. Amazon GuardDuty를 구성하여 공격자를 자동으로 차단합니다.
- C. 정적 및 동적 콘텐츠 모두에 Amazon CloudFront를 사용하도록 웹사이트를 구성합니다.
- D. AWS Lambda 함수를 사용하여 공격자 IP 주소를 VPC 네트워크 ACL에 자동으로 추가합니다.
- E. 대상 추적 확장 정책이 CPU 사용률 80%로 설정된 자동 확장 그룹에서 EC2 스팟 인스턴스를 사용합니다.
이 문제는 웹사이트가 Amazon EC2 인스턴스에서 실행되는 상황에서, 대규모 DDoS 공격을 받는 경우 이를 어떻게 완화하고 고가용성을 유지할 수 있는지 묻는 것. 특히, “웹사이트에 다운타임은 허용되지 않는다”는 조건이 중요
📌 목표:
- 고가용성 인프라 설계 (즉, 장애 발생 시에도 웹사이트가 계속 동작해야 함)
- Windows 기반 EC2 웹 서버 사용
- 수천 개의 IP에서 발생하는 대규모 DDoS 공격 차단 필요
- 다운타임 허용 불가
✅ 정답:
A. AWS Shield Advanced를 사용하여 DDoS 공격을 차단하세요.
C. 정적 및 동적 콘텐츠 모두에 Amazon CloudFront를 사용하도록 웹사이트를 구성합니다.
🟩 정답 해설:
A. AWS Shield Advanced를 사용하여 DDoS 공격을 차단하세요. ✅
- AWS Shield는 AWS에서 제공하는 DDoS 보호 서비스입니다.
- Basic은 모든 AWS 고객에게 자동 적용되지만, 고급 보호 기능은 Shield Advanced를 통해 제공됩니다.
- Shield Advanced는 다음과 같은 기능을 제공합니다:
- 대형 DDoS 공격 탐지 및 완화
- 실시간 공격 대시보드
- 24x7 DDoS 대응 팀(DRT) 접근
- 비용 보호 (DDoS로 인해 발생한 과금에 대한 보호)
- 따라서 고가용성과 고급 보호를 보장하기 위해 반드시 필요한 구성요소입니다.
C. 정적 및 동적 콘텐츠 모두에 Amazon CloudFront를 사용하도록 웹사이트를 구성합니다. ✅
- CloudFront는 AWS의 글로벌 콘텐츠 전송 네트워크(CDN)로, 엣지 로케이션을 통해 트래픽을 분산시킵니다.
- CloudFront 앞단에 웹사이트를 배치하면:
- DDoS 공격 트래픽이 엣지에서 필터링되어 원본 EC2 인스턴스까지 도달하지 않음
- 캐시를 통해 정적 콘텐츠 제공 → EC2 부하 감소
- WAF와 연동하여 IP 기반 또는 요청 기반 필터링 가능
- 동적 콘텐츠도 오리진으로 전달 가능하므로, 전체 트래픽 분산이 가능합니다.
- 따라서 CloudFront는 성능 향상 및 DDoS 완화 모두에 효과적입니다.
🟥 오답 해설:
B. Amazon GuardDuty를 구성하여 공격자를 자동으로 차단합니다. ❌
- GuardDuty는 AWS 계정 및 리소스를 대상으로 보안 위협을 탐지하는 서비스입니다.
- 머신러닝을 활용하여 이상 징후를 탐지하지만, 자동 차단 기능은 제공하지 않습니다.
- GuardDuty는 탐지를 위한 서비스이며, 차단을 위해서는 별도의 조치 또는 통합이 필요합니다 (예: Lambda 연동).
- 따라서 직접적인 DDoS 완화 역할은 할 수 없습니다.
D. AWS Lambda 함수를 사용하여 공격자 IP 주소를 VPC 네트워크 ACL에 자동으로 추가합니다. ❌
- 이 접근 방식은 기술적으로 가능하지만 비효율적입니다:
- 네트워크 ACL은 평가 순서가 고정된 stateless 필터입니다.
- ACL은 최대 규칙 수 제한이 있으며, 수천 개의 IP를 실시간으로 추가하는 것은 어렵습니다.
- DDoS 공격은 빠르게 IP를 순환시키기 때문에 실효성이 낮습니다.
- 따라서 대규모 DDoS 공격 대비책으로 적절하지 않습니다.
E. 대상 추적 확장 정책이 CPU 사용률 80%로 설정된 자동 확장 그룹에서 EC2 스팟 인스턴스를 사용합니다. ❌
- Auto Scaling은 EC2 인스턴스 수를 조절해 부하 분산에는 도움이 될 수 있습니다.
- 하지만 스팟 인스턴스는 AWS의 용량 상황에 따라 예고 없이 종료될 수 있으므로, "다운타임이 허용되지 않는" 상황에는 적합하지 않습니다.
- 또한, DDoS 공격에 의해 발생한 트래픽 증가에 대응하기 위해 무작정 인스턴스를 늘리는 것은 비용 및 자원 낭비로 이어질 수 있습니다.
- 근본적인 방어가 아닌 반응적 조치이므로 효과적이지 않습니다.
📌 요약표:
옵션설명정오 판단비고| A | AWS Shield Advanced로 DDoS 보호 | ✅ 정답 | 고급 보호 + 비용 보호 + 지원 |
| B | GuardDuty로 자동 차단 | ❌ 오답 | 탐지만 가능, 차단 불가 |
| C | CloudFront로 콘텐츠 분산 | ✅ 정답 | 엣지 분산 + 성능 향상 + 보안 강화 |
| D | Lambda + NACL로 IP 차단 | ❌ 오답 | 비효율적이며 확장성 낮음 |
| E | Auto Scaling + 스팟 사용 | ❌ 오답 | 스팟은 중단 가능성 있음, 고가용성과 맞지 않음 |
✅ 최종 정답:
A. AWS Shield Advanced를 사용하여 DDoS 공격을 차단하세요.
C. 정적 및 동적 콘텐츠 모두에 Amazon CloudFront를 사용하도록 웹사이트를 구성합니다.
#105번
한 회사가 새로운 서버리스 워크로드를 배포할 준비를 하고 있습니다. 솔루션 아키텍트는 AWS Lambda 함수를 실행하는 데 사용될 권한을 구성하기 위해 최소 권한의 원칙을 사용해야 합니다. Amazon EventBridge(Amazon CloudWatch Events) 규칙은 함수를 호출합니다.
어떤 솔루션이 이러한 요구 사항을 충족합니까?
- A. lambda:InvokeFunction을 작업으로, *를 주체로 하여 함수에 실행 역할을 추가합니다.
- B. Lambda:InvokeFunction을 작업으로, Service: lambda.amazonaws.com을 주체로 하여 함수에 실행 역할을 추가합니다.
- C. Lambda:*를 작업으로, Service: events.amazonaws.com을 주체로 하는 리소스 기반 정책을 함수에 추가합니다.
- D. lambda:InvokeFunction을 작업으로, Service: events.amazonaws.com을 주체로 하여 함수에 리소스 기반 정책을 추가합니다.
✅ 정답:
D. lambda:InvokeFunction을 작업으로, Service: events.amazonaws.com을 주체로 하여 함수에 리소스 기반 정책을 추가합니다.
🔍 질문 요약
- 서버리스 워크로드: AWS Lambda 사용
- 호출 주체: Amazon EventBridge (이전 이름: CloudWatch Events)
- 요구 사항: 최소 권한 원칙 적용 (Least Privilege Principle)
- 목적: Lambda 함수가 EventBridge에 의해 호출될 수 있도록 권한 부여
🧠 개념 정리
✅ Lambda 함수 호출 권한 설정 방법
AWS Lambda 함수는 외부 서비스(예: EventBridge, S3, API Gateway 등)가 호출할 수 있도록 별도의 리소스 기반 정책(Resource-based policy)이 필요합니다.
- 이 정책은 Lambda 함수에 저장되며, 호출 주체가 누구인지 명시합니다.
- 호출 주체는 일반적으로 "Service Principal"로 표현됩니다. 예: events.amazonaws.com
✅ 최소 권한 원칙 적용
- 필요한 동작만 허용해야 함 → lambda:InvokeFunction
- 필요한 주체만 허용해야 함 → events.amazonaws.com
- 모든 서비스에 허용하거나 모든 작업(*)을 허용해서는 안 됨
✅ 정답 해설
D. lambda:InvokeFunction을 작업으로, Service: events.amazonaws.com을 주체로 하여 함수에 리소스 기반 정책을 추가합니다.
- 정확히 필요한 작업(lambda:InvokeFunction)만 허용함 → 최소 권한 원칙 적용
- 호출 주체가 EventBridge 서비스임 → 주체가 events.amazonaws.com
- 리소스 기반 정책은 Lambda 함수에 직접 추가되어야 하며, 외부 서비스가 호출할 수 있도록 설정함
- 이 구성은 EventBridge가 Lambda 함수를 트리거하는 데 필요한 정확한 권한입니다
✅ 따라서 이 옵션이 정답입니다.
❌ 오답 해설
A. lambda:InvokeFunction을 작업으로, *를 주체로 하여 함수에 실행 역할을 추가합니다.
- 주체가 * (와일드카드) → 모든 사용자/서비스에게 권한 부여 = 최소 권한 원칙 위배
- 실행 역할은 Lambda 함수가 다른 AWS 서비스에 접근할 때 사용하는 역할임 → 지금 상황과는 무관
- 외부 서비스가 Lambda를 호출하도록 허용하려면 리소스 기반 정책이 필요함
❌ 오답
B. Lambda:InvokeFunction을 작업으로, Service: lambda.amazonaws.com을 주체로 하여 함수에 실행 역할을 추가합니다.
- 먼저 작업명이 대소문자 혼용(Lambda:) → 잘못된 IAM 액션 (IAM에서는 소문자 사용)
- lambda.amazonaws.com는 Lambda 자체를 위한 서비스 주체임 → 여기서는 EventBridge가 호출자
- 실행 역할은 Lambda 함수 자체의 역할임 → 호출자가 사용할 권한 아님
❌ 오답
C. Lambda:*를 작업으로, Service: events.amazonaws.com을 주체로 하는 리소스 기반 정책을 함수에 추가합니다.
- Lambda:* → 모든 Lambda 작업 허용 = 최소 권한 원칙 위배
- 좋은 방향은 맞지만 너무 많은 권한 부여됨
- invoke만 필요하므로 lambda:InvokeFunction만 설정해야 함
❌ 오답
📌 요약표
옵션설명정오 판단비고
| A | 모든 주체(*)에게 invoke 권한 부여 | ❌ | 최소 권한 원칙 위배 |
| B | 실행 역할에 잘못된 주체 사용 | ❌ | 호출자 권한 아님 |
| C | events.amazonaws.com 주체 OK, 그러나 너무 많은 권한(Lambda:*) | ❌ | 과도한 권한 부여 |
| D | 필요한 동작만(lambda:InvokeFunction), 정확한 주체(events.amazonaws.com) 사용 | ✅ | 최소 권한 원칙 충족! |
✅ 최종 정답:
D. lambda:InvokeFunction을 작업으로, Service: events.amazonaws.com을 주체로 하여 함수에 리소스 기반 정책을 추가합니다.
#106번
한 회사가 Amazon S3에 기밀 데이터를 저장할 준비를 하고 있습니다. 규정 준수를 위해 데이터는 휴면 상태에서 암호화되어야 합니다. 암호화 키 사용은 감사 목적으로 기록되어야 합니다. 키는 매년 순환되어야 합니다.
이러한 요구 사항을 충족하고 가장 운영 효율적인 솔루션은 무엇입니까?
- A. 고객 제공 키를 사용한 서버 측 암호화(SSE-C)
- B. Amazon S3 관리 키를 사용한 서버 측 암호화(SSE-S3)
- C. 수동 로테이션을 사용한 AWS KMS 키(SSE-KMS)를 사용한 서버 측 암호화
- D. 자동 순환을 포함한 AWS KMS 키(SSE-KMS)를 사용한 서버 측 암호화
✅ 정답:
D. 자동 순환을 포함한 AWS KMS 키(SSE-KMS)를 사용한 서버 측 암호화
🔍 질문 요약:
한 회사가 Amazon S3에 기밀 데이터를 저장하려고 합니다. 다음과 같은 요구 사항이 있습니다:
- 데이터는 휴면 상태(At-Rest)에서 암호화되어야 함
- 암호화 키의 사용은 감사(Audit)를 위해 기록되어야 함
- 암호화 키는 매년 순환(Rotation)되어야 함
- 운영 효율성이 높은 솔루션이 필요함
✅ 정답 해설:
D. 자동 순환을 포함한 AWS KMS 키(SSE-KMS)를 사용한 서버 측 암호화
- ❇️ 데이터 암호화: SSE-KMS는 S3 객체를 저장 시 자동으로 암호화
- ❇️ 키 순환: AWS 관리형 KMS 키(auto-rotated KMS key)는 연 1회 자동으로 키를 순환함 → 요구 사항 충족
- ❇️ 감사 로깅: AWS CloudTrail을 통해 KMS 키 사용 내역 자동 기록 → 감사 목적 충족
- ❇️ 운영 효율성: 자동 키 순환 및 통합된 권한 관리로 운영 부담 낮음
따라서 모든 요구 사항을 충족하면서도 가장 운영 효율적인 선택입니다.
🟥 오답 해설:
A. 고객 제공 키를 사용한 서버 측 암호화 (SSE-C)
- 사용자(고객)가 직접 키를 관리하고 제공해야 함 → 운영 부담 증가
- AWS는 키를 저장하지 않음 → 로테이션, 감사 로깅 불가능
- SSE-C는 CloudTrail에 KMS 사용 로그가 남지 않음
❌ 운영 효율성 및 감사 요건을 충족하지 못함
B. Amazon S3 관리 키를 사용한 서버 측 암호화 (SSE-S3)
- S3가 자체적으로 관리하는 키로 데이터를 암호화
- KMS를 사용하지 않기 때문에, 키 사용 로그가 CloudTrail에 기록되지 않음 → 감사 불가
- 키 순환은 AWS가 내부적으로 관리하지만, 사용자 제어 불가
❌ 감사 요건 및 명시적 키 순환 요구 사항 미충족
C. 수동 로테이션을 사용한 AWS KMS 키(SSE-KMS)를 사용한 서버 측 암호화
- 수동으로 사용자 관리형 KMS 키 생성 후 직접 로테이션 수행해야 함
- 연간 로테이션은 가능하지만 운영자가 수동으로 처리해야 함 → 운영 효율 떨어짐
❌ 기술적으로 가능하지만 운영 효율성 요구 사항 미충족
📌 요약표:
옵션설명충족 여부비고
| A | 고객 제공 키(SSE-C) | ❌ | 감사 불가, 운영 부담 큼 |
| B | S3 관리형 키(SSE-S3) | ❌ | CloudTrail 로깅 불가, 통제력 없음 |
| C | KMS + 수동 로테이션 | ❌ | 가능은 하나 운영 효율성 낮음 |
| D | KMS + 자동 로테이션 | ✅ | 감사 가능, 자동 순환, 낮은 운영 부담 |
✅ 최종 정답:
D. 자동 순환을 포함한 AWS KMS 키(SSE-KMS)를 사용한 서버 측 암호화