371
디지털 미디어 스트리밍 애플리케이션 호스팅하기위해 EKS 클러스터 생성 → EBS 볼륨으로 백업된 관리형 노드 그룹을 스토리지로 사용 + KMS에 저장된 고객 관리형 키를 사용하여 모든 저장 데이터를 암호화
C. EKS 클러스터가 생성될 AWS 지역에서 기본적으로 EBS 암호화를 활성화합니다. 기본 키로 고객 관리 키를 선택합니다.
→ EBS의 기본 암호화를 활성화하면, 모든 새로 생성된 EBS 볼륨이 자동으로 지정된 고객 관리형 키를 사용하여 암호화
D. EKS 클러스터를 만듭니다. 고객 관리 키에 대한 권한을 부여하는 정책이 있는 IAM 역할을 만듭니다. 역할을 EKS 클러스터와 연결합니다.
→ IAM 역할을 사용하여 EKS 클러스터가 KMS 키를 사용할 수 있도록 권한을 부여해야 KMS를 사용한 암호화 가능.
* Elastic Kubernetes Service: AWS에서 제공하는 컨테이너 기반의 서비스로 컨트롤 플레인을 직접 구성하지 않고 운영 및 유지 관리할 필요가 없는 관리형 서비스
372
Oracle 데이터베이스를 AWS로 마이그레이션 + 수백만 개의 고해상도 지리 정보 시스템 이미지가 포함된 단일 테이블로 구성 → 재해가 발생 시 수만 개의 이미지가 몇 분마다 업데이트 → 가용성이 높고 확장 가능한 솔루션 + 비용 효율적
B. Amazon S3 버킷에 이미지를 저장합니다. 지리적 코드를 키로, 이미지 S3 URL을 값으로 사용하여 Amazon DynamoDB를 사용합니다
⇒ S3에 이미지 저장( 무한 스토리지 용량, 내구성이 뛰어나고 빠른 데이터 액세스 속도 보장),
DynamoDB 사용(지리적 코드를 키로, 이미지가 저장된 S3 URL은 값으로 사용. 효율적으로 조회)
* DynamoDB: 키-값 데이터를 저장하는 데 최적화
373
IoT 센서에서 데이터를 수집하는 애플리케이션 + Kinesis Data Firehose를 통해 S3에 저장 + 이전 30일의 데이터를 사용하여 일련의 머신 러닝(ML) 모델을 재교육 + 매년 4회 이전 12개월의 데이터를 사용하여 분석을 수행하고 다른 모델로 교육 → 최대 1년 동안 최소한의 지연으로 사용 + 1년 후에는 보관 목적으로 데이터를 보관 + 가장 비용 효율적
D. S3 Standard 스토리지 클래스를 사용합니다. 30일 후에 S3 Standard-Infrequent Access(S3 Standard-IA)로, 1년 후에 S3 Glacier Deep Archive로 객체를 전환하는 S3 Lifecycle 정책을 만듭니다.
⇒S3 Standard-Infrequent Access: 필요할때 빠른 액세스가 필요한 데이터를 위한 것
데이터는 30일 동안 매일(Standard) 사용되고, 나머지 12개월 동안은 3~4회 사용(IA)되고, 12개월 후에는 전혀 사용되지 않고 보관되어야 합니다(Glacier Deep Archive)
* S3 Standrard 스토리지 클래스 : 자주 액세스 되는 데이터를 위한 기본 스토리지
* S3 Intelligent-Tiering 스토리지 클래스 : 데이터 액세스 패턴이 예측하기 어려운 경우
* S3 Standard-IA: 가끔 액세스되는 데이터에 적합
374
3개의 별도 VPC + VPC간에 통신 / 단일 온프레미스 데이터 센터에서 실행되는 지연에 민감한 애플리케이션에 매일 수백 기가바이트의 데이터를 지속적으로 전송 / 비용 효율성을 극대화하는 네트워크 솔루션 설계
D. 데이터 센터에서 AWS로 AWS Direct Connect 연결을 하나 설정합니다. 전송 게이트웨이를 만들고 각 VPC를 전송 게이트웨이에 연결합니다. Direct Connect 연결과 전송 게이트웨이 간의 연결을 설정합니다.
* Direct Connect: 인터넷이 아닌 다른 방법으로 AWS에 연결할 수 있는 네트워킹 서비스
* Transit Gateway 사용 => VPN 및 Direct Connect 연결을 여러 VPC와 공유 가능 → 비용 절감
375
서버리스 분산 애플리케이션을 구축 / 주문 처리 애플리케이션에 대한 아키텍처 설계 + 여러 Lambda 함수를 반응형 서버리스 애플리케이션으로 결합 + 인스턴스, 컨테이너 또는 온프레미스 서버에서 실행되는 데이터와 서비스를 조정 + 최소한의 운영 오버헤드
A. AWS Step Functions를 사용하여 애플리케이션을 빌드합니다.
* AWS Step Functions: AWS 서비스를 사용하여 “분산 애플리케이션”을 구축하고 프로세스를 자동화하며, Lambda 함수와 상태머신으로 결합하여 실행. 반응형 “서버리스” 서비스. 주문처리와 같은 워크플로우에 적합.
376
RDS for MYSQL DB 인스턴스 + 대부분의 연결은 서버리스 애플리케이션에서 발생 + 트래픽은 무작위 간격으로 크게 변경 → 수요가 많은 시간에 사용자는 데이터베이스 연결 거부 오류가 발생 + 가장 적은 운영 오버헤드
A. RDS Proxy에서 프록시를 만듭니다. RDS Proxy를 통해 DB 인스턴스를 사용하도록 사용자 애플리케이션을 구성합니다.
RDS 연결 거부 오류 ⇒ RDS Proxy 사용
* RDS Proxy: 확장성을 개선하기 위해 데이터베이스 연결을 풀링하고 공유하는 프록시 계층 제공
377
EC2 인스턴스의 운영 체제 버전, 패치 및 설치된 SW에 대한 정보를 중앙 집중화하기 위한 새로운 감사 시스템 + EC2 자동 확장 그룹을 통해 프로비저닝된 모든 인스턴스가 시작 및 종료되는 즉시 감사 시스템에 보고서를 성공적으로 보내야함
B. EC2 자동 확장 라이프사이클 후크를 사용하여 인스턴스가 시작되고 종료될 때 감사 시스템으로 데이터를 전송하는 사용자 지정 스크립트를 실행합니다.
* EC2 Auto Scaling Lifecycle Hooks : 새 인스턴스 시작 시 또는 인스턴스 종료 전에 호출되는 사용자 지정 작업을 정의하는 데 유용. 사용자 지정 스크립트 실행.
378
UDP를 사용하는 실시간 멀티플레이어 게임 개발 + 확장되는 데이터베이스 솔루션에 게이머 점수와 기타 비관계형 데이터를 저장.
B. 트래픽 분산을 위해 네트워크 로드 밸런서를 사용하고 데이터 저장을 위해 주문형 Amazon DynamoDB를 사용합니다.
* UDP ⇒ Network Load Balancer 사용
* Aurora Serverless ⇒ 관계형 데이터베이스
* DynamoDB ⇒ 비관계형 데이터베이스
379
AWS Lambda와 통합된 Amazon API Gateway API 백엔드 / Lambda 함수는 Amazon RDS 데이터베이스에 연결 / 회사 운영에 대한 변경 횟수를 최소화하여 모든 사용자에게 응답 지연 시간을 낮추고자함
B. 요청을 처리하는 Lambda 함수에 대해 프로비저닝된 동시성을 구성합니다.
프로비저닝된 동시성:
사전 초기화된 실행 환경 : 수신 함수 요청에 즉시 응답할 수 있도록 실행 환경을 초기화.
콜드 스타트 지연 감소: 프로비저닝된 동시성을 설정하면 사전에 Lambda 인스턴스를 준비해 함수의 호출에 즉시 응답
⇒ 프로세스 속도 증가
* 콜드 스타트 : Lambda 함수가 호출될 때마다 새로운 인스턴스가 생성되면서 초기화 시간이 발생하여 응답이 지연.
380
회사가 AWS로 마이그레이션 + 여러 EC2 인스턴스와 RDS DB 인스턴스 사용 + 영업 시간 외에 EC2 인스턴스와 DB 인스턴스를 자동으로 시작하고 중지하는 솔루션 + 비용과 인프라 유지 관리 최소화
D. EC2 인스턴스와 DB 인스턴스를 시작 및 중지하는 AWS Lambda 함수를 만듭니다. Amazon EventBridge를 구성하여 일정에 따라 Lambda 함수를 호출합니다.
* Lambda: “서버리스” 서비스, 실행시간에 대해서만 비용 부과
* EventBridge: 일정에 따라 Lambda 함수 트리거 가능하므로 추가 인프라 비용 없이 자동화 구현 가능
381
PostgreSQL 데이터베이스를 포함하는 3계층 웹 애플리케이션 호스팅 + 보고서에서 검토하는 문서를 검색하기 위해 메타데이터에서 주요 용어 검색 + 문서는 S3에 저장 + 한 번만 작성되지만 자주 업데이트 → 관계형 쿼리를 사용하면 보고 프로세스에 몇 시간이 걸림 + 문서 수정이나 새 문서 추가를 방해해서는 안됨 → 보고 프로세스를 가속화하기 위한 솔루션 + 코드를 가장 적게 변경하여 요구사항 충족
B. Aurora Replica를 포함하는 새로운 Amazon Aurora PostgreSQL DB 클러스터를 설정합니다. Aurora Replica에 쿼리를 발행하여 보고서를 생성합니다.
→ Aurora Replica: 읽기 복제본 자동으로 확장하여 보고 부하 처리 가능 + 호환되는 버전인 Aurora PostgreSQL 사용
382
사용자 기기에서 센서 데이터를 수집하는 3계층 애플리케이션 보유 + 트래픽은 NLB를 거쳐 EC2 인스턴스로 흐름 → 전송 중인 데이터의 보안 개선.
A. TLS 리스너를 구성합니다. NLB에 서버 인증서를 배포합니다.
SSL /TLS 사용 ⇒ NLB는 TLS 지원
* TLS (Transport Layer Security): 데이터를 암호화하여 전송 중에 데이터의 기밀성과 무결성을 보장
383
예측 가능한 용량 및 가동시간 요구사항이 있는 소켓과 코어를 사용하는 라이선스 모델 / 가장 비용 효율적인 가격 옵션
A. 전용 예약 호스트
예측 가능한 용량 및 가동 시간 요구 사항 ⇒ 예약형
소켓 및 코어 ⇒ 전용 호스트
384
Linux 인스턴스 애플리케이션에는 고가용성 및 POSIX 호환 스토리지 계층이 필요함 / 스토리지 계층은 최대 데이터 내구성 제공 + EC2 인스턴스에서 공유 가능 + 스토리지 계층의 데이터는 30일동안 자주 액세스 + 그 이후에 드물게 액세스 + 비용 효율적
C. Amazon Elastic File System(Amazon EFS) Standard 스토리지 클래스를 사용합니다. 라이프사이클 관리 정책을 만들어서 자주 액세스하지 않는 데이터를 EFS Standard-Infrequent Access(EFS Standard-IA)로 옮깁니다.
* AWS EFS: 간단하고 확장 가능하며 탄력적인 완전관리형 NFS 파일 시스템 + POSIX 규정 준수 공유 파일 스토리지
* 고가용성 : One-Zone 사용 X
385
새로운 VPC 디자인 + 로드 밸런서용 보안그룹 생성 0.0.0.0/0에서 포트 443을 허용 + 정책에 따라 리소스는 작업을 수행하는데 필요한 최소한의 액세스 권한 → 추가 구성 전략
C. 웹 서버에 대한 보안 그룹을 만들고 로드 밸런서에서 포트 443을 허용합니다. MySQL 서버에 대한 보안 그룹을 만들고 웹 서버 보안 그룹에서 포트 3306을 허용합니다.
* 최소 권한 : 웹 서버는 외부에서 들어오는 트래픽을 LB를 통해서만 받아야 하므로 0.0.0.0/0이 아닌 LB에서 포트 443을 받아야함
* 네트워크 ACL은 모든 인스턴스에 대한 규칙을 적용. 보안그룹이 더 세밀하게 정의.
386
데이터베이스에서 동일한 데이터 세트를 반환하는 호출이 자주 발생하여 성능이 저하 → 성능 개선
B. Amazon ElastiCache를 구현하여 대규모 데이터 세트를 캐시합니다.
* AWS ElastiCache: 인 메모리 데이터베이스 캐싱 시스템을 제공. 데이터를 검색할 수있는 성능, 속도 및 중복성을 향상시키는 캐싱 서비스. 자주 액세스하는 데이터가 메모리에 저장되어 검색 시간이 더 빨라짐. 빈번한 호출을 완화.
387
새로운 배포 엔지니어 + CloudFormation 템플릿을 사용하여 여러 AWS 리소스 생성 + 최소권한의 원칙을 따르면서 작업 수행
D. 배포 엔지니어를 위한 새로운 IAM 사용자를 생성하고 AWS CloudFormation 작업만 허용하는 IAM 정책이 있는 그룹에 IAM 사용자를 추가합니다.
E. 배포 엔지니어가 AWS CloudFormation 스택에 대한 권한을 명시적으로 정의하고 해당 IAM 역할을 사용하여 스택을 시작할 수 있도록 IAM 역할을 생성합니다.
* 루트 계정은 최소 권한 원칙에 대한 선택이 아님.
388
퍼블릭 서브넷이 있는 Auto Scailing Group 사용 + 데이터베이스는 프라이빗 서브넷에 있는 RDS for MYSQL DB 인스턴스 → 웹 계층이 프라이빗 서브넷에 있는 데이터베이스에 연결 X → 데이터베이스는 작동중 / 네트워크 ACL, 보안 그룹 및 경로 테이블에 대한 모든 구성은 여전히 기본 상태
D. 웹 계층 보안 그룹에서의 트래픽을 허용하기 위해 데이터베이스 계층 RDS 인스턴스의 보안 그룹에 인바운드 규칙을 추가합니다.
보안그룹 기본값 : 모든 인바운드 트래픽 차단
웹 계층 보안 그룹에서 트래픽을 허용하려면 데이터베이스 계층 RDS 인스턴스의 보안 그룹에 인바운드 규칙 추가
389
RDS for MYSQL DB 인스턴스에 저장된 온라인 광고 사업을 위한 대규모 데이터 세트 보유
→ DB 인스턴스에 대한 쓰기 작업에 영향을 미치지 않고 비즈니스 보고 쿼리를 실행
A. 비즈니스 보고 쿼리를 처리하기 위해 RDS 읽기 복제본을 배포합니다.
⇒ 읽기 복제본: 쓰기 작업에서 분리되서 프로덕션 쓰기 작업에 영향을 미치지 않고 보고 쿼리 수행 가능
390
3계층 전자상거래 애플리케이션 호스팅 + 거래 중에 고객 세션 관리를 최적화 + 세션 데이터를 내구성 있게 저장
A. ALB에서 스티키 세션 기능(세션 친화성)을 켭니다.
⇒ 동일한 사용자가 지속적으로 동일한 EC2 인스턴스에 연결
D. 고객 세션 정보를 저장하기 위해 Redis 클러스터용 Amazon ElastiCache를 배포합니다.
⇒ Redis는 매우 빠른 인메모리 데이터 저장소로, 세션 데이터를 내구성 있게 저장하고 빠르게 액세스할 수 있는 옵션입니다. ElastiCache를 사용하면 세션 관리가 효율적이고 내구성이 보장되며, Multi-AZ 구성을 통해 고가용성도 유지할 수 있습니다.
고객 세션 관리 최적화, 세션 관리 ⇒ Sticky + ElastiCache
* Sticky Session: 특정 세션의 요청을 처음 처리한 서버로만 전송하는 것
391
3계층 무상태 웹 애플리케이션 / Auto Scailing Group의 EC2 인스턴스에서 실행 + DB 계층은 PostgreSQL용 RDS에서 실행 → 웹 애플리케이션은 EC2 인스턴스에서 임시 로컬 스토리지 필요 X → 회사의 복구 지점 목표(RPO)는 2시간, 확장성을 극대화하고 리소스 활용도를 최적화
C. 웹 및 애플리케이션 계층의 최신 Amazon Machine Images(AMI)를 유지합니다. Amazon RDS에서 자동 백업을 활성화하고 RPO를 충족하기 위해 point-in-time 복구를 사용합니다.
* 3계층 무상태 웹 애플리케이션: 영구적인 데이터 저장이 필요하지 x 정기적 백업 x 최신 AMI를 유지하여 복구
* point-in-time 복구(PITR): 지정된 시점으로 데이터베이스를 복구
→ ASG에 따라 동적으로 생성되거나 종료되므로 인스턴스 상태는 중요하지 않고 새로운 인스턴스를 띄우는 것이 효율적임.
EC2 인스턴스는 무상태이므로 데이터를 유지할 필요가 없음. AMI를 사용하여 백업하면 충분함
392
새로운 퍼블릭 웹 애플리케이션 배포 + EC2 인스턴스를 사용하는 웹 서버 계층 포함 + RDS for MYSQL DB인스턴스도 사용
→ 동적 IP 주소를 가진 글로벌 고객에게 안전하고 액세스 가능해야함
A. 웹 서버의 보안 그룹을 구성하여 0.0.0.0/0에서 포트 443으로 인바운드 트래픽을 허용합니다. DB 인스턴스의 보안 그룹을 구성하여 웹 서버의 보안 그룹에서 포트 3306으로 인바운드 트래픽을 허용합니다.
* 동적 IP 주소=> 알 수 없으므로 0.0.0.0/0 인바운드 트래픽 허용 + DB 인스턴스의 보안그룹을 구성하여 웹 서버의 보안 그룹에서 포트 3306으로 인바운드 트래픽 허용
393
결제 처리 회사가 고객과의 모든 음성 통신을 녹음하고 S3 버킷에 오디오 파일을 저장 → 오디오 파일에서 텍스트를 캡처해야함 + 고객의 개인식별정보 (PII)를 제거
C. PII 편집을 켜서 Amazon Transcribe 전사 작업을 구성합니다. 오디오 파일이 S3 버킷에 업로드되면 AWS Lambda 함수를 호출하여 전사 작업을 시작합니다. 출력을 별도의 S3 버킷에 저장합니다.
⇒ 전사 작업 중에 PII 편집 기능을 켜면, 자동으로 텍스트 내에서 개인 식별 정보(PII)를 감지하고 제거하거나 마스킹할 수 있습니다.
* AWS Transcribe: 기계 학습 모델을 사용하여 오디오를 텍스트로 변환하는 자동 음성 인식 서비스
* Kinesis Video Streams: 주로 비디오 스트리밍 처리에 사용
* Amazon Textract: 문서에서 텍스트를 추출하는 서비스
* Amazon Connect: 음성 통화를 관리하는 데 유용
394
회사가 다중 계층 전자상거래 웹 애플리케이션 실행 + SSD(gp3) 볼륨에 2000GB의 스토리지가 있는 최신 세대 DB로 구성 / 데이터베이스 성능은 수요가 많은 기간 동안 애플리케이션에 영향 → 데이터베이스 관리자가 CloudWatch Logs 의 로그를 분석하고 읽기 및 쓰기 IOPS 수가 20000보다 높으면 성능이 항상 저하된다는 부분 확인 → 성능을 개선
C. 볼륨을 Provisioned IOPS SSD(io2) 볼륨으로 교체합니다.
D. 2,000GB gp3 볼륨을 두 개의 1,000GB gp3 볼륨으로 교체합니다.
→ IOPS는 기본적으로 스토리지 크기에 의존하지 않으며, 이를 분할한다고 해서 성능이 반드시 개선되지 않습니다.
프로비저닝된 IOPS SSD(io2)는 지속적인 고성능과 낮은 지연 시간을 제공하도록 설계
395
회사 계정의 AWS 리소스에 여러 가지 구성 변경 → 어떤 IAM 사용자가 변경을 담당했는지 확인하기 위한 서비스
C. AWS CloudTrail (클라우드 트레일)
* CloudTrail 이란?
- AWS 계정 내에서 이루어지는 모든 작업과 활동에 대해 기록하는 서비스
- "누가" 변경을 적용했는지 감시하는 것에 초점을
* Config 란?
- AWS 리소스의 구성 변경에 대한 기록과 변경 알림을 제공하는 서비스
- "무엇이" 변경되었는지 감시하는 것에 초점을
396
자체 관리형 DNS 서비스 구현 → 1. 다양한 지역의 Amazon EC2 인스턴스 2. Global Accelerator의 표준 가속기 엔드포인트
→ DDOS 공격으로부터 솔루션 보호
A. AWS Shield Advanced를 구독합니다. 가속기를 보호할 리소스로 추가합니다.
* DDOS 공격 ⇒ Shield Advanced 사용
* Global Accelerator : 인터넷에 노출되는 부분 ⇒ DDOS가 발생할 수 있는 부분 ⇒ Shield Advanced로 보호해야 하는 부분
397
분석을 위해 판매 기록을 집계하고 필터링하기 위해 예약된 일일 작업 실행 / Amazon S3 버킷에 판매 기록을 저장 → 판매 이벤트 수에 따라 작업을 완료하는데 최대 1시간이 걸릴 수 있음 + 최대 10GB + 작업의 CPU 및 메모리 사용량은 일정하며 미리 알려져 있음
→ 필요한 운영 노력의 양 최소화 솔루션
C. AWS Fargate 시작 유형으로 Amazon Elastic Container Service(Amazon ECS) 클러스터를 만듭니다. 클러스터에서 ECS 작업을 시작하여 작업을 실행하는 Amazon EventBridge 예약 이벤트를 만듭니다.
Lambda: 15분의 실행 시간 제한 존재 → 1시간이 걸릴 수 있는 작업에는 불충분
Fargate ECS ↔ EC2 Auto Scailing Group ECS
Fargate ECS가 더 운영 오버헤드가 적음
398
600TB의 데이터 전송 + 데이터는 민감하므로 전송 중에 암호화 + 인터넷 연결은 100Mbps의 업로드 속도를 지원 + 비용 효율적
C. AWS Snow Family 콘솔을 사용하여 여러 AWS Snowball Edge Storage Optimized 장치를 주문합니다. 장치를 사용하여 데이터를 Amazon S3로 전송합니다.
⇒ Snowball Edge: 페타바이트 규모의 데이터 전송 장치로, 대량의 데이터를 안전하고 빠르게 전송하는데 도움.
데이터 전송 전부터 암호화되며, 전송되는 동안에도 계속 암호화 상태가 유지됩니다
399
Amazon API Gateway Regional API 엔드포인트 사용하여 현재 주가를 검색할 수 있는 기능을 제공 → API 요청 수가 증가 + HTTP 플러드 공격으로 인해 애플리케이션이 오프라인이 될 수 있다는 우려 → 공격으로부터 애플리케이션을 보호하는 솔루션
B. 요금 기반 규칙으로 지역 AWS WAF 웹 ACL을 만듭니다. 웹 ACL을 API Gateway 스테이지와 연결합니다.
⇒ HTTP 플러드 공격으로부터 API Gateway API를 보호 가능.
* HTTP 플러드 공격 : DDOS의 일종. 대량의 HTTP 요청으로 정상적인 트래픽을 처리하지 못하도록 함.
WAF, CloudFront, Shield Advanced, Auto Scaling으로 방어.
* WAF: 웹 애플리케이션에 대한 HTTP 요청을 모니터링하고, 악의적인 트래픽을 필터링하거나 차단
* ACL(Application Control List): AWS WAF에서 특정 트래픽을 허용하거나 차단하는 규칙을 적용하는 데 사용
400
날씨 데이터를 온라인 사용자에게 판매하기 위한 웹 애플리케이션 보유 + DynamoDB를 사용하여 데이터를 저장하고 새로운 이벤트가 기록될 때마다 4개 내부 팀의 관리자에게 알림을 보내는 새로운 서비스를 구축 → 현재 애플리케이션 성능에 영향을 미치지 않기를 원함 + 최소한의 운영 오버헤드
C. 테이블에서 Amazon DynamoDB Streams를 활성화합니다. 트리거를 사용하여 팀이 구독할 수 있는 단일 Amazon Simple Notification Service(Amazon SNS) 토픽에 씁니다.
* DynamoDB Stream: DynamoDB Table의 변경사항에 대한 정보들을 시간 순서에 따라 항목 수준 수정을 캡처하고 이 정보를 최대 24시간 동안 로그에 저장. 비동기적으로 처리하기 때문에 성능에 영향 x
⇒ Lambda 함수 트리거를 통해 SNS 토픽에 메시지를 게시하면, 각 팀이 이 토픽을 구독하여 알림을 받을 수 있음
'클라우드 > AWS' 카테고리의 다른 글
| [Associate SAA-C03] - dump 정리 441 ~ 470 (0) | 2024.10.07 |
|---|---|
| [Associate SAA-C03] - dump 정리 401 ~ 440 (0) | 2024.10.07 |
| [Associate SAA-C03] - dump 정리 351 ~ 370 (0) | 2024.10.05 |
| [Associate SAA-C03] - dump 정리 321 ~ 350 (0) | 2024.10.04 |
| [Associate SAA-C03] - dump 정리 301 ~ 320 (0) | 2024.10.02 |