a. 수평 확장성
b. 수직 확장성
a. 수평 확장성
b. 수직 확장성
a. 애플리케이션에 사용 가능한 정적 IPv4
b. 애플리케이션에 사용 가능한 정적 DNS 이름
c. 애플리케이션에 사용 가능한 정적 IPv6
a. 웹사이트가 다수의 EC2 인스턴스에서 호스팅되어 문제가 발생
b. IP 주소를 확인할 수 없기 때문에 EC2 인스턴스가 사용자들을 로그아웃 시키고, 그 대신 ELB IP 주소를 받은 것
c. ELB가 고정 세션을 활성화하지 않은 것
a. 웹사이트의 프론트엔드를 수정해 사용자들의 모든 요청에서 자신의 IP를 보낼 수 있도록 만들기
b. 웹사이트의 백엔드를 수정해 X-Forwarded-For 헤더로부터 클라이언트 IP 주소를 가져오도록 만들기
c. 웹사이트의 백엔드를 수정해 X-Forwarded-Port 헤더로부터 클라이언트 IP 주소를 가져오도록 만들기
d. 웹사이트의 백엔드를 수정해 X-Forwarded-Proto 헤더로부터 클라이언트 IP 주소를 가져오도록 만들기
a. ELB 상태 확인 활성화
b. ELB 고착도 활성화
c. SSL 종료 활성화
d. 영역간 로드 밸런싱 활성화
a. ALB
b. CLB
c. NLB
a. HTTP
b. HTTPS
c. TCP
d. WebSocket
a. 클라이언트의 위치(지리적)
b. 호스트 이름
c. 요청 URL 경로
d. 소스 IP-주소
a. EC2 인스턴스
b. NLB
c. 사설 IP 주소
d. .Lambda 함수
a. 탄력적 IP가 연결된 ALB
b. NLB
c. CLB
a. AWSALBAPP
b. APPUSERC
c. AWSALBTG
d. AWSALB
a. 영역간 로드 밸런싱 활성화
b. 고정 세션 활성화
c. ELB 상태 확인 활성화
d. SSL 종료 활성화
a. TLS 종료
b. 서버 이름 표식(SNI)
c. SSL 보안 정책
d. 호스트 헤더
a. HTTP를 HPPTS로 리다이렉팅하는 규칙 사용
b. 보안 그룹 SSL 인증서 사용
c. 서버 이름 표식(SNI) 사용
a. 아무 일도 일어나지 않음
b. 희망 용량은 4까지 올라가는 반면, 최대 용량은 3에 머뭄
c. 희망 용량은 4까지 올라가는 반면, 최대 용량은 4에 머뭄
a. ASG가 인스턴스는 계속 실행하되, 애플리케이션은 재시작할 것
b. ASG가 EC2 인스턴스를 분리하고 실행 상태로 둘 것
c. ASG가 EC2 인스턴스를 종료할 것
a. CloudWatch 사용자 지정 지표를 생성한 후 ASG를 스케일링하기 위한 CloudWatch 경보 생성
b. 불가능한 작업이라고 공손히 설명
c. 상세 모니터링을 활성화한 후 ASG 스케일링을 위한 CloudWatch 경보 생성
a. 단순 조정 정책
b. 단계 조정 정책
c. 대상 추적 조정 정책
d. 예약된 조정 정책
a. 로드 밸런서를 애플리케이션 로드 밸런서로 변경한다
b. 상태 확인 방식을 HTTP로 변경한다
a. 모든 고객에게 HTTPS 대신 HTTP를 사용하라는 이메일을 보낸다
b. 애플리케이션 로드 밸런서가 HTTP를 HTTPS로 리디렉션하도록 설정한다
c. DNS 레코드가 HTTP를 HTTPS로 리디렉션하도록 설정한다
Q_1. (b)
Q_2. (a)
Q_3. (c)
AWS에서 관리하는 기반 인프라가 변경되었다고 하더라도, AWS가 정적 엔드 포인트를 사용해 로드 밸런스로 액세스할 수 있기를 원하는 이유입니다.
Q_4. (c)
ELB 고정 세션 기능은 동일한 클라이언트에 대한 트래픽이 항상 동일한 대상으로 리다이렉트되도록 해줍니다(예: EC2 인스턴스) 이는 클라이언트들이 세션 데이터를 소실하지 않게 해줍니다.
Q_5. (b)
Application Load Balancer를 사용하여 EC2 인스턴스에 트래픽을 배분하는 경우, 요청을 받게 되는 IP 주소는 ALB의 사설 IP 주소가 됩니다. 클라이언트의 IP 주소를 받기 위해, ALB는 클라이언트의 IP 주소를 포함하고 있는 X-Forwarded-For라는 헤더를 추가합니다.
Q_6. (a)
ELB 상태 확인을 활성화하면, ELB가 비정상(충돌) EC2 인스턴스로는 트래픽을 보내지 않게 됩니다.
Q_7. (c)
Network Load Balancer는 애플리케이션이 필요로 할 경우 가장 높은 성능과 가장 낮은 지연 시간을 제공합니다.
Q_8. (c)
Network Load Balancer는 TCP와 UDP 프로토콜을 모두 지원합니다.
Q_9. (a)
ALB는 URL 경로, 호스트 이름, HTTP 헤더 및 쿼리 문자열을 기반으로 트래픽을 다른 대상 그룹으로 라우팅할 수 있습니다.
Q_10. (b)
전용 호스트는 높은 수준의 규정 준수가 필요한 기업, 혹은 복잡한 라이선스 모델을 가진 소프트웨어에 적합합니다. 이는 가장 비싼 EC2 구매 옵션입니다.
Q_11. (b)
Network Load Balancer는 AZ 당 하나의 정적 IP 주소를 가지며, 여기에 탄력적 IP 주소를 연결할 수 있습니다. Application Load Balancer와 Classic Load Balancer를 정적 DNS 이름으로 사용할 수 있습니다.
Q_12. (b)
다음의 쿠키 이름은 ELB가 선점하고 있습니다(AWSALB, AWSALBAPP, AWSALBTG).
Q_13. (a)
영역간 로드 밸런싱을 활성화하면, ELB가 모든 AZ에 있는 등록된 EC2 인스턴스 전체에 동등하게 분배됩니다.
Q_14. (b)
Q_15. (c)
서버 이름 표식(SNI)을 사용하면 동일한 리스너 상에 있는, 자체 SSL 인증서를 가진 다수의 HTTPS 애플리케이션을 노출시킬 수 있습니다.
Q_16. (a)
오토 스케일링 그룹은 스케일 아웃 시, (구성된) 최대 용량을 넘어설 수 없습니다.
Q_17. (c)
오토 스케일링 그룹이 EC2 상태 확인(기본 설정)이 아닌 Application Load Balancer의 상태 확인을 기반으로 EC2 인스턴스의 상태를 판단하도록 구성할 수 있습니다. EC2 인스턴스가 ALB의 상태 확인에 실패할 경우, 이는 비정상인 것으로 표시되어 종료되며 ASG는 새로운 EC2 인스턴스를 실행합니다.
Q_18. (a)
백엔드-데이터베이스 연결에는 ‘분당 요청'에 해당하는 CloudWatch 지표가 존재하지 않습니다. CloudWatch 경보를 생성하려면 CloudWatch 사용자 지정 지표를 먼저 생성해야 합니다.
Q_19. (c)
ALB만이 EC2 인스턴스로 액세스할 수 있게 할 수 있는 가장 안전한 방법입니다. 규칙에서 보안 그룹을 참조하는 것은 매우 강력한 규칙으로, 이 내용을 바탕으로 많은 시험 문제가 출제됩니다. 그러니 이에 관련된 내용은 반드시 숙지하도록 하세요!
Q_20. (b)
NLB는 TCP, HTTPS 및 HTTP 상태 확인을 지원합니다.
Q_21. (b)