Practice Test #1

각 account에서 EC2에 cron 기반 스크립트를 실행하는 방식은 상당한 관리 오버헤드(instance, patching, IAM, scheduling, scaling)를 유발합니다. 5분 간격은 즉시 탐지가 아니며 정책 위반이 지속될 수 있습니다. RDS에 로깅하는 것은 비용과 관리를 추가하며, 여전히 기본 제공 컴플라이언스 보고를 제공하지 않습니다. 이 접근 방식은 운영적으로 무겁고 AWS managed 거버넌스 패턴과 맞지 않습니다.

Lambda는 서버 관리를 줄이지만, 옵션은 “프로그래밍 방식으로 확인”이라고 설명하여 이벤트 기반 탐지보다는 polling을 의미합니다. polling은 여전히 즉시성이 없고 scheduling 및 custom 상태 저장이 필요합니다. account별 OpenSearch는 비용이 크고 운영이 복잡하며, AWS Config가 제공하는 직관적인 컴플라이언스 이력 및 감사 뷰를 제공하지 않습니다. SAM은 배포에 도움이 되지만 거버넌스/보고는 여전히 custom입니다.

GuardDuty는 위협 탐지 서비스이며 NAT gateway 생성에 대한 표준 finding type을 제공하지 않습니다(언급된 finding type은 일반적인 GuardDuty taxonomy가 아닙니다). 설령 이벤트를 캡처하더라도 S3에 런타임 로그를 저장하는 것은 rule 평가 및 타임라인을 갖춘 컴플라이언스 이력과 동일하지 않습니다. 또한 이 옵션은 AWS Config보다 컴플라이언스 거버넌스에 덜 신뢰할 수 있는 방식으로 서비스를 혼합합니다.

옵션 B는 두 개의 10 Gbps 연결만 사용하며, 각 Direct Connect location당 하나씩이고 각각 다른 라우터에 종단됩니다. 대역폭은 충분하지만, 이 설계는 location당 회선이 하나뿐이므로 단일 회선 장애가 발생하면 해당 location을 통한 모든 연결이 사라집니다. 이는 4개 연결 설계보다 회선 수준 복원력이 낮으며, 회선 장애를 견뎌야 한다는 요구 사항에도 덜 부합합니다. 최대 복원력을 위한 AWS 모범 사례는 여러 location과 라우터에 걸쳐 여러 연결을 사용하는 것입니다.

옵션 C는 총 4 Gbps를 제공하는 4개의 1 Gbps 연결을 제공하지만, 이는 정상 운영 중에만 가능합니다. 단일 회선에 장애가 발생하면 사용 가능한 대역폭은 3 Gbps로 떨어지며, 더 이상 4 Gbps 전송 요구 사항을 충족하지 못합니다. 마찬가지로 라우터 하나에 장애가 발생하고 두 개의 회선이 해당 라우터에 연결되어 있다면 2 Gbps만 남습니다. 따라서 이 옵션은 가용성 관점에서는 복원력이 있지만, 지정된 장애 시나리오 동안 필요한 처리량을 유지하지는 못합니다.

옵션 D는 2개의 1 Gbps 연결만 제공하므로 최대 총 처리량은 2 Gbps입니다. 이는 장애를 고려하기 전에도 명시된 4 Gbps 피크 트래픽 요구 사항을 충족하기에 부족합니다. 또한 회선 하나 또는 라우터 하나를 잃으면 용량은 더 줄어듭니다. 이 옵션은 대역폭과 복원력 요구 사항을 모두 충족하지 못합니다.

가장 운영 효율적인 방식이 아닙니다. DynamoDB 기반 Lambda updater는 커스텀 자동화, IAM role, 오류 처리, 그리고 모든 계정에 대한 배포 및 유지 관리를 필요로 합니다. function이 실패하거나 잘못 구성되면 운영 오버헤드와 드리프트 가능성이 생깁니다. 동작은 가능하지만, 중앙에서 CIDR allow list를 관리하도록 설계된 네이티브 VPC 구성 요소를 사용하는 것보다 확장성이 떨어지고 덜 우아합니다.

이 선택지는 prefix list가 변경될 때마다 security group을 업데이트하기 위해 EventBridge와 Lambda를 추가하므로, 사용자 지정 orchestration과 운영 오버헤드를 다시 도입하게 되어 덜 효율적입니다. Prefix list가 선택된 추상화라면, 목표는 지원되는 곳에서 이를 직접 사용하는 것이어야지 security group rule을 다시 작성하도록 코드를 트리거하는 것이어서는 안 됩니다. 또한 필요한 cross-account 공유 메커니즘이 빠져 있으므로, multi-account 중앙 관리 요구 사항을 완전히 해결하지 못합니다.

옵션 A와 유사하게, 운영 부담이 더 큰 커스텀 자동화 접근 방식입니다. CIDR을 S3에 저장하고 Lambda를 실행하여 계정 간 security group을 업데이트하려면 계정별 배포, cross-account permission, 그리고 장애 및 동시성에 대한 견고한 처리가 필요합니다. AWS RAM을 통해 공유되는 managed prefix list를 사용하는 것만큼 효율적이거나 확장 가능하지 않습니다. 이 방식은 해당 사용 사례를 위해 목적에 맞게 설계되어 있습니다.

오답입니다. AWS Site-to-Site VPN은 개별 원격 사용자용 Client VPN이 아니라 네트워크 간 연결(예: 온프레미스와 VPC)을 위한 것입니다. 사용자를 Site-to-Site VPN으로 마이그레이션하려면 새로운 customer gateway 디바이스/구성이 필요하며 지리적 위치 문제를 직접 해결하지도 못합니다. 또한 Client VPN 라우팅을 조정하는 것에 비해 서비스 중단과 운영 변경이 큽니다.

오답입니다. Client VPN endpoint security group에서 0.0.0.0/0 아웃바운드 규칙을 제거해도 지리적 위치 문제를 유발하는 라우팅 문제는 해결되지 않습니다. 오히려 VPN 클라이언트에서 내부 리소스(및 필요할 수 있는 AWS 서비스)로의 정상적인 아웃바운드 연결을 깨뜨릴 가능성이 높아 불필요한 중단을 초래합니다. 지리적 위치는 SG 규칙이 아니라 egress 경로/IP에 의해 결정됩니다.

오답입니다. 다른 VPC에서 Client VPN endpoint를 삭제하고 재생성하는 것은 매우 중단이 큽니다(새 endpoint, association, authorization rules, 클라이언트 구성 업데이트 필요). egress IP 범위를 바꿔 지리적 위치가 달라질 수는 있지만, 근본 원인(인터넷 트래픽이 AWS를 통해 라우팅되는 풀 터널)을 해결하지 못합니다. split-tunnel과 라우트 변경이 최소 중단 해결책입니다.

NLB origins와 Route 53 weighted routing을 사용하는 CloudFront distributions는 일부 트래픽 전환을 제공할 수 있지만, CloudFront는 NLB 뒤의 임의의 애플리케이션 프로토콜에 대한 일반적인 TCP/UDP 프런트 도어로 의도되지 않았습니다. 또한 weighted DNS는 DNS 해석 이후에도 트래픽이 퍼블릭 인터넷을 통과하므로 jitter/first-byte latency를 본질적으로 최소화하지 못합니다. 이 옵션은 TCP/UDP 및 jitter 요구 사항을 가장 잘 충족하지 못하는 방식으로 서비스를 혼합하고 있습니다.

S3 Transfer Acceleration은 edge locations를 사용하여 Amazon S3로의 업로드/다운로드를 가속하는 기능일 뿐이며, EC2/NLB 기반 multi-tier 애플리케이션의 프런트 도어 역할을 하지 못하고 NLB endpoints로의 TCP/UDP listener 라우팅도 제공하지 않습니다. 또한 애플리케이션 스택의 단계적 롤아웃을 위한 필요한 multi-Region traffic dials도 제공하지 않습니다. 서비스가 요구 사항과 맞지 않습니다.

CloudFront origin groups는 주로 origin failover(기본/보조)를 위한 것이며, 일반적인 TCP/UDP 애플리케이션 트래픽보다는 HTTP/HTTPS 콘텐츠 전송에 초점이 맞춰져 있습니다. Route 53 latency routing은 사용자를 더 낮은 지연의 Regions로 스티어링할 수 있지만, Global Accelerator traffic dials처럼 롤아웃 비율을 정밀하게 제어할 수 없고, AWS backbone을 통한 라우팅만큼 jitter/first-byte latency를 효과적으로 줄이지도 못합니다.

오답입니다. Amazon CloudFront는 주로 HTTP/HTTPS를 위한 CDN이며 NLB 오리진으로의 범용 UDP 가속 경로를 제공하지 않습니다. CloudFront가 웹 전달을 위해 특정 TCP 기반 오리진을 앞단에 둘 수는 있지만, 독점 UDP 센서 프로토콜을 프록시하도록 설계되지 않았습니다. UDP 가속과 static anycast 인그레스를 위해서는 Global Accelerator가 적절한 AWS 서비스입니다.

오답입니다. Route 53 failover routing은 active-passive이며 기본 endpoint가 비정상(unhealthy)일 때 가용성을 제공하기 위한 것입니다. 지연 시간을 최적화하지 않으며, 기본 endpoint가 정상인 상태에서 발생하는 간헐적 패킷 손실을 해결하지 못합니다. 또한 “패킷이 드롭됨”은 Route 53이 플로우 단위로 감지할 수 있는 것이 아니며, DNS failover는 UDP 텔레메트리 스트림에 비해 거칠고 느립니다.

오답입니다. ENA를 통한 enhanced networking은 패킷이 인스턴스에 도달한 이후에 EC2 네트워크 성능(더 높은 bandwidth, 더 낮은 latency, 더 높은 PPS)을 개선합니다. 설명된 문제는 남아시아에서 us-west-2로 공용 인터넷을 통해 전송되는 과정에서, 트래픽이 AWS에 도착하기 전에 발생하는 패킷 손실입니다. ENA는 장거리 경로의 신뢰성을 실질적으로 개선하거나 인터넷 라우팅 관련 손실을 줄이지 못합니다.

이 옵션은 기본 ALB listener rule이 path-pattern 또는 source-ip와 같은 조건을 포함하도록 수정될 수 없기 때문에 잘못되었습니다. 기본 rule은 항상 무조건적이며, 모든 더 높은 priority rules가 확인된 후에만 평가됩니다. 또한 조건이 일치하지 않을 때 management target group으로 전달한다고 설명하는데, 이는 원하는 동작과 반대입니다. group-level stickiness는 이 잘못된 listener-rule 설계를 해결하지 못합니다.

이 옵션은 ALB listener rules가 X-Forwarded-For header를 검사하는 대신 native source-ip 조건을 사용해야 하므로 잘못되었습니다. X-Forwarded-For는 여러 주소를 포함할 수 있으며, ALB listener rule matching을 위한 의도된 access-control primitive가 아닙니다. 요구 사항은 specifically on-premises source CIDR ranges로 액세스를 제한하는 것이며, 이는 ALB가 직접 지원합니다. group-level stickiness는 유용할 수 있지만, 여기의 트래픽 매칭 방식은 기술적으로 부적절합니다.

이 옵션은 모든 요청을 web app target group으로 전달하면 /management path가 management target group으로 라우팅되지 못하므로 잘못되었습니다. 또한 stickiness를 비활성화하라고 하는데, 이는 management application의 stateful 특성과 충돌합니다. 올바른 ALB 구성에는 /management를 위한 특정한 더 높은 priority rule과 나머지 모든 것에 대한 별도의 기본 action이 필요합니다. 이 옵션은 필요한 listener-rule 조합을 구현하지 않습니다.

TGW는 VPC-to-VPC 확장성을 개선하지만, TGW와 SD-WAN transit VPC 사이에 Site-to-Site VPN을 사용하는 경우 여전히 VPN tunnel 구성을 기반으로 하며, 설계에 따라 더 수동적인 라우팅(static route 또는 제한적인 동적 동작)이 필요할 수 있습니다. 동작은 가능하지만, SD-WAN 통합을 위해 목적에 맞게 설계되고 BGP 기반의 동적 route 교환을 제공하는 TGW Connect에 비해 운영 오버헤드가 가장 낮지는 않습니다.

VPC peering은 이 사용 사례에 대해 확장성이 좋지 않습니다: non-transitive(허브를 구축하려 할 때의 핵심 제한)이며, VPC 수가 증가할수록 많은 peering 연결을 관리해야 하고, peer당 route table entry가 증가합니다. 또한 현재 모델 대비 운영 오버헤드를 본질적으로 줄이지 못하며 route table 확장 문제를 다시 유발할 수 있습니다.

이는 서로 맞지 않는 두 가지 확장 접근 방식을 혼합합니다: VPC 연결에 VPC peering(비전이적이며 대규모에서 운영 부담이 큼)을 사용하고, SD-WAN 통합에는 TGW Connect를 사용합니다. SD-WAN 통합이 개선되더라도 VPC-to-VPC 및 VPC-to-hub 연결은 여전히 peering의 확장/관리 제한을 겪게 되므로, 전체 요구 사항을 가장 적은 운영 오버헤드로 충족하지 못합니다.

오답입니다. VPC Reachability Analyzer는 VPC 내 경로를 확인하는 데 적절한 도구이지만, 감지 메커니즘이 잘못되었습니다. 네트워크 구성 변경(security group, NACL, route table)은 기본적으로 CloudWatch에 “로그로 기록”되는 것이 아니라 AWS CloudTrail에 기록되는 control-plane API call입니다. CloudTrail log를 CloudWatch Logs로 전달할 수는 있지만, 표준적이고 가장 직접적인 event 트리거는 EventBridge가 CloudTrail event를 매칭하는 방식입니다.

오답입니다. Transit Gateway Network Manager Route Analyzer는 단일 VPC 내 리소스 간 연결성을 검증하는 데 가장 적합한 도구가 아니며, 특히 장애 원인이 security group 또는 NACL일 수 있는 경우에는 더 그렇습니다. 또한 이 옵션은 변경 사항이 “CloudWatch에 기록”된다는 전제에 의존하는데, 이는 구성 변경 event의 주요 소스가 아닙니다. 이 조합은 CloudTrail + Reachability Analyzer만큼 명확하게 요구 사항을 충족하지 못합니다.

오답입니다. CloudTrail은 올바른 변경 감지 소스이지만, Transit Gateway Network Manager Route Analyzer는 요구 사항에 맞지 않는 분석 도구입니다. 문제는 SG/NACL/route table 변경 후 단일 VPC 내 중요한 애플리케이션 리소스 간 연결성 검증을 요구합니다. VPC Reachability Analyzer는 이러한 VPC 구성 요소를 직접 평가하는 반면, TGW Route Analyzer는 TGW route propagation/association 및 attachment routing에 초점을 맞추며 전체 VPC reachability 의미론을 다루지 않습니다.