본문 바로가기
Cloud/AWS

모의테스트2 재오답노트

by 에르모사 쩐뉴 2025. 10. 14.

문제

https://docs.google.com/forms/d/e/1FAIpQLSesN8_Uu8VBprGJno0JqiGOj-M-_UsBGzjejs9h7YBlxonaiQ/viewform

 

답안

https://docs.google.com/forms/d/e/1FAIpQLSesN8_Uu8VBprGJno0JqiGOj-M-_UsBGzjejs9h7YBlxonaiQ/viewscore?viewscore=AE0zAgBDVkd8CR0o7W4_JICWp9iPNoll_MLaW-yZRnPXdxYrRol6_zCg0NMClUZGyhmUSSs

 

정답률

41/65 (63.08%)

 

 

질문 3

개발자는 PHP로 간단한 웹 애플리케이션을 작성했으며 자신의 코드를 AWS 클라우드에 업로드하고 AWS에서 배포를 자동으로 처리하도록 하고 싶지만 추가 개선을 위해 기본 운영 체제에 계속 액세스하려고 합니다. 클라우드 실무자로서 이 사용 사례에 대해 다음 AWS 서비스 중 어떤 것을 추천하시겠습니까?

*

1/1

  • Amazon Elastic Container Service(Amazon ECS)
  • AWS CloudFormation
  • Amazon Elastic Compute Cloud(Amazon EC2)
  • AWS Elastic Beanstalk

정답은 AWS Elastic Beanstalk입니다.

해설: 자동 배포와 OS 액세스의 균형

이 시나리오의 핵심 요구사항은 다음과 같이 두 가지 상반된 필요를 동시에 충족해야 합니다.

  1. 자동 배포: 코드를 업로드하면 AWS에서 배포를 자동으로 처리해야 합니다. (개발 편의성)
  2. OS 접근: 추가 개선을 위해 기본 운영 체제(OS)에 계속 액세스할 수 있어야 합니다. (유연성 및 제어)

AWS Elastic Beanstalk은 이 두 가지 요구사항을 완벽하게 충족하는 서비스입니다.

AWS Elastic Beanstalk의 역할

  • 자동 배포 및 관리: Elastic Beanstalk는 PHP, Node.js 등 다양한 언어로 작성된 애플리케이션 코드를 업로드하면, 필요한 EC2 인스턴스, 로드 밸런서, Auto Scaling 그룹 등을 자동으로 프로비저닝하고 관리하며 배포를 처리합니다. (요구사항 1 충족)
  • 기본 OS 접근 허용: Elastic Beanstalk는 EC2 인스턴스를 기반으로 실행됩니다. 개발자는 SSH 또는 기타 방법을 사용하여 기본 OS에 접근하여 로그를 확인하거나, 사용자 지정 소프트웨어를 설치하거나, 설정을 미세 조정할 수 있습니다. (요구사항 2 충족)

오답이 부적절한 이유

오답 서비스 주요 역할 부적합한 이유
Amazon Elastic Compute Cloud (Amazon EC2) 가상 서버를 제공합니다. 자동 배포 및 관리 부재. OS 접근은 가능하지만, 배포(웹 서버 설정, 로드 밸런서 연결 등)를 자동으로 처리하지 않으며 모든 것을 수동으로 구성해야 합니다.
Amazon Elastic Container Service (Amazon ECS) 컨테이너 오케스트레이션 서비스입니다. OS 직접 접근의 어려움. ECS는 컨테이너 수준의 배포에 초점을 맞추며, 기본 호스트 OS에 접근하는 것은 가능하지만, 애플리케이션 개발자가 코드를 업로드하고 OS를 직접 개선한다는 시나리오에는 Elastic Beanstalk가 더 적합합니다.
AWS CloudFormation 인프라를 코드로 관리하는(IaC) 서비스입니다. 배포 실행 도구. CloudFormation은 인프라 자원을 생성할 뿐, 애플리케이션 코드를 직접 업로드하고 배포를 자동화하는 플랫폼 서비스가 아닙니다.

따라서 배포 자동화의 편리함과 기본 OS 제어의 유연성을 모두 제공하는 것은 AWS Elastic Beanstalk입니다.

 

정답은 AWS Elastic Beanstalk입니다.

 

 

질문 4

AWS 서비스에 문제가 발생할 때 비즈니스에 미치는 영향을 신속하게 평가할 수 있도록 클라우드 아키텍처의 일부인 AWS 서비스 상태에 대한 맞춤형 보기를 제공하는 서비스는 무엇입니까?

*

0/1

  • Amazon CloudWatch
  • AWS 상태 - 서비스 상태 대시보드
  • Amazon Inspector
  • AWS 상태 - 계정 상태 대시보드

정답은 **AWS 상태 - 계정 상태 대시보드 (AWS Health - Account Health Dashboard)**입니다.

해설: 맞춤형 서비스 상태 보기 및 비즈니스 영향 평가

이 질문은 AWS 서비스에 문제가 발생했을 때, 고객의 개별 리소스 및 비즈니스에 미치는 영향에 대한 맞춤형 정보를 제공하는 서비스가 무엇인지 묻고 있습니다.

AWS Health의 역할

AWS Health는 고객의 개별 AWS 환경에 영향을 미치는 AWS 서비스 이벤트를 맞춤형으로 제공하는 서비스입니다. 이는 두 가지 대시보드로 구성됩니다.

  • AWS Health - Service Health Dashboard (서비스 상태 대시보드):
    • AWS 전체 서비스의 글로벌 상태를 보여줍니다. (예: "EC2가 미국 동부(버지니아 북부)에서 장애 발생")
    • 이는 모든 고객에게 동일하게 표시되는 일반적인 정보입니다.
  • AWS Health - Account Health Dashboard (계정 상태 대시보드):
    • 이것이 정답인 이유입니다. 이 대시보드는 고객 계정이 사용하는 특정 AWS 리소스 및 서비스에만 영향을 미치는 이벤트에 대한 맞춤형(Personalized) 뷰를 제공합니다.
    • 비즈니스 영향 평가: 예를 들어, 고객의 특정 EC2 인스턴스에 영향을 미치는 하드웨어 유지 관리 이벤트가 예약된 경우, Account Health Dashboard에서만 이 정보를 확인할 수 있습니다. 이를 통해 회사는 문제가 비즈니스에 미치는 영향을 신속하게 평가하고 대응할 수 있습니다.

오답이 부적절한 이유

  • Amazon CloudWatch: 리소스의 성능 지표와 운영 로그를 모니터링하지만, AWS 서비스 자체의 상태 및 장애 이벤트를 맞춤형으로 알려주지는 않습니다. (이는 AWS Health의 역할입니다.)
  • Amazon Inspector: EC2 인스턴스의 OS 및 애플리케이션 취약점을 평가하는 보안 서비스입니다. 서비스 상태와는 무관합니다.
  • AWS 상태 - 서비스 상태 대시보드: 글로벌 서비스 상태를 보여줄 뿐, 질문에서 요구하는 개별 계정 리소스에 대한 맞춤형 보기를 제공하지 않습니다.

따라서 개인화된 리소스 상태 및 비즈니스 영향 정보를 제공하는 것은 AWS Health - 계정 상태 대시보드입니다.

 

 

질문 5

규제 및 규정 준수 이유로 인해 조직은 클라우드의 모든 데이터 암호화 작업에 하드웨어 장치를 사용해야 합니다. 이 규정 준수 요구 사항을 충족하려면 어떤 AWS 서비스를 사용할 수 있습니까?

*

0/1

  • AWS CloudHSM
  • AWS 키 관리 서비스(AWS KMS)
  • AWS Secret Manager
  • AWS Trusted Advisor

정답은 AWS CloudHSM입니다.

해설: 하드웨어 기반 암호화 (Hardware Security Module)

이 시나리오의 핵심 요구사항은 규제 및 규정 준수 목적으로 클라우드의 모든 데이터 암호화 작업에 하드웨어 장치를 사용해야 한다는 것입니다.

**AWS CloudHSM (Hardware Security Module)**은 이러한 규제 요구 사항을 충족하도록 특별히 설계된 서비스입니다.

AWS CloudHSM의 역할

  • 전용 하드웨어 장치: CloudHSM은 클라우드에서 단일 테넌트(Single-tenant) 방식으로 전용 **HSM(Hardware Security Module)**을 제공합니다. 이 HSM은 FIPS 140-2 Level 3 인증을 받은 장치입니다.
  • 고객 제어: 고객은 HSM 내의 암호화 키에 대한 모든 통제권을 가집니다. AWS는 고객의 키에 접근할 수 없습니다.
  • 규정 준수: 금융, 의료, 정부 등 까다로운 규정(예: PCI DSS, HIPAA)을 준수해야 하는 조직은 하드웨어 기반 암호화 및 키 관리가 필요하며, CloudHSM은 이를 충족하는 유일한 AWS 서비스입니다.

다른 서비스가 부적절한 이유

서비스 주요 역할 부적합한 이유
AWS 키 관리 서비스 (AWS KMS) 암호화 키를 생성하고 관리하는 관리형 서비스입니다. KMS는 보안성이 높지만, 키는 AWS가 소유하고 관리하는 HSM에서 보호됩니다. 고객이 자체 전용 HSM 하드웨어를 직접 사용해야 한다는 요구사항을 충족하지 못합니다.
AWS Secret Manager 비밀 정보(비밀번호, API 키 등)의 저장 및 교체를 관리합니다. 암호화 키 관리 자체가 아닌, 자격 증명 관리 서비스입니다.
AWS Trusted Advisor 비용, 보안, 성능 등에 대한 모범 사례 권장 사항을 제공하는 조언 도구입니다. 암호화 작업이나 키 관리를 위한 서비스가 아닙니다.

따라서 하드웨어 기반의 엄격한 키 관리 및 암호화라는 규정 준수 요건을 충족하는 것은 AWS CloudHSM뿐입니다.

 

 

질문 6

한 IT 회사의 엔지니어링 팀은 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 플릿의 CPU 사용률을 모니터링하고 사용률이 80%를 초과하면 관리자에게 이메일을 보내려고 합니다. 클라우드 실무자로서 이 솔루션을 구축하려면 어떤 AWS 서비스를 추천하시겠습니까? (2개 선택)

*

0/1

  • Amazon Simple Notification Service(SNS)
  • AWS CloudTrail
  • Amazon Simple Queue Service(SQS)
  • Amazon CloudWatch
  • AWS Lambda
 

 

질문 9

조직에는 많은 시스템 종속성이 포함된 복잡한 IT 아키텍처가 있으며 각 리소스에 대한 변경 내역을 추적하려고 합니다. 조직이 모든 리소스에 대한 구성 변경 내역을 추적하는 데 도움이 되는 AWS 서비스는 무엇입니까?

*

0/1

AWS Config

AWS CloudFormation

AWS CloudTrail

AWS 서비스 Catalog

 

정답은 AWS Config입니다.

해설: 복잡한 아키텍처의 구성 변경 내역 추적

이 시나리오의 핵심 요구사항은 복잡한 IT 아키텍처와 많은 시스템 종속성을 가진 조직에서 모든 리소스에 대한 구성 변경 내역을 추적하는 것입니다.

AWS Config는 이 요구사항을 충족하기 위한 AWS의 주요 거버넌스 및 감사 서비스입니다.

AWS Config의 역할

  • 구성 기록 (Configuration Recorder): AWS Config는 계정 내 모든 리소스(EC2, S3, RDS 등)의 **구성(Configuration)**을 지속적으로 기록하고 추적합니다.
  • 변경 내역 추적: 리소스의 시점별 스냅샷을 생성하여, 특정 시점에 리소스의 구성이 어떠했는지 정확히 알 수 있습니다. 이는 "누가, 무엇을, 언제 변경했는지"에 대한 기록을 제공하여 복잡한 시스템 종속성 내에서 변경 사항을 파악하는 데 필수적입니다.
  • 규정 준수 평가: 또한, 리소스 구성이 사전에 정의된 모범 사례나 규정 준수 규칙을 따르고 있는지 자동으로 평가하는 기능도 제공합니다.

오답이 부적절한 이유

오답 서비스 주요 역할 부적합한 이유
AWS CloudTrail API 활동 및 사용자 활동을 기록합니다. CloudTrail은 **'누가 이 리소스를 변경하라는 API를 호출했는지'**를 기록하지만, 변경된 **'리소스의 실제 구성 상태'**를 추적하고 저장하는 것은 Config의 역할입니다.
AWS CloudFormation 인프라를 코드로 배포하고 프로비저닝하는 데 사용되는 서비스입니다. 리소스의 변경 내역을 추적하는 것이 아니라, 리소스를 생성하는 도구입니다.
AWS 서비스 Catalog 조직 내 승인된 IT 서비스(템플릿)를 생성하고 관리하여 배포를 표준화하는 서비스입니다. 리소스의 구성 변경 내역을 추적하는 기능과는 직접적인 관련이 없습니다.

따라서 모든 AWS 리소스에 대한 구성 변경 내역을 지속적으로 추적하는 서비스는 AWS Config가 가장 적합합니다.

 

 

질문 12

가장 빠른 경험을 제공하는 AWS 엔드포인트로 요청을 라우팅하여 고객의 성능을 향상시키기 위해 어떤 Amazon Route 53 라우팅 정책을 사용하시겠습니까?

*

0/1

  • 지연 시간 기반 라우팅
  • 간단한 라우팅
  • 가중치 기반 라우팅
  • 장애 조치 라우팅

정답은 **지연 시간 기반 라우팅(Latency-Based Routing)**입니다.

해설: 가장 빠른 경험을 위한 라우팅 정책

이 시나리오의 목표는 가장 빠른 경험을 제공하는 **AWS 엔드포인트(가장 낮은 지연 시간)**로 고객의 요청을 라우팅하여 성능을 향상시키는 것입니다.

**지연 시간 기반 라우팅(LBR)**은 이 요구 사항을 정확하게 충족하도록 설계된 Amazon Route 53의 정책입니다.

지연 시간 기반 라우팅 (Latency-Based Routing, LBR)의 역할

  • 지연 시간 측정: LBR은 AWS 리전 간의 네트워크 지연 시간(Latency) 데이터를 기반으로 작동합니다.
  • 최적 경로 선택: 요청이 들어왔을 때, 해당 최종 사용자에게 지리적으로 가장 가깝고 네트워크 지연 시간이 가장 낮은 AWS 리전의 엔드포인트로 트래픽을 라우팅합니다.
  • 성능 향상: 고객의 요청이 가장 빠른 서버에서 처리되도록 보장하여, 전체적인 웹 애플리케이션의 응답 시간을 단축하고 사용자 경험을 개선합니다.

오답이 부적절한 이유

라우팅 정책 주요 역할 부적합한 이유
간단한 라우팅 (Simple Routing) 단일 리소스만 지정하거나, 여러 리소스를 무작위로 선택하는 기본 라우팅입니다. 지연 시간이나 성능을 고려하지 않습니다.
가중치 기반 라우팅 (Weighted Routing) 서로 다른 비율(가중치)로 트래픽을 여러 엔드포인트에 분산시킵니다 (예: 80%는 신규 버전, 20%는 구 버전). 성능 최적화가 아닌 트래픽 분산 제어에 중점을 둡니다.
장애 조치 라우팅 (Failover Routing) 기본(Primary) 엔드포인트에 장애가 발생했을 때 백업(Secondary) 엔드포인트로 트래픽을 전환합니다. 가용성(Availability) 확보에 중점을 두며, 지연 시간을 기준으로 가장 빠른 경로를 찾는 것이 목적이 아닙니다.

따라서 가장 빠른 경험 (최소 지연 시간)을 제공하는 엔드포인트로 라우팅하려면 지연 시간 기반 라우팅을 사용해야 합니다.

 

질문 16

Docker 컨테이너 이미지를 저장, 관리 및 배포하는 데 사용할 수 있는 AWS 서비스는 무엇입니까?

*

0/1

  • Amazon Elastic Compute Cloud(Amazon EC2)
  • Amazon Elastic Container Registry(Amazon ECR)
  • AWS Lambda
  • Amazon Elastic Container Service(Amazon ECS)

정답은 **Amazon Elastic Container Registry(Amazon ECR)**입니다.

해설: Docker 컨테이너 이미지의 저장, 관리 및 배포

이 질문은 Docker 컨테이너의 생명 주기 중 이미지 저장소(Registry) 역할을 수행하는 AWS 서비스를 묻고 있습니다.

Amazon ECR의 역할

  • 저장 및 관리: Amazon ECR은 개발자가 Docker 컨테이너 이미지를 저장, 관리, 공유 및 배포할 수 있도록 해주는 완전 관리형 Docker 컨테이너 레지스트리 서비스입니다.
  • 배포 통합: ECR은 같은 AWS 생태계 내의 Amazon ECS, Amazon EKS, AWS Lambda 등 다른 컨테이너 및 서버리스 서비스와 통합되어 컨테이너 이미지를 빠르고 안정적으로 가져올 수 있게 합니다.

오답이 부적절한 이유

서비스 주요 역할 부적합한 이유
Amazon Elastic Container Service (Amazon ECS) 컨테이너 오케스트레이션. 컨테이너를 실행, 중지 및 관리하는 서비스입니다. 이미지를 저장하는 역할이 아닙니다.  
Amazon Elastic Compute Cloud (Amazon EC2) 가상 서버 제공. 컨테이너 이미지를 저장소로 사용하는 것이 아니라, 이미지를 실행할 기반 인프라를 제공합니다.  
AWS Lambda 서버리스 컴퓨팅. 코드를 이벤트에 반응하여 실행하는 서비스입니다. 컨테이너 이미지를 저장하거나 관리하는 역할이 없습니다. (최근에는 Lambda가 컨테이너 이미지를 기반으로 실행될 수 있지만, 이미지를 저장하는 서비스 자체는 ECR입니다.)  

결론: Docker 이미지를 위한 안전하고 확장 가능한 저장소(Registry) 역할을 하는 서비스는 Amazon ECR입니다.

 

 

질문 17

컨테이너 애플리케이션을 실행하고 싶지만 서버 확장, 패치 적용, 보안 및 관리에 따른 운영 오버헤드를 피하고 싶다면 어떤 AWS 서비스를 사용해야 합니까?

*

1/1

  • AWS Lambda
  • Amazon Elastic Container Service(Amazon ECS) - EC2 시작 유형
  • Amazon Elastic Compute Cloud(Amazon EC2)
  • Amazon Elastic Container Service(Amazon ECS) - Fargate 시작 유형

 

정답은 Amazon Elastic Container Service(Amazon ECS) - Fargate 시작 유형입니다.

해설: 서버리스 컨테이너와 운영 오버헤드 회피

이 시나리오의 핵심 목표는 컨테이너 애플리케이션을 실행하면서도, 서버 관리(확장, 패치, 보안)에 따른 모든 운영 오버헤드를 피하는 것입니다.

Amazon ECS - Fargate 시작 유형의 역할

AWS Fargate는 컨테이너 실행을 위한 서버리스(Serverless) 컴퓨팅 엔진입니다.

  • 운영 오버헤드 제거: Fargate를 사용하면 **기본 EC2 인스턴스(서버)**를 프로비저닝, 확장, 패치 또는 보안 관리할 필요가 전혀 없습니다. AWS가 컨테이너를 실행하는 데 필요한 모든 인프라 관리를 대신 처리합니다. (요구사항 완벽 충족)
  • 간편한 컨테이너 실행: 개발자는 오직 컨테이너 이미지와 필요한 CPU/메모리 사양만 지정하면, Fargate가 백그라운드에서 컨테이너를 실행합니다.

오답이 부적절한 이유

오답 서비스 관리 오버헤드 수준 부적합한 이유
Amazon Elastic Container Service (Amazon ECS) - EC2 시작 유형 중간 오버헤드. ECS는 컨테이너를 관리하지만, **컨테이너를 실행하는 EC2 인스턴스(서버)**의 확장, 패치, 보안은 여전히 고객의 책임입니다. 운영 오버헤드를 피할 수 없습니다.
Amazon Elastic Compute Cloud (Amazon EC2) 높은 오버헤드. 컨테이너를 실행하려면 OS 설치, Docker 설치, 네트워크 구성, 확장 등 모든 것을 수동으로 관리해야 합니다. 오버헤드가 가장 높습니다.
AWS Lambda 서버리스. 서버 관리가 필요 없지만, 컨테이너화된 애플리케이션이 아닌, **코드 조각(Functions)**을 이벤트 기반으로 실행하는 데 초점을 맞춥니다. 시나리오에서 요구하는 "컨테이너 애플리케이션" 실행에 가장 적합한 서버리스 옵션은 Fargate입니다.

따라서 컨테이너의 이점을 누리면서 서버 관리의 모든 부담을 AWS에 위임하려면 Amazon ECS의 Fargate 시작 유형이 정답입니다.

 

질문 18

초당 청구 및 기본 OS에 대한 액세스를 지원하여 클라우드에서 크기 조정 가능한 컴퓨팅 용량에 액세스하는 가장 쉬운 방법을 제공하는 AWS 컴퓨팅 서비스는 무엇입니까?

*

0/1

  • Amazon Elastic Compute Cloud(Amazon EC2)
  • Amazon Elastic Container Service(Amazon ECS)
  • Amazon LightSail
  • AWS Lambda

정답은 **Amazon Elastic Compute Cloud(Amazon EC2)**입니다.

해설: EC2의 특징 (초 단위 청구 및 OS 접근)

이 시나리오가 요구하는 세 가지 주요 조건은 다음과 같습니다.

  1. 클라우드에서 크기 조정 가능한 컴퓨팅 용량에 접근하는 가장 쉬운 방법 (확장성)
  2. 초당 청구 (Per-second Billing) 지원
  3. 기본 OS에 대한 액세스 지원 (제어)

Amazon EC2는 이 모든 조건을 충족하는 AWS의 기본적인 컴퓨팅 서비스입니다.

Amazon EC2의 역할

  • 초당 청구: 대부분의 리눅스(Linux) 기반 EC2 인스턴스는 2017년부터 최소 60초 후 초 단위(Per-second)로 요금이 청구됩니다. (조건 2 충족)
  • OS 접근: EC2는 가상 머신(Virtual Machine)을 제공하므로, 사용자는 SSH 또는 RDP를 사용하여 인스턴스의 기본 OS에 완전히 접근할 수 있으며, 운영 체제를 직접 관리하고 개선할 수 있습니다. (조건 3 충족)
  • 쉬운 접근성 및 확장성: EC2는 AWS의 가장 기본적이고 널리 사용되는 서비스이며, 콘솔, CLI, SDK를 통해 쉽게 액세스하고 필요에 따라 수직적/수평적으로 크기 조정할 수 있습니다. (조건 1 충족)

오답이 부적절한 이유

서비스 문제점
AWS Lambda OS 접근 불가. 서버리스 서비스로, OS에 직접 액세스할 수 없습니다.
Amazon LightSail 가장 쉬운 방법을 제공하지만, 규모 조정(Scalability) 측면에서 EC2에 비해 유연성과 확장성 옵션이 제한적이며, AWS의 주력 컴퓨팅 서비스로 언급하기 어렵습니다.
Amazon Elastic Container Service (Amazon ECS) 컨테이너 오케스트레이션에 중점을 둡니다. OS 접근은 ECS의 주요 목적이 아니며, Fargate를 사용할 경우 아예 OS 접근이 불가능합니다.

따라서 초당 청구, OS 접근, 확장 가능한 컴퓨팅 용량이라는 조건을 모두 충족하는 가장 기본적인 AWS 서비스는 Amazon EC2입니다.

 

 

질문 19

회사는 온프레미스 애플리케이션에서 메시지 브로커 서비스를 사용하고 있으며 이 메시징 기능을 AWS 클라우드로 이동하려고 합니다. 다음 중 기존 기능을 쉽게 이전하기 위한 올바른 선택은 무엇입니까?

*

0/1

  • Amazon Simple Queue Service(Amazon SQS)
  • Amazon MQ
  • Amazon Kinesis Data Stream
  • Amazon Simple Notificatiion Service(Amazon SNS)

정답은 Amazon MQ입니다.

해설: 기존 메시지 브로커의 쉬운 이전

이 시나리오의 핵심 요구사항은 다음과 같습니다.

  1. 기존 온프레미스 애플리케이션이 메시지 브로커 서비스를 사용하고 있음.
  2. 이 메시징 기능을 AWS 클라우드로 쉽게 이전하기를 원함.

Amazon MQ는 이 요구 사항을 충족하기 위한 AWS의 완전 관리형 메시지 브로커 서비스입니다.

Amazon MQ의 역할 (쉬운 마이그레이션)

  • 관리형 메시지 브로커: Amazon MQ는 Apache ActiveMQ 또는 RabbitMQ와 같은 표준 메시지 브로커를 AWS 클라우드에서 완전 관리형 서비스로 제공합니다.
  • 기존 기능 유지: 가장 중요한 점은 Amazon MQ가 **표준 메시징 프로토콜(예: AMQP, STOMP, MQTT, OpenWire)**을 지원한다는 것입니다.
  • 쉬운 이전: 온프레미스 애플리케이션이 이미 ActiveMQ와 같은 표준 브로커를 사용하고 있다면, Amazon MQ로 마이그레이션할 때 애플리케이션 코드를 크게 수정하지 않고 엔드포인트만 변경하여 쉽게 이전할 수 있습니다. 이것이 "기존 기능을 쉽게 이전"하기 위한 가장 올바른 선택인 이유입니다.

오답이 부적절한 이유

서비스 주요 역할 부적합한 이유
Amazon Simple Queue Service (Amazon SQS) 메시지 큐 서비스. 메시지를 큐에 저장합니다. 기존의 메시지 브로커가 제공하는 주제(Topic) 기반 발행/구독(Pub/Sub) 기능이나 복잡한 라우팅 기능을 MQ만큼 완벽하게 대체하지 못하며, 애플리케이션 코드 변경이 필요합니다.
Amazon Simple Notificatiion Service (Amazon SNS) 발행/구독(Pub/Sub) 서비스. 대규모로 메시지를 여러 구독자에게 푸시하는 데 중점을 둡니다. SQS와 마찬가지로, 기존 메시지 브로커의 복잡한 라우팅 및 프로토콜 호환성을 그대로 이전하기는 어렵습니다.
Amazon Kinesis Data Stream 대규모 실시간 스트리밍 데이터를 처리하고 수집하는 데 중점을 둡니다. 일반적인 엔터프라이즈 메시지 브로커의 마이그레이션 용도로는 적합하지 않으며, 실시간 분석 및 로깅에 주로 사용됩니다.

 

질문 21

다음 중 AWS 클라우드에서 리소스 보안을 구현하는 데 필수적인 AWS 서비스는 무엇입니까?

*

0/1

  • AWS ID 및 액세스 관리(IAM)
  • 아마존 CloudWatch
  • AWS Web Application Firewall(AWS WAF)
  • AWS Shield

정답은 **AWS ID 및 액세스 관리(IAM)**입니다.

해설: AWS 리소스 보안 구현의 필수 서비스

이 질문은 AWS 클라우드에서 리소스 보안을 구현하는 데 필수적인 서비스, 즉 **인증(Authentication)**과 **권한 부여(Authorization)**를 담당하는 기본적인 서비스를 묻고 있습니다.

AWS IAM (ID 및 액세스 관리)의 역할

  • 보안의 근간: IAM은 AWS에서 보안의 가장 기본적인 핵심 서비스입니다. IAM은 "누가 무엇을 할 수 있는지"를 정의합니다.
  • 인증 및 권한 부여:
    • 사용자 및 역할 관리: AWS 리소스에 액세스할 사용자, 그룹, 역할을 생성하고 관리합니다.
    • 정책 정의: IAM 정책을 사용하여 특정 사용자 또는 역할이 특정 AWS 서비스(예: S3, EC2)의 특정 리소스에 대해 **어떤 작업(예: 읽기, 쓰기, 삭제)**을 수행할 수 있는지 허용하거나 거부합니다.
  • 리소스 보안 필수 요소: 모든 AWS 서비스는 IAM을 사용하여 액세스를 통제하므로, 클라우드 환경에서 리소스 보안을 구현하고 통제하는 데 가장 필수적이며 첫 번째 단계가 되는 서비스입니다.

오답이 부적절한 이유

서비스 주요 역할 부적합한 이유
AWS Web Application Firewall (AWS WAF) 애플리케이션 레이어 보호. 웹 공격(SQL 인젝션, XSS 등)으로부터 웹 애플리케이션을 보호합니다. 인터넷 트래픽에 대한 보호에 중점을 두며, 리소스 액세스 권한을 통제하는 근본적인 서비스는 아닙니다.
AWS Shield DDoS 방어. 분산 서비스 거부 공격으로부터 보호합니다. 네트워크 가용성 보호에 중점을 두며, 리소스 접근 권한을 정의하지는 않습니다.
Amazon CloudWatch 모니터링 및 로깅. 리소스의 성능과 운영 상태를 관찰합니다. 보안 구현보다는 운영 상태 관찰에 중점을 둡니다.

따라서 리소스에 대한 액세스를 정의하고 통제하는 가장 근본적이고 필수적인 서비스는 AWS IAM입니다.

 

 

질문 23

전자 상거래 회사는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 배포된 애플리케이션의 취약성과 AWS 모범 사례와의 차이를 평가하려고 합니다. 이를 촉진하기 위해 어떤 AWS 서비스를 사용할 수 있습니까?

*

/1

  • AWS CloudHSM
  • Amazon Inspector
  • AWS Trusted Advisor
  • AWS Secret Manager

정답은 Amazon Inspector입니다.

해설: 애플리케이션 취약점 및 모범 사례 평가

이 시나리오의 핵심 목표는 Amazon EC2 인스턴스에 배포된 애플리케이션의 두 가지 주요 요소를 평가하는 것입니다.

  1. 취약성 (Vulnerability): 애플리케이션 및 OS의 보안 취약점 확인.
  2. AWS 모범 사례와의 차이: 보안 설정이 AWS 모범 사례를 따르고 있는지 평가.

Amazon Inspector의 역할

Amazon Inspector는 AWS 워크로드의 보안 취약점 및 모범 사례 편차를 지속적으로 평가하고 관리하는 서비스입니다.

  • 취약점 평가: EC2 인스턴스에 설치된 운영 체제(OS)와 애플리케이션의 **취약점(CVE)**을 자동으로 검색하고 보고합니다.
  • 보안 모범 사례 평가: Inspector는 AWS 계정 수준이 아닌, 배포된 리소스(EC2) 수준에서 네트워크 접근성 및 보안 구성이 AWS 모범 사례에 부합하는지 평가합니다. (예: 인스턴스의 보안 그룹이 과도하게 열려 있는지 확인)

오답이 부적절한 이유

서비스 주요 역할 부적합한 이유
AWS Trusted Advisor 계정 수준에서 비용 절감, 성능, 보안 등에 대한 일반적인 모범 사례 권장 사항을 제공합니다. 애플리케이션이나 OS의 심층적인 보안 취약성을 평가하지는 않습니다.
AWS CloudHSM 암호화 키를 위한 **전용 하드웨어 모듈(HSM)**을 제공합니다. 키 관리 서비스이며, 애플리케이션의 취약점을 평가하는 데 사용되지 않습니다.
AWS Secret Manager 비밀 정보(비밀번호, API 키)를 안전하게 저장하고 교체하는 서비스입니다. 취약점 평가와는 무관한 자격 증명 관리 서비스입니다.

따라서 EC2 인스턴스에 배포된 애플리케이션의 보안 취약성과 구성 오류를 평가하는 데 가장 적합한 서비스는 Amazon Inspector입니다.

 

 

질문 25

데이터 분석 회사는 Amazon Simple Storage Service(Amazon S3)에 데이터를 저장하고 최소한의 노력으로 이 데이터에 대한 SQL 기반 분석을 수행하려고 합니다. 클라우드 실무자로서 이 사용 사례에 대해 다음 AWS 서비스 중 어떤 것을 제안하시겠습니까?

*

0/1

  • Amazon Aurora
  • Amazon Athena
  • Amazon RedShift
  • Amazon DynamoDB

정답은 Amazon Athena입니다.

해설: S3 데이터에 대한 SQL 기반 분석

이 시나리오의 핵심 요구사항은 다음과 같습니다.

  1. 데이터는 **Amazon Simple Storage Service (Amazon S3)**에 저장되어 있습니다.
  2. 최소한의 노력으로 이 데이터에 대해 SQL 기반 분석을 수행해야 합니다.

Amazon Athena는 이 요구 사항을 정확하게 충족하도록 설계된 서버리스 대화형 쿼리 서비스입니다.

Amazon Athena의 역할

  • 서버리스 SQL 분석: Athena는 서버를 프로비저닝하거나 관리할 필요 없이(최소한의 노력) 표준 SQL을 사용하여 Amazon S3의 데이터를 직접 분석합니다.
  • 데이터 원본: Athena는 S3 버킷에 저장된 파일을 직접 쿼리하며, 데이터를 로드하거나 ETL(추출, 변환, 로드) 과정을 거칠 필요가 없습니다.
  • 비용 효율성: 실행한 쿼리에서 스캔된 데이터의 양에 대해서만 비용을 지불하므로(Pay-per-query), 매우 비용 효율적입니다.

오답이 부적절한 이유

서비스 주요 역할 부적합한 이유
Amazon RedShift 클라우드 데이터 웨어하우스. 대규모 정형 데이터 분석을 위해 설계되었습니다. 데이터를 S3에서 RedShift 클러스터로 로드해야 하며, 클러스터를 프로비저닝하고 관리해야 하므로 **"최소한의 노력"**이라는 조건에 부합하지 않습니다.
Amazon Aurora 관계형 데이터베이스(RDBMS). 고성능 OLTP(온라인 트랜잭션 처리) 워크로드에 중점을 둡니다. S3에 저장된 대량의 데이터를 분석하기 위해 설계되지 않았으며, 데이터를 RDBMS로 가져와야 합니다.
Amazon DynamoDB NoSQL 데이터베이스. 키-값 및 문서 데이터를 위한 서비스입니다. SQL 기반 분석이 아닌, NoSQL 형태의 쿼리 언어를 사용하며 S3 데이터 분석 용도가 아닙니다.

따라서 S3 데이터를 직접, 서버리스 방식으로, SQL을 사용하여 분석할 수 있는 가장 적합하고 노력이 최소화되는 서비스는 Amazon Athena입니다.

 

질문 27

AWS 클라우드의 모든 리전에서 모든 AWS 서비스의 일반 상태 및 가용성에 대한 최신 정보를 게시하는 AWS 서비스는 무엇입니까?

*

0/1

AWS CloudFormation

AWS 상태 대시보드 – 계정 상태

AWS 상태 대시보드 - 서비스 상태

Amazon CloudWatch

 

정답은 **AWS 상태 대시보드 - 서비스 상태 (AWS Health Dashboard - Service Health)**입니다.

해설: AWS 서비스의 일반 상태 및 가용성 확인

이 시나리오가 요구하는 것은 AWS 클라우드의 모든 리전에서 모든 AWS 서비스의 일반적인 상태 및 가용성에 대한 최신 정보를 확인하는 것입니다.

**AWS 상태 대시보드 - 서비스 상태 (Service Health Dashboard, SHD)**는 이 요구 사항을 충족하는 공개 대시보드입니다.

Service Health Dashboard (SHD)의 역할

  • 글로벌/일반 상태: SHD는 AWS의 모든 서비스(예: S3, EC2, Lambda 등)에 대해 전 세계 리전별로 현재 운영상의 문제나 잠재적 장애가 있는지 여부를 모든 고객에게 공개적으로 게시합니다.
  • 실시간 정보: 이 대시보드는 AWS 엔지니어링팀이 보고한 서비스 중단이나 성능 저하에 대한 최신 업데이트를 제공합니다.

AWS Health - 계정 상태 대시보드 (Account Health Dashboard)와의 차이점

이전 문제(질문 4)와 혼동될 수 있는 계정 상태 대시보드와의 차이점은 명확합니다.

대시보드 유형 제공하는 정보 대상
서비스 상태 (Service Health) 모든 AWS 서비스의 일반적, 글로벌 상태 (전체 AWS의 건강 상태) 모든 고객에게 공개
계정 상태 (Account Health) 고객의 개별 리소스에만 영향을 미치는 맞춤형, 비공개 이벤트 로그인한 특정 고객 계정

오답이 부적절한 이유

  • AWS 상태 대시보드 – 계정 상태: 이는 사용자 계정에만 해당되는 맞춤형 정보를 제공하며, 모든 AWS 서비스의 일반 상태를 보여주지는 않습니다.
  • Amazon CloudWatch: 리소스의 성능 모니터링 및 운영 지표에 중점을 두며, AWS 서비스 자체의 상태를 게시하는 서비스가 아닙니다.
  • AWS CloudFormation: 인프라를 코드로 프로비저닝하는 서비스이며, 서비스 상태 정보와는 무관합니다.

따라서 AWS 클라우드 전체의 일반적인 상태 및 가용성에 대한 정보를 게시하는 서비스는 AWS 상태 대시보드 - 서비스 상태입니다.

 

 

 

질문 28

다음 중 DDoS(분산 서비스 거부) 공격을 방지하는 데 사용할 수 있는 AWS 서비스는 무엇입니까? (3개 선택)

*

1/1

  • Amazon Route 53을 사용하는 Amazon CloudFront
  • AWS Trusted Advisor
  • Amazon Inspector
  • AWS CloudHSM
  • AWS Web Application Firewall(AWS WAF)
  • AWS Shield

정답은 Amazon Route 53을 사용하는 Amazon CloudFront, AWS Web Application Firewall(AWS WAF), 그리고 AWS Shield입니다.

해설: DDoS 공격 방어 AWS 서비스 (3개 선택)

DDoS(분산 서비스 거부) 공격을 방지하는 것은 AWS의 보안 원칙에서 중요한 부분입니다. 다음 세 가지 서비스는 AWS에서 DDoS 방어를 위해 핵심적으로 사용됩니다.

1. AWS Shield (필수 방어선)

  • 역할: AWS Shield는 모든 AWS 고객에게 기본적으로 제공되는 Standard와 프리미엄 유료 서비스인 Advanced로 나뉩니다.
  • 방어 계층: 주로 **네트워크 레이어(Layer 3/4)**에서 발생하는 볼륨 공격(Volume-based attacks)을 자동으로 탐지하고 완화하여 AWS 인프라를 보호합니다.

2. AWS Web Application Firewall (AWS WAF)

  • 역할: AWS WAF는 **애플리케이션 레이어(Layer 7)**에서 발생하는 공격으로부터 웹 애플리케이션을 보호합니다.
  • 방어 계층: SQL 인젝션, XSS(크로스 사이트 스크립팅), HTTP 플러딩 등 정교한 DDoS 공격 유형을 방어하기 위해 사용자 지정 규칙을 생성하거나 관리형 규칙을 사용하여 트래픽을 필터링합니다. WAF는 Shield와 함께 작동하여 포괄적인 방어를 제공합니다.

3. Amazon Route 53을 사용하는 Amazon CloudFront

  • 역할: CloudFront(CDN)와 Route 53(DNS)은 DDoS 공격을 흡수하고 분산시키는 핵심적인 엣지 서비스입니다.
  • CloudFront: 전 세계에 분산된 캐시 서버를 사용하여 공격 트래픽이 오리진 서버에 도달하기 전에 엣지에서 흡수하고 완화합니다.
  • Route 53: DNS 서버에 대한 대규모 쿼리 공격(DNS Flooding)을 방어하고, Route 53의 다양한 라우팅 정책을 통해 정상 트래픽을 정상 엔드포인트로 유지할 수 있습니다.

오답이 부적절한 이유

  • AWS CloudHSM: 암호화 키 관리용 하드웨어 모듈입니다. DDoS 방어와는 관련이 없습니다.
  • Amazon Inspector: EC2 인스턴스의 취약점 평가 서비스입니다. 실시간 트래픽 방어와는 관련이 없습니다.
  • AWS Trusted Advisor: 비용, 성능, 보안 등에 대한 모범 사례 권장 사항을 제공하는 조언 서비스입니다. 실제 방어 메커니즘이 아닙니다.

따라서 DDoS 공격 방어를 위한 핵심적인 서비스 조합은 AWS Shield, AWS WAF, 그리고 CloudFront/Route 53입니다.

 

 

질문 30

AWS Well-Architected 프레임워크는 AWS 모범 사례를 사용하여 클라우드 기반 애플리케이션을 구축하는 방법에 대한 지침을 제공합니다. 다음 옵션 중 AWS Well-Architected 프레임워크에 언급된 핵심 요소는 무엇입니까? (2개 선택)

*

0/1

  • 신뢰할 수 있음
  • 확장성
  • 비용 최적화
  • 유효성
  • 탄력

정답은 신뢰할 수 있음과 비용 최적화입니다.

해설: AWS Well-Architected 프레임워크의 핵심 요소

AWS Well-Architected Framework는 클라우드 기반 애플리케이션을 설계하고 운영할 때 AWS 모범 사례를 따를 수 있도록 설계된 개념적 지침 세트입니다. 이 프레임워크는 다섯 가지 주요 **핵심 요소(Pillars)**로 구성되어 있습니다.

AWS Well-Architected Framework의 5대 핵심 요소

  1. 운영 우수성 (Operational Excellence)
  2. 보안 (Security)
  3. 안정성 (Reliability)
  4. 성능 효율성 (Performance Efficiency)
  5. 비용 최적화 (Cost Optimization)

주어진 보기 중에서 이 다섯 가지 핵심 요소에 해당하는 것은 **신뢰할 수 있음 (Reliability)**과 **비용 최적화 (Cost Optimization)**입니다.

오답이 부적절한 이유

  • 확장성 (Scalability), 유효성 (Validity), 탄력 (Resilience): 이 용어들은 핵심 요소 **안정성 (Reliability)**이나 성능 효율성 (Performance Efficiency) 내에서 다루어지는 특성 또는 원리입니다. 예를 들어, 탄력성은 안정성 요소의 핵심 설계 원리 중 하나이며, 확장성은 성능 효율성의 핵심입니다. 이들은 5대 핵심 요소 자체는 아닙니다.

따라서 5대 핵심 요소의 명칭으로 정확한 것은 신뢰할 수 있음과 비용 최적화입니다.

 

 

질문 32

다음 중 AWS 루트 사용자 계정에 대한 올바른 설명은 무엇입니까? (2개 선택)

*

0/1

  • 루트 사용자 자격 증명은 작업을 완료하는 데 관리 책임이 필요한 관리자와만 공유되어야 합니다.
  • 루트 사용자 계정에 대해 Multi-Factor Authentication(MFA)을 활성화하는 것이 좋습니다.
  • 루트 사용자 계정은 계정이 생성될 때 무제한 권한을 갖지만 IAM 정책을 사용하여 제한할 수 있습니다.
  • 루트 사용자 계정 비밀번호는 일단 설정되면 변경할 수 없습니다.
  • 루트 사용자 액세스 자격 증명은 AWS 계정을 생성하는 데 사용되는 이메일 주소와 비밀번호입니다.

정답은 루트 사용자 계정에 대해 Multi-Factor Authentication(MFA)을 활성화하는 것이 좋습니다. 와 루트 사용자 액세스 자격 증명은 AWS 계정을 생성하는 데 사용되는 이메일 주소와 비밀번호입니다. 입니다.

해설: AWS 루트 사용자 계정의 올바른 특징

AWS 루트 사용자 계정은 AWS 계정 생성 시 사용된 이메일 주소와 비밀번호로 접근하며, 계정 내에서 가장 강력한 권한을 가집니다. AWS 보안 모범 사례에 따르면 이 계정은 일상적인 작업에 사용해서는 안 됩니다.

올바른 설명

  1. 루트 사용자 액세스 자격 증명은 AWS 계정을 생성하는 데 사용되는 이메일 주소와 비밀번호입니다.
    • 설명: 루트 사용자 계정은 AWS에 처음 등록할 때 사용한 이메일 주소와 암호로 로그인하는 계정이며, 모든 서비스에 대한 무제한 권한을 가집니다.
  2. 루트 사용자 계정에 대해 Multi-Factor Authentication(MFA)을 활성화하는 것이 좋습니다.
    • 설명: 루트 사용자 계정은 무제한 권한을 가지므로, 반드시 MFA를 활성화하여 보안을 강화해야 합니다. 이는 AWS의 가장 중요한 보안 모범 사례 중 하나입니다.

올바르지 않은 설명

  • 루트 사용자 자격 증명은 작업을 완료하는 데 관리 책임이 필요한 관리자와만 공유되어야 합니다.
    • 오답 이유: 루트 사용자 자격 증명은 절대로 공유되어서는 안 됩니다. 루트 사용자는 일상적인 관리 책임에도 사용하지 않아야 하며, 모든 관리 작업은 IAM 사용자 또는 역할에 위임해야 합니다.
  • 루트 사용자 계정은 계정이 생성될 때 무제한 권한을 갖지만 IAM 정책을 사용하여 제한할 수 있습니다.
    • 오답 이유: 루트 사용자는 기본적으로 **무제한 권한(Superuser)**을 가지며, IAM 정책을 사용하여 루트 사용자의 권한을 제한할 수 없습니다. 루트 사용자는 모든 IAM 정책을 무시하고 모든 작업을 수행할 수 있습니다.
  • 루트 사용자 계정 비밀번호는 일단 설정되면 변경할 수 없습니다.
    • 오답 이유: 루트 사용자 비밀번호는 IAM 콘솔을 통해 언제든지 변경할 수 있습니다.

 

질문 36

소셜 미디어 회사가 SQL 주입 및 크로스 사이트 스크립팅과 같은 일반적인 웹 익스플로잇으로부터 웹 애플리케이션을 보호하고자 합니다. 다음 중 어떤 AWS 서비스를 사용하여 이 사용 사례를 해결할 수 있습니까?

*

0/1

  • AWS 웹 애플리케이션 방화벽(AWS WAF)
  • 아마존 가드듀티
  • AWS 클라우드워치
  • 아마존 인스펙터

정답은 **AWS 웹 애플리케이션 방화벽(AWS WAF)**입니다.

해설: 일반적인 웹 익스플로잇 방어

이 시나리오의 핵심 목표는 SQL 인젝션 및 **크로스 사이트 스크립팅(XSS)**과 같이 애플리케이션 레이어(Layer 7)에서 발생하는 일반적인 웹 공격으로부터 웹 애플리케이션을 보호하는 것입니다.

**AWS 웹 애플리케이션 방화벽 (AWS WAF)**은 이 요구 사항을 정확하게 충족하도록 설계된 서비스입니다.

AWS WAF의 역할

  • 웹 트래픽 필터링: AWS WAF는 웹 트래픽을 모니터링하고, 사용자가 정의한 규칙이나 AWS 관리형 규칙에 따라 악성 요청이 애플리케이션에 도달하는 것을 차단합니다.
  • Layer 7 공격 방어:
    • SQL 인젝션: 데이터베이스 쿼리에 악성 코드를 삽입하려는 시도를 차단하는 규칙을 설정할 수 있습니다.
    • 크로스 사이트 스크립팅 (XSS): 웹사이트에 악성 스크립트를 삽입하려는 시도를 차단하는 규칙을 설정할 수 있습니다.
  • 통합: WAF는 Amazon CloudFront, Application Load Balancer(ALB), Amazon API Gateway 등과 통합되어 엣지나 로드 밸런서 수준에서 보호 기능을 제공합니다.

오답이 부적절한 이유

서비스 주요 역할 부적합한 이유
아마존 가드듀티 (Amazon GuardDuty) 지능형 위협 탐지 서비스. AWS 계정 및 워크로드에서 비정상적인 활동이나 잠재적인 위협(예: 무단 접근, 비트코인 채굴)을 지속적으로 모니터링합니다. 실시간으로 웹 익스플로잇을 차단하는 방화벽이 아닙니다.
AWS 클라우드워치 (AWS CloudWatch) 모니터링 및 로깅. 리소스 성능을 추적하고 알림을 설정합니다. 웹 공격을 차단하는 보안 메커니즘이 아닙니다.
아마존 인스펙터 (Amazon Inspector) EC2 인스턴스의 OS 및 애플리케이션 취약점을 평가합니다. 애플리케이션이 이미 가지고 있는 취약점을 찾는 서비스이며, 실시간으로 들어오는 웹 공격 트래픽을 차단하는 서비스가 아닙니다.

따라서 일반적인 웹 익스플로잇에 대한 실시간 방화벽 보호를 제공하는 서비스는 AWS WAF입니다.

 

질문 38

다음 AWS 서비스 중에서 항상 무료로 사용할 수 있는 것은 무엇입니까? (2개 선택)

*

0/1

  • 아마존 다이나모DB
  • AWS ID 및 액세스 관리(AWS IAM)
  • AWS 자동 확장
  • Amazon Elastic Compute Cloud(Amazon EC2)
  • Amazon Simple Storage Service(Amazon S3)

정답은 **AWS ID 및 액세스 관리(AWS IAM)**와 **AWS 자동 확장(AWS Auto Scaling)**입니다.

AWS 서비스 요금 모델: 항상 무료 vs. 프리 티어

AWS에는 세 가지 주요 요금 모델이 있습니다.

  1. 항상 무료 (Always Free): 기간 제한 없이 무료로 사용할 수 있는 서비스입니다.
  2. AWS 프리 티어 (Free Tier): 서비스별로 지정된 사용량까지만 12개월 동안 무료로 제공됩니다.
  3. 종량제 (Pay-as-you-go): 사용한 만큼만 비용을 지불합니다.

주어진 보기 중 **항상 무료(Always Free)**로 제공되어 사용량에 관계없이 요금이 부과되지 않는 서비스는 다음과 같습니다.

1. AWS ID 및 액세스 관리 (AWS IAM)

  • 항상 무료: IAM은 AWS 계정의 보안 및 권한 관리를 위한 기본적인 핵심 서비스이므로, 사용자 생성, 정책 관리, 역할 생성 등 IAM 자체 기능에 대해서는 항상 요금이 부과되지 않습니다.

2. AWS 자동 확장 (AWS Auto Scaling)

  • 항상 무료: Auto Scaling은 애플리케이션의 로드에 따라 EC2 인스턴스 수를 자동으로 조정해주는 서비스입니다. Auto Scaling 서비스 자체 (예: Auto Scaling 그룹 설정, 정책 생성)에는 요금이 부과되지 않습니다. (단, Auto Scaling이 프로비저닝하는 EC2 인스턴스, 로드 밸런서 등 리소스 사용에 대해서는 요금이 부과됩니다.)

오답이 부적절한 이유

서비스 요금 모델 이유
Amazon DynamoDB 프리 티어 및 종량제. 항상 무료는 아니며, AWS 프리 티어를 통해 매월 일정량의 읽기 및 쓰기 용량 단위(WCUs/RCUs)와 스토리지 용량이 12개월 동안 무료로 제공됩니다.
Amazon Elastic Compute Cloud (Amazon EC2) 프리 티어 및 종량제. 항상 무료는 아니며, AWS 프리 티어를 통해 특정 인스턴스 유형(예: t2.micro 또는 t3.micro)에 대해 12개월 동안 매월 최대 750시간이 무료로 제공됩니다.
Amazon Simple Storage Service (Amazon S3) 프리 티어 및 종량제. 항상 무료는 아니며, AWS 프리 티어를 통해 12개월 동안 일정량의 스토리지 용량, GET/PUT 요청 및 데이터 전송량이 무료로 제공됩니다.

따라서 IAM과 Auto Scaling은 서비스 자체 사용에 대해 항상 무료로 제공됩니다.

 

 

질문 42

전자상거래 회사는 추천 엔진의 데이터를 데이터베이스에 저장하려고 합니다. 클라우드 실무자로서 모든 규모에 대해 최소한의 운영 오버헤드로 이 기능을 제공하기 위해 어떤 AWS 서비스를 권장하시겠습니까?

*

0/1

  • Amazon 관계형 데이터베이스 서비스(Amazon RDS)
  • Amazon Simple Storage Service(Amazon S3)
  • 아마존 다이나모DB
  • 아마존 해왕성

정답은 Amazon DynamoDB입니다.

해설: 모든 규모를 위한 최소 운영 오버헤드의 데이터베이스

이 시나리오의 핵심 요구사항은 다음과 같습니다.

  1. 추천 엔진의 데이터를 저장 (높은 트래픽, 예측 불가능한 액세스 패턴)
  2. 모든 규모에 대해 서비스를 제공해야 함 (무한 확장성)
  3. 최소한의 운영 오버헤드 (서버리스 또는 완전 관리형)

Amazon DynamoDB는 이 모든 조건을 충족하는 AWS의 완전 관리형 NoSQL 데이터베이스입니다.

Amazon DynamoDB의 역할

  • 무한 확장성: DynamoDB는 수십억 개의 항목과 초당 수백만 건의 요청을 처리하도록 설계된 NoSQL 데이터베이스입니다. 추천 엔진과 같이 트래픽이 급변하는 워크로드에 완벽하게 대응하여 모든 규모를 지원합니다.
  • 최소 운영 오버헤드: DynamoDB는 **완전 관리형 서비스(서버리스)**입니다. 서버를 프로비저닝하거나 패치, 확장, 백업 등을 관리할 필요가 없습니다. 이는 최소한의 운영 오버헤드를 보장합니다.
  • 낮은 지연 시간: 단 몇 밀리초의 일관된 응답 시간을 제공하여, 실시간으로 작동해야 하는 추천 엔진에 필수적입니다.

오답이 부적절한 이유

서비스 주요 역할 부적합한 이유
Amazon 관계형 데이터베이스 서비스 (Amazon RDS) 관계형 데이터베이스를 관리합니다. 확장성 및 운영 오버헤드. 대규모 트래픽에서 수직적 확장(Scale-up)에 한계가 있으며, 인스턴스 크기 조정, 백업 전략 등 운영 오버헤드가 DynamoDB보다 높습니다.
Amazon Simple Storage Service (Amazon S3) 객체 스토리지 서비스입니다. 데이터베이스가 아님. 데이터를 저장하지만, 초 단위의 낮은 지연 시간으로 쿼리 및 트랜잭션을 처리하는 데이터베이스 기능을 직접 제공하지 않습니다.
아마존 해왕성 (Amazon Neptune) 그래프 데이터베이스 서비스입니다. 그래프 데이터베이스는 관계(Relations)를 모델링하는 데 유용하지만, 대규모 키-값 또는 문서 데이터를 저장하는 추천 엔진의 일반적인 요구 사항에 대해 최소 운영 오버헤드 및 모든 규모 확장성을 제공하는 가장 일반적인 선택지는 DynamoDB입니다.

따라서 모든 규모에서 최소한의 관리 노력으로 안정적인 성능을 제공하는 것은 Amazon DynamoDB입니다.

 

 

질문 44

운영 관점에서 AWS Cloud Adoption Framework(AWS CAF)의 일부인 기본 기능은 무엇입니까?

*

0/1

  • 플랫폼 엔지니어링 >> 플랫폼 관점 
  • 취약점 관리 >> 보안 관점
  • 성능 및 용량 관리 >> 운영 관점
  • 애플리케이션 포트폴리오 관리 >>  거버넌스? 비즈니스? 관점

정답은 성능 및 용량 관리입니다.

해설: AWS CAF의 운영 관점 핵심 기능

AWS Cloud Adoption Framework (AWS CAF)는 클라우드 도입 여정 전반에 걸쳐 조직이 성공적으로 클라우드를 구현할 수 있도록 돕는 프레임워크입니다. CAF는 여섯 가지 관점(Perspective)과 각 관점에 필요한 핵심 기능(Capability)으로 구성되어 있습니다.

질문에서 묻는 **운영 관점 (Operations Perspective)**은 클라우드 환경에서 IT 운영을 효과적으로 실행하고 관리하는 데 필요한 핵심 역량을 다룹니다.

AWS CAF의 운영 관점 (Operations Perspective)

운영 관점은 IT 운영의 일상적인 활동을 다루며, 주요 목표는 클라우드 환경의 안정성과 효율성을 유지하는 것입니다. 이 관점에 포함되는 핵심 기능들은 다음과 같습니다.

핵심 기능 설명
성능 및 용량 관리 클라우드 리소스의 성능을 모니터링하고, 워크로드 수요에 맞춰 용량을 계획하고 확장하는 활동.
서비스 모니터링 애플리케이션 및 인프라의 상태를 지속적으로 관찰하고 알림을 설정하는 활동.
인프라 및 애플리케이션 프로비저닝 리소스 배포 및 관리를 자동화하는 활동.
인시던트 및 문제 관리 서비스 장애 발생 시 신속하게 대응하고 근본 원인을 해결하는 활동.

주어진 보기 중에서 운영 관점의 핵심 기능에 해당하는 것은 **성능 및 용량 관리 (Performance and Capacity Management)**입니다.

오답이 부적절한 이유

  • 애플리케이션 포트폴리오 관리: 비즈니스 관점(Business Perspective) 또는 **플랫폼 관점(Platform Perspective)**의 일부입니다.
  • 플랫폼 엔지니어링: **플랫폼 관점(Platform Perspective)**의 일부입니다.
  • 취약점 관리: **보안 관점(Security Perspective)**의 핵심 기능입니다.

AWS CAF 6가지 관점 (6 Perspectives)

AWS CAF는 조직이 클라우드 여정을 계획하고 실행하는 데 필요한 역할과 역량을 6가지 관점으로 나누어 설명합니다.

CAF 관점 핵심 초점 시나리오와의 연관성
People (인력) 조직 구조, 역할, 책임, 기술, 문화적 변화 관리. 클라우드 도입에 따라 개발팀이 새로운 기술을 배우고, 역할이 바뀌며, 조직 문화가 변화하는 전반적인 인적 변화를 관리합니다.
Business (비즈니스) 비즈니스 가치, 재무 모델, 전략적 목표. 이 관점은 왜 클라우드를 도입하는지(비용 절감, 민첩성 증가 등)에 초점을 맞춥니다.
Operations (운영) 일상적인 운영, 모니터링, 관리 프로세스. 클라우드 도입 이후의 인프라 관리 방식(모니터링, 성능 관리 등)에 초점을 맞춥니다.
Security (보안) 위험 관리, 컴플라이언스, 보안 통제. 클라우드 환경의 보안 요구사항(인증, 접근 제어, 데이터 보호 등)에 초점을 맞춥니다.
Governance (거버넌스) 포트폴리오 관리, 프로그램 및 프로젝트 관리, 규정 준수 및 위험 관리. 클라우드 투자에 대한 전략적 통제를 확립하고, 비즈니스 가치를 달성하기 위해 위험을 관리하고, 규정 준수 정책을 시행하는 방식에 초점을 맞춥니다.
Platform (플랫폼) 핵심 클라우드 인프라 설계, 배포, 네트워크, 데이터베이스, 스토리지 솔루션. 클라우드에서 애플리케이션을 호스팅하기 위한 기반 기술 아키텍처를 구축하는 데 필요한 원칙과 결정을 다룹니다.

 

질문 49

고객이 AWS Cloud 내에 VPC와 서브넷을 생성했습니다. 다음 중 어느 진술이 맞습니까?

*

0/1

  • Amazon Virtual Private Cloud(Amazon VPC)는 해당 지역의 모든 가용 영역(AZ)에 걸쳐 있는 반면, 서브넷은 해당 지역에서 하나의 가용 영역(AZ)에만 걸쳐 있습니다.
  • 서브넷은 지역의 모든 가용성 영역(AZ)에 걸쳐 있는 반면 Amazon Virtual Private Cloud(Amazon VPC)는 지역의 단 하나의 가용성 영역(AZ)에만 걸쳐 있습니다.
  • Amazon Virtual Private Cloud(Amazon VPC)와 서브넷은 모두 해당 지역의 모든 가용성 영역(AZ)에 걸쳐 있습니다.
  • Amazon Virtual Private Cloud(Amazon VPC)와 서브넷은 모두 해당 지역에서 하나의 가용 영역(AZ)에만 걸쳐 있습니다.

정답은 Amazon Virtual Private Cloud(Amazon VPC)는 해당 지역의 모든 가용 영역(AZ)에 걸쳐 있는 반면, 서브넷은 해당 지역에서 하나의 가용 영역(AZ)에만 걸쳐 있습니다. 입니다.

해설: VPC와 서브넷의 지역적 범위

이 질문은 AWS의 네트워크 기본 구조인 **VPC (Virtual Private Cloud)**와 **서브넷(Subnet)**이 AWS의 지리적 구조(리전 및 가용 영역)와 어떻게 연결되는지를 묻고 있습니다.

1. Amazon VPC의 범위 (리전 수준)

  • VPC는 리전(Region)에 걸쳐 있습니다.
  • VPC를 생성하면 해당 AWS 리전 내의 모든 가용 영역(AZ)을 포괄하는 프라이빗 네트워크 공간이 설정됩니다.
  • 따라서 VPC는 단일 AZ에 국한되지 않고, 해당 리전의 모든 AZ에 걸쳐 리소스를 배치할 수 있는 논리적 컨테이너 역할을 합니다.

2. 서브넷의 범위 (AZ 수준)

  • 서브넷은 단일 가용 영역(AZ)에 국한됩니다.
  • VPC 내에서 서브넷을 생성할 때, 해당 서브넷이 위치할 특정 AZ를 지정해야 합니다.
  • 서브넷은 AZ 경계를 넘을 수 없으며, 서브넷 내의 모든 리소스(EC2 인스턴스 등)는 해당 서브넷이 속한 AZ에 위치해야 합니다.

결론

VPC가 리전 전체의 논리적인 범위를 설정하는 반면, 서브넷은 물리적인 범위를 설정하며 가용 영역(AZ) 하나에만 매핑됩니다.

 

 

질문 54

AWS 공유 책임 모델에 따르면 Amazon RDS에 대한 고객의 책임은 다음 중 무엇입니까?

*

0/1

  • Amazon Relational Database Service(Amazon RDS)가 실행되는 기본 서버 하드웨어 관리
  • 데이터베이스 암호화
  • 기본 OS에 패치 적용
  • Amazon Relational Database Service(Amazon RDS) 데이터베이스에 패치 적용

 

정답은 데이터베이스 암호화입니다.

해설: AWS 공유 책임 모델 (Shared Responsibility Model)

AWS 공유 책임 모델은 AWS 클라우드를 사용할 때 AWS와 고객 간의 책임 경계를 명확히 합니다. 이 모델은 "클라우드의 보안(Security of the Cloud)"과 "클라우드 내의 보안(Security in the Cloud)"으로 구분됩니다.

Amazon RDS에 대한 책임 구분

Amazon RDS(관계형 데이터베이스 서비스)는 AWS가 관리형 서비스로 제공하는 PaaS(Platform as a Service)의 예시입니다.

책임 영역 AWS의 책임 (클라우드의 보안) 고객의 책임 (클라우드 내의 보안)
인프라 및 OS 기본 서버 하드웨어 관리, 기본 OS 패치 적용 및 보안, 데이터 센터의 물리적 보안 등. 해당 없음 (AWS가 관리).
데이터베이스 엔진 Amazon RDS 데이터베이스 소프트웨어 패치 적용 및 업데이트(주요 버전 업그레이드는 고객 선택). 해당 없음 (AWS가 관리).
데이터 및 액세스 해당 없음. 데이터베이스 암호화 (저장 데이터 및 전송 중 데이터), 네트워크 액세스 제어(보안 그룹), 사용자 계정 및 권한 관리(IAM).

정답 상세 분석

  • 데이터베이스 암호화: 데이터 자체와 암호화 키 관리는 고객의 책임입니다. 고객은 데이터가 안전하게 저장되도록 저장 중 암호화(Encryption at Rest) 옵션(예: KMS 키 사용)을 선택하고 활성화해야 합니다. (정답)

오답 상세 분석

  • Amazon RDS가 실행되는 기본 서버 하드웨어 관리: AWS의 책임 (클라우드의 보안).
  • 기본 OS에 패치 적용: AWS의 책임. RDS는 기본 OS를 고객에게 노출하지 않고 AWS가 관리합니다.
  • Amazon Relational Database Service(Amazon RDS) 데이터베이스에 패치 적용: 데이터베이스 소프트웨어 자체의 패치 적용은 AWS의 책임입니다.
    • 참고: RDS는 데이터베이스 엔진의 마이너 버전 패치 적용을 자동으로 처리하지만, 주요 버전 업그레이드는 고객이 선택하고 수행해야 하는 영역이므로 약간의 책임이 있지만, 이 보기는 가장 명확한 고객 책임 영역인 데이터 암호화에 비해 덜 정확합니다. 일반적으로 OS 및 DB 엔진 패치는 AWS의 몫으로 간주됩니다.

질문 58

사진 공유 웹 애플리케이션은 Amazon Simple Storage Service(Amazon S3)에 사용자가 업로드한 이미지의 썸네일을 저장하려고 합니다. 썸네일은 거의 사용되지 않지만 웹 애플리케이션에서 즉시 액세스할 수 있어야 합니다. 썸네일은 분실된 경우 쉽게 다시 생성할 수 있습니다. Amazon Simple Storage Service(Amazon S3)에 이러한 썸네일을 저장하는 가장 비용 효율적인 방법은 무엇입니까?

*

0/1

  • Amazon S3 One Zone-Infrequent Access(S3 One Zone-IA)를 사용하여 썸네일 저장
  • Amazon S3 Standard를 사용하여 썸네일 저장
  • Amazon S3 Glacier Flexible Retrieval을 사용하여 썸네일을 저장합니다.
  • Amazon S3 Standard-Infrequent Access(S3 Standard-IA)를 사용하여 썸네일을 저장합니다.

정답은 Amazon S3 One Zone-Infrequent Access(S3 One Zone-IA)를 사용하여 썸네일 저장입니다.

해설: S3 스토리지 클래스 비용 효율성 분석

이 시나리오의 핵심 요구사항은 다음과 같습니다.

  1. 접근 빈도: 썸네일은 거의 사용되지 않지만(Infrequent Access), 필요할 때는 **즉시 액세스(Immediate Access)**할 수 있어야 합니다.
  2. 데이터 복구성: 썸네일은 분실된 경우 쉽게 다시 생성할 수 있습니다. (내구성에 대한 요구사항이 낮음)

이러한 조건을 만족하는 S3 스토리지 클래스는 S3 One Zone-Infrequent Access입니다.

S3 One Zone-IA (가장 비용 효율적인 선택)

특징 설명 요구 사항 충족 여부
저장 비용 S3 Standard-IA보다 20% 저렴합니다. 가장 비용 효율적인 방법입니다.
내구성 데이터를 **단일 가용 영역(AZ)**에만 저장합니다. AZ 장애 발생 시 데이터가 손실될 수 있습니다. 썸네일을 쉽게 다시 생성할 수 있으므로, 단일 AZ 저장의 위험을 감수할 수 있습니다. (비용 절감 가능)
접근성 필요 시 즉시 액세스가 가능합니다. 즉시 액세스 요구 사항을 충족합니다.

다른 옵션이 부적절한 이유

  • Amazon S3 Standard-Infrequent Access (S3 Standard-IA):
    • 문제점: S3 Standard-IA는 데이터를 최소 3개 이상의 AZ에 저장하여 높은 내구성을 제공합니다. 썸네일은 쉽게 다시 생성할 수 있기 때문에 이 추가적인 내구성은 불필요한 비용 낭비입니다.
  • Amazon S3 Standard:
    • 문제점: 가장 비싼 스토리지 클래스입니다. 썸네일은 거의 사용되지 않으므로 빈번한 액세스에 최적화된 Standard를 사용하는 것은 비용 낭비입니다.
  • Amazon S3 Glacier Flexible Retrieval:
    • 문제점: 즉시 액세스 불가. 데이터 검색(Retrieval)에 분~시간 단위의 시간이 소요됩니다. "웹 애플리케이션에서 즉시 액세스할 수 있어야 한다"는 요구 사항을 충족하지 못합니다.

 

질문 61

한 게임 회사는 다양한 위치에 있는 최종 사용자에게 뛰어난 사용자 경험을 보장하기 위해 지연 시간이 짧은 게임 플레이를 일관되게 제공할 수 있는 기술/서비스를 찾고 있습니다.

어떤 AWS 기술/서비스가 최종 사용자에게 필요한 저지연 액세스를 제공할까요?

*

0/1

  • AWS Local Zones
  • AWS Wavelength
  • AWS Edge Locations
  • AWS Direct Connect

정답은 AWS Local Zones입니다.

해설: 저지연 게임 플레이를 위한 AWS 서비스

게임과 같이 지연 시간(Latency)에 매우 민감한 워크로드의 경우, 사용자 요청을 가장 가까운 곳에서 처리하여 왕복 시간(Round-Trip Time, RTT)을 최소화하는 것이 중요합니다.

AWS Local Zones의 역할

  • 리전 확장: AWS Local Zones는 AWS 리전의 인프라를 지리적으로 최종 사용자와 가까운 주요 대도시 지역으로 확장하는 서비스입니다.
  • 저지연 컴퓨팅: Local Zones를 사용하면 EC2 인스턴스, EBS 등 핵심 AWS 서비스를 대도시 지역에 배포할 수 있습니다. 이를 통해 사용자가 애플리케이션에 액세스할 때 발생하는 지연 시간을 단일 밀리초(Single-digit Milliseconds) 수준으로 낮출 수 있습니다.
  • 일관된 경험: 게임 서버를 사용자 위치와 매우 가깝게 호스팅함으로써, 다양한 위치에 있는 최종 사용자에게 일관되게 지연 시간이 낮은 게임 플레이 경험을 제공할 수 있습니다.

다른 서비스가 부적절한 이유

서비스 주요 역할 부적합한 이유
AWS Wavelength 5G 이동통신사의 네트워크 엣지로 AWS 서비스를 확장합니다. Local Zones와 유사하지만, Wavelength는 특히 5G 모바일 장치 사용자를 위한 초저지연 액세스에 중점을 둡니다. 일반적인 "다양한 위치의 최종 사용자"를 포괄하는 더 넓은 개념은 Local Zones입니다.
AWS Edge Locations Amazon CloudFront 및 Route 53이 사용하는 전 세계 캐싱 및 접속 지점입니다. AWS Edge Locations은 Amazon CloudFront의 핵심이며, 주로 다음과 같은 작업에 최적화되어 있습니다.
  • 콘텐츠 캐싱: 웹사이트의 이미지, 동영상, CSS 등 정적 파일을 사용자에게 가장 가까운 지점에서 캐시하여 다운로드 속도를 빠르게 합니다.
  • DNS 쿼리: Amazon Route 53를 통해 DNS 쿼리에 응답하여 사용자에게 최적의 IP 주소를 알려주는 초기 연결 지연 시간을 단축합니다.
문제점: 엣지 로케이션은 대부분 컴퓨팅 자원을 호스팅하지 않습니다. 즉, 게임 플레이의 핵심인 실시간 게임 로직 처리나 서버 상태 동기화를 수행하는 EC2 인스턴스나 DB를 엣지 로케이션에 직접 실행할 수 없습니다. 엣지 로케이션은 데이터를 가져오는 통로 역할이 주를 이룹니다.
AWS Direct Connect 온프레미스 데이터 센터와 AWS 간의 전용 프라이빗 네트워크 연결입니다. 최종 사용자부터 AWS까지의 지연 시간을 줄이는 것이 아니라, 고객의 데이터 센터와 AWS 간의 지연 시간을 줄이는 데 사용됩니다.

따라서 다양한 위치의 일반 최종 사용자에게 저지연 컴퓨팅 용량을 제공하기 위한 가장 적합한 AWS 기술은 AWS Local Zones입니다.

 

 

질문 64

한 IT 회사에서 매주 월요일 오전 2시에 로그 백업 프로세스를 실행하려고 합니다. 일반적인 프로세스 실행 시간은 5분입니다. 클라우드 실무자로서 이 사용 사례에 대한 서버리스 솔루션을 구축하려면 어떤 AWS 서비스를 권장하시겠습니까? (2개 선택)

*

0/1

  • AWS Step Function
  • Amazon Elastic Compute Cloud(Amazon EC2)
  • AWS 람다
  • AWS 시스템 관리자
  • Amazon EventBridge

정답은 **AWS 람다 (AWS Lambda)**와 Amazon EventBridge입니다.

해설: 서버리스 예약 작업 솔루션

이 시나리오의 목표는 **정해진 시간(매주 월요일 오전 2시)**에 짧은 시간(5분) 실행되는 **로그 백업 프로세스(작업)**를 서버리스 방식으로 구현하는 것입니다.

서버리스 예약 작업(Cron Job)을 구축하는 가장 표준적이고 비용 효율적인 AWS 조합은 **Amazon EventBridge (스케줄러)**와 **AWS Lambda (실행기)**입니다.

1. AWS Lambda (실행할 작업)

  • 역할: 서버리스 컴퓨팅 서비스로, 코드를 업로드하면 서버를 관리할 필요 없이 코드를 실행합니다.
  • 적합성: 실행 시간이 5분 이내로 짧은 백업 프로세스에 완벽하게 맞습니다. 서버를 상시 가동할 필요가 없으므로 운영 오버헤드가 없고 비용 효율적입니다.

2. Amazon EventBridge (트리거/스케줄러)

  • 역할: 이벤트 버스 서비스로, 특히 예약 실행(Scheduler) 기능을 제공합니다.
  • 적합성: Cron 표현식을 사용하여 "매주 월요일 오전 2시"와 같이 정확한 시간과 반복 주기를 설정하고, 지정된 시간에 AWS Lambda 함수를 자동으로 호출하여 백업 프로세스를 시작하도록 트리거할 수 있습니다.

오답이 부적절한 이유

  • Amazon Elastic Compute Cloud (Amazon EC2): 서버를 24시간 실행해야 하므로 서버리스 솔루션이 아니며, 운영 오버헤드가 발생합니다.
  • AWS Step Function: 복잡한 다단계 워크플로우를 조정하고 시퀀스를 정의하는 데 사용됩니다. 단일, 간단한 백업 프로세스를 단순히 예약 실행하는 이 시나리오에서는 과도한 서비스입니다.
  • AWS 시스템 관리자 (AWS Systems Manager): 주로 EC2 인스턴스에 대한 운영 자동화 및 패치 관리에 중점을 둡니다. 서버리스 환경의 작업을 예약하는 데 직접적으로 사용되지는 않습니다.

 

질문 65

AWS Compute Optimizer는 다음 중 어떤 AWS 리소스에 대한 권장 사항을 제공합니까? (2개 선택)

*

0/1

  • Amazon Elastic File System(Amazon EFS), AWS Lambda 기능
  • AWS Lambda 함수, Amazon Simple Storage Service(Amazon S3)
  • Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, Amazon Elastic File System(Amazon EFS)
  • Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, Amazon EC2 Auto Scaling 그룹
  • Amazon Elastic Block Store(Amazon EBS), AWS Lambda 기능

정답은 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, Amazon EC2 Auto Scaling 그룹과 Amazon Elastic Block Store(Amazon EBS), AWS Lambda 기능입니다.

해설: AWS Compute Optimizer의 권장 사항 대상

AWS Compute Optimizer는 머신 러닝을 사용하여 고객의 AWS 리소스 사용률 데이터를 분석하고, 성능 저하 없이 비용을 절감하거나 성능을 향상할 수 있도록 최적의 리소스 권장 사항을 제공하는 서비스입니다.

Compute Optimizer가 현재 권장 사항을 제공하는 주요 리소스 유형은 다음과 같습니다.

Compute Optimizer의 주요 권장 대상

  1. Amazon EC2 인스턴스: 현재 인스턴스 유형이 워크로드에 비해 과도하게 또는 과소하게 프로비저닝되었는지 분석하여 최적의 EC2 인스턴스 유형을 추천합니다.
  2. Amazon EC2 Auto Scaling 그룹: Auto Scaling 그룹 내에서 사용되는 인스턴스 유형의 최적화를 추천합니다.
  3. Amazon EBS 볼륨: 볼륨 유형(예: gp3, io1, st1 등)의 성능(IOPS/처리량)이 워크로드에 적합한지 분석하여 비용 효율적인 EBS 볼륨 구성을 추천합니다.
  4. AWS Lambda 기능 (Functions): Lambda 함수의 메모리 설정이 함수의 성능 및 비용에 최적인지 분석하여 메모리 크기 조정을 추천합니다.

정답 상세 분석

주어진 보기 중에서 Compute Optimizer의 현재 지원 대상이 되는 리소스 조합은 다음과 같습니다.

  • Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, Amazon EC2 Auto Scaling 그룹: (EC2 최적화의 핵심 조합)
  • Amazon Elastic Block Store(Amazon EBS), AWS Lambda 기능: (스토리지 및 서버리스 컴퓨팅 최적화 조합)

오답이 부적절한 이유

  • Amazon Elastic File System (Amazon EFS), Amazon Simple Storage Service (Amazon S3):
    • EFS는 Amazon EFS 파일 시스템 최적화를 제공하지만, S3는 현재 Compute Optimizer의 직접적인 최적화 권장 대상이 아닙니다.
  • Amazon Elastic File System (Amazon EFS), AWS Lambda 기능:
    • EFS와 Lambda는 각각 지원 대상이지만, EFS는 옵션에 없습니다.

따라서 가장 정확하고 포괄적인 권장 대상 조합을 포함하는 보기를 모두 선택해야 합니다.

'Cloud > AWS' 카테고리의 다른 글

모의테스트3 재오답노트 개념 정리  (0) 2025.10.14
모의테스트2 재오답노트 개념정리 ★  (1) 2025.10.14
AWS 서비스 관리 유형별 구분 및 책임  (0) 2025.10.14
모의테스트1 재오답노트  (0) 2025.10.14
AWS 클라우드 마이그레이션 서비스 핵심 요약  (0) 2025.10.14

관련글

티스토리툴바