목차
| 문제 | 키워드 | 난이도 |
|---|---|---|
| Q18 | IAM + SQS Policy 동시 적용 | ⭐⭐⭐ |
| Q19 | CloudWatch Logs KMS 암호화 | ⭐⭐ |
| Q20 | Cross-Account SQS 접근 | ⭐⭐⭐ |
| Q21 | STS decode-authorization-message | ⭐⭐ |
| Q22 | S3 SSE-KMS 자동 Key Rotation | ⭐⭐ |
| Q23 | EC2 Log → Kinesis Agent | ⭐⭐ |
| Q24 | S3 SSE-KMS Header 값 | ⭐⭐ |
| Q25 | IAM Policy Deny/Allow 평가 | ⭐⭐ |
| Q26 | EC2 IAM Instance Role | ⭐⭐ |
| Q27 | ElastiCache Redis Cluster Mode | ⭐⭐⭐ |
| Q28 | SQS FIFO MessageGroupId | ⭐⭐ |
| Q29 | X-Ray Cross-Account 설정 | ⭐⭐⭐ |
| Q30 | DynamoDB DAX vs ElastiCache | ⭐⭐ |
| Q31 | CloudWatch Agent + Metric Filter | ⭐⭐⭐ |
| Q32 | S3 Versioning 특징 | ⭐⭐ |
| Q33 | KMS ThrottlingException 해결 | ⭐⭐⭐ |
| Q34 | ElastiCache Lazy Loading + TTL | ⭐⭐ |
| Q35 | Lambda Cross-Account DynamoDB | ⭐⭐⭐ |
Q18. IAM Policy + SQS Policy 동시 적용 시 Permission 평가
문제: 한 사용자가 자신의 account에 적용되는 IAM policy와 Amazon SQS policy를 모두 가지고 있습니다. IAM policy는 example_queue에 대한 ReceiveMessage action 권한을 부여하고, Amazon SQS policy는 동일한 queue에 대한 SendMessage action 권한을 부여합니다. 위의 permission을 고려할 때, 다음 중 올바른 옵션은 무엇입니까? (2개 선택)
- queue에 대한 모든 action의 접근을 거부하는 policy를 추가하면, 해당 policy가 다른 두 policy를 override하여 사용자는 example_queue에 접근할 수 없게 된다
- IAM policy 또는 Amazon SQS policy 중 하나만 사용하여 permission을 부여해야 하며, 둘을 함께 사용할 수 없다
- 사용자가 example_queue에 SendMessage 요청을 보내면, IAM policy가 이 action을 deny한다
- 사용자가 example_queue에 ReceiveMessage 요청을 보낼 수 있으며, IAM policy가 이 action을 allow한다
- queue에 대한 모든 action을 deny하는 IAM policy만 추가하는 것으로는 충분하지 않으며, SQS policy도 명시적으로 모든 action을 deny해야 한다
정답 및 해설
✅ 정답: 1번, 4번
정답 1: 모든 action을 deny하는 policy가 다른 두 policy를 override한다
사용자의 queue 접근 권한을 완전히 제거하려면, queue에 대한 모든 action을 deny하는 policy를 추가하면 됩니다. Explicit deny는 항상 allow를 override하기 때문에, 이 policy가 다른 두 policy를 override합니다. Amazon SQS policy에 사용자의 모든 접근을 deny하는 추가 statement를 넣어도 동일한 효과를 얻을 수 있습니다.
정답 2: 사용자가 ReceiveMessage 요청을 보낼 수 있다
사용자는 IAM policy와 Amazon SQS policy가 모두 적용됩니다. IAM policy가 example_queue에 대한 ReceiveMessage action을 허용하므로, 사용자는 해당 요청을 보낼 수 있습니다.
❌ 오답 해설
SendMessage 요청 시 IAM policy가 deny한다 - 사용자가 example_queue에 SendMessage 요청을 보내면, Amazon SQS policy가 이 action을 allow합니다. IAM policy에는 이 action에 대한 explicit deny가 없으므로, IAM policy는 아무런 영향을 미치지 않습니다. deny가 없는 것은 deny가 아닙니다.
IAM policy 또는 SQS policy 중 하나만 사용해야 한다 - Amazon SQS 리소스에 대한 permission을 부여하는 방법은 두 가지입니다: Amazon SQS policy 시스템과 IAM policy 시스템. 하나만 사용하거나 둘 다 함께 사용할 수 있으며, 대부분의 경우 어느 쪽을 사용하든 동일한 결과를 얻을 수 있습니다.
IAM policy만으로는 충분하지 않으며 SQS policy도 deny해야 한다 - 어느 한쪽의 policy에서든 explicit deny가 있으면 다른 policy에서 정의된 모든 allow action을 override합니다. 양쪽 모두에서 deny할 필요는 없습니다.
AWS Permission 평가 규칙
| 우선순위 | 규칙 | 설명 |
|---|---|---|
| 1 | Explicit Deny | 항상 최우선 (모든 Allow를 override) |
| 2 | Explicit Allow | Deny가 없으면 허용 |
| 3 | Implicit Deny | Allow도 Deny도 없으면 기본적으로 거부 |
IAM policy와 SQS policy는 **합산(union)**되어 평가됩니다. 어느 쪽이든 allow가 있고 explicit deny가 없으면 허용됩니다.
Q19. 기존 CloudWatch Logs에 KMS 암호화 적용
문제: 한 사이버보안 회사가 3개월 전에 생성된 Amazon CloudWatch Logs의 log group에 중요한 log 데이터를 publish하고 있습니다. 회사의 보안 가이드라인을 충족하기 위해 AWS KMS customer master key(CMK)를 사용하여 log 데이터를 encrypt해야 하며, 향후 모든 데이터가 encrypt되어야 합니다. 이 use case를 어떻게 해결할 수 있습니까?
- AWS CLI describe-log-groups command를 사용하고 KMS key ARN을 지정
- AWS CLI associate-kms-key command를 사용하고 KMS key ARN을 지정
- AWS CLI create-log-group command를 사용하고 KMS key ARN을 지정
- CloudWatch Logs console에서 log group의 encrypt 기능을 활성화
정답 및 해설
✅ 정답: AWS CLI associate-kms-key command 사용
CloudWatch Logs의 log group 데이터는 항상 encrypt됩니다. 선택적으로 AWS Key Management Service를 사용하여 이 encryption을 수행할 수 있습니다.
AWS KMS를 사용한 encryption은 log group 수준에서 활성화되며, log group을 생성할 때 또는 이미 존재하는 log group에 CMK를 연결하여 수행합니다. CMK를 log group에 연결하면, 해당 log group에 새로 수집되는 모든 데이터가 CMK를 사용하여 encrypt됩니다.
기존 log group에 CMK를 연결하려면 associate-kms-key command를 사용합니다.
❌ 오답 해설
CloudWatch Logs console에서 encrypt 기능 활성화 - CloudWatch Logs console에는 log group에 대한 encryption을 활성화하는 옵션이 없습니다. AWS CLI를 사용해야 합니다.
AWS CLI describe-log-groups command 사용 - describe-log-groups command는 log group에 이미 CMK가 연결되어 있는지 확인하는 데 사용됩니다. CMK를 연결하는 command가 아닙니다.
AWS CLI create-log-group command 사용 - create-log-group command는 log group을 새로 생성할 때 CMK를 연결하는 데 사용됩니다. 문제에서는 이미 3개월 전에 생성된 기존 log group이므로, 이 command는 적합하지 않습니다.
CloudWatch Logs KMS 관련 CLI command 정리
| Command | 용도 |
|---|---|
| create-log-group | 새 log group 생성 시 CMK 연결 |
| associate-kms-key | 기존 log group에 CMK 연결 |
| describe-log-groups | log group에 CMK가 연결되어 있는지 확인 |
| disassociate-kms-key | log group에서 CMK 연결 해제 |
문제에서 "이미 존재하는" log group → associate-kms-key
Q20. Cross-Account SQS 접근 설정
문제: 두 AWS account 간에 queue에 대한 공유 접근을 위해 Amazon SQS를 구성해야 합니다. AWS account A에 SQS queue가 있고, AWS account B에 이 queue에 대한 접근 권한을 부여해야 합니다. cross-account 접근을 허용하기 위해 어떤 옵션들을 조합해야 합니까? (3개 선택)
- account A administrator가 account B를 role을 assume할 수 있는 principal로 식별하는 trust policy를 role에 attach한다
- account A administrator가 account B를 role을 assume할 수 있는 AWS service principal로 식별하는 trust policy를 role에 attach한다
- account A administrator가 IAM role을 생성하고 permissions policy를 attach한다
- account B administrator가 IAM role을 생성하고 account B를 principal로 하는 trust policy를 role에 attach한다
- account B administrator가 account B의 모든 사용자에게 role을 assume할 수 있는 permission을 delegate한다
- account A administrator가 account A의 모든 사용자에게 role을 assume할 수 있는 permission을 delegate한다
정답 및 해설
✅ 정답: 1번, 3번, 5번
Cross-account permission을 부여하려면, IAM role에 identity-based permissions policy를 attach해야 합니다. account A administrator가 account B에 cross-account permission을 부여하는 과정은 다음과 같습니다:
Step 1) account A administrator가 IAM role을 생성하고, account A의 리소스에 대한 permission을 부여하는 permissions policy를 role에 attach합니다.
Step 2) account A administrator가 account B를 role을 assume할 수 있는 principal로 식별하는 trust policy를 role에 attach합니다.
Step 3) account B administrator가 account B의 모든 사용자에게 role을 assume할 수 있는 permission을 delegate합니다.
이를 통해 account B의 사용자들이 account A의 queue를 생성하거나 접근할 수 있습니다.
❌ 오답 해설
account B administrator가 IAM role을 생성하고 trust policy를 attach한다 - IAM role은 account A administrator가 생성해야 합니다. 리소스가 있는 account(A)에서 role을 만들고 permissions policy를 attach해야 하기 때문입니다.
account A administrator가 account A의 사용자에게 role assume permission을 delegate한다 - 접근 권한이 필요한 것은 account B의 사용자입니다. account A의 사용자에게 delegate하는 것은 이 use case와 관련이 없습니다.
account B를 AWS service principal로 식별하는 trust policy를 attach한다 - AWS service principal은 AWS 서비스(예: ec2.amazonaws.com, lambda.amazonaws.com)에 role assume 권한을 부여할 때 사용합니다. 이 use case는 다른 AWS account에 권한을 부여하는 것이므로, service principal이 아닌 account principal을 사용해야 합니다.
Cross-Account 접근 패턴
리소스 소유 account (A):
- IAM role 생성 + permissions policy attach
- Trust policy에 접근할 account (B)를 principal로 지정
접근하는 account (B): 3. 사용자에게 해당 role을 assume할 수 있는 permission delegate
Principal 구분:
arn:aws:iam::123456789:root→ Account principal (다른 account)ec2.amazonaws.com→ Service principal (AWS 서비스)
Q21. Authorization Failure Message 디코딩
문제: 기술 회사의 매니저로서, 회사의 AWS 인프라에서 작업할 개발자 팀을 새로 고용했습니다. 모든 개발자가 AWS CLI를 사용하여 command를 실행할 때 다음과 같은 exception으로 실패한다고 보고합니다:
You are not authorized to perform this operation. Encoded authorization failure message: 6h34GtpmGjJJUm946eDVBfzWQJk6z5GePbbGDs9Z2T8xZj9EZtEduSnTbmrR7pMqpJrVYJCew2m8YBZQf4HRWEtrpncANrZMsnzk.
다음 중 개발자들이 이 message를 decode하는 데 도움이 되는 action은 무엇입니까?
- AWS STS decode-authorization-message
- AWS Cognito Decoder
- AWS IAM decode-authorization-message
- KMS decode-authorization-message 사용
정답 및 해설
✅ 정답: AWS STS decode-authorization-message
decode-authorization-message를 사용하여 AWS 요청에 대한 응답으로 반환된 encoded message에서 authorization 상태에 대한 추가 정보를 decode할 수 있습니다.
사용자가 요청한 action을 수행할 권한이 없는 경우, 요청은 Client.UnauthorizedOperation 응답(HTTP 403 응답)을 반환합니다.
message가 encode되어 있는 이유는 authorization 상태의 세부 정보가 **해당 작업을 요청한 사용자가 볼 수 없어야 하는 권한 있는 정보(privileged information)**를 포함할 수 있기 때문입니다.
authorization 상태 message를 decode하려면, 사용자에게 IAM policy를 통해 DecodeAuthorizationMessage(sts:DecodeAuthorizationMessage) action을 요청할 수 있는 permission이 부여되어야 합니다.
❌ 오답 해설
AWS IAM decode-authorization-message - IAM 서비스에는 이 command가 존재하지 않습니다. 만들어진 옵션입니다.
KMS decode-authorization-message 사용 - KMS 서비스에는 이 command가 존재하지 않습니다. 만들어진 옵션입니다.
AWS Cognito Decoder - Cognito 서비스에는 이 command가 존재하지 않습니다. 만들어진 옵션입니다.
- Encoded authorization failure message →
sts:DecodeAuthorizationMessage - 이 기능은 **AWS STS(Security Token Service)**에 속합니다
- decode를 수행하려면 해당 사용자에게
sts:DecodeAuthorizationMessagepermission이 별도로 부여되어야 합니다
Q22. S3 암호화와 자동 Key Rotation
문제: 개발팀이 S3에 민감한 고객 데이터를 저장하고 있으며, at-rest encryption이 필요합니다. encryption key는 최소 연 1회 rotate되어야 합니다. 이 요구사항을 구현하는 가장 쉬운 방법은 무엇입니까?
- 연간 자동 key rotation이 포함된 SSE-C 사용
- 자동 key rotation이 포함된 AWS KMS 사용
- Amazon S3로 보내기 전에 데이터를 encrypt
- custom key를 AWS KMS로 import하고 Lambda function을 사용하여 연간 key rotation을 자동화
정답 및 해설
✅ 정답: 자동 key rotation이 포함된 AWS KMS 사용
Server-side encryption은 데이터를 수신하는 application 또는 서비스가 목적지에서 데이터를 encrypt하는 것입니다. Amazon S3는 데이터를 데이터 센터의 디스크에 쓸 때 object 수준에서 encrypt하고, 접근할 때 decrypt합니다.
encryption key 관리 방식에 따라 세 가지 옵션이 있습니다: SSE-S3, SSE-KMS, SSE-C.
SSE-KMS를 사용할 때, 기본 AWS managed CMK를 사용하거나 이미 생성한 customer managed CMK를 지정할 수 있습니다. customer managed CMK를 지정하지 않으면, SSE-KMS로 encrypt된 object를 처음 bucket에 추가할 때 Amazon S3가 자동으로 AWS managed CMK를 생성합니다.
AWS KMS HSM 내에서 생성된 key에 대해 매년 자동으로 CMK를 rotate하도록 선택할 수 있습니다. 이것이 가장 쉬운 구현 방법입니다.
❌ 오답 해설
Amazon S3로 보내기 전에 데이터를 encrypt - 데이터를 S3로 보내기 전에 encrypt하는 것은 Client-Side encryption입니다. key 생성, 유지보수, rotation 프로세스를 직접 관리해야 하므로, "가장 쉬운 방법"이 아닙니다.
custom key를 KMS로 import하고 Lambda로 rotation 자동화 - custom key를 import하면, key 관리 인프라에서 import된 key의 복사본을 직접 유지하여 언제든 재import할 수 있어야 합니다. 또한 imported key에 대해서는 자동 key rotation이 지원되지 않습니다. Lambda function을 사용한 rotation은 가능한 솔루션이지만, 현재 use case에 최적의 방법은 아닙니다.
연간 자동 key rotation이 포함된 SSE-C 사용 - SSE-C에서는 사용자가 encryption key를 관리하고 Amazon S3가 encryption/decryption을 수행합니다. key는 Amazon S3 어디에도 저장되지 않습니다. SSE-C에는 자동 key rotation 기능이 없습니다.
S3 Encryption 옵션 비교
| 옵션 | Key 관리 | 자동 Key Rotation |
|---|---|---|
| SSE-S3 | AWS 관리 | ✅ (자동) |
| SSE-KMS | AWS KMS 관리 | ✅ (연간, 활성화 필요) |
| SSE-C | 고객 관리 | ❌ (직접 해야 함) |
| Client-Side | 고객 관리 | ❌ (직접 해야 함) |
"가장 쉬운" + "자동 rotation" → SSE-KMS with automatic key rotation
문제에서 **"rotate"**가 나오면 무엇을 rotate하는지 잘 확인해야 합니다!
| 서비스 | Rotation 대상 | 용도 |
|---|---|---|
| Secrets Manager | Credentials (password, API key 등) | 인증 정보 관리 |
| KMS | Encryption key (CMK) | 데이터 암호화 key 관리 |
- database credentials를 자동 rotate → Secrets Manager
- encryption key를 연간 rotate → KMS automatic key rotation
Q23. EC2 Log 파일을 Kinesis Data Streams로 전송
문제: 한 회사에 보안 및 compliance 목적으로 분석해야 하는 다양한 log 파일을 생성하는 여러 Linux 기반 EC2 instance가 있습니다. 회사는 Kinesis Data Streams(KDS)를 사용하여 이 log 데이터를 분석하려고 합니다. EC2 instance에서 KDS로 log 데이터를 보내는 가장 최적의 방법은 무엇입니까?
- Kinesis Producer Library(KPL)를 사용하여 각 EC2 instance에서 데이터를 수집
- 각 instance에 AWS SDK를 설치하고 필요한 파일을 Kinesis Data Streams로 전송하도록 구성
- 각 instance에서 cron job을 실행하여 log 데이터를 수집하고 Kinesis Data Streams로 전송
- 각 instance에 Kinesis Agent를 설치하고 구성
정답 및 해설
✅ 정답: 각 instance에 Kinesis Agent를 설치하고 구성
Kinesis Agent는 Kinesis Data Streams로 데이터를 수집하고 전송하는 쉬운 방법을 제공하는 standalone Java software application입니다.
Agent의 주요 기능:
- 파일 세트를 지속적으로 모니터링하고 새 데이터를 stream으로 전송
- file rotation, checkpointing, 실패 시 retry를 자동 처리
- streaming 프로세스를 모니터링하고 troubleshoot할 수 있도록 Amazon CloudWatch metrics를 emit
web server, log server, database server와 같은 Linux 기반 서버 환경에 agent를 설치할 수 있습니다. 설치 후 모니터링할 파일과 데이터 stream을 지정하여 구성하면, agent가 파일에서 데이터를 안정적으로 수집하고 stream으로 전송합니다.
❌ 오답 해설
cron job을 실행하여 log 데이터를 수집하고 전송 - 가능한 솔루션이지만 최적은 아닙니다. custom code를 작성하고 파일/log 변경 사항을 추적하며, 실패 시 retry 등을 직접 처리해야 합니다. Kinesis Agent는 이 모든 요구사항을 처리하도록 설계되어 있습니다.
AWS SDK를 설치하고 구성 - AWS SDK에서 제공하는 Kinesis Data Streams API를 사용하면 stream 생성, resharding, record put/get 등을 관리할 수 있습니다. 하지만 log 파일의 새로운 데이터를 처리하고 stream으로 전송하는 custom code를 직접 작성해야 합니다.
Kinesis Producer Library(KPL) 사용 - KPL은 Kinesis data stream에 쓰기 위한 라이브러리입니다. producer application code와 Kinesis Data Streams API 사이의 중개자 역할을 합니다. 하지만 파일을 지속적으로 모니터링하고 새 데이터를 stream으로 전송하도록 설계된 Kinesis Agent에 비해 최적이 아닙니다.
EC2 log → Kinesis Data Streams 전송 방법 비교
| 방법 | 최적성 | 특징 |
|---|---|---|
| Kinesis Agent | ✅ 가장 최적 | 파일 모니터링, retry, checkpointing 자동 |
| KPL | ⚠️ 가능하지만 차선 | application 코드에서 데이터 전송에 적합 |
| AWS SDK | ⚠️ 가능하지만 차선 | custom code 작성 필요 |
| Cron job | ❌ 비최적 | 모든 것을 직접 구현해야 함 |
"EC2 log 파일 → Kinesis" 패턴 → Kinesis Agent가 정답
Q24. S3 SSE-KMS Encryption Header 값
문제: 개발팀이 AWS SDK for Java를 사용하여 SSE-KMS encryption 메커니즘을 사용하여 여러 Amazon S3 bucket에 파일을 업로드하는 web application을 개발하고 있습니다. 개발자들이 HTTP를 통해 object를 push하려고 할 때 permission error를 받고 있다고 보고합니다. 요청에 어떤 header를 포함해야 합니까?
'x-amz-server-side-encryption': 'AES256''x-amz-server-side-encryption': 'SSE-S3''x-amz-server-side-encryption': 'SSE-KMS''x-amz-server-side-encryption': 'aws:kms'
정답 및 해설
✅ 정답: 'x-amz-server-side-encryption': 'aws:kms'
Server-side encryption은 데이터를 수신하는 application 또는 서비스가 목적지에서 데이터를 encrypt하는 것입니다.
AWS KMS는 cloud에 맞게 확장된 key 관리 시스템을 제공하는 서비스입니다. Amazon S3는 AWS KMS customer master key(CMK)를 사용하여 S3 object를 encrypt합니다. AWS KMS는 object 데이터만 encrypt하며, object metadata는 encrypt되지 않습니다.
요청에 x-amz-server-side-encryption header가 포함되지 않으면 **요청이 거부(denied)**됩니다.
❌ 오답 해설
'x-amz-server-side-encryption': 'SSE-S3' - 유효하지 않은 header 값입니다. SSE-S3를 사용할 경우 올바른 값은 'AES256'입니다.
'x-amz-server-side-encryption': 'SSE-KMS' - 유효하지 않은 header 값입니다. SSE-KMS는 encryption 옵션의 이름이지, header에 사용하는 실제 값이 아닙니다.
'x-amz-server-side-encryption': 'AES256' - 이 값은 SSE-S3 server-side encryption을 사용할 때의 올바른 header 값입니다. SSE-KMS가 아닌 SSE-S3에 해당하므로 이 use case에는 맞지 않습니다.
S3 Server-Side Encryption Header 값 정리
| Encryption 방식 | Header 값 |
|---|---|
| SSE-S3 | 'x-amz-server-side-encryption': 'AES256' |
| SSE-KMS | 'x-amz-server-side-encryption': 'aws:kms' |
| SSE-C | 'x-amz-server-side-encryption-customer-algorithm' 등 |
시험에서 자주 나오는 함정: SSE-KMS라는 이름이지만, header 값은 **'aws:kms'**입니다. 'SSE-KMS'가 아닙니다!
Q25. IAM Policy Deny/Allow 평가
문제: 다음 IAM policy를 살펴보세요:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::EXAMPLE-BUCKET/private*"
},
{
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject"],
"Resource": "arn:aws:s3:::EXAMPLE-BUCKET/*"
}
]
}이 policy에 따라 올바른 설명은 무엇입니까?
- 이 policy는 EXAMPLE-BUCKET bucket의 모든 object에 대해 PutObject 및 GetObject 접근을 제공하며, private로 시작하는 object에 대해 모든 s3 action 접근도 제공한다
- 이 policy는 private로 시작하는 object를 제외하고 EXAMPLE-BUCKET bucket의 모든 object에 대해 PutObject 및 GetObject 접근을 제공한다
- 이 policy는 EXAMPLE-BUCKET/private bucket을 제외한 모든 bucket에 대해 PutObject 및 GetObject 접근을 제공한다
- 이 policy는 EXAMPLE-BUCKET/private bucket을 제외한 모든 bucket에 대해 PutObject 및 GetObject 접근을 deny한다
정답 및 해설
✅ 정답: private로 시작하는 object를 제외하고 PutObject 및 GetObject 접근 제공
첫 번째 statement: EXAMPLE-BUCKET bucket에서 private로 시작하는 모든 object에 대한 모든 S3 action을 Deny합니다.
두 번째 statement: EXAMPLE-BUCKET bucket의 모든 object에 대해 PutObject 및 GetObject를 Allow합니다.
최종 효과: Explicit Deny가 항상 Allow를 override하므로, private로 시작하는 object를 제외하고 EXAMPLE-BUCKET bucket의 모든 object에 대해 PutObject 및 GetObject 접근이 허용됩니다.
❌ 오답 해설
모든 bucket에 대해 접근을 제공한다 - 이 policy의 Resource는 arn:aws:s3:::EXAMPLE-BUCKET/*로, EXAMPLE-BUCKET bucket에만 적용됩니다. 모든 bucket에 대한 접근이 아닙니다.
private로 시작하는 object에 대해 모든 s3 action 접근도 제공한다 - 첫 번째 statement가 private*에 대해 Deny하므로 정반대입니다. Explicit Deny는 어떤 Allow도 override합니다.
모든 bucket에 대해 접근을 deny한다 - policy의 구조와 완전히 반대되는 설명입니다.
IAM Policy 평가 핵심 원칙
- Explicit Deny는 항상 최우선 → 어떤 Allow도 override
- Resource의
private*에서*는 wildcard → private로 시작하는 모든 object에 적용 - Policy는 특정 bucket에만 적용 (EXAMPLE-BUCKET), 모든 bucket이 아님
이 패턴은 **"특정 prefix의 object를 보호하면서 나머지는 허용"**하는 일반적인 S3 접근 제어 방식입니다.
Q26. EC2에서 AWS 서비스 접근을 위한 Credentials 관리
문제: EC2에서 호스팅되는 web application이 PHP용 SDK를 사용하여 Amazon S3에 저장된 object에 대해 GET 및 PUT 요청을 수행합니다. 보안팀이 application의 취약점에 대한 최종 검토를 완료한 후, application이 AWS 서비스에 접근하기 위해 hardcoded된 IAM access key와 secret access key를 사용하고 있음을 발견했습니다. 가능하면 temporary credentials를 사용하는 더 안전한 설정을 권장합니다. 이 use case를 해결하기 위해 어떤 옵션을 사용할 수 있습니까?
- IAM Instance Role 사용
- Environment variables 사용
- SSM Parameter Store 사용
- Application code에 credentials를 hardcode
정답 및 해설
✅ 정답: IAM Instance Role 사용
Instance profile은 EC2 instance가 시작될 때 role 정보를 전달하는 데 사용할 수 있는 IAM role의 컨테이너입니다.
AWS SDK는 IAM instance role 덕분에 EC2 metadata service를 통해 temporary credentials를 자동으로 획득합니다. 이것은 EC2 instance에 어떤 종류의 application이든 배포할 때 가장 안전하고 일반적인 설정입니다.
❌ 오답 해설
Environment variables 사용 - EC2 instance에서 AWS CLI를 구성할 때 AWS_ACCESS_KEY_ID와 AWS_SECRET_ACCESS_KEY environment variable을 설정하는 방법입니다. 단일 instance에서는 나쁘지 않을 수 있지만, 여러 EC2 instance를 실행하기 시작하면 각 instance에서 credentials를 변경해야 할 수 있어 좋은 방법이 아닙니다.
Application code에 credentials를 hardcode - 동작은 하겠지만, 보안 관점에서 좋은 방법이 아닙니다. 이것이 바로 현재 문제의 원인입니다.
SSM Parameter Store 사용 - Parameter Store에 password 등의 데이터를 저장할 수 있습니다. 하지만 문제는 Parameter Store에 접근하려면 SDK가 필요하고, credentials 없이는 SDK를 사용할 수 없다는 것입니다. Parameter Store는 이미 AWS에 인증된 상태에서 database connection string이나 다른 secret을 저장하는 용도로 사용해야 합니다.
EC2에서 AWS 서비스 접근 시 credentials 관리 우선순위
| 방법 | 보안 수준 | Temporary Credentials |
|---|---|---|
| IAM Instance Role | ✅ 가장 안전 | ✅ 자동 발급/갱신 |
| Environment vars | ⚠️ 보통 | ❌ 고정 credentials |
| SSM Parameter Store | ⚠️ 인증 필요 | ❌ 먼저 인증이 필요 |
| Hardcoded | ❌ 가장 위험 | ❌ 고정 credentials |
EC2에서 AWS 서비스 접근 = 항상 IAM Instance Role을 먼저 떠올리세요!
Q27. ElastiCache for Redis Cluster Mode
문제: 개발팀이 관계형 database의 in-memory caching 솔루션으로 Amazon ElastiCache for Redis를 고려하고 있습니다. ElastiCache를 구성할 때 올바른 옵션은 무엇입니까? (2개 선택)
- Redis cluster mode enabled에서는 asynchronous replication을 사용하고, cluster mode disabled에서는 synchronous로 수행된다
- replica node를 추가하여 Redis의 write capacity를 확장할 수 있다
- Redis cluster mode enabled를 사용할 때, replica node를 수동으로 primary로 promote할 수 없다
- Redis cluster의 모든 node는 동일한 region에 있어야 한다
- replica가 없고 node가 실패하면, Redis cluster mode enabled를 사용할 때 데이터 손실이 발생하지 않는다
정답 및 해설
✅ 정답: 3번, 4번
정답 1: Redis cluster의 모든 node는 동일한 region에 있어야 한다
Redis cluster의 모든 node(cluster mode enabled 또는 cluster mode disabled 모두)는 동일한 region에 존재해야 합니다.
정답 2: cluster mode enabled에서 replica node를 수동으로 primary로 promote할 수 없다
Redis cluster mode enabled를 사용할 때 다음과 같은 제한사항이 있습니다:
- Replica node를 수동으로 primary로 promote할 수 없다
- Multi-AZ가 필수이다
- Cluster의 구조, node type, node 수는 backup에서 복원해야만 변경할 수 있다
❌ 오답 해설
cluster mode enabled는 asynchronous, disabled는 synchronous replication이다 - 잘못된 설명입니다. read replica를 cluster에 추가하면, primary의 모든 데이터가 새 node에 복사됩니다. 그 이후부터 변경 사항이 모든 read replica에 asynchronous로 전파됩니다. 이는 cluster mode enabled와 disabled 모두 동일합니다.
replica가 없고 node가 실패하면 데이터 손실이 없다 - 잘못된 설명입니다. replica가 없고 node가 실패하면:
- Cluster mode enabled: 해당 node의 shard에 있는 모든 데이터가 손실
- Cluster mode disabled: 전체 데이터가 손실
replica node를 추가하여 write capacity를 확장할 수 있다 - replica node를 추가하면 read capacity만 증가합니다. write capacity는 read replica로 향상되지 않습니다.
ElastiCache for Redis 핵심 정리
| 항목 | Cluster Mode Disabled | Cluster Mode Enabled |
|---|---|---|
| Shard 수 | 1개 | 여러 개 |
| Replication | Asynchronous | Asynchronous |
| 수동 Promote | ✅ 가능 | ❌ 불가능 |
| Multi-AZ | 선택 | 필수 |
| Write 확장 | ❌ | ✅ (shard 추가로) |
| Read 확장 | Replica 추가 | Replica 추가 |
Write capacity 확장 → replica 추가가 아닌 shard(partition) 추가로만 가능합니다!
Q28. SQS FIFO Queue 메시지 순서 보장
문제: AWS SQS FIFO queue를 사용하여 user_id 기준으로 message의 순서를 보장하고 있습니다. 개발자로서, 순서를 보장하기 위해 user_id 값을 어떤 message parameter에 설정해야 합니까?
- MessageOrderId
- MessageDeduplicationId
- MessageGroupId
- MessageHash
정답 및 해설
✅ 정답: MessageGroupId
AWS FIFO queue는 작업 및 이벤트의 순서가 보장되어야 할 때 application 간 메시징을 강화하도록 설계되었습니다.
MessageGroupId는 message가 특정 message group에 속한다는 것을 지정하는 tag입니다. 동일한 message group에 속하는 message는 항상 해당 message group에 대해 엄격한 순서로 하나씩 처리됩니다. 그러나 서로 다른 message group에 속하는 message는 순서 없이 처리될 수 있습니다.
따라서 user_id를 MessageGroupId로 설정하면 각 사용자별로 message 순서가 보장됩니다.
❌ 오답 해설
MessageDeduplicationId - message deduplication ID는 전송된 message의 **중복 제거(deduplication)**에 사용되는 token입니다. 특정 message deduplication ID로 message가 성공적으로 전송되면, 동일한 deduplication ID로 전송된 message는 수락되지만 5분 deduplication interval 동안 전달되지 않습니다. 순서 보장이 아닌 중복 방지 용도입니다.
MessageOrderId / MessageHash - 둘 다 실제로 존재하지 않는 만들어진 옵션입니다.
SQS FIFO Queue 핵심 parameter
| Parameter | 용도 |
|---|---|
| MessageGroupId | 메시지 순서 보장 (같은 group 내에서 FIFO) |
| MessageDeduplicationId | 메시지 중복 제거 (5분 interval) |
순서(ordering) → MessageGroupId / 중복 방지(deduplication) → MessageDeduplicationId
Q29. X-Ray Cross-Account Trace 설정
문제: 회사가 팀별로 각자의 환경을 갖도록 여러 AWS account를 운영하고 있습니다. 이러한 account에 배포된 서비스들이 서로 상호작용하며, 이제 EC2 instance와 여러 AWS account에 배포된 모든 application에 걸쳐 X-Ray trace를 구현해야 하는 요구사항이 있습니다. 모든 trace를 볼 수 있는 통합 account를 갖고 싶습니다. 이를 구현하기 위해 X-Ray daemon 설정에서 무엇을 해야 합니까? (2개 선택)
- X-Ray console에서 Cross Account collection 활성화
- X-Ray daemon이 IAM instance role을 사용하도록 구성
- target 통합 account에 user를 생성하고 access key와 secret key를 생성
- target 통합 account에 role을 생성하고 각 sub-account의 role이 해당 role을 assume할 수 있도록 허용
- X-Ray daemon이 access key와 secret key를 사용하도록 구성
정답 및 해설
✅ 정답: 2번, 4번
정답 1: X-Ray daemon이 IAM instance role을 사용하도록 구성
정답 2: target 통합 account에 role을 생성하고 각 sub-account의 role이 assume할 수 있도록 허용
AWS X-Ray는 microservices 아키텍처를 사용하여 구축된 분산 application을 분석하고 debug하는 데 도움을 줍니다.
X-Ray agent는 실행 중인 account와 다른 account에 데이터를 publish하기 위해 role을 assume할 수 있습니다. 이를 통해 application의 다양한 구성 요소에서 중앙 account로 데이터를 publish할 수 있습니다.
즉, 각 sub-account의 EC2 instance에서 IAM instance role을 사용하고, 통합 account에 생성된 role을 assume하여 trace 데이터를 중앙에서 수집하는 구조입니다.
❌ 오답 해설
통합 account에 user를 생성하고 access/secret key를 생성 + X-Ray daemon이 access/secret key를 사용하도록 구성 - 이 두 옵션을 조합하면 동작은 하지만, 보안 관점에서 best practice가 아닙니다. IAM instance role과 cross-account role assumption을 사용하는 것이 temporary credentials를 활용하므로 훨씬 안전합니다.
X-Ray console에서 Cross Account collection 활성화 - 실제로 존재하지 않는 만들어진 옵션입니다.
X-Ray Cross-Account 설정 패턴
Sub-Account (각 팀):
- EC2 instance에 IAM instance role 부여
- X-Ray daemon이 해당 role을 사용하도록 구성
Target 통합 Account (중앙): 3. Role을 생성하고 각 sub-account의 role이 assume할 수 있도록 trust policy 설정
핵심 원칙: access key/secret key 대신 항상 IAM role을 사용하는 것이 AWS 보안 best practice입니다.
Q30. DynamoDB Hot Partition 해결
문제: 인기 있는 모바일 앱이 4개의 partition에 균등하게 분배된 read-capacity unit(RCU)으로 provisioned된 AWS DynamoDB 테이블에서 데이터를 조회합니다. 해당 partition 중 하나가 다른 partition보다 더 많은 트래픽을 받고 있어 hot partition 문제가 발생하고 있습니다. 최소한의 노력으로 AWS DynamoDB 테이블의 read 트래픽을 줄일 수 있는 기술은 무엇입니까?
- More partitions
- DynamoDB DAX
- ElastiCache
- DynamoDB Streams
정답 및 해설
✅ 정답: DynamoDB DAX
Amazon DynamoDB Accelerator(DAX)는 DynamoDB를 위한 fully managed, 고가용성 in-memory cache입니다.
초당 수백만 건의 요청에서도 millisecond에서 microsecond까지 최대 10배의 성능 향상을 제공합니다.
DAX는 DynamoDB와 완벽하게 호환되므로, application 코드를 최소한으로 변경하여 적용할 수 있습니다.
❌ 오답 해설
DynamoDB Streams - stream record는 DynamoDB 테이블의 단일 item에 대한 데이터 변경(modification) 정보를 포함합니다. read 트래픽을 줄이는 용도가 아니므로 이 use case에 적합하지 않습니다.
ElastiCache - ElastiCache는 어떤 결과든 cache할 수 있지만, 메인 데이터 저장소에 query하기 전에 cache를 먼저 확인하도록 코드를 수정해야 합니다. 문제에서 최소한의 노력을 요구하므로 적합하지 않습니다.
More partitions - DynamoDB는 partition을 자동으로 관리합니다. 사용자가 수동으로 partition을 추가하는 것은 해당되지 않습니다.
DynamoDB 캐싱 솔루션 비교
| 항목 | DynamoDB DAX | ElastiCache |
|---|---|---|
| 코드 변경 | ✅ 최소 (API 호환) | ❌ 코드 수정 필요 |
| DynamoDB 통합 | ✅ 네이티브 통합 | ❌ 수동 구현 |
| 관리 | Fully managed | Fully managed |
| 용도 | DynamoDB 전용 캐시 | 범용 캐시 |
"DynamoDB + 캐싱 + 최소 노력" → 항상 DAX가 정답입니다!
Q31. CloudWatch Agent로 Custom Metric 모니터링
문제: 비즈니스 크리티컬 application이 Amazon EC2 instance에서 호스팅되고 있으며, 최신 업데이트가 테스트 단계에 있습니다. 비즈니스에서 application의 평균 response time을 추적하고, 특정 threshold를 초과하면 매니저에게 notification을 보내는 솔루션을 요청했습니다. 다음 중 비즈니스 요구사항을 충족하기 위해 조합해야 하는 옵션은 무엇입니까? (2개 선택)
- response time metric의 평균이 threshold를 초과하면 Amazon SNS notification을 보내는 CloudWatch alarm 생성
- application이 EC2 instance의 log 파일에 response time을 기록하도록 구성. EC2 instance에 Amazon CloudWatch agent를 설치 및 구성하여 application log를 CloudWatch Logs로 stream. log 파일에서 response time에 대한 metric filter 생성
- application이 instance의 log 파일에 response time을 기록하도록 구성. EC2 instance에 Amazon Inspector agent를 설치 및 구성하여 log를 읽고 response time을 Amazon EventBridge로 전송
- EC2 instance에 AWS Systems Manager Agent(SSM Agent)를 설치 및 구성하여 response time을 모니터링하고 데이터를 Amazon CloudWatch에 custom metric으로 전송
- response time metric의 평균이 threshold를 초과하면 Amazon SNS notification을 보내는 EventBridge custom rule 구성
정답 및 해설
✅ 정답: 1번, 2번
정답 1: CloudWatch agent로 log 수집 + metric filter 생성
Amazon EC2 instance 및 on-premises server에서 CloudWatch agent를 사용하여 metric과 log를 수집할 수 있습니다.
application이 response time을 log 파일에 기록하고, CloudWatch agent가 이를 CloudWatch Logs로 stream한 후, metric filter를 생성하여 response time을 metric으로 변환합니다.
정답 2: CloudWatch alarm으로 SNS notification 전송
Metric alarm은 단일 CloudWatch metric을 모니터링합니다. metric 값이 threshold를 초과하면 Amazon SNS topic에 notification을 전송하는 action을 수행할 수 있습니다.
❌ 오답 해설
Amazon Inspector agent를 설치하여 log를 읽고 EventBridge로 전송 - Amazon Inspector는 EC2, Lambda function, container workload에서 소프트웨어 취약점과 의도하지 않은 네트워크 노출을 스캔하는 서비스입니다. log 수집 agent가 아닙니다.
EventBridge custom rule로 SNS notification 전송 - CloudWatch alarm에서 직접 SNS notification을 보내는 것이 더 직관적입니다.
SSM Agent를 설치하여 response time을 모니터링 - SSM Agent는 Systems Manager가 리소스를 업데이트, 관리, 구성할 수 있게 하는 소프트웨어입니다. log 데이터를 수집하고 CloudWatch Logs로 push할 수 없습니다.
Custom Application Metric 모니터링 패턴
Application → Log 파일 → CloudWatch Agent → CloudWatch Logs
→ Metric Filter → CloudWatch Alarm → SNS Notification
| 도구 | 역할 |
|---|---|
| CloudWatch Agent | Log 수집 및 CloudWatch Logs로 전송 |
| Metric Filter | Log에서 특정 값을 추출하여 metric으로 변환 |
| CloudWatch Alarm | Metric 모니터링 및 threshold 초과 시 action |
| SNS | Notification 전송 |
Q32. S3 Versioning 특징
문제: 조직에 고객 이름으로 레이블이 지정된 폴더가 포함된 단일 Amazon S3 bucket이 있습니다. 여러 administrator가 S3 bucket에 대한 IAM 접근 권한을 가지고 있으며, 의도하지 않은 사용자 action으로부터 쉽게 복구하기 위해 versioning이 활성화되어 있습니다. 이 시나리오에서 versioning에 대해 올바르지 않은 설명은 무엇입니까?
- 파일 삭제는 복구 가능한 작업이다
- Versioning은 특정 폴더에 대해서만 활성화할 수 있다
- 파일을 덮어쓰면 version이 증가한다
- Versioning 활성화 전에 unversioned였던 파일은 'null' version을 갖는다
정답 및 해설
✅ 정답: Versioning은 특정 폴더에 대해서만 활성화할 수 있다 (올바르지 않음)
Versioning 상태는 해당 bucket의 모든 object에 적용됩니다. 일부 object에만 적용하는 것은 불가능합니다.
bucket에 대해 처음 versioning을 활성화하면, 그 이후부터 bucket의 object는 항상 versioned 상태가 되며 고유한 version ID가 부여됩니다.
❌ 나머지 옵션 (모두 올바른 설명)
파일을 덮어쓰면 version이 증가한다 - 올바른 설명입니다. object(파일)를 overwrite하면 bucket에 새로운 object version이 생성됩니다.
파일 삭제는 복구 가능한 작업이다 - 올바른 설명입니다. object(파일)를 삭제하면 Amazon S3가 delete marker를 삽입하고, 이전 version을 복원할 수 있습니다.
Versioning 활성화 전 파일은 'null' version을 갖는다 - 올바른 설명입니다. Versioning 상태를 설정하기 전에 bucket에 저장된 object는 version ID가 null입니다.
S3 Versioning 핵심 정리
| 항목 | 동작 |
|---|---|
| 적용 범위 | Bucket 전체 (폴더/object 단위 불가) |
| 파일 덮어쓰기 | 새 version 생성 (이전 version 유지) |
| 파일 삭제 | Delete marker 삽입 (복구 가능) |
| 기존 파일 | Version ID = null |
| 비활성화 | 완전히 끌 수 없고, Suspended 상태만 가능 |
Q33. KMS ThrottlingException 해결
문제: e-commerce application이 주문 transaction을 대량으로 accounting application에 게시하여 추가 처리를 수행합니다. compliance 규정 변경으로 인해 모든 transaction이 accounting application에 게시되기 전에 AWS KMS key로 encrypt되고 있습니다. 이 변경 이후, 테스터들이 application에서 ThrottlingException error를 받고 있다는 티켓을 제기했습니다. 이 문제를 가장 최적으로 해결하기 위해 개발자가 취해야 하는 조치는 무엇입니까? (2개 선택)
- 요청 속도를 줄이고 backoff 및 retry 로직 사용을 고려
- AWS Encryption SDK encryption library의 data key caching 기능 사용
- Amazon CloudWatch Logs Insights에서 query를 작성하여 API 요청 사용량을 추적하고 AWS Support case를 제출하여 quota 증가 요청
- AWS KMS가 생성한 AWS CloudTrail event를 Amazon CloudWatch Logs로 전송
- SSE-KMS용 bucket-level key를 사용하여 AWS KMS에 대한 요청 트래픽을 줄여 ThrottlingException error 방지
정답 및 해설
✅ 정답: 1번, 2번
정답 1: 요청 속도를 줄이고 backoff 및 retry 로직 사용
각 AWS SDK는 자동 retry 로직을 구현합니다. 단순 retry 외에도 각 AWS SDK는 더 나은 flow control을 위해 exponential backoff algorithm을 구현합니다.
exponential backoff의 핵심은 연속적인 error 응답에 대해 점진적으로 더 긴 대기 시간을 사용하는 것입니다.
정답 2: AWS Encryption SDK의 data key caching 기능 사용
Data key caching은 data key와 관련 cryptographic material을 cache에 저장합니다. 데이터를 encrypt 또는 decrypt할 때, AWS Encryption SDK는 cache에서 일치하는 data key를 먼저 찾습니다. 일치하는 key를 찾으면 새로운 key를 생성하는 대신 cached data key를 사용합니다.
Data key caching은 성능을 향상시키고, 비용을 절감하며, application이 확장될 때 service limit 내에 유지하는 데 도움이 됩니다.
❌ 오답 해설
AWS CloudTrail event를 CloudWatch Logs로 전송 - API 사용량을 추적하는 것은 가능하지만, ThrottlingException error를 해결하는 최적의 방법은 아닙니다.
CloudWatch Logs Insights로 API 사용량 추적 후 quota 증가 요청 - 현재는 AWS Service Quotas console에서 직접 확인할 수 있어, 이 방법은 비효율적입니다.
SSE-KMS용 bucket-level key 사용 - 이 use case에서 Amazon S3 bucket은 언급되지 않았으므로 관련이 없습니다.
KMS ThrottlingException 해결 전략
| 방법 | 효과 |
|---|---|
| Exponential backoff + retry | 요청 속도 조절로 throttling 완화 |
| Data key caching | KMS API 호출 횟수 자체를 감소 |
| Quota 증가 요청 | 가능하지만 최적의 방법은 아님 |
핵심: ThrottlingException = 너무 많은 API 호출 → 호출 횟수를 줄이거나(caching), 호출 속도를 조절(backoff)하는 것이 최적의 해결책
Q34. ElastiCache Caching 전략 선택
문제: 사용자들이 서로 follow할 수 있는 web application을 만들고 있습니다. 일부 사용자는 다른 사용자보다 더 인기가 많아 데이터가 매우 자주 요청됩니다. 현재 사용자 데이터는 RDS에 있으며, 읽기 성능을 향상시키기 위해 ElastiCache를 caching layer로 사용하라는 권장을 받았습니다. 전체 사용자 dataset을 ElastiCache에 넣으면 엄청난 비용이 발생하므로, 가장 자주 요청되는 사용자 profile만 cache하려고 합니다. 트래픽이 높은 웹사이트이므로 잠시 동안 stale 데이터가 있는 것은 허용되지만, stale 데이터는 1분 미만이어야 합니다. 어떤 caching 전략을 추천하시겠습니까?
- Write Through 전략 + TTL 사용
- Write Through 전략 + TTL 미사용
- Lazy Loading 전략 + TTL 사용
- Lazy Loading 전략 + TTL 미사용
정답 및 해설
✅ 정답: Lazy Loading 전략 + TTL 사용
Lazy Loading은 필요할 때만 데이터를 cache에 로드하는 caching 전략입니다.
application이 데이터를 요청할 때마다 먼저 ElastiCache cache에 요청합니다. 데이터가 cache에 존재하고 유효하면 ElastiCache가 데이터를 반환합니다. 데이터가 cache에 없거나 만료되었으면 application이 data store에서 데이터를 요청합니다.
이 경우, 사용자가 활발하게 요청하는 데이터만 ElastiCache에 cache되고, TTL 덕분에 1분 후 데이터를 만료시켜 데이터 staleness를 제한할 수 있습니다.
❌ 오답 해설
Lazy Loading 전략 + TTL 미사용 - 읽기 요구사항에는 부합하지만, stale 데이터를 만료시키는 데 도움이 되지 않습니다. 1분 미만의 staleness 요구사항을 충족하려면 TTL이 필요합니다.
Write Through 전략 + TTL 사용 / TTL 미사용 - Write Through 전략의 문제점은 데이터가 쓰여질 때마다 cache에도 기록된다는 것입니다. 이렇게 하면 불필요한 데이터로 cache가 가득 차게 됩니다. 문제에서 언급했듯이 전체 dataset을 cache에 넣을 공간이 충분하지 않으므로, Write Through 전략은 사용할 수 없습니다.
Caching 전략 비교
| 전략 | 동작 | 장점 | 단점 |
|---|---|---|---|
| Lazy Loading | 요청 시에만 cache에 로드 | 공간 효율적 | Cache miss 시 latency |
| Write Through | 쓰기 시 항상 cache에도 기록 | 항상 최신 데이터 | 공간 낭비 |
선택 기준:
- 공간 제한 + 자주 요청되는 데이터만 cache → Lazy Loading
- Stale 데이터 허용 기간 제한 → TTL 추가
- 항상 최신 데이터 필요 → Write Through
Q35. Lambda Cross-Account DynamoDB 접근
문제: 소매 조직의 개발팀이 AWS Account A의 Lambda function이 다른 AWS Account B의 DynamoDB 테이블에 접근할 수 있도록 허용하려고 합니다. 이 use case에 어떤 솔루션을 추천하시겠습니까?
- AWS Account B의 DynamoDB 테이블에 resource policy를 추가하여 Account A의 Lambda function에 접근 권한 부여
- Account B에 DynamoDB 접근 권한이 있는 IAM role을 생성. Account A의 execution role의 trust policy를 수정하여 Lambda의 execution role이 Account B의 IAM role을 assume할 수 있도록 허용. Lambda function 코드에 AssumeRole API call 추가
- Account B에 DynamoDB 접근 권한이 있는 IAM role을 생성. Account B의 role의 trust policy를 수정하여 Lambda의 execution role이 이 role을 assume할 수 있도록 허용. Lambda function 코드에 AssumeRole API call 추가
- AWS Account B에 Lambda function의 clone을 생성하여 같은 account의 DynamoDB 테이블에 접근
정답 및 해설
✅ 정답: Account B에 IAM role 생성 + Account B의 trust policy 수정 + AssumeRole API call
한 account("Account A")에서 생성된 Lambda function에 다른 account("Account B")의 role을 assume하여 DynamoDB나 S3 bucket 같은 리소스에 접근할 수 있는 permission을 부여할 수 있습니다.
설정 절차:
- Account A에 Lambda function이 작업을 수행할 수 있는 execution role 생성
- Account B에 Lambda function이 cross-account DynamoDB 테이블에 접근하기 위해 assume할 IAM role 생성
- Account B의 role의 trust policy를 수정하여 Account A의 Lambda execution role이 이 role을 assume할 수 있도록 허용
- Lambda function 코드에 AssumeRole API call 추가
❌ 오답 해설
Account B에 Lambda function의 clone 생성 - Lambda function의 clone을 생성하는 것은 문제에서 설명하는 use case를 해결하지 못합니다.
DynamoDB 테이블에 resource policy 추가 - DynamoDB 테이블에는 resource policy를 attach할 수 없습니다. S3 bucket, SQS queue, SNS topic 등과 달리 DynamoDB는 resource-based policy를 지원하지 않습니다.
Account A의 execution role의 trust policy를 수정 - trust policy를 수정해야 하는 것은 Account A의 execution role이 아니라 Account B의 IAM role입니다.
Cross-Account 접근 시 trust policy 수정 위치
Trust policy는 항상 **"리소스가 있는 account(B)"**의 role에서 수정합니다!
| Account | 역할 |
|---|---|
| Account A (Lambda) | Execution role 보유 + 코드에 AssumeRole API call |
| Account B (DynamoDB) | IAM role 생성 + 이 role의 trust policy 수정 |
기억할 점: DynamoDB는 resource-based policy를 지원하지 않으므로, cross-account 접근은 반드시 IAM role assumption 방식을 사용해야 합니다.