AWS Certified Advanced Networking - Specialty (ANS-C01)

Practice Test #1

65개 문제와 170분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.

65문제170분750/1000합격 점수

기출 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.

GPT Pro

Claude Opus

Gemini Pro

선택지별 상세 해설

심층 문제 분석

3개 모델 합의 정확도

기출 문제

문제 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

한 회사가 최근 개발자가 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는 컴플라이언스 타임라인과 감사 준비가 된 이력을 위한 정석 서비스입니다.

문제 3

한 회사가 온프레미스 데이터 센터에서 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, 여러 고객 라우터를 사용하고 장애를 견딜 수 있을 만큼 충분한 여유 용량을 갖추는 것입니다.

문제 4

한 핀테크 회사는 여러 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 경계를 주의 깊게 살펴보세요.

문제 5

(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과 필요한 네트워크에 대한 명시적 사설 라우트를 사용하는 것입니다.

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

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

문제 6

스타트업 회사의 애플리케이션 팀이 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 및 성능 민감한 글로벌 진입 지점에 적합합니다.

문제 7

(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(가용성)을 구분하십시오.

문제 8

(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로 제한해야 합니다. 네트워크 엔지니어는 어떤 단계 조합을 수행해야 합니까? (두 개 선택)

문제 9

한 마케팅 회사가 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를 떠올리십시오.

문제 10

한 물류 회사가 AWS Cloud에서 Transit Gateway로 상호 연결된 multi-VPC 환경을 배포했습니다. 이 회사는 네트워크 운영자가 security group, network ACL 또는 route table을 변경한 후 서비스 중단을 겪었습니다. 향후 장애를 방지하기 위해, 회사는 어떤 네트워크 구성 변경이 이루어진 직후 단일 VPC 내의 중요한 애플리케이션 리소스 간 네트워크 연결성을 선제적으로 검증하는 자동화 시스템을 구현하려고 합니다. 네트워크 엔지니어는 VPC 내의 네트워크 구성 변경을 자동으로 감지한 다음, 연결성 손실이 발생하지 않았는지 확인하기 위해 특정 리소스 간 연결성 검사를 트리거하는 솔루션을 설계해야 합니다. 운영상의 수작업 오버헤드를 줄이기 위해 솔루션은 완전 자동화되어야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 VPC 내부에서 구성 변경 후 자동화된 네트워크 검증을 테스트합니다. 핵심 서비스는 AWS CloudTrail(API 수준의 네트워크 변경을 기록), Amazon EventBridge(해당 변경을 감지하고 자동화를 트리거), AWS Lambda(작업을 오케스트레이션), VPC Reachability Analyzer(route table, security group, NACL, IGW/NAT/TGW attachment 등을 고려하여 두 엔드포인트 간 L3/L4 reachability를 프로그래밍 방식으로 검증)입니다. 정답이 맞는 이유: Option B가 정답인 이유는 CloudTrail이 security group, network ACL, route table에 대한 구성 변경(예: AuthorizeSecurityGroupIngress/Egress, CreateNetworkAclEntry, ReplaceRoute, AssociateRouteTable)을 감지하는 권위 있는 소스이기 때문입니다. EventBridge는 CloudTrail event를 거의 실시간으로 매칭하여 Lambda function을 호출할 수 있습니다. 그런 다음 Lambda는 Reachability Analyzer API(예: CreatePath/StartNetworkInsightsAnalysis 또는 설계에 따라 StartNetworkInsightsAccessScopeAnalysis)를 호출하여, 변경 직후 VPC 내 사전에 정의된 중요한 경로에 대해 연결성 검사를 실행할 수 있습니다. 이는 선제적이고 자동화된 검증을 제공하며 수작업 운영 오버헤드를 줄입니다. 주요 AWS 기능 / Best Practices: - CloudTrail management event는 EC2/VPC networking 리소스에 대한 control-plane API call을 캡처합니다. - EventBridge는 CloudTrail event에 대한 event pattern(source: aws.ec2, detail-type: AWS API Call via CloudTrail)과 eventName 및 리소스별 세밀한 필터링을 지원합니다. - Reachability Analyzer는 결정론적 reachability analysis(패킷 probing이 아님)를 제공하며 Lambda에서 SDK/CLI를 통해 자동화할 수 있습니다. - “critical path”(source/destination ENI, instance, subnet)를 코드/구성(예: SSM Parameter Store/DynamoDB)으로 저장하여 솔루션의 유지보수성을 높입니다. 흔한 오해: 흔한 함정은 구성 변경이 CloudWatch에 “로그로 기록된다”고 가정하는 것입니다. CloudWatch Logs는 CloudTrail log를 저장할 수 있지만, API 변경을 감지하는 기본 event source는 CloudTrail이며 EventBridge는 CloudTrail event와 직접 통합됩니다. 또 다른 오해는 intra-VPC reachability에 Transit Gateway Network Manager Route Analyzer를 사용하는 것입니다. Route Analyzer는 attachment 전반의 TGW route 분석에 초점을 맞추며, SG/NACL을 포함한 전체 VPC dataplane 평가가 아닙니다. 시험 팁: 문제에서 “어떤 네트워크 구성 변경 후”라고 하면 CloudTrail + EventBridge를 떠올리십시오. “VPC 내 리소스 간 연결성 검증”이라고 하면 VPC Reachability Analyzer( TGW Route Analyzer가 아님)를 떠올리십시오. 또한 SG/NACL/route table 변경이라는 표현에 주의하십시오. 이는 CloudTrail management event로 캡처되는 EC2/VPC API call입니다.

합격 후기(9)

c*****Nov 23, 2025

학습 기간: 2 months

This practice questions help you in understanding the concepts on which you can get the questions in certification exam. Solutions and the explanation is really good. I was able to crack the exam. Thank you.

박

박**Nov 17, 2025

학습 기간: 1 month

앱 200 몇 문제를 2번 정도 초기화해서 다시 풀었고, 개념 이해가 완전히 될 때까지 공부했습니다.

r***********Nov 14, 2025

학습 기간: 2 months

Excellent practice questions. It helped in refreshing a lot a concepts

김

김**Nov 9, 2025

학습 기간: 2 months

문제들이 다양한 유형을 커버해서 좋았고 실제 시험에서 비슷한 유형이 많아서 큰 도움이 됐어요

진

진**Nov 9, 2025

학습 기간: 3 months

Udemy에서 강의들으며 개념익히고, 이 앱에서 문제랑 해설보며 공부했어요. 모르는 aws 리소스에 대해선 따로 공부도 했어요 앱 유용하게 이용했네요!

← 모든 AWS Certified Advanced Networking - Specialty (ANS-C01) 문제 보기

지금 학습 시작하기

Cloud Pass를 다운로드하고 모든 AWS Certified Advanced Networking - Specialty (ANS-C01) 기출 문제를 풀어보세요.

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

앱 받기

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

Cloud Pass

AWS Certified Advanced Networking - Specialty (ANS-C01)

Practice Test #1

65개 문제와 170분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.

65문제170분750/1000합격 점수

기출 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.

GPT Pro

Claude Opus

Gemini Pro

선택지별 상세 해설

심층 문제 분석

3개 모델 합의 정확도

기출 문제

문제 1

문제 분석

문제 2

문제 분석

문제 3

문제 분석

문제 4

문제 분석

문제 5

(3개 선택)

문제 분석

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

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

문제 6

문제 분석

문제 7

(2개 선택)

문제 분석

문제 8

(2개 선택)

문제 9

문제 분석

문제 10

문제 분석

합격 후기(9)

c*****Nov 23, 2025

학습 기간: 2 months

박

박**Nov 17, 2025

학습 기간: 1 month

앱 200 몇 문제를 2번 정도 초기화해서 다시 풀었고, 개념 이해가 완전히 될 때까지 공부했습니다.

r***********Nov 14, 2025

학습 기간: 2 months

Excellent practice questions. It helped in refreshing a lot a concepts

김

김**Nov 9, 2025

학습 기간: 2 months

문제들이 다양한 유형을 커버해서 좋았고 실제 시험에서 비슷한 유형이 많아서 큰 도움이 됐어요

진

진**Nov 9, 2025

학습 기간: 3 months

Udemy에서 강의들으며 개념익히고, 이 앱에서 문제랑 해설보며 공부했어요. 모르는 aws 리소스에 대해선 따로 공부도 했어요 앱 유용하게 이용했네요!

← 모든 AWS Certified Advanced Networking - Specialty (ANS-C01) 문제 보기

지금 학습 시작하기

Cloud Pass를 다운로드하고 모든 AWS Certified Advanced Networking - Specialty (ANS-C01) 기출 문제를 풀어보세요.

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

앱 받기

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