정답 · 해설

해설

【핵심 용어】 ▸ Traffic Mirroring — VPC 트래픽 복사/분석 ▸ Network Load Balancer (NLB) — Layer 4 로드 밸런싱, 매우 높은 처리량 ▸ Gateway Load Balancer (GLB) — 어플라이언스 통합용 로드 밸런서 ▸ Auto Scaling — 동적 인스턴스 스케일링 【정답 포인트】 ▸ Traffic Mirroring은 Layer 4 프로토콜 기반 트래픽 복사 → NLB (Layer 4) 적합 ▸ 높은 처리량 + 낮은 지연시간 필요 → NLB의 이점 활용 ▸ 트래픽 분석 도구는 단순 Layer 4 리밸런싱으로 충분 → ALB/GLB 불필요 ▸ 스케일링 필요 → Auto Scaling과 자연스러운 조합 Option A: NLB는 Traffic Mirroring 타겟으로 적합. Layer 4에서 분산하여 백엔드 인스턴스 부하 완화. 초당 수백만 개 요청 처리 가능. Auto Scaling으로 자동 스케일. 【오답 체크】 (B) ALB는 Layer 7 기반 → Traffic Mirroring (Layer 4)과 불일치. 시간 제한 추가 요구사항도 부적절. (C) GLB는 제3자 네트워크 어플라이언스 처리용 → 분석 도구의 단순 로드 밸런싱에는 과하고 불필요한 복잡성 추가. (D) HTTPS 리스너 + 시간 제한 → 지속적 모니터링 요구사항과 맞지 않음. 【시험 포인트】 ▸ 로드 밸런서 선택: 프로토콜 레이어 매칭 (L4 트래픽 = NLB) ▸ Traffic Mirroring: 분석/감시용 독립적 인프라 필요 ▸ 고처리량 + 낮은 지연시간: NLB의 핵심 이점

해설

【핵심 용어】 ▸ Route 53 Resolver Inbound Endpoint — AWS에서 온프레미스로부터 수신 ▸ Route 53 Resolver Outbound Endpoint — AWS에서 온프레미스로 쿼리 전송 ▸ Resolver Rule — DNS 쿼리 라우팅 정책 【정답 포인트】 ▸ 온프레미스 → AWS 쿼리: Inbound Endpoint 필요 (온프레미스 DNS가 AWS로 쿼리 전송) ▸ AWS → 온프레미스 쿼리: Outbound Endpoint 필요 (VPC에서 온프레미스로 쿼리 포워딩) ▸ Inbound Endpoint IP로 온프레미스 DNS 포워드 설정 ▸ Outbound Endpoint로 corp.example.com 쿼리 라우팅 Option B: 온프레미스 DNS 리졸버를 Inbound Endpoint의 IP로 aws.example.com 포워드 → VPC로부터의 쿼리를 AWS DNS가 처리. Option C: 양방향 통신 필요 → Inbound + Outbound 엔드포인트 모두 필수. Option E: VPC에서 corp.example.com 쿼리 → Outbound Endpoint로 온프레미스로 전달하는 규칙. 【오답 체크】 (A) Outbound Endpoint로 aws.example.com 포워드는 잘못됨 (aws.example.com은 Route 53에서 호스팅, 외부로 포워드 불필요). (D) Inbound Endpoint로 aws.example.com 포워드도 불필요 (이미 Route 53 PHZ에 있음). (F) Outbound Endpoint로 aws.example.com 포워드는 잘못됨. 【시험 포인트】 ▸ Inbound vs Outbound: 트래픽 방향 구분 필수 ▸ Hybrid DNS 통합: 양쪽 엔드포인트 + Resolver Rule 조합 ▸ 프라이빗 호스팅 영역: 이미 AWS 내부에서 해결됨

해설

【핵심 용어】 ▸ Gateway Load Balancer (GLB) — 네트워크 어플라이언스 통합 ▸ Transit Gateway Appliance Mode — 비대칭 라우팅 방지 ▸ Route Table Association — TGW 라우팅 정책 【정답 포인트】 ▸ GLB는 제3자 어플라이언스를 위한 표준 → NLB 대비 우수한 선택 ▸ GLB Endpoint를 통한 자동 트래픽 분산 → Auto Scaling 지원 ▸ 비대칭 라우팅 방지: Appliance Mode 필수 ▸ 양방향 트래픽이 동일 어플라이언스를 통과해야 함 Option B: GLB는 네트워크 어플라이언스 전문 LB. GLB Endpoint가 투명한 트래픽 리다이렉션 제공. Auto Scaling으로 고가용성. Option C: 이중 경로 테이블 구조: 애플리케이션 VPC는 app RT, 검사 VPC는 inspection RT. 애플리케이션 RT의 기본 경로 → 검사 어플라이언스. Appliance Mode 활성화 → 양방향 대칭 경로 보장. 【오답 체크】 (A) NLB는 Layer 4 LB → 어플라이언스 검사 요구사항 충족 미흡. GLB 없음. (D) 경로 테이블 구성 역순 → 트래픽 흐름이 잘못됨. (E) 단일 경로 테이블 → 비대칭 라우팅 불가피 → 어플라이언스에서 응답 패킷 처리 불가. 【시험 포인트】 ▸ 네트워크 어플라이언스 패턴: GLB + Appliance Mode ▸ 이중 경로 테이블: Application ↔ Inspection 일방향만 필터링 ▸ 비대칭 라우팅 방지: 양쪽 경로가 동일 어플라이언스 통과

해설

【핵심 용어】 ▸ NAT Gateway (Private) — 프라이빗 서브넷의 아웃바운드 IP 소스 ▸ Source NAT (SNAT) — 송신 패킷의 출발지 IP 변환 ▸ Stateful Firewall — 상태 저장 방화벽 【정답 포인트】 ▸ EC2 인스턴스 출발 트래픽만 허용 필요 → SNAT로 단일 IP로 통합 ▸ 프라이빗 NAT Gateway — 프라이빗 서브넷 EC2가 아웃바운드 시에만 사용 ▸ 방화벽에서 단일 IP 규칙 추가 → NAT Gateway IP로 통합 ▸ 역방향 인바운드 불가능 → EC2는 완전히 보호됨 Option C: Private NAT Gateway는 프라이빗 서브넷 내에서만 작동. EC2의 모든 아웃바운드 트래픽을 NAT Gateway IP로 변환. 방화벽에서 이 IP 주소만 허용하면 모든 EC2 통신 수용. 운영 오버헤드 최소화. 【오답 체크】 (A) VPN over Direct Connect는 불필요한 복잡성 + 암호화 오버헤드 + 방화벽 양쪽 구성 필요. (B) 온프레미스 방화벽만으로 제어 → AWS 측에서 NAT 없이 EC2 직접 IP 노출 → 인바운드 위험. (D) NAT 인스턴스는 관리 오버헤드 (OS 패치, 가용성 수동 관리 등) → 게이트웨이 대비 복잡. 【시험 포인트】 ▸ Private NAT Gateway: 프라이빗 리소스의 아웃바운드 IP 통합 ▸ SNAT 기반 방화벽 규칙: 단일 IP 매칭으로 다중 인스턴스 제어 ▸ AWS 측 인바운드 차단: 완벽한 일방향 통신

해설

【핵심 용어】 ▸ Transit Gateway (TGW) — 다중 VPC 중앙 집중식 라우팅 ▸ AWS Resource Access Manager (RAM) — 다중 계정 리소스 공유 ▸ VPN Throughput — 단일 VPN 500 Mbps 한계 ▸ Scalability — 향후 대역폭 증가 대비 【정답 포인트】 ▸ 현재: 360개 VPN 터널, 500 Mbps/리전 → 심각한 한계 ▸ 향후: 2 Gbps 추가 필요 → VPN만으로 불가능 ▸ Transit Gateway: 모든 VPC 통합 → 터널 360개 → 소수로 축소 ▸ 다중 VPN으로 대역폭 확장 가능 (각 터널 500 Mbps) ▸ RAM으로 다중 계정 공유 → 중앙 관리 Option C: 각 리전에 TGW 생성 (VPN 여러 개) → RAM으로 60개 계정 공유 → 각 VPC를 TGW에 연결 → 기존 vPGW 제거. 다중 VPN으로 합산 3-4 Gbps 달성 가능. 관리 오버헤드 극적 감소 (1 TGW + N VPN vs 360 터널). 【오답 체크】 (A) Direct Connect는 비용 고려 필요 + VPN 대비 복잡성. 기존 VPN 500 Mbps 한계 미해결. (B) 단일 TGW는 여러 리전 미지원 → 리전당 TGW 부족 → 각 리전의 처리량 여전히 500 Mbps 한계. (D) VPC Peering 기반 Transit VPC는 확장성 떨어짐 + 메시 구조 + 관리 복잡. 【시험 포인트】 ▸ Transit Gateway의 확장성: 단일 TGW + 다중 VPN으로 대역폭 선형 증가 ▸ 다중 계정 통합: RAM 사용으로 중앙 집중식 관리 ▸ VPN 한계 극복: 리전당 여러 VPN 터널로 합산 처리량 향상

해설

【핵심 용어】 ▸ Gateway VPC Endpoint — S3 접근 시 NAT 우회 가능 ▸ Interface VPC Endpoint — ENI 기반 엔드포인트 (추가 비용) ▸ NAT Gateway Bypass — 데이터 전송 비용 제거 ▸ S3 트래픽 최적화 — 프라이빗 서브넷에서의 비용 효율적 접근 【정답 포인트】 ▸ Gateway Endpoint는 라우트 테이블 기반으로 S3 트래픽 자동 리다이렉션 ▸ Interface Endpoint와 달리 추가 비용 없음 (S3 전용) ▸ NAT Gateway를 거치지 않으므로 데이터 전송 비용 완전 제거 ▸ 라우트 테이블의 프리픽스 리스트로 자동 라우팅 설정 Option D: Gateway Endpoint를 S3에 생성하고 VPC 라우트 테이블을 업데이트하면, 프라이빗 서브넷의 EC2에서 S3로 가는 트래픽이 자동으로 NAT Gateway를 우회하여 직접 S3에 접속. 비용 효율성 최대화. 【오답 체크】 (A) Direct Connect 프라이빗 VIF는 온프레미스 연결용이며 AWS 내부 S3 트래픽과 무관함. 문제 미해결. (B) VPN Tunnel은 암호화 오버헤드만 추가되고 NAT Gateway 비용은 여전히 발생함. (C) Interface Endpoint는 ENI 생성으로 시간당 비용 발생 + 추가 관리 필요. 【시험 포인트】 ▸ S3/DynamoDB 접근: Gateway Endpoint 필수 선택 ▸ 비용 최적화: Interface Endpoint 대비 Gateway Endpoint 우선순위 ▸ 라우트 기반 자동화: Prefix List 매커니즘 이해

해설

【핵심 용어】 ▸ Transit Gateway Network Manager — TGW 네트워크 모니터링 통합 ▸ CloudWatch Logs Insights — 로그 검색 및 분석 도구 ▸ EventBridge — 이벤트 기반 자동화 및 알림 ▸ BGP Route Change Events — 라우팅 테이블 변경 감지 【정답 포인트】 ▸ TGW Network Manager가 Direct Connect BGP 이벤트를 수집 ▸ CloudWatch Logs에 자동으로 로그 전송 (수동 설정 불필요) ▸ EventBridge가 로그 패턴 변화를 감지하여 실시간 알림 ▸ Lambda polling 대비 이벤트 기반으로 실시간 반응 가능 Option B: TGW Network Manager를 온보딩하면 BGP 이벤트가 CloudWatch Logs로 자동 전송. EventBridge 규칙으로 경로 변경 패턴 감지 시 즉시 알림. 네이티브 AWS 솔루션으로 관리 오버헤드 최소. 【오답 체크】 (A) CloudWatch Metrics는 수치 메트릭(대역폭)만 추적 가능 - 경로 변경 이벤트 감지 불가. (C) Lambda Polling은 정기적 체크로 실시간성 부족 + 추가 비용 + 코드 관리 필요. (D) Transit VIF는 CloudWatch Logs를 지원하지 않음 - 경로 정보 전송 불가. 【시험 포인트】 ▸ Hybrid Network Monitoring: TGW Network Manager 기본 ▸ 이벤트 기반 자동화: CloudWatch Logs + EventBridge 조합 ▸ 실시간 라우팅 변경 감지: 네트워크 가시성 핵심

해설

【핵심 용어】 ▸ MACsec (Media Access Control Security) — Layer 2 암호화 표준 ▸ Direct Connect Encryption — AWS와 코로케이션 간 암호화 ▸ Bandwidth Preservation — 기존 대역폭 유지 ▸ Operational Overhead — 운영 복잡성 최소화 【정답 포인트】 ▸ MACsec은 Direct Connect 네이티브 암호화로 VPN 대비 오버헤드 최소 ▸ Layer 2에서 암호화로 성능 영향 무시할 수 있는 수준 ▸ 새로운 DX 연결로 배포 후 점진적 마이그레이션 가능 ▸ 엣지 라우터에서 초기 구성 후 자동화 - 지속적 관리 최소 Option C: MACsec이 포함된 새로운 10 Gbps Direct Connect 연결 2개(중복성) 배포. 엣지 라우터에 MACsec 설정. 기존 연결에서 새 연결로 트래픽 마이그레이션. VPN 오버헤드 없이 10 Gbps 유지. 【오답 체크】 (A) Public VIF 암호화 옵션 존재하지 않음 - 실질적 암호화 불가능. (B) VPN(IPsec)은 암호화 오버헤드 + 성능 저하 + 대역폭 손실 위험 초래. (D) DX + Public VIF + VPN 다층 구조는 복잡성 극대화 + 운영 비효율. 【시험 포인트】 ▸ Direct Connect MACsec: Layer 2 암호화의 표준 솔루션 ▸ 대역폭 효율성: VPN 오버헤드 없음 ▸ 점진적 마이그레이션: 기존 DX 유지 중 신규 DX 증설

해설

【핵심 용어】 ▸ ALB Access Logs — Application Load Balancer 액세스 로그 ▸ Amazon Athena — S3 기반 SQL 쿼리 엔진 ▸ Amazon S3 — 로그 저장소 ▸ Operational Efficiency — 관리 오버헤드 최소화 【정답 포인트】 ▸ ALB는 S3에 자동 로그 저장 지원 (네이티브 기능) ▸ Athena는 S3의 로그를 직접 SQL로 쿼리 (ETL 불필요) ▸ 서버리스 아키텍처로 인프라 관리 불필요 ▸ 클라이언트 IP, 대상 IP, 포트, User-Agent 모두 ALB 로그에 포함 Option D: ALB Access Logs를 S3에 저장 후, Athena로 직접 SQL 쿼리. WHERE 절로 IP/포트/User-Agent 필터링. 추가 인프라 없이 비용 효율적 분석. 【오답 체크】 (A) 수동 다운로드 + 스프레드시트는 확장성 부족 + 반복 작업 비효율. (B) Kinesis Data Streams은 ALB가 직접 지원하지 않음 - 커스텀 통합 필요 + 추가 비용. (C) Kinesis + OpenSearch는 복잡한 파이프라인 + 유지보수 오버헤드 과다. 【시험 포인트】 ▸ ALB 로그 분석: Athena 표준 패턴 ▸ 서버리스 로그 분석: S3 + Athena 조합 기본 ▸ 운영 효율성: 기존 AWS 서비스 조합 최우선

해설

【핵심 용어】 ▸ CloudFront Edge Encryption — 엔드유저와 CloudFront 간 HTTPS ▸ Origin HTTPS — CloudFront와 ALB 간 HTTPS ▸ Certificate Chain — 공인 인증서의 신뢰 체인 ▸ HTTP Redirect — 강제 암호화 정책 【정답 포인트】 ▸ CloudFront 엣지: service.example.com 공인 인증서 필요 (ACM 권장) ▸ 백엔드: ALB와 EC2 모두 HTTPS 리스너 필요 ▸ ALB: service-alb.example.com ACM 공인 인증서 필수 ▸ EC2 인스턴스: 제3자 공인 인증서 또는 ACM 인증서 설정 ▸ 양쪽 HTTP → HTTPS 리다이렉트로 강제 암호화 Option B: CloudFront에 ACM 인증서(service.example.com) 적용 + HTTP→HTTPS 리다이렉트 Option D: EC2 백엔드에 공인 인증서 설치 + HTTPS 리스너 + Auto Scaling 연결 Option E: ALB에 ACM 인증서(service-alb.example.com) + HTTPS 리스너 + CloudFront HTTPS only 조합 BDE: 3단계 암교화 완성 (사용자→CF→ALB→EC2) 【오답 체크】 (A) 자체 서명 인증서는 브라우저 경고 발생 - 신뢰 체인 미충족. (C) EC2 인스턴스 대상 + 모든 도메인 인증서는 도메인 불일치 문제. (F) 자체 서명 인증서는 ALB-CloudFront 검증 실패. 【시험 포인트】 ▸ Multi-tier HTTPS: 각 구간 독립 인증서 ▸ CloudFront + ALB: 도메인 명확한 구분 ▸ ACM 공인 인증서: 자체 서명 절대 금지

해설

【핵심 용어】 ▸ NLB Availability Zone — NLB 리스너가 활성화된 Availability Zone ▸ Target Registration — 대상 그룹에 EC2 인스턴스 등록 ▸ Cross-AZ Load Balancing — 다중 Availability Zone 트래픽 분산 【정답 포인트】 ▸ NLB는 생성 시 기본으로 초기 AZ만 활성화됨 ▸ 새로운 인스턴스가 있는 AZ도 명시적으로 활성화 필요 ▸ 대상 그룹에는 이미 두 AZ의 인스턴스가 등록됨 ▸ NLB 구성에서 AZ 활성화만으로 문제 해결 Option A: NLB 구성 패널에서 새로운 Availability Zone을 활성화하면, 기존 대상 그룹의 인스턴스에 자동으로 2개 AZ에 트래픽 분산. 단순한 설정 변경만 필요. 【오답 체크】 (B) 새로운 NLB 생성은 비용 추가 + 관리 복잡성 증가 - 불필요. (C) Proxy Protocol은 클라이언트 IP 정보 전달용 - 로드 밸런싱 문제 미해결. (D) 대상은 이미 등록됨 - 새 대상 그룹 생성 불필요. 【시험 포인트】 ▸ NLB Multi-AZ: AZ 활성화 설정 필수 ▸ 기본 설정: NLB 생성 시 초기 AZ만 활성화 ▸ 대상 그룹 재사용: 이미 등록된 대상 활용

해설

【핵심 용어】 ▸ Bring Your Own IP (BYOIP) — 고객 소유 IP 주소 풀 ▸ Elastic IP (from BYOIP) — BYOIP 풀에서 할당받은 공인 IP ▸ User Data Script — 인스턴스 부팅 시 실행되는 초기화 스크립트 ▸ Secondary Network Interface — 추가 ENI(Elastic Network Interface) 【정답 포인트】 ▸ 시작 템플릿은 프라이머리 ENI만 정의 가능 (2차 ENI는 부팅 후 추가) ▸ cloud-init 스크립트를 user data로 실행하여 2차 ENI 생성 ▸ BYOIP 풀에서 Elastic IP를 할당받아 2차 ENI에 연결 ▸ Auto Scaling이 인스턴스마다 자동으로 이 프로세스 반복 Option D: Auto Scaling 그룹에서 프라이머리 네트워크 인터페이스 서브넷 선택. cloud-init user data 스크립트로 2차 ENI 생성 + BYOIP Elastic IP 할당. 각 인스턴스마다 자동 실행. 【오답 체크】 (A) 시작 템플릿에서 2개 ENI 정의 가능하지만, BYOIP pool ID를 직접 선택할 수 없음. (B) User data는 맞으나 "자동 할당" 옵션은 BYOIP 미지원 - 명시적 Elastic IP 필요. (C) Lambda + Global Accelerator는 과도한 복잡성 + 목표 미달성. 【시험 포인트】 ▸ Auto Scaling + Multi-ENI: user data 자동화 필수 ▸ BYOIP: Elastic IP로만 할당 가능 ▸ 시작 템플릿 범위: 프라이머리 ENI만 정의

해설

【핵심 용어】 ▸ Route 53 Private Hosted Zone (PHZ) — VPC 내부 DNS 해석 ▸ Split-View DNS — 같은 도메인명, 내부/외부 다른 IP 응답 ▸ DNS Hostname Resolution — VPC 인스턴스의 프라이빗 호스트명 지원 ▸ Record Synchronization — 퍼블릭과 프라이빗 영역 레코드 동기화 【정답 포인트】 ▸ VPC 내 구성요소가 같은 호스트명으로 프라이빗 IP 접근 필요 ▸ Private Hosted Zone 생성 + VPC 연결 → VPC 내부 DNS 해석 활성화 ▸ DNS Hostname 활성화 → EC2가 프라이빗 호스트명 사용 가능 ▸ 퍼블릭 호스팅 영역의 각 레코드를 프라이빗 IP로 복제 → Split-View DNS 구현 Option B: PHZ 생성 및 애플리케이션 VPC에 연결 Option C: VPC에서 DNS Hostname 활성화 Option D: PHZ에 공개 호스팅 영역의 동일 레코드를 프라이빗 IP로 복제 조합 BCD: 내부 구성요소는 같은 이름으로 프라이빗 IP 접근, 외부는 공인 IP 접근 【오답 체크】 (A) 지오프록시미티는 지역 기반 라우팅 - Split-View DNS 미달성. (E) EventBridge + Lambda는 자동화이나, 문제에 "향후 변경 수용"만 있고 "자동화 필수"는 아님. (F) 퍼블릭 호스팅 영역에 프라이빗 IP 추가는 부적절 - 인터넷에 프라이빗 IP 노출. 【시험 포인트】 ▸ Split-View DNS: Private Hosted Zone 기본 사용 ▸ VPC DNS 설정: 호스트명 활성화 필수 ▸ 수동 레코드 복제: 변경 주기가 낮으면 충분

해설

【핵심 용어】 ▸ [Service/Concept 1] — 설명 ▸ [Service/Concept 2] — 설명 ▸ [Service/Concept 3] — 설명 ▸ [Service/Concept 4] — 설명 【정답 포인트】 ▸ [Key Point 1] — 정답 이유 ▸ [Key Point 2] — 정답 이유 ▸ [Key Point 3] — 정답 이유 Option D: [정답 옵션 상세 설명] 【오답 체크】 (A) [옵션 A 오답 이유 - 60~100자] (B) [옵션 B 오답 이유 - 60~100자] (C) [옵션 C 오답 이유 - 60~100자] (D) [옵션 D 오답 이유 - 60~100자] 【시험 포인트】 ▸ [시험 패턴 1] — 중요 개념 ▸ [시험 패턴 2] — 중요 개념 ▸ [시험 패턴 3] — 중요 개념

해설

【핵심 용어】 ▸ [Service/Concept 1] — 설명 ▸ [Service/Concept 2] — 설명 ▸ [Service/Concept 3] — 설명 ▸ [Service/Concept 4] — 설명 【정답 포인트】 ▸ [Key Point 1] — 정답 이유 ▸ [Key Point 2] — 정답 이유 ▸ [Key Point 3] — 정답 이유 Option C: [정답 옵션 상세 설명] 【오답 체크】 (A) [옵션 A 오답 이유 - 60~100자] (B) [옵션 B 오답 이유 - 60~100자] (C) [옵션 C 오답 이유 - 60~100자] (D) [옵션 D 오답 이유 - 60~100자] 【시험 포인트】 ▸ [시험 패턴 1] — 중요 개념 ▸ [시험 패턴 2] — 중요 개념 ▸ [시험 패턴 3] — 중요 개념

해설

【핵심 용어】 ▸ [Service/Concept 1] — 설명 ▸ [Service/Concept 2] — 설명 ▸ [Service/Concept 3] — 설명 ▸ [Service/Concept 4] — 설명 【정답 포인트】 ▸ [Key Point 1] — 정답 이유 ▸ [Key Point 2] — 정답 이유 ▸ [Key Point 3] — 정답 이유 Option C: [정답 옵션 상세 설명] 【오답 체크】 (A) [옵션 A 오답 이유 - 60~100자] (B) [옵션 B 오답 이유 - 60~100자] (C) [옵션 C 오답 이유 - 60~100자] (D) [옵션 D 오답 이유 - 60~100자] 【시험 포인트】 ▸ [시험 패턴 1] — 중요 개념 ▸ [시험 패턴 2] — 중요 개념 ▸ [시험 패턴 3] — 중요 개념

해설

【핵심 용어】 ▸ [Service/Concept 1] — 설명 ▸ [Service/Concept 2] — 설명 ▸ [Service/Concept 3] — 설명 ▸ [Service/Concept 4] — 설명 【정답 포인트】 ▸ [Key Point 1] — 정답 이유 ▸ [Key Point 2] — 정답 이유 ▸ [Key Point 3] — 정답 이유 Option D: [정답 옵션 상세 설명] 【오답 체크】 (A) [옵션 A 오답 이유 - 60~100자] (B) [옵션 B 오답 이유 - 60~100자] (C) [옵션 C 오답 이유 - 60~100자] (D) [옵션 D 오답 이유 - 60~100자] 【시험 포인트】 ▸ [시험 패턴 1] — 중요 개념 ▸ [시험 패턴 2] — 중요 개념 ▸ [시험 패턴 3] — 중요 개념

해설

【핵심 용어】 ▸ [Service/Concept 1] — 설명 ▸ [Service/Concept 2] — 설명 ▸ [Service/Concept 3] — 설명 ▸ [Service/Concept 4] — 설명 【정답 포인트】 ▸ [Key Point 1] — 정답 이유 ▸ [Key Point 2] — 정답 이유 ▸ [Key Point 3] — 정답 이유 Option C: [정답 옵션 상세 설명] 【오답 체크】 (A) [옵션 A 오답 이유 - 60~100자] (B) [옵션 B 오답 이유 - 60~100자] (C) [옵션 C 오답 이유 - 60~100자] (D) [옵션 D 오답 이유 - 60~100자] 【시험 포인트】 ▸ [시험 패턴 1] — 중요 개념 ▸ [시험 패턴 2] — 중요 개념 ▸ [시험 패턴 3] — 중요 개념

해설

【핵심 용어】 ▸ [Service/Concept 1] — 설명 ▸ [Service/Concept 2] — 설명 ▸ [Service/Concept 3] — 설명 ▸ [Service/Concept 4] — 설명 【정답 포인트】 ▸ [Key Point 1] — 정답 이유 ▸ [Key Point 2] — 정답 이유 ▸ [Key Point 3] — 정답 이유 Option B: [정답 옵션 상세 설명] 【오답 체크】 (A) [옵션 A 오답 이유 - 60~100자] (B) [옵션 B 오답 이유 - 60~100자] (C) [옵션 C 오답 이유 - 60~100자] (D) [옵션 D 오답 이유 - 60~100자] 【시험 포인트】 ▸ [시험 패턴 1] — 중요 개념 ▸ [시험 패턴 2] — 중요 개념 ▸ [시험 패턴 3] — 중요 개념

해설

【핵심 용어】 ▸ [Service/Concept 1] — 설명 ▸ [Service/Concept 2] — 설명 ▸ [Service/Concept 3] — 설명 ▸ [Service/Concept 4] — 설명 【정답 포인트】 ▸ [Key Point 1] — 정답 이유 ▸ [Key Point 2] — 정답 이유 ▸ [Key Point 3] — 정답 이유 Option C: [정답 옵션 상세 설명] 【오답 체크】 (A) [옵션 A 오답 이유 - 60~100자] (B) [옵션 B 오답 이유 - 60~100자] (C) [옵션 C 오답 이유 - 60~100자] (D) [옵션 D 오답 이유 - 60~100자] 【시험 포인트】 ▸ [시험 패턴 1] — 중요 개념 ▸ [시험 패턴 2] — 중요 개념 ▸ [시험 패턴 3] — 중요 개념