AWS SAA-C03 25번 ~ 32번

25번

답 : D
요약 : 손실없이 데이터 처리를 보장하는 SQS가 합리적
해설 : 이 회사는 어플을 사용하는데 API로 들어온 정보를 Lambda가 받아서 aurora postgre로 전달합니다. 그런데 회사는 대용량을 처리해야하므로 람다 처리량 또한 늘려야합니다. 이에 대비한 새로운 아키텍쳐가 필요한데 설정은 쉬워야하고 스케일링이 적용되어야 합니다. 이 경우 자동 스케일링이 적용되는 관리형 서비스를 써야하기 때문에 A는 탈락하며, 변경도 최소화해야하므로 DB를 바꾸는 B도 탈락합니다. C와 D 모두 스케일링이 적용되지만 SNS는 DB에 정보를 전달하는 로직에서는 적절하지 못한데 그 이유는 람다의 동작을 검증하지 않기 때문입니다. SQS는 큐에 쌓인 메세지를 람다에 전달하고 람다가 처리 후 그 메세지를 삭제하지 않으면 다시 전달하는 메커니즘이 있으나 SNS는 pub/sub 정책으로 최소한 한번 보낸 것으로 만족합니다. 따라서 적합한 아키텍쳐는 D입니다.

26번

답: A
요약: 서비스의 설정(configuration)의 관리는 AWS Config로 할 수 있다.
해설: Trusted Advisor는 아키텍쳐(비용이나 리소스)를 효율적으로 수정해나가도록 도움을 주는 서비스입니다.
Inspactor는 컨테이너 이미지나 인스턴스의 취약점을 분석하는 도구입니다. S3 access log는 이미 접근된 내용을 보기 때문에 설정 자체를 제한하는 기능안 아닙니다. Config는 사용하고 있는 다양한 서비스의 관계 및 권한을 통합적으로 관리할 수 있게 도와주는 서비스입니다. 따라서 답은 A입니다.

27번

답: A
요약: dashboard 하나만 공유해주면 되기 때문에 A가 적합
해설: CloudWatch 대시보드를 만들었습니다. 매니저가 가끔 봐야하기 때문에 대시보드를 공유해주려했는데 AWS 아이디가 없다고 합니다. 이 경우 두 가지 옵션이 떠오릅니다. 하나는 IAM으로 user를 생성해서 readonly권한만 주고 공유하는 것입니다. 다른 하나는 CloudWatch 콘솔에서 생성된 Dashboard에서 이메일 및 아이디 비밀번호 생성을 통해 공유하는 것입니다. 이 문제는 least privilege를 말하고 있습니다. IAM으로 user를 생성하는 옵션은 Dashboard뿐만 아니라 CloudWatch에 있는 모든 정보를 볼 수 있습니다. 반면 A의 경우 그 대시보드만 볼 수 있기 때문에 더 적합한 옵션입니다. 따라서 A입니다.

28번

답: B
요약: on-prem self-managed AD와 클라우드 상의 IAM SSO를 사용하려면 two-way trusted가 요구됩니다.
해설: 저도 이번에 문제를 풀면서 알게되었는데요, 온프렘에서 Microsoft의 AD를 사용하면서 AWS의 IAM 서비스의 SSO를 활성화하여 trusted relationship을 갖게하려면 two-way trusted로 설정하여야 합니다. 아래 Docs에서 정확한 내용을 확인하실 수 있습니다.
https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_setup_trust.html
AD를 다룰 기회가 없었던 저에게는 다소 생소한 문제였네요😥

29번

답: A
요약: Global Accelerator로 모든 요건 충족 가능
해설: 회사는 UDP연결을 사용하면서 낮은 지연을 위해 다중 리전의 사용이 필요합니다. UDP 패킷을 전송해야하기 때문에 로드밸런서는 NLB가 되구요, A와 C가 남는데 이 역시 마찬가지로 UDP패킷이기 때문에 CloudFront를 사용하지 않습니다. Global Acceclerator를 사용하면 다중리전 페일오버 구성이 가능하면서도 동적 서비스의 지연시간을 낮출 수 있으므로 답은 A입니다. 자세한 내용은 아래 링크를 참조하세요.
https://aws.amazon.com/ko/global-accelerator/faqs/ 

 

30번

답: C
요약: 인스턴스를 stop하는 것보다 스냅샷을 찍고 저장해두는 비용이 더 저렴합니다.
해설: 한 달에 48시간 진행하는 테스트를 위해 고성능 DB를 항상 켜 두는 것은 당연히 비용낭비입니다. 따라서 쓸 때만 켜두고 안쓸 때는 꺼두는 것이 좋은데요, 이렇게 사용하지 않는 기간이 길 때에는 인스턴스를 stop 상태로 뒀다가 restart하는 것보다 스냅샷을 찍은 후 terminate한 후 나중에 스냅샷으로 재생성하는 것이 비용상 유리합니다. 물론 인스턴스는 정지 중에는 비용이 발생하지 않지만 볼륨에는 발생하는데요, 고성능 DB는 높은 IOPS로 생성되었을 것이므로 계속 많은 비용이 청구될 것입니다. 따라서 쓰지 않을 때에는 스냅샷만 S3에 보관하여 나중에 사용할 때 재생성하는 것이 가장 바람직한 사용사례가 될 것입니다.

31번

 

답: A
요약: AWS Config를 통해 tag를 갖고있는지 확인하는 rule을 생성하면 쉽게 확인 가능
해설: B는 생성된 테그가 잘 들어가있는 리소스만 확인하는 것이 가능하며, C와 D는 tag가 잘 들어가있는지 확인하기 위해 모든 리소스를 정의해놓아야하는 번거로움이 있습니다. 반면 A는 콘솔에서 tag를 확인하는 규칙만 생성하면 쉽게 만들고 확인할 수 있습니다.

32번

답: B
요약: 모두 정적 컨텐츠이므로 S3를 통해 호스팅하는 것이 가장 저렴합니다.
해설: S3에서 정적 컨텐츠를 배포하는 것이 가장 저렴하면서 효율적인 방식이라는 것은 매우 잘 알려진 best practice입니다. 이번 문제는 HTML, CSS, Client-side JavaScript와 image가 정적 컨텐츠인지를 아는지 물어보는 문제였다고 볼 수 있습니다. 위 컨텐츠 모두 사전 정의된 컨텐츠이며 서버가 사용자의 요청에 따라 새로 가공하는 것이 아니므로 S3를 통해 배포하는 것이 가장 비용 효율적입니다.