실전 문제

문제 1

한 회사는 온프레미스 데이터 센터에 연결된 두 개의 AWS Direct Connect 링크를 보유하고 있습니다. 한 Direct Connect 링크는 us-east-1 Region에서 종단되고, 다른 Direct Connect 링크는 af-south-1 Region에서 종단됩니다. 회사는 AWS와 경로를 교환하기 위해 BGP를 사용하고 있습니다. 회사의 온프레미스 환경은 AWS로 가는 기본 경로로 us-east-1 링크를 사용하고, 보조(백업) 경로로 af-south-1 링크를 사용하도록 구성되어야 합니다. 네트워크 엔지니어는 온프레미스 라우터에서 BGP를 구성하여 AWS로 향하는 모든 트래픽에 대해 us-east-1 링크가 우선되도록 하고, 기본 링크에 장애가 발생한 경우에만 af-south-1 링크가 사용되도록 해야 합니다. 이 솔루션은 표준 BGP 속성과 AWS BGP community tags를 사용해야 합니다. 네트워크 엔지니어는 af-south-1이 AWS로 가는 보조 링크로 사용되도록 보장하기 위해 BGP를 어떻게 구성해야 합니까?

문제 분석

핵심 개념: 이 문제는 customer-side BGP best-path selection과 AWS Direct Connect BGP communities를 결합하여 두 개의 AWS Direct Connect 연결에서 결정적인 primary/backup routing을 구축하는 방법을 테스트합니다. 온프레미스 router는 AWS로 향하는 트래픽에 대해 us-east-1 session에 더 높은 local preference를 할당하여 이를 선호해야 하며, af-south-1 session은 더 낮은 local preference로 backup으로 처리되어야 합니다. AWS 측에서는 customer가 backup DX를 통해 광고하는 route에 AWS low-local-preference community를 태그하여 두 경로가 모두 사용 가능할 때 AWS가 return traffic에 대해 primary DX를 선호하도록 해야 합니다. 정답인 이유: 올바른 설계는 us-east-1 BGP peer에 더 높은 local preference를 설정하고 af-south-1 BGP peer에 더 낮은 local preference를 설정하여 enterprise network가 AWS로 나가는 outbound traffic에 대해 항상 us-east-1을 먼저 선택하도록 하는 것입니다. 또한 af-south-1 link에는 AWS community 7224:7300을 태그해야 하며, 이는 AWS가 해당 연결에서 학습한 route에 더 낮은 local preference를 할당하도록 지시합니다. 이렇게 하면 AWS에서 온프레미스로 돌아오는 경로에서 af-south-1이 덜 선호되는 경로가 되어 primary path가 실패하지 않는 한 backup으로 동작합니다. 주요 특징: - Local Preference는 customer AS 내부에서 사용되는 표준 BGP attribute이며, 값이 높을수록 선호됩니다. - AWS Direct Connect는 customer prefixes를 향한 inbound traffic에 대해 AWS local preference에 영향을 주기 위해 7224:7300과 같은 BGP communities를 지원합니다. - 두 제어를 함께 사용하면 대칭적인 primary/backup 의도를 제공합니다: outbound traffic에 대한 customer-side preference와 return traffic에 대한 AWS-side preference입니다. 일반적인 오해: - 많은 수험자가 AWS DX communities와 customer local preference를 혼동합니다. AWS communities는 customer가 광고하는 route를 AWS가 처리하는 방식에 영향을 주며, router의 best-path decision에는 영향을 주지 않습니다. - 또 다른 흔한 실수는 7224:7100이 일반적으로 'primary'를 의미하고 7224:7300이 'secondary'를 의미한다고 가정하는 것입니다. 실제로는 7224:7300이 backup path를 덜 선호하도록 만드는 명시적인 low-preference community입니다. - 또한 local preference 값을 반대로 설정하기 쉬운데, 그렇게 하면 backup link가 standby가 아니라 active가 됩니다. 시험 팁: - customer-to-AWS path preference의 경우, 먼저 customer router의 local preference를 보십시오: primary에는 높게, backup에는 낮게 설정합니다. - AWS-to-customer return path preference의 경우, backup path에서 AWS local preference를 낮추는 AWS DX community(일반적으로 7224:7300)를 찾으십시오. - 어떤 선택지가 local preference는 올바르게 설정했지만 low-preference AWS community를 primary link에 적용했다면, 그것은 최선의 정답이 아닙니다.

문제 2

(2개 선택)

한 회사의 보안 정책에 따라 AWS VPC에서 온프레미스 데이터 센터로 나가는 모든 아웃바운드 트래픽은 서드파티 보안 어플라이언스에 의해 검사되어야 합니다. 이 어플라이언스는 VPC 내의 Amazon EC2 인스턴스에서 실행됩니다. 한 네트워크 엔지니어가 온프레미스 데이터 센터와 이 보안 어플라이언스 간의 네트워크 성능을 개선하는 업무를 맡았습니다. 기존 연결은 인터넷을 통한 표준 VPN입니다. 현재 성능은 온프레미스 사용자에게 병목이 되고 있습니다. 네트워크 엔지니어는 온프레미스 데이터 센터와 EC2 기반 보안 어플라이언스 간의 네트워크 성능을 개선해야 합니다. 솔루션은 이 특정 트래픽 흐름에 대해 처리량을 늘리고 지연 시간을 줄이는 데 초점을 맞춰야 합니다. 이러한 요구 사항을 충족하기 위해 네트워크 엔지니어가 수행해야 할 작업은 무엇입니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 특정 트래픽 경로(온프레미스에서 EC2 기반 검사 어플라이언스로)의 EC2 네트워크 성능 최적화를 평가합니다. 병목은 데이터 센터와 EC2 인스턴스 사이에 있으므로, VPC 라우팅 구성 요소를 변경하기보다는 인스턴스의 패킷 처리 및 네트워크 I/O 기능을 개선하는 데 초점을 맞춰야 합니다. 정답이 맞는 이유: A (enhanced networking)는 SR-IOV 기반 드라이버(ENA 또는 Intel VF)를 사용하여 더 높은 처리량과 더 일관된 성능을 제공함으로써 초당 패킷 수(PPS)를 직접 증가시키고 지연 시간과 지터를 줄입니다. 이는 PPS 및 패킷당 오버헤드에 민감한 네트워크 어플라이언스(방화벽/IDS/IPS)에 대한 주요 모범 사례입니다. C (EC2 인스턴스 크기 증가)도 정답입니다. AWS에서 네트워크 성능은 인스턴스 타입/크기와 강하게 연관되어 있습니다. 더 큰 인스턴스는 일반적으로 더 높은 기본 및 버스트 대역폭, 더 높은 PPS, 그리고 암호화/검사를 위한 더 많은 CPU 리소스를 제공합니다. 서드파티 보안 어플라이언스의 경우, 특히 deep packet inspection을 수행할 때 NIC 처리량만큼이나 CPU와 메모리가 제한 요인이 될 수 있습니다. 주요 AWS 기능 / 모범 사례: - 네트워킹에 최적화된 인스턴스 패밀리(예: ENA를 사용하는 Nitro 기반 인스턴스)를 사용하고 AMI/드라이버에서 ENA가 활성화되어 있는지 확인합니다. - 예상 처리량에 충분한 “Network bandwidth” 및 “PPS”를 제공하는 인스턴스 크기를 선택하고, 검사 처리를 위한 CPU 여유도 고려합니다. - VPN이 전체적으로 제한 요인이라면 일반적인 아키텍처 단계는 AWS Direct Connect이지만, 여기서는 선택지에 없으므로 가능한 최선의 조치는 EC2 어플라이언스의 네트워킹과 용량을 최적화하는 것입니다. 흔한 오해: - Transit Gateway (B)를 선택해 “성능을 개선”하려는 유혹이 있지만, TGW는 라우팅 허브이며 단일 EC2 어플라이언스 경로에 대해 처리량/지연 시간을 본질적으로 개선하지 않습니다. 또한 추가 홉을 더합니다. - Placement group (D)는 EC2 인스턴스 간의 낮은 지연 시간의 east-west 트래픽에 도움이 되며, VPN을 통한 온프레미스-EC2 트래픽에는 해당되지 않습니다. - 여러 ENI (E)는 단일 플로우에 대해 대역폭을 집계하지 않으며 복잡성을 증가시킵니다. 처리량 확장은 보통 적절한 인스턴스 타입/크기 선택과 enhanced networking, 또는 로드 밸런싱 뒤에서 어플라이언스를 수평 확장하는 방식으로 수행합니다. 시험 팁: 문제가 “EC2 인스턴스로의” 성능 개선을 요구할 때는 먼저 enhanced networking(ENA/SR-IOV), 인스턴스 타입/크기의 네트워크 한계, 그리고 패킷 처리를 위한 CPU를 떠올리십시오. 라우팅 구성 요소(TGW, placement group)는 문제가 명시적으로 멀티 VPC 연결, east-west 지연 시간, 또는 라우팅 규모에 관한 경우에만 선택하고, 순수한 어플라이언스 처리량 향상 목적에는 선택하지 마십시오.

문제 3

한 회사가 최근 개발자가 VPC 네트워크 인프라를 시작(launch)하는 것을 금지하는 보안 정책을 구현했습니다. 이 정책은 VPC에서 NAT gateway가 시작(launch)될 때마다 회사의 네트워크 보안 팀이 NAT gateway를 종료(terminate)하기 위해 즉시 알림을 받아야 한다고 명시합니다. 네트워크 보안 팀은 가능한 한 최소한의 관리 오버헤드로 AWS accounts 전반에 배포할 수 있는 솔루션을 구현해야 합니다. 또한 이 솔루션은 네트워크 보안 팀이 컴플라이언스 이력을 간단하게 확인할 수 있는 방법을 제공해야 합니다. 이 솔루션은 어떤 VPC에서든 NAT Gateway 생성 여부를 탐지하고, 보안 팀에 알림을 보내며, 리소스를 자동으로 종료하고, 컴플라이언스에 대한 과거 기록을 제공해야 합니다. 또한 최소한의 수동 작업으로 여러 AWS accounts에 쉽게 배포할 수 있어야 합니다. 다음 중 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 여러 AWS accounts에 걸친 거버넌스 및 컴플라이언스 자동화를 테스트합니다. 가장 적합한 패턴은 지속적인 리소스 컴플라이언스 평가를 위한 AWS Config와 자동 remediation(AWS Systems Manager Automation), 그리고 멀티 account 배포(AWS CloudFormation StackSets)의 조합입니다. 정답이 맞는 이유: custom AWS Config rule은 금지된 리소스(NAT gateways)가 존재하거나 생성되는지 평가할 수 있으며, 시간 경과에 따른 컴플라이언스 상태 변경을 기록합니다. 이는 AWS Config가 리소스별 및 rule별로 구성 변경과 컴플라이언스 결과의 타임라인을 제공하므로 “컴플라이언스 이력을 간단하게 확인할 수 있는 방법” 요구 사항을 직접 충족합니다. SSM Automation remediation action을 연결하면 보안 팀이 자동으로 대응할 수 있습니다. 즉, 알림을 전송(일반적으로 automation 또는 Lambda 단계에서 SNS/SES 통합 사용)한 다음 EC2 API를 호출하여 NAT gateway를 삭제할 수 있습니다. 마지막으로 StackSets는 AWS Organizations에서 많은 accounts(및 OUs)에 동일한 Config rule, IAM roles, SSM runbooks를 일관되게 배포하기 위한 최소 관리 오버헤드 방식을 제공합니다. 주요 AWS 기능: - AWS Config custom rules: 리소스를 평가하고 컴플라이언스 이력을 유지. - SSM Automation을 통한 remediation: 표준화되고 감사 가능한 runbooks; 비컴플라이언스 시 자동 remediation으로 설정 가능. - CloudFormation StackSets: drift detection과 함께 중앙에서 멀티 account/멀티-Region 롤아웃. - Well-Architected (Security pillar): 지속적 모니터링, 자동 remediation, 중앙 집중식 거버넌스. 일반적인 오해: - “생성 이벤트만 탐지하면 된다”: 이벤트 기반 탐지만으로는(예: 주기적 스크립트 또는 임시 로그) 내구성 있는 컴플라이언스 이력과 표준화된 보고가 부족한 경우가 많습니다. - “GuardDuty가 NAT gateway 생성을 탐지한다”: GuardDuty는 위협 탐지용이며, NAT gateway 생성은 일반적인 GuardDuty finding type이 아닙니다. - “EC2에서 cron이 가장 간단하다”: 운영 부담이 증가하고, 실시간이 아니며, 기본 제공 컴플라이언스 보고를 제공하지 않습니다. 시험 팁: 멀티 account 배포, 최소 오버헤드, 자동 remediation, 컴플라이언스 이력 같은 요구 사항이 보이면 AWS Config + (SSM Automation remediation) + StackSets/Organizations를 떠올리십시오. AWS Config는 컴플라이언스 타임라인과 감사 준비가 된 이력을 위한 정석 서비스입니다.

문제 4

한 회사가 온프레미스 데이터 센터에서 AWS로 애플리케이션을 마이그레이션하고 있으며, 온프레미스 메인프레임과의 데이터 교환이 필요합니다. 솔루션은 피크 트래픽에 대해 4 Gbps 전송 속도를 달성해야 하며, 회선 또는 라우터 장애에 대한 고가용성과 복원력을 보장해야 합니다. 4 Gbps를 지원하고 회선 또는 라우터 장애를 견딜 수 있는 고가용성, 복원력 있는 네트워킹 솔루션을 설계하십시오. 다음 중 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 대역폭과 장애 허용을 모두 고려한 AWS Direct Connect 복원력 설계를 평가합니다. 요구 사항은 정상 운영 시 4 Gbps에 도달하는 것만이 아니라, 회선 또는 라우터 장애를 견디면서도 필요한 트래픽을 계속 지원할 수 있는 고가용성 및 복원력 있는 솔루션을 설계하는 것입니다. Direct Connect 설계에서는 여러 Direct Connect location과 여러 고객 라우터에 걸쳐 중복 연결을 제공하고, 장애 발생 후에도 충분한 잔여 용량을 보장해야 함을 의미합니다. 정답인 이유: 옵션 A는 두 개의 Direct Connect location에 분산되고 두 개의 별도 온프레미스 라우터에 종단되는 네 개의 10 Gbps Direct Connect 연결을 사용합니다. 이 설계는 회선, location, 라우터 수준의 단일 장애 지점을 제거합니다. 단일 회선 장애, 전체 라우터 장애, 또는 하나의 Direct Connect location을 사용할 수 없게 되는 상황이 발생하더라도, 남아 있는 링크는 여전히 요구되는 4 Gbps 처리량을 훨씬 초과하여 제공합니다. 따라서 대역폭 목표와 복원력 요구 사항을 동시에 명확하게 충족하는 유일한 옵션입니다. 주요 AWS 기능 / 모범 사례: - 시설 수준 중복성을 위해 최소 두 개의 Direct Connect location을 사용합니다. - 단일 라우터 장애가 연결을 중단시키지 않도록 별도의 customer edge router를 사용합니다. - 단일 회선이 병목 또는 단일 장애 지점이 되는 것을 방지하기 위해 여러 물리적 연결을 사용합니다. - 정상 상태뿐 아니라 장애 시나리오 중에도 필요한 처리량을 계속 사용할 수 있도록 총 용량을 산정합니다. 흔한 오해: - 문제에서 회선 또는 라우터 장애에 대한 복원력을 명시적으로 요구하는 경우, 정상 조건에서만 4 Gbps를 충족하는 것으로는 충분하지 않습니다. - 4개의 1 Gbps 링크는 단일 회선 장애 후에는 3 Gbps만 남기 때문에 4 Gbps 요구 사항을 충족하지 못합니다. - 2개의 10 Gbps 링크는 충분한 대역폭을 제공하지만, 두 라우터와 두 location에 분산된 4개 링크와 동일한 회선 수준 복원력을 제공하지는 않습니다. 시험 팁: AWS networking 시험 문제에서는 장애 중에도 대역폭이 유지되어야 하는지에 특히 주의하세요. 문제가 설계가 회선 또는 라우터 장애를 견뎌야 한다고 말하면, 그러한 장애 중 하나가 발생한 후에도 필요한 처리량이 계속 지원 가능해야 한다고 가정하세요. 가장 복원력 있는 Direct Connect 패턴은 여러 연결, 여러 location, 여러 고객 라우터를 사용하고 장애를 견딜 수 있을 만큼 충분한 여유 용량을 갖추는 것입니다.

문제 5

(3개 선택)

한 회사는 두 개의 10 Gbps 연결로 구성된 Link Aggregation Group (LAG)을 사용하는 AWS Direct Connect private VIF를 사용하고 있습니다. 회사의 보안 팀은 외부 네트워크 연결이 layer 2 encryption을 제공해야 한다는 새로운 요구 사항을 구현했습니다. 회사의 네트워크 팀은 새로운 요구 사항을 충족하기 위해 Direct Connect에 대한 MACsec 지원을 사용할 계획입니다. 네트워크 팀은 서비스를 중단하지 않고 가능한 한 최소한의 다운타임으로 기존 Direct Connect 연결의 private VIF에 MACsec encryption을 구현해야 합니다. 이 기능을 구현하기 위해 네트워크 팀이 수행해야 하는 단계 조합은 무엇입니까? (세 개를 선택하세요.)

문제 분석

핵심 개념: 이 문제는 Link Aggregation Group (LAG)과 private VIF를 사용할 때 AWS Direct Connect MACsec (IEEE 802.1AE)을 통한 Layer 2 encryption과, 최소 다운타임으로 이를 도입하는 방법을 평가합니다. MACsec은 물리/링크 계층 encryption 기능으로, MACsec을 지원하는 포트/회선이 필요하며 Connectivity Association Key (CAK)와 Connection Key Name (CKN)을 사용해 보안 연결을 설정합니다. 정답이 맞는 이유: 기존 LAG에서 사용 중인 private VIF를 중단하지 않기 위해, 최소 다운타임 접근 방식은 MACsec을 지원하는 경로를 병렬로 구축한 다음 트래픽을 마이그레이션하는 것입니다. MACsec을 지원하지 않는 회선/포트에서는 MACsec을 “켜는” 것이 불가능하며, 운영 중인 프로덕션 LAG에서 MACsec을 활성화하면 반대편이 동시에 구성되지 않았을 경우 링크 플랩이 발생할 수 있습니다. 따라서 네트워크 팀은 (1) MACsec을 명시적으로 지원하는 새로운 Direct Connect 연결로 새 LAG를 생성하고, (2) 해당 새 LAG에 CAK/CKN을 연결(associate)하며, (3) 새 LAG에서 MACsec encryption mode를 구성해야 합니다. 검증 후 private VIF/트래픽을 새로운 암호화 연결로 통제된 전환(cutover) 방식으로 이동할 수 있습니다. 주요 AWS 기능: Direct Connect MACsec은 CAK/CKN과 encryption mode(예: should_encrypt 또는 must_encrypt)를 사용하여 연결/LAG 수준에서 구성됩니다. MACsec은 IPsec이 아니며 IKE를 사용하지 않습니다. LAG는 링크 이중화/집계를 제공하지만, MACsec 지원 여부는 기반이 되는 dedicated connection과 해당 포트에 종속됩니다. 일반적인 오해: 자주 발생하는 함정은 MACsec을 IPsec VPN (IKE)과 혼동하는 것입니다. 또 다른 오해는 MACsec 지원 회선/포트를 확인하지 않고 기존 LAG에서 MACsec을 인플레이스(in place)로 활성화할 수 있다고 가정하는 것입니다. 또한 일관된 동작을 위해 LAG 수준에서 MACsec을 관리하려는 의도라면, 구성은 “각 멤버 연결별”로 수행하는 것이 아니라 LAG 수준에서 수행하는 것으로 이해해야 합니다. 시험 팁: 요구 사항이 Direct Connect에서 Layer 2 encryption을 지정하면 MACsec을 떠올리세요(VPN이 아님). “최소 다운타임”이라면 병렬 구축 + cutover를 선호합니다. 선택지에 IKE가 언급되면, 거의 확실히 MACsec이 아니라 IPsec VPN을 의미합니다. 또한 포트/회선이 MACsec을 지원한다는 문구를 확인하세요. 하드웨어 지원 여부가 핵심 제약 조건입니다.

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

문제 6

(2개 선택)

한 투자 플랫폼은 모든 인터넷 서비스 트래픽을 로깅하고 2년 동안 보관해야 합니다. dev에서 팀은 mirror target으로 Network Load Balancer (NLB)를 사용하는 cross‑account Amazon VPC Traffic Mirroring 설계를 검증했습니다. production에서는 mirroring이 활성화되어 있지만 일부 트래픽이 미러링되지 않으며 누락된 패킷은 무작위로 나타납니다. 이 설계에서 간헐적/유실된 mirrored traffic에 대한 그럴듯한 설명을 식별하십시오. 어떤 진술이 모든 트래픽이 미러링되지 않는 이유를 설명합니까? (두 개 선택.)

문제 7

한 핀테크 회사는 여러 AWS 계정에 걸쳐 여러 개발 환경을 보유하고 있으며, 모두 us-east-1 Region에서 운영되고 있습니다. 이러한 환경은 private subnet 내의 Amazon EC2 instance에서 백엔드 서비스를 호스팅하며, public subnet에 있는 Network Load Balancer (NLB)를 통해 액세스됩니다. 규정 준수(compliance) 이유로, 이러한 서비스에 대한 API 액세스는 소수의 승인된 third-party vendor로 제한됩니다. NLB의 security group은 특정 vendor IP address range 집합에서 오는 port 443의 inbound TCP traffic만 허용하도록 구성되어 있습니다. 회사에는 새로운 vendor가 온보딩될 때마다 해당 IP address range를 모든 계정의 NLB security group에 추가해야 한다는 엄격한 정책이 있습니다. 네트워크 엔지니어는 모든 계정 전반에서 이러한 vendor IP address range를 중앙에서 관리할 수 있는 가장 운영 효율적인 방법을 찾아야 합니다. 네트워크 엔지니어는 새로운 vendor의 IP address range를 단일 중앙 위치에서 한 번만 업데이트할 수 있는 솔루션을 구현해야 합니다. 그런 다음 이 변경 사항이 각 계정에서 수동 개입 없이 모든 관련 계정의 security group에 자동으로 반영되어야 합니다. 솔루션은 매우 효율적이고 확장 가능해야 합니다. 다음 중 이러한 요구 사항을 가장 운영 효율적으로 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 여러 AWS 계정 전반에서 승인된 vendor CIDR 범위를 최소한의 운영 오버헤드로 중앙 관리하는 방법을 테스트합니다. 이상적인 패턴은 사용자 지정 동기화 로직을 구축하는 대신, 한 번 업데이트한 후 널리 재사용할 수 있는 네이티브 AWS networking 구성을 사용하는 것입니다. 그러나 공유된 모든 network 리소스를 routing에서 사용하는 방식과 동일하게 계정 간 security group에서 참조할 수 있는 것은 아니므로 주의가 필요합니다. 정답인 이유: 제공된 선택지 중에서 managed prefix list를 사용하는 것이 여전히 중앙 집중식이고 확장 가능한 설계에 가장 가까운 선택입니다. 이는 vendor CIDR 범위를 유지 관리하기 위한 단일 객체를 제공하기 때문입니다. Prefix list는 재사용 가능한 CIDR 관리를 위해 특별히 설계되었으며, DynamoDB 또는 S3에 CIDR를 저장하고 모든 계정에서 Lambda로 업데이트를 오케스트레이션하는 것보다 운영 측면에서 훨씬 더 효율적입니다. 핵심 이점은 추적하고 업데이트해야 하는 개별 CIDR 항목 수를 줄이는 것이며, 원래 설명이 시사하는 것보다 정확한 cross-account security group 사용은 더 제한적일 수 있습니다. 주요 AWS 기능: - VPC Managed Prefix Lists: allow-list 관리를 단순화할 수 있는 재사용 가능한 CIDR block 모음입니다. - AWS RAM: customer-managed prefix list를 포함한 특정 리소스를 계정 간에 공유할 수 있게 합니다. - 운영 효율성: 정적인 allow-list 배포에는 일반적으로 사용자 지정 event-driven automation보다 네이티브 networking 구성이 더 바람직합니다. 흔한 오해: 흔한 오해 중 하나는 공유된 모든 network 객체가 로컬인 것처럼 자동으로 계정 간 security group에서 정확히 동일하게 참조될 수 있다는 것입니다. 또 다른 오해는 Lambda 기반 동기화가 네이티브 구성과 효율성 면에서 동등하다는 것입니다. 실제로는 사용자 지정 automation이 deployment, IAM, retry, drift-management 오버헤드를 추가합니다. Prefix list는 복잡성을 줄여 주지만, 정확히 지원되는 integration은 항상 검증해야 합니다. 시험 팁: AWS networking 시험에서 반복되는 CIDR allow list를 중앙에서 유지 관리해야 하는 경우, managed prefix list가 일반적으로 가장 먼저 고려해야 할 서비스입니다. 또한 네이티브 AWS 기능과 사용자 지정 automation을 비교하고, 문제가 명시적으로 bespoke orchestration을 요구하지 않는 한 네이티브 옵션을 선호하세요. 특히 security group이 관련된 cross-account 사용 사례에서는 service-integration 경계를 주의 깊게 살펴보세요.

문제 8

회사의 온프레미스 방화벽이 단일 Site‑to‑Site VPN으로 AWS Transit Gateway에 연결되어 있습니다. 트래픽 증가로 인해 이제 VPN이 포화 상태입니다. 회사는 온프레미스에서 여러 VPC로의 VPN 처리량을 확장할 수 있는 보안적이고 고가용성인 설계가 필요합니다. 가용성이나 보안을 희생하지 않고 집계 VPN 대역폭을 늘려야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 AWS Transit Gateway(TGW)로 들어오는 AWS Site-to-Site VPN 연결의 확장성과 고가용성을 테스트합니다. 핵심 개념은 여러 VPN tunnel/attachment 사용, BGP 기반 동적 라우팅, 그리고 Equal-Cost Multi-Path (ECMP)를 사용하여 복원력을 유지하면서 집계 처리량을 증가시키는 것입니다. 정답이 맞는 이유: Transit Gateway에 여러 개의 동적(BGP) Site-to-Site VPN 연결을 생성하고 ECMP를 활성화하면 트래픽을 여러 VPN tunnel/경로에 병렬로 분산할 수 있습니다. 단일 Site-to-Site VPN 연결에는 이미 HA를 위한 두 개의 tunnel이 포함되지만, 단일 VPN 연결 자체가 처리량 병목이 될 수 있습니다. 추가 VPN 연결(각각 두 개의 tunnel 포함)을 더하고 BGP와 ECMP를 사용하면 온프레미스 방화벽과 TGW가 여러 tunnel에 걸쳐 flow를 로드 셰어링하여 집계 대역폭을 늘리면서도 중복성을 유지할 수 있습니다. 이 설계는 보안(IPsec)과 고가용성(여러 연결에 걸친 여러 tunnel)을 모두 유지합니다. 주요 AWS 기능 / 모범 사례: - Transit Gateway는 동적 라우팅(BGP)을 사용할 때 VPN attachment에 대해 ECMP를 지원합니다. 이는 VPN 처리량을 확장하기 위한 표준 AWS 접근 방식입니다. - 용량과 복원력을 모두 개선하기 위해 여러 VPN 연결을 사용합니다(가능하다면 여러 customer gateway device 또는 동일 device에서 지원되는 여러 public IP 사용). - BGP는 자동 route 교환과 정적 route보다 빠른 failover를 제공하며, 이 맥락에서 ECMP 로드 셰어링 동작을 위해 필요합니다. - 이 패턴은 AWS Well-Architected(Reliability 및 Performance Efficiency): 중복성 + 수평 확장과 일치합니다. 흔한 오해: - “두 개의 tunnel이면 대역폭이 두 배”: 단일 VPN의 두 tunnel은 주로 HA를 위한 것이며, ECMP를 사용하고 device가 이를 지원하지 않으면 로드 셰어링이 보장되지 않습니다. - “정적 route가 더 단순”: 정적 라우팅은 일반적으로 TGW VPN에서 ECMP를 방해하며, failover 및 라우팅 변경이 수동이어서 운영 복원력이 떨어집니다. - “VPN acceleration이 포화를 해결”: acceleration은 지연/jitter를 줄일 수 있지만, 집계 처리량을 확장하기 위해 필요한 병렬 경로를 대체하지는 못합니다. 시험 팁: “TGW + VPN 포화 + 더 많은 대역폭 필요 + HA 유지”를 보면 “여러 BGP VPN + ECMP”를 떠올리십시오. 문제가 여러 VPC에 걸친 처리량 확장을 강조한다면 TGW가 허브이며, 동적 라우팅과 ECMP가 정석적인 AWS 정답입니다. 특정 요구 사항이 없는 한 자체 관리 VPN appliance보다 관리형 AWS 네트워킹 기능을 우선하십시오.

문제 9

(3개 선택)

한 회사는 AWS Client VPN을 사용하여 원격 사용자가 여러 개의 피어링된 VPC와 온프레미스 데이터 센터의 리소스에 액세스할 수 있도록 합니다. Client VPN endpoint route table에는 단일 0.0.0.0/0 항목이 있으며, 해당 security group에는 인바운드 규칙이 없고 0.0.0.0/0로의 모든 트래픽을 허용하는 아웃바운드 규칙이 있습니다. 원격 사용자는 웹 검색 결과에서 잘못된 지리적 위치 정보가 표시된다고 보고합니다. 서비스 중단을 최소화하면서 Client VPN 사용자에 대한 잘못된 지리적 위치 문제를 해결하십시오. 서비스 중단이 가장 적도록 이 문제를 해결하기 위해 네트워크 엔지니어가 수행해야 할 단계 조합은 무엇입니까? (세 가지 선택)

문제 분석

핵심 개념: 이 문제는 AWS Client VPN의 라우팅 동작(풀 터널 vs split-tunnel), Client VPN route table, 그리고 기본 라우트(0.0.0.0/0)가 인터넷 egress 및 인지되는 지리적 위치에 미치는 영향을 평가합니다. 풀 터널에서는 모든 클라이언트 트래픽(웹 브라우징 포함)이 VPN을 통해 라우팅되고 VPC의 인터넷 경로(NAT Gateway/IGW)로 egress되므로, 웹 서비스가 사용자의 로컬 ISP가 아니라 AWS egress IP를 기준으로 위치를 추정하여 사용자의 위치가 잘못 표시될 수 있습니다. 정답이 맞는 이유: 원격 사용자가 잘못된 지리적 위치를 보는 이유는 Client VPN endpoint route table에 단일 0.0.0.0/0 라우트가 있어 사실상 모든 트래픽이 VPN을 통해 강제로 전달(풀 터널)되기 때문입니다. 가장 중단이 적은 해결책은 내부/사설 네트워크에 대해서만 VPN을 사용하도록 유지하면서 일반 인터넷 트래픽을 AWS로 보내지 않도록 하는 것입니다. 이를 위해 (B) split-tunnel을 활성화하여 Client VPN에 명시적으로 연결된 라우트만 클라이언트에 푸시되도록 하고, (F) 0.0.0.0/0 라우트를 제거하여 VPN이 모든 목적지를 끌어들이지 않게 하며, (C) 피어링된 VPC CIDRs 및 온프레미스 CIDRs에 대한 구체적인 라우트를 추가하여 내부 리소스 액세스가 계속 동작하도록 합니다. 주요 AWS 기능: Client VPN은 route table과 authorization rules를 사용하여 클라이언트가 트래픽을 보낼 수 있는 위치를 제어합니다. Split-tunnel은 클라이언트의 기본 라우트가 VPN으로 리디렉션되는지 여부를 결정합니다. 0.0.0.0/0를 제거하고 내부 CIDR 라우트만 추가하면 내부 연결성을 보장하면서 로컬 인터넷 브레이크아웃(및 올바른 지리적 위치)을 유지할 수 있습니다. 이는 중앙집중식 egress를 통한 불필요한 트래픽을 줄이고 영향 범위를 제한함으로써 AWS Well-Architected(보안 및 신뢰성)와도 부합합니다. 일반적인 오해: security group 변경(예: 0.0.0.0/0 아웃바운드 제거)은 라우팅/지리적 위치 문제를 해결하지 못하며 오히려 액세스를 깨뜨릴 수 있습니다. 다른 VPC에서 endpoint를 재생성하면 egress IP가 바뀔 수는 있지만 여전히 인터넷이 AWS를 통해 라우팅되어 중단을 유발하며 근본 원인을 해결하지 못합니다. Site-to-Site VPN으로 전환하는 것은 다른 사용 사례이며 원격 사용자에 대한 최소 중단 해결책이 아닙니다. 시험 팁: Client VPN + 0.0.0.0/0 라우트 + “인터넷/지리적 위치 문제”를 보면 “풀 터널로 인해 AWS egress가 발생”을 떠올리십시오. 일반적인 개선책은 endpoint를 재구축하거나 VPN 유형을 바꾸는 것이 아니라, split-tunnel과 필요한 네트워크에 대한 명시적 사설 라우트를 사용하는 것입니다.

문제 10

한 제조 회사의 AWS 워크로드와 온프레미스 리소스를 통합하기 위한 private DNS 설계 작업을 네트워크 엔지니어가 수행하고 있습니다. AWS 배포는 eu-west-1 Region의 5개 VPC로 구성되어 있으며, 이들은 AWS Direct Connect를 통해 온프레미스 네트워크에 연결됩니다. VPC들은 transit gateway를 사용하여 서로 통신합니다. 각 VPC는 corp.global.internal 도메인을 사용하는 private hosted zone과 연결되어 있습니다. 네트워크 엔지니어는 shared services VPC에 Amazon Route 53 Resolver outbound endpoint를 생성하고, shared services VPC를 transit gateway에 연결합니다. 네트워크 엔지니어는 DNS resolution을 위한 솔루션을 구현해야 하며, 여기서 corp.global.internal로 끝나는 hostname에 대한 쿼리는 AWS 내의 private hosted zone을 사용해야 하고, 그 외 모든 도메인에 대한 쿼리는 private 온프레미스 DNS resolver로 전달되어야 합니다. 이 솔루션은 중앙 집중식이어야 하며 5개 VPC 전체에서 작동해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 11

한 유럽 자동차 제조업체가 두 개의 데이터 센터(50마일 간격)에서 AWS로 고객 대면 서비스와 분석을 이전하고 있습니다. 워크로드는 eu‑west‑3 및 eu‑central‑1의 계정 전반에 걸쳐 있습니다. 각 Region에서 회사는 복원력이 있는 1 Gbps DX 회선 2개를 주문합니다. 네트워크는 모든 VPC와 온프레미스를 상호 연결하고, Regional 분리를 유지하며, Regions 간 장애 조치를 제공해야 합니다. DX를 통한 multi‑Region 연결을 설계하여 전체 VPC 도달성과 cross‑Region 복원력을 제공하십시오. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 Direct Connect Gateway(DXGW)와 AWS Transit Gateway(TGW)를 사용하여 확장 가능하고 full-mesh VPC 연결성과 복원력 있는 온프레미스 연결을 제공하면서, Regional 분리를 보존하고 cross-Region 장애 조치를 가능하게 하는 AWS Direct Connect multi-Region 설계를 평가합니다. 정답이 맞는 이유: 옵션 C만이 모든 요구 사항을 깔끔하게 충족하는 설계입니다: (1) 모든 VPC와 온프레미스 상호 연결, (2) Regional 분리 유지(각 Region이 자체 라우팅 도메인을 가짐), (3) cross-Region 복원력 제공. DXGW는 Direct Connect를 위한 글로벌 연결 지점을 제공하며 여러 TGW(서로 다른 Regions 포함)와 연동될 수 있습니다. Region별로 TGW를 1개씩 배포하고 transit VIF를 사용해 각 TGW를 DXGW에 연결하면, 온프레미스 네트워크는 복원력 있는 DX 회선을 통해 두 Regional TGW 모두에 도달할 수 있습니다. 이후 TGW를 피어링하면 eu-west-3와 eu-central-1의 VPC 간에 제어된 cross-Region 연결을 제공할 수 있습니다. 한 Region(또는 해당 DX 경로)에 문제가 생기면, 남아 있는 DX 연결성과 TGW peering 경로를 통해 라우팅이 다른 Region으로 장애 조치될 수 있으며, 동시에 각 Region의 VPC 연결은 해당 Region의 TGW에 로컬로 유지됩니다. 주요 AWS 기능: - DXGW + transit VIF: DX가 TGW에 연결되도록(직접 VPC가 아님) 하며, 대규모 multi-account/multi-VPC를 지원합니다. - Region별 TGW 1개: Regional 분리를 유지하고 단일 글로벌 라우팅의 광범위한 영향 범위를 방지합니다. - TGW peering: 두 TGW 간 cross-Region VPC-to-VPC 및 전이 라우팅을 제공하며(명시적 route table 제어 포함). - 복원력: Region당 DX 회선 2개(이상적으로는 서로 다른 위치)와 BGP 경로 선택을 통한 장애 조치. 흔한 오해: - VGW에 private VIF를 사용하는 방식(옵션 A)은 더 단순해 보이지만, “모든 VPC”로 확장하기 어렵고 관리형 cross-Region VPC 상호 연결을 깔끔하게 제공하지 못합니다. - 두 Regions에 대해 단일 TGW를 사용하는 것(옵션 B)은 TGW가 Regional 리소스이므로 유효하지 않습니다. 또한 “inter-Region LAG”는 DX의 구성 요소가 아닙니다. - private VIF와 TGW 연결을 혼합하는 것(옵션 D)은 개념적으로 일관되지 않습니다. DXGW-to-TGW에는 transit VIF가 필요하며, “inter-Region LAG” 역시 적용되지 않습니다. 시험 팁: 기억할 점: TGW는 Regional이고, DXGW는 글로벌입니다. 많은 VPC가 있는 multi-Region DX의 일반적인 패턴은 DX 회선 -> DXGW(transit VIF) -> Region별 TGW, 그리고 cross-Region 연결 및 장애 조치를 위한 TGW peering입니다. “inter-Region LAG” 같은 유효하지 않은 용어와, 소수의 VPC를 넘어 확장되지 않는 설계를 주의하십시오.

문제 12

스타트업 회사의 애플리케이션 팀이 AWS Cloud에 새로운 multi-tier 애플리케이션을 배포하고 있습니다. 이 애플리케이션은 공개적으로 액세스 가능한 Network Load Balancer (NLB) 뒤에서 Auto Scaling group으로 실행되는 Amazon EC2 인스턴스 플릿에서 호스팅됩니다. 애플리케이션은 클라이언트가 UDP 트래픽과 TCP 트래픽을 모두 처리해야 합니다. 단기적으로 애플리케이션은 동일한 지리적 위치 내의 사용자에게만 서비스를 제공할 예정입니다. 애플리케이션 팀은 애플리케이션을 글로벌 사용자로 확장할 계획이며, 최종 사용자에게 애플리케이션을 더 가깝게 제공하기 위해 전 세계 여러 AWS Regions로 배포를 이동할 예정입니다. 애플리케이션 팀은 새로운 Regions를 사용하여 애플리케이션의 새 버전을 배포하고, 이러한 롤아웃 동안 각 Region이 수신하는 트래픽 양을 제어할 수 있기를 원합니다. 또한 애플리케이션 팀은 최종 사용자의 first-byte latency와 jitter(무작위 지연)를 최소화해야 합니다. 애플리케이션 팀은 TCP와 UDP 트래픽을 모두 처리하고, 여러 AWS Regions로의 트래픽 분산을 제어하여 단계적 글로벌 롤아웃을 지원하며, 최종 사용자의 지연 시간과 jitter를 줄일 수 있는 네트워크 아키텍처를 설계해야 합니다. 이러한 요구 사항을 충족하기 위해 애플리케이션 팀은 애플리케이션의 네트워크 아키텍처를 어떻게 설계해야 합니까?

문제 분석

핵심 개념: 이 문제는 TCP와 UDP를 모두 필요로 하는 multi-Region 애플리케이션에 대해, 롤아웃 중 제어된 트래픽 전환을 수행하면서 latency와 jitter를 최소화하는 글로벌 네트워크 프런트 도어를 테스트합니다. 핵심 서비스는 AWS Global Accelerator (AGA)이며, 이는 anycast static IP를 제공하고 사용자 트래픽을 AWS 글로벌 네트워크를 통해 가장 가까운 정상 endpoint로 라우팅합니다. 정답이 맞는 이유: AWS Global Accelerator는 TCP와 UDP를 모두 지원하며, 가능한 한 경로의 대부분에서 퍼블릭 인터넷 대신 AWS backbone에 트래픽을 유지함으로써 first-byte latency를 개선하고 jitter를 줄이도록 특별히 설계되었습니다. 또한 Region별 endpoint groups를 사용한 multi-Region active-active 아키텍처와, 단계적 롤아웃을 지원합니다. traffic dial을 사용하면 배포 중 각 Region으로 전송되는 트래픽 비율을 정밀하게 제어할 수 있습니다(예: 1% canary, 이후 10%, 50% 등). 각 Region의 공개적으로 액세스 가능한 NLB를 endpoint로 등록하는 것은 NLB 뒤의 EC2 Auto Scaling에 대한 표준 패턴입니다. 주요 AWS 기능: - Anycast static IPs: 전 세계적으로 하나의 IP 세트를 제공하여 클라이언트 구성과 failover를 단순화합니다. - Listeners and port ranges: 필요한 TCP/UDP 포트를 endpoints에 매핑합니다. - Endpoint groups per Region: Region별 health checks 및 라우팅 결정을 제공합니다. - Traffic dials: 제어된 롤아웃을 위한 퍼센트 기반 트래픽 전환을 제공합니다. - Health-based failover: 비정상 endpoints에서 자동으로 트래픽을 우회 라우팅합니다. 일반적인 오해: CloudFront는 종종 “global acceleration”을 위해 선택되지만, CloudFront는 주로 HTTP/HTTPS(및 제한된 기타 프로토콜)를 위한 CDN/edge caching 서비스이며, NLB 뒤의 일반적인 TCP/UDP 애플리케이션 트래픽에는 적합하지 않습니다. Route 53 weighted/latency routing은 트래픽을 전환할 수 있지만, DNS에 의존하고 이름 해석 이후 경로가 퍼블릭 인터넷을 따르기 때문에 AGA처럼 jitter/first-byte latency를 줄이지는 못합니다. 시험 팁: (1) TCP + UDP, (2) 퍼센트 제어가 가능한 multi-Region 트래픽 스티어링, (3) latency/jitter 감소 요구 사항이 보이면, endpoint groups와 traffic dials를 사용하는 AWS Global Accelerator를 떠올리십시오. Route 53는 DNS 기반 스티어링용이고, CloudFront는 caching/HTTP 가속용이며, AGA는 non-HTTP 및 성능 민감한 글로벌 진입 지점에 적합합니다.

문제 13

TGW가 DX gateway 및 19개의 VPC에 연결되어 있습니다. 두 개의 새 VPC(10.0.32.0/21 및 10.0.40.0/21)가 추가로 연결될 예정입니다. allowed prefix list에는 항목을 하나만 더 추가할 수 있는 여유가 있습니다. prefix-list 항목 제한을 유지하면서 AWS에서 on‑premises로 라우트를 광고(Advertise)해야 합니다. 엔지니어는 무엇을 해야 합니까?

문제 분석

핵심 개념: 이 문제는 transit gateway (TGW)가 연결되어 있을 때 Direct Connect gateway (DXGW) allowed prefix list가 어떤 AWS prefix를 온프레미스로 광고할지 어떻게 제어하는지를 테스트합니다. allowed prefix list는 사실상 AWS에서 온프레미스로의 route advertisement에 대한 whitelist이며, 각 CIDR은 하나의 항목을 소비합니다. 목록에 항목 하나만 더 추가할 수 있는 여유가 있을 때, 엔지니어는 가능하다면 유효한 aggregate route를 사용해야 합니다. 정답인 이유: 새로운 두 VPC CIDR인 10.0.32.0/21과 10.0.40.0/21은 모두 단일 aggregate인 10.0.32.0/20으로 포함할 수 있습니다. 두 /21 범위가 서로 인접해 있지는 않지만, 둘 다 해당 /20 supernet 안에 포함되므로 DXGW allowed prefix list에 10.0.32.0/20을 추가하면 항목 하나만 사용하면서 두 VPC route 모두를 온프레미스로 광고할 수 있습니다. 이는 prefix-list 항목 제한을 유지하면서 route-advertisement 요구 사항을 충족합니다. 주요 특징: DXGW allowed prefixes는 DXGW/TGW 연결을 통해 BGP로 온프레미스에 광고되는 AWS 측 route를 결정합니다. Route summarization은 광고되는 prefix 수를 줄이고 서비스 제한 내에 머무르기 위해 일반적으로 사용됩니다. AWS managed prefix lists는 Direct Connect BGP advertisement 제어와는 관련이 없습니다. 이는 security groups 및 route tables 같은 VPC 구성 요소에서 재사용 가능한 CIDR 집합으로 사용됩니다. 흔한 오해: 흔한 실수는 AWS managed prefix lists와 DXGW allowed prefix list를 혼동하는 것입니다. 또 다른 함정은 완전히 인접한 prefix만 summarization할 수 있다고 가정하는 것입니다. 실제로는 더 넓은 범위를 광고하는 것이 허용된다면 더 큰 aggregate를 사용할 수 있습니다. 여기서 핵심 시험 단서는 allowed prefix list에 항목 하나만 추가할 수 있다는 제한이며, 이는 DXGW allowed prefix list에서 단일 aggregate를 사용해야 함을 강하게 시사합니다. 시험 팁: DXGW, TGW, 그리고 allowed prefix list가 보이면 VPC routing이나 security-group 구성 요소보다 AWS에서 온프레미스로의 BGP route advertisement에 집중하세요. 여러 VPC CIDR을 하나의 supernet 항목으로 표현할 수 있는지 확인하세요. 또한 선택지가 CIDR을 올바른 AWS 기능에 배치하는지도 확인하세요: AWS managed prefix list가 아니라 DXGW allowed prefix list여야 합니다.

문제 14

(2개 선택)

한 IoT 회사가 미국과 남아시아에 배포된 수천 개의 센서에서 데이터를 수집합니다. 센서는 UDP 기반으로 구축된 독점 통신 프로토콜을 사용하여 데이터를 Amazon EC2 인스턴스 플릿으로 전송합니다. 인스턴스는 Auto Scaling 그룹에 있으며 Network Load Balancer (NLB) 뒤에서 실행됩니다. 인스턴스, Auto Scaling 그룹, NLB는 us-west-2 Region에 배포되어 있습니다. 회사의 데이터에 따르면 남아시아의 센서에서 전송된 데이터가 공용 인터넷을 통해 전송되는 과정에서 간헐적으로 손실되어 EC2 인스턴스에 도달하지 못합니다. 회사는 남아시아 센서에서 발생하는 데이터 손실 문제를 해결할 솔루션이 필요합니다. 솔루션은 센서에서 애플리케이션으로 향하는 UDP 트래픽에 대해 신뢰할 수 있고 지연 시간이 짧은 경로를 제공해야 하며, 장거리 구간에서 네트워크 성능을 최적화하기 위해 AWS 서비스를 활용해야 합니다. 어떤 솔루션이 이 문제를 해결할 수 있습니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 장거리 UDP 트래픽이 AWS로 유입될 때 신뢰성과 지연 시간을 개선하는 방법을 평가합니다. 핵심 서비스는 공용 인터넷 인그레스를 AWS 글로벌 네트워크로 최적화하는 AWS Global Accelerator (GA)와, Amazon Route 53 latency-based routing을 사용하는 멀티-Region 아키텍처입니다. 정답이 맞는 이유: A (Global Accelerator + 기존 NLB)는 센서에 anycast static IP를 제공하여 가장 가까운 AWS edge location에서 트래픽을 종단(terminate)하게 함으로써 공용 인터넷에서의 패킷 손실과 가변적인 성능 문제를 해결합니다. 그 이후 트래픽은 AWS global backbone을 통해 Regional endpoint(즉, us-west-2의 NLB)로 전달됩니다. 이는 특히 남아시아에서 us-west-2로의 경로에서 best-effort 인터넷 라우팅 대비 일반적으로 jitter를 줄이고 경로 안정성을 높이며 지연 시간을 낮춥니다. C (`ap-south-1`에 두 번째 스택 + Route 53 latency routing)은 남아시아 센서에 더 가까운 위치에 컴퓨팅을 배치하여 물리적 거리와 인터넷 홉 수를 줄입니다. latency-based routing을 사용하면 클라이언트가 가장 낮은 지연 시간을 제공하는 Region으로 유도되어 성능과 실질적인 신뢰성(손실이 발생할 수 있는 장거리 구간 감소)이 모두 개선됩니다. GA는 네트워크 경로를 최적화하고 멀티-Region은 거리를 줄이므로, 함께 사용하면 견고한 솔루션이 됩니다. 주요 AWS 기능: Global Accelerator는 TCP와 UDP를 지원하며 endpoint로 NLB와 통합됩니다. health check와 자동 endpoint failover를 사용하고 static anycast IP를 제공합니다. Route 53 latency routing은 DNS resolver 위치 기준으로 가장 성능이 좋은 endpoint를 반환합니다. active-active 멀티-Region NLB/ASG 배포와 결합하면 전 세계에 분산된 디바이스의 사용자 경험을 개선합니다. 흔한 오해: CloudFront는 HTTP/HTTPS(및 일부 TCP 사용 사례)를 위한 서비스이며 NLB 오리진으로의 일반적인 UDP 프록시가 아닙니다. Route 53 failover는 지연 시간 최적화가 아니라 가용성(active-passive)을 위한 것이며, 장거리 경로로 인해 발생하는 간헐적 패킷 손실을 직접 해결하지 못합니다. enhanced networking (ENA)은 인스턴스 수준의 throughput/pps를 개선하지만, 트래픽이 AWS에 도달하기 전에 발생하는 패킷 손실을 해결하지는 못합니다. 시험 팁: “UDP + 글로벌 클라이언트 + 인터넷 경로 문제”라면 Global Accelerator를 떠올리십시오. “여러 대륙의 클라이언트 + 낮은 지연 시간 필요”라면 멀티-Region + Route 53 latency routing(또는 여러 endpoint를 둔 GA)을 떠올리십시오. latency-based routing(성능)과 failover routing(가용성)을 구분하십시오.

문제 15

(2개 선택)

한 회사는 private subnets에서 동일한 Application Load Balancer (ALB) 뒤에 stateless web app (ASG)과 stateful admin/management app (별도의 ASG)을 실행합니다. 회사는 web app과 동일한 URL에서 path prefix /management를 사용하여 management app에 액세스하려고 합니다. 두 app 모두 protocol, hostname, port는 동일해야 합니다. /management에 대한 액세스는 on-premises source IP ranges로 제한되어야 합니다. ALB는 ACM certificate를 사용합니다. ALB listener rules를 구현하여 /management를 admin targets로 path-route하고, 모든 트래픽을 동일한 HTTPS listener로 유지하면서 이를 on-premises CIDRs로 제한해야 합니다. 네트워크 엔지니어는 어떤 단계 조합을 수행해야 합니까? (두 개 선택)

문제 16

한 회사에 Amazon EC2 인스턴스 플릿에서 실행되는 웹 애플리케이션이 있습니다. 새로운 회사 규정에 따라 EC2 인스턴스로 들어오고 나가는 모든 네트워크 트래픽은 목적지에 도달하기 전에 콘텐츠 검사를 위해 중앙 집중식 타사 EC2 어플라이언스로 전송되어야 합니다. 회사는 애플리케이션의 기능에 영향을 주지 않으면서 이 새로운 검사 계층이 올바르게 구현되었는지 확인하기 위한 테스트를 수행하고 있습니다. 검사 어플라이언스는 모든 네트워크 트래픽의 사본을 확인해야 하는 단일 노드 인스턴스입니다. 네트워크 엔지니어는 애플리케이션의 EC2 인스턴스에서 발생하는 모든 인그레스 및 이그레스 네트워크 트래픽을 타사 검사 어플라이언스로 투명하게 전달하여 실시간 콘텐츠 검사를 수행하는 솔루션을 설계해야 합니다. 이 솔루션은 트래픽의 완전한 사본을 캡처하여 원래 트래픽 흐름을 방해하지 않고 어플라이언스에 전달해야 합니다. 다음 중 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 주로 Amazon VPC Traffic Mirroring에 관한 것입니다. Traffic Mirroring은 ENI(소스)에서 네트워크 패킷의 out-of-band 사본을 생성하여 원래 패킷 흐름을 변경하지 않고 검사, IDS/IPS 또는 문제 해결을 위해 mirror target으로 해당 사본을 전송합니다. 정답이 맞는 이유: 요구 사항이 명확합니다. 검사 어플라이언스는 “모든 네트워크 트래픽의 사본”을 확인해야 하며, 솔루션은 “원래 트래픽 흐름을 방해하지 않고” 어플라이언스에 전달해야 합니다. 이는 VPC Traffic Mirroring이 정확히 수행하는 기능입니다. 선택지 중 Network Load Balancer (NLB)를 mirror target으로 사용하는 것은 소스와 타깃 엔드포인트를 확장하거나 추상화할 수 있는 지원되는 패턴입니다. 애플리케이션 인스턴스의 ENI를 소스로 하여 mirror session을 생성하고, 인그레스/이그레스를 위한 mirror filter를 적용한 다음, 미러링된 패킷을 NLB로 전송하면 NLB가 이를 검사 어플라이언스로 전달합니다. 프로덕션 트래픽은 변경 없이 원래 목적지로 계속 전달됩니다. 주요 AWS 기능 / 구성 참고 사항: - VPC Traffic Mirroring 구성 요소: mirror source(ENI), mirror target(NLB 또는 ENI), mirror filter(방향/포트/프로토콜 규칙), mirror session. - 미러링은 패킷 수준(메타데이터만이 아님)이므로 실시간 콘텐츠 검사가 가능합니다. - NLB를 타깃으로 사용하면 소스를 어플라이언스에서 분리할 수 있으며, 이후 여러 어플라이언스로 확장하는 것도 지원할 수 있습니다(이 문제는 단일 노드라고 명시하지만). - 어플라이언스가 미러링된 트래픽을 수신할 수 있도록(대개 전용 ENI/subnet/security group) 하고, NLB target group의 health check 및 listener 구성이 어플라이언스의 캡처 방식과 일치하도록 보장해야 합니다. 일반적인 오해: - flow logs(선택지 A)는 메타데이터(5-tuple, accept/reject, bytes/packets)만 캡처하며 패킷 페이로드를 포함하지 않으므로 콘텐츠 검사를 지원할 수 없습니다. - Gateway Load Balancer (선택지 D)는 inline 삽입(트래픽을 어플라이언스를 통해 조향)용이며, 원래 흐름을 그대로 두고 사본을 보내는 용도가 아닙니다. - Kinesis Data Firehose(선택지 C)는 Traffic Mirroring의 유효한 타깃이 아니며, 패킷 미러링이 아니라 데이터 스트리밍 전달을 위한 서비스입니다. 시험 팁: - 문제에서 “트래픽의 사본”과 “중단 없음”이 나오면 VPC Traffic Mirroring을 떠올리십시오. - “목적지에 도달하기 전에 모든 트래픽을 어플라이언스를 통해 보내야 한다”라고 하면 GWLB(inline)를 떠올리십시오. “사본”(mirroring)과 “조향/inline”(GWLB)을 구분하십시오.

문제 17

한 마케팅 회사가 AWS Direct Connect 및 software-defined wide area network(SD-WAN) overlay를 통해 지사 사무실을 AWS에 연결하는 하이브리드 인프라를 사용하고 있습니다. 이 회사는 현재 동일한 account 내의 transit VPC에 상주하는 third-party SD-WAN appliance에 여러 VPC를 AWS Site-to-Site VPN을 사용해 연결하고 있습니다. 회사는 더 많은 VPC를 SD-WAN appliance transit VPC에 연결하여 AWS 사용 범위를 확장할 계획입니다. 그러나 기존 아키텍처는 확장성, route table 제한, 그리고 수많은 VPN 연결로 인한 높은 비용 측면에서 문제를 겪고 있습니다. 네트워크 엔지니어는 이러한 문제를 해결하고 전체 운영 오버헤드를 줄이기 위한 새로운 솔루션을 설계해야 합니다. 네트워크 엔지니어는 route table 제한을 해결하고 비용을 절감하면서, 모든 VPC와 SD-WAN appliance 간에 확장 가능한 연결을 제공하는 솔루션을 설계해야 합니다. 솔루션은 가장 적은 운영 오버헤드로 구현되어야 합니다. 다음 중 이러한 요구 사항을 가장 적은 운영 오버헤드로 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 AWS Transit Gateway(TGW)와, 특히 third-party SD-WAN appliance를 통합하기 위한 Transit Gateway Connect를 사용한 AWS의 확장 가능한 hub-and-spoke 네트워킹을 평가합니다. 또한 다수의 Site-to-Site VPN(각 VPC별 tunnel, route table 증가, 운영 오버헤드)에서 흔히 발생하는 확장 문제를 다룹니다. 정답이 맞는 이유: TGW는 중앙 라우팅 허브를 통해 많은 VPC를 연결하는 AWS 네이티브 방식으로, 각 VPC가 transit VPC appliance에 자체 VPN을 구성할 때 발생하는 VPN 메시와 VPC별 route table 확장 문제를 피할 수 있습니다. SD-WAN appliance 환경을 TGW에 가장 적은 운영 오버헤드로 연결하려면, TGW Connect가 이 정확한 사용 사례를 위해 설계되었습니다. TGW Connect는 GRE tunnel과 BGP를 사용하여 TGW와 third-party SD-WAN virtual hub/appliance 간에 대규모의 BGP 기반 통합을 제공합니다. 이를 통해 개별 VPN 연결 수를 줄이고, TGW route table을 통한 route propagation/segmentation을 단순화하며, 더 많은 VPC attachment가 추가되어도 확장할 수 있습니다. 주요 AWS 기능 및 모범 사례: 각 VPC에 대해 TGW VPC attachment를 사용하고, TGW route table을 사용하여 segmentation(예: shared services, prod/dev 분리)을 제어합니다. SD-WAN appliance transit VPC에 TGW Connect attachment를 사용(종종 중간 VPC attachment + Connect를 통해)하고 BGP를 실행하여 TGW와 SD-WAN overlay 간에 route를 동적으로 교환합니다. 이는 static route 관리를 피하고 VPC를 추가할 때 필요한 운영 작업을 최소화합니다. 또한 라우팅을 중앙화하고 managed construct를 사용함으로써 AWS Well-Architected(Reliability/Operational Excellence)와도 부합합니다. 흔한 오해: 옵션 A(TGW + Site-to-Site VPN)는 더 단순해 보이지만, 설계에 VPN 구성을 유지하며 SD-WAN native integration 패턴을 활용하지 못할 수 있습니다. 옵션 C/D는 VPC peering에 의존하는데, 이는 확장성이 낮고(non-transitive, 연결별 관리, peer당 route table entry) 핵심 확장성/운영 오버헤드 문제를 해결하지 못합니다. 시험 팁: “많은 VPC”, “route table 제한”, “너무 많은 VPN”이 보이면 Transit Gateway를 떠올리십시오. “third-party SD-WAN 통합”과 “가장 적은 운영 오버헤드”가 보이면, 다수의 VPN 또는 peering 링크를 구축/유지하는 대신 BGP를 통한 동적 라우팅을 제공하는 TGW Connect를 떠올리십시오.

문제 18

한 회사는 사무실에서 ap-southeast-2의 VPC로 2 Gbps AWS Direct Connect hosted connection을 사용하고 있으며, 동일 Region의 다른 Direct Connect location에서 5 Gbps hosted connection을 추가합니다. 두 연결은 서로 다른 router에서 종료되며, 그 사이에 iBGP session이 있습니다. 네트워크 엔지니어는 VPC가 5 Gbps 연결을 우선 사용하고, 5 Gbps 연결에 장애가 발생하면 2 Gbps 연결로 failover되기를 원합니다. 5 Gbps Direct Connect 연결이 정상일 때는 VPC가 사무실로 가는 트래픽에 5 Gbps Direct Connect 연결을 사용하고, 5 Gbps Direct Connect 연결이 다운되면 2 Gbps 연결로 failover되도록 보장해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 BGP를 사용하는 AWS Direct Connect routing 동작과 VPC에서 on-premises로 향하는 경로(“return path”)에 대해 AWS가 어떤 경로를 사용하도록 영향을 주는 방법을 평가합니다. 동일 Region에서 여러 Direct Connect connection이 동일한 prefix를 광고하는 경우, AWS는 link speed가 아니라 BGP attribute를 사용하여 최적 경로를 선택합니다. 따라서 5 Gbps 경로를 선호하도록 하고 2 Gbps를 백업으로 유지하려면 BGP attribute 또는 prefix를 조정해야 합니다. 정답이 맞는 이유: 5 Gbps connection을 선호하게 하려면, AWS 입장에서 2 Gbps connection을 덜 매력적으로 만들어야 합니다. 옵션 A는 2 Gbps connection에 연결된 router에서 AWS로 광고하는 route에 AS_PATH를 prepend(길게)하여 이를 수행합니다. 다른 attribute가 동일하다면 AWS는 일반적으로 더 짧은 AS_PATH를 가진 route를 선호하므로, 5 Gbps advertisement(더 짧은 AS_PATH)가 선택됩니다. 5 Gbps connection에 장애가 발생하면 해당 route가 withdraw되고, AWS는 남아 있는 2 Gbps 경로를 사용하여 failover를 달성합니다. 주요 AWS 기능 / 동작: - Direct Connect는 private virtual interface에서 고객 router와 AWS 간에 eBGP를 사용하여 route를 교환합니다. - AWS는 더 높은 bandwidth를 자동으로 선호하지 않으며, BGP best-path selection을 따릅니다. - AS_PATH prepending은 동일한 prefix를 광고하는 여러 경로가 있을 때 inbound traffic selection(AWS-to-customer 방향)에 영향을 주는 표준적이고 지원되는 방법입니다. - 두 router와 그 사이의 iBGP를 사용하면, 내부적으로 일관된 routing을 유지하면서도 각 edge가 AWS에 무엇을 광고하는지 조정할 수 있습니다. 흔한 오해: 많은 사람이 “5 Gbps가 자동으로 우선되어야 한다”고 가정하지만, BGP attribute 또는 prefix specificity가 그렇게 만들지 않는 한 그렇지 않습니다. 또 다른 함정은 잘못된 방향에 영향을 주려는 것입니다. local preference는 고객 네트워크에서 outbound에 영향을 주지만, 요구 사항은 VPC-to-office(AWS가 경로를 선택)입니다. 시험 팁: Direct Connect 경로 선호도를 위해 기억할 점: AWS-to-on-prem 트래픽을 제어하려면 AWS에 광고하는 내용을 조정해야 합니다(AS_PATH prepending 또는 more-specific prefix). 링크를 백업으로 만들려면 AS_PATH prepending을 사용하고, more-specific prefix는 routing을 관리하기 더 어렵게 만들 수 있고 추가 IP 계획이 필요할 수 있으므로 주의해서 사용하십시오.

문제 19

(2개 선택)

내부 웹사이트가 VPC(172.31.0.0/16)에서 내부 ALB 뒤에서 실행 중입니다. Route 53에 private hosted zone example.com이 존재합니다. AWS Site-to-Site VPN이 오피스 네트워크를 VPC에 연결합니다. 직원들은 오피스 네트워크에서 https://example.com 에 액세스해야 합니다. VPN을 통해 on-premises에서 VPC의 private hosted zone 및 ALB로 example.com에 대한 private DNS resolution을 활성화해야 합니다. 어떤 단계 조합이 이 요구 사항을 충족합니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 Amazon Route 53 Resolver를 사용하여 private Route 53 hosted zone에 대한 하이브리드 DNS를 테스트합니다. private hosted zone은 명시적으로 on-premises 네트워크로 DNS resolution을 확장하지 않는 한, 연결(associate)된 VPC 내부에서만 확인(resolvable)할 수 있습니다. Site-to-Site VPN을 통해 on-prem 사용자에게 제공하려면 일반적으로 Resolver inbound endpoint를 사용하여 on-prem DNS 서버가 VPC로 쿼리를 전달할 수 있게 합니다. 정답이 맞는 이유: 두 가지가 필요합니다: (1) private hosted zone에서 example.com을 내부 ALB로 매핑하는 DNS record, (2) on-premises DNS resolver가 해당 private hosted zone을 질의할 수 있는 방법. 옵션 A는 private hosted zone에서 내부 ALB를 가리키는 Alias record를 생성합니다. Alias는 ALB의 변경되는 IP를 추적하며 zone apex(example.com)에서 지원되므로, AWS load balancer에 대해 권장되는 Route 53 메커니즘입니다. 옵션 C는 Route 53 Resolver inbound endpoint를 생성하고 example.com에 대한 on-prem conditional forwarder를 해당 endpoint로 구성합니다. 이를 통해 오피스 DNS 서버가 VPN을 통해 VPC로 example.com 쿼리를 전송할 수 있고, Route 53 Resolver가 private hosted zone을 사용해 응답할 수 있습니다. 주요 AWS 기능 / 모범 사례: - ALB에 대한 Route 53 Alias: IP를 하드코딩하지 않고 apex record를 지원합니다. - Route 53 Resolver inbound endpoint: on-prem forwarding을 위한 subnet 내 static IP(ENI)를 제공하며, on-prem에서 UDP/TCP 53을 허용하는 SG rule로 보호합니다. - on-prem conditional forwarding: example.com만 AWS로 전달하고 다른 DNS는 로컬로 유지합니다. 흔한 오해: - on-prem에서 AmazonProvidedDNS(VPC의 .2 resolver)로 직접 지정하는 것은 지원되지 않습니다. 이는 VPC 내부 리소스에서만 도달/사용 가능하도록 설계되었습니다. - zone apex(example.com)에서 CNAME을 사용하는 것은 DNS 표준상 허용되지 않습니다. Alias는 이를 해결하기 위해 존재합니다. - outbound endpoint는 반대 방향(VPC-to-on-prem) 용도이며, on-prem-to-VPC가 아닙니다. 시험 팁: “on-prem에서 private hosted zone을 resolve해야 한다”를 보면 “Resolver inbound endpoint + conditional forwarder”를 떠올리세요. ALB/NLB/CloudFront로 매핑할 때는 특히 apex 이름의 경우 CNAME보다 “Alias”를 선호하세요. 또한 SG, subnet 배치, VPN 라우팅도 고려해야 하지만, 시험에서의 핵심 패턴은 Route 53 private zone으로의 하이브리드 DNS를 위해 inbound endpoint를 사용하는 것입니다.

문제 20

(3개 선택)

한 회사는 transit gateway를 통해 연결된 us-east-1의 VPC들을 보유하고 있습니다. AWS Direct Connect 연결이 온프레미스 데이터 센터로 설정되어 있으며, Amazon CloudWatch의 ConnectionState metric은 UP으로 표시되지만 transit VIF는 DOWN입니다. 네트워크 엔지니어는 온프레미스 라우터에서 transit VIF 및 BGP 구성을 확인했으며 문제는 없었지만, Amazon peer IP address로 ping을 보낼 수 없습니다. 연결성을 설정하기 위해 DOWN 상태의 transit VIF를 트러블슈팅하십시오. 이 문제를 트러블슈팅하기 위해 네트워크 엔지니어가 수행해야 하는 단계의 조합은 무엇입니까? (세 개 선택)

문제 분석

핵심 개념: 이 문제는 물리적 Direct Connect connection은 UP이지만 VIF는 DOWN인 상황에서 AWS Direct Connect transit virtual interface의 문제 해결을 테스트합니다. 이 경우 엔지니어는 VIF에 사용되는 물리 계층과 고객 라우터 subinterface 구성을 검증해야 합니다. 그 이유는 기본 Layer 1/Layer 2/Layer 3 파라미터가 올바르기 전까지는 BGP가 올라올 수 없기 때문입니다. 정답인 이유: 가장 적절한 문제 해결 단계는 subinterface IP address와 subnet mask를 확인하고(A), cross connect를 통한 optical signal이 정상인지 확인하며(D), 올바른 VLAN tag가 라우터 subinterface에 구성되어 있는지 확인하는 것(E)입니다. 물리적 connection은 UP으로 표시되더라도 여전히 트래픽에 영향을 주는 signal quality 문제가 있을 수 있으며, VLAN 또는 peer IP 설정이 올바르지 않으면 VIF는 DOWN 상태로 유지됩니다. 엔지니어가 Amazon peer IP에 ping할 수 없으므로, 문제는 순수한 BGP policy 이슈라기보다 IP adjacency 계층 이하 또는 그 계층에 있을 가능성이 가장 높습니다. 주요 AWS 기능: AWS Direct Connect는 물리적 connection 상태와 virtual interface 상태를 분리합니다. ConnectionState metric은 물리적 port의 상태를 나타내며, transit VIF는 BGP가 수립되기 전에 올바른 optics, 802.1Q VLAN tagging, 그리고 Amazon peer까지의 point-to-point IP addressing에 의존합니다. Transit VIF는 multi-VPC 및 hybrid connectivity를 위해 Direct Connect gateway 및 Transit Gateway와 함께 사용됩니다. 흔한 오해: 흔한 실수는 Amazon peer IP에 도달조차 할 수 없는 상황에서 즉시 BGP TCP port 179에 집중하는 것입니다. 또 다른 오해는 UP으로 표시된 물리적 connection이 VIF 트래픽에 대해 optical path가 완전히 정상임을 보장한다고 가정하는 것입니다. 엔지니어는 ARP-table 검증을 지나치게 중요하게 생각할 수도 있지만, DOWN VIF에 대한 주요 문서화된 확인 항목은 물리적 signal, VLAN tagging, 그리고 IP addressing입니다. 시험 팁: 시험에서 Direct Connect가 connection UP이지만 VIF DOWN으로 표시되면 계층별로 생각하세요. 먼저 물리 optics/cross-connect, 그다음 VLAN encapsulation, 그다음 peer IP/subnet 구성, 그리고 그 이후에야 BGP 설정을 봐야 합니다. 문제에서 Amazon peer IP에 ping할 수 없다고 언급하면 pre-BGP 문제 해결을 우선시하세요. AWS는 종종 물리적 connection 상태와 virtual interface 상태를 구분할 수 있는지를 평가합니다.