AWS Certified Developer – Associate 자격증 공부 8일차

오늘은 201~ 300까지 풀었다.

https://dumps.kr/dumps/amazon-dva-c01/201

 

---

201.

- Secrets Manager가 최신의 정답이고 이전에는 AWS SSM Parameter Store를 사용하여 비밀을 저장하고 EC2 인스턴스의 IAM 역할을 사용하여 프로그래밍 방식으로 액세스했음

 

202.

- B가 안되는 이유는 이미 구축되어 있기 때문에 만들필요가 없고 A만 하면 됨

 

203.

비교하기!

- 사용자 풀은 인증용

- 자격 증명 풀은 애플리케이션이 리소스에 액세스할 수 있도록 승인

 

204.

- E : 애플리케이션은 버킷의 접두사당 초당 최소 3,500개의 PUT/COPY/POST/DELETE 또는 5,500개의 GET/HEAD 요청을 달성할 수 있습니다. 버킷의 접두사 수에는 제한이 없습니다. 읽기를 병렬화하여 읽기 또는 쓰기 성능을 향상시킬 수 있습니다. 예를 들어 Amazon S3 버킷에 10개의 접두사를 생성하여 읽기를 병렬화하는 경우 읽기 성능을 초당 55,000개의 읽기 요청으로 확장할 수 있습니다.

 

- A : Cloudfront는 Edge에서 캐시해서 성능을 향상시킴

 

208.

- D : 보유 옵션을 보유로 설정하면 소스 번들이 S3에 유지된다.

C는 x이다.

 

210.

- codebuild 보고서를 사용하면 buildspec.yml 파일의 빌드 또는 post_build 시퀀스에서 단위, 기능 또는 통합 테스트가 생성된 보고서를 볼 수 있다.

 

211.

- C : Round data to the nearest 4KB for event./strongly READ consistency calculations: 5KB data chunk read requires 2 RCU (2*4KB, 1RCU = 4KB). 2RCU*100 reads per second gives us 200 strongly consistent reads

 

1 RCU = 1KB이므로 5 KB 는 2RCU가 필요하다.

2RCU * 100개 항목 = 200 읽기 용량 단위가 필요하다.

 

212.

- B가 안되는 이유 : 암호화된 트래픽을 명시적으로 "허용"한다고 해서 암호화되지 않은 트래픽을 거부하는 것은 아니라는 사실 때문

- D인 이유 : 암호화되지 않은 트래픽을 명시적으로 거부하기 때문

 

213.

- 기본 키는 해시 키와 선택적 범위 키로 구성됩니다. 해시 키는 DynamoDB 파티션을 선택하는 데 사용됩니다. 파티션은 테이블 데이터의 일부입니다. 범위 키는 파티션에 항목이 있는 경우 항목을 정렬하는 데 사용됩니다.

 

214.

- 각 Lambda 함수는 자체 /tmp 디렉터리에서 512MB의 비영구적 디스크 공간을 받습니다.

 

216.

- A : 대기열에 처음 추가됨 -> 대기열에서 소비된 후 대기열 지연 -> 가시성 시간 초과(visibility timeouts)

 

218.

- B 안되는 이유 : 프록시 URL(클라이언트에 공유되는 엔드포인트 URL이라고도 함)은 lambda-based-microservices 에서 지원하므로 결국 /v1은 buggy-lambda-based-microservice를 가리키고 /v2는 bugfixed-lambda-based-microservice를 가리킵니다.

(또는 클라이언트가 사용중인 버전을 알 수 없으므로 단계적 배포 매개변수가 존재 하기 어렵다)

- C : 새 단계를 배포해서 url 제공

 

219.

- C : 정당 테이블 모든 AWS 계정의 초기 제한은 AWS 리전당 256개 테이블입니다. 서비스 제한 증가를 요청하려면 https://aws.amazon.com/support를 참조

- D가 안되는 이유 : 테이블당 20개의 글로벌 보조 인덱스의 초기 제한이 있고 AWS 에 문의해서 늘릴 수 있음.

- E : DynamoDB 스트림이 활성화된 DynamoDB 테이블의 쓰기 용량에 몇 가지 기본 제한을 설정합니다. 더 높은 금액을 요청하지 않는 한 이것이 한도입니다. 서비스 한도 증가를 요청하려면 https://aws.amazon.com/support를 참조

 

* C, E는 요금 늘리면 처리량 늘려줌

 

221.

 

- 환경이 다르므로 서로 다른 lambda에서 가리키도록 해야함.(패키지도 다를 수 있으므로)

 

222.

- D : 단계 변수에 다른 엔드포인트 값을 설정하여 다른 백엔드 엔드포인트에 연결하도록 각 단계에서 API 메서드를 구성

https://aws.amazon.com/ko/about-aws/whats-new/2015/11/amazon-api-gateway-supports-stage-variables/

 

224.

- CodeDeploy 애플리케이션에 대해 하나 이상의 배포 그룹을 지정할 수 있습니다. 각 애플리케이션 배포는 해당 배포 그룹 중 하나를 사용합니다. 배포 그룹에는 배포 중에 사용되는 설정 및 구성이 포함됩니다.

 

226.

- B , E : 스토리지 디바이스의 유효 수명이 다하면 AWS는 NIST 800-88에 자세히 설명된 기술을 사용하여 미디어를 폐기합니다. AWS는 스토리지 장치의 수명이 다하면 폐기 프로세스를 시작합니다. 이 프로세스는 고객 데이터가 승인되지 않은 개인에게 노출되지 않도록 합니다. 이 하드웨어 장치는 AWS가 따르는 표준 프로세스를 사용한 폐기에 실패할 경우 물리적으로 파괴되거나 소자됩니다.

즉, 저장장치, 물리적 저장장치는 AWS에서 관리, 내부는 고객이 관리

 

227.

- A  : Session 데이터가 항상 Elasticache 또는 DB에 저장되어야 함.

- C인 이유 : C Sticky는 NLB에서 사용할 수 있으며 어떤 Stick 세션이 더 나은지 사용자 활동(요청)을 기록

 

A와 C가 갈린다. 근데 A가 맞아보인다.

정답은 A : sticky 세션이 요청을 동일한 인스턴스로 라우팅하는 기능일 뿐이지만 실행 중인 컨테이너의 요구 사항이 낮아져 인스턴스가 삭제되면 사용자는 오류에 직면하고 다시 로그인하게 됩니다. Redis를 사용하면 이 이벤트가 발생하더라도 동일한 세션을 유지할 수 있다.

 

230.

- B 가 안되는 이유 : SAML은 문제에서 언급되지 않은 도메인 자격 증명용으로 사용하는 것임

- A인 이유 : 웹 자격 증명 연동을 사용하여 AWS 리소스에 액세스하도록 개별 자격 증명 공급자를 직접 구성가능

https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/loading-browser-credentials-federated-id.html

 

231.

- AssumedRoleId 역할 ID와 역할 세션 이름이 포함된 고유 식별자입니다. 역할 ID는 역할이 생성될 때 AWS에서 생성됩니다. 자격 증명 액세스 키 ID, 비밀 액세스 키 및 보안(또는 세션) 토큰을 포함하는 임시 보안 자격 증명입니다. 

즉 , AccessKeyId 임시 보안 자격 증명을 식별하는 액세스 키 ID

 

241.

- A 인 이유 : 배포가 완료된 후 권한을 변경할 수 있음.

 

242.

lambda로 하루 이미지를 다 가져오는 건 아니고 여러날 이미지가 필요하므로 EC2로 하는게 lambda보다 맞음

 

246.

- AWS는 CloudFront 캐시를 무효화하여 이전 데이터를 지울 수 있습니다.

- 만약 C처럼 데이터 삭제가 없다면, 더 나은 솔루션은 CloudFront에서 TTL을 0으로 줄이는 것도 같은 효과를 낼 수 있다.

 

248.

 

- Prod, dev 및 staging의 경우 코드가 동일한 경우 다른 단계를 갖는 것이 의미가 없기 때문에 코드가 다른 다른 람다가 필요합니다.

- 여러 별칭이 있는 하나의 lambda 함수를 사용하여 여러 단계의 API 게이트웨이를 한 개 생성한다.

 

249.

- B : 하나의 쓰기 용량 단위는 최대 1KB 크기의 항목에 대해 초당 하나의 쓰기를 나타냅니다. 1분 동안 1KB 데이터가 기록되므로 초당 1/60KB 데이터가 기록됩니다(WCU는 초당 계산됨). 따라서 1/60*600=10 WCU입니다.

 

250.

- A : EB 콘솔 및 애플리케이션으로 이동하면 ; 콘솔에서 바로 업로드 및 배포를 위한 BIG 옵션을 볼 수 있습니다. (Zip 업로드 및 배포).

- D : 애플리케이션 새 버전을 생성하고 대상 앱의 환경을 업데이트하여 AWS EB CLI를 사용하여 동일한 작업을 수행

 

253.

-C :  동일한 버킷에 액세스 로그를 넣으면 안됨. 루프가 된다.

소스 버킷 자체를 포함하여 소스 버킷과 동일한 리전에 있는 소유한 모든 버킷에 넣으면 로그의 무한 루프가 발생하므로 권장하지 않습니다. 간단한 로그 관리를 위해 액세스 로그를 다른 버킷에 저장하는 것이 좋습니다.

 

255.

- 사용자 풀은 인증(신원 확인)을 위한 것입니다. 사용자 풀을 사용하면 앱 사용자가 사용자 풀을 통해 로그인하거나 타사 ID 공급자(IdP)를 통해 연동할 수 있습니다.

- 자격 증명 풀은 권한 부여(액세스 제어)를 위한 것입니다. 자격 증명 풀을 사용하여 사용자의 고유 자격 증명을 생성하고 다른 AWS 서비스에 대한 액세스 권한을 부여할 수 있습니다.

 

256.

- EB의 경우 : Elastic Beanstalk를 사용하는 경우 애플리케이션 코드에 언어별 X-Ray 라이브러리를 포함해야 합니다

- EC2 또는 ECS와 같은 다른 AWS 서비스에서 실행되는 애플리케이션의 경우 :  X-Ray 에이전트를 설치하고 애플리케이션 코드를 계측해야 합니다.

 

* B 외에 정답으로 인정할 수 있는 것은 X-RAY에 쓸 수 있는 IAM 역할도 줘야한다는 것이다.

 

258.

 

- Dockerrun.aws.json은 환경의 각 컨테이너 인스턴스(Docker 컨테이너를 호스팅하는 Amazon EC2 인스턴스)에 배포할 컨테이너와 탑재할 컨테이너에 대해 호스트 인스턴스에 생성할 데이터 볼륨을 설명합니다.

- Amazon ECS 작업 정의 : Elastic Beanstalk는 프로젝트의 Dockerrun.aws.json 파일을 사용하여 환경에서 컨테이너 인스턴스를 구성하는 데 사용되는 Amazon ECS 작업 정의를 생성합니다. 그렇기 때문에 작업 정의를 사용하는 것입니다.

 

요약하자면, Dockerrun.aws.json은 기본적으로 다양한 유형의 컨테이너, 메모리 사용량, 포트 매핑 등을 정의하는 ECS 작업 정의할 수 있다.

 

259.

- DAX는 DynamoDB용 캐싱 솔루션이다.

- DynamoDB NoSQL 계층을 확장하여 이러한 반복 요청을 캐시하도록 요청했기 때문에 B가 알맞다.

 

만약 NoSQL 계층 확장하여 반복 요청을 캐시이런 말이 없었다면 D도 알맞을 것이다.

 

261.

E : S3는 컴퓨팅을 수행하지 않으며 파일과 같은 객체만 반환하기 때문에 틀림(정적 컨텐츠라서 작동하지 않음)

- B : ALB는 정적 DNS 이름을 노출합니다. 필요한 경우 URL 경로 방식을 사용하여 트래픽을 라우팅할 수 있고 애플리케이션은 EC2에서 실행됩니다.

- D : API 게이트웨이는 쿼리를 실행하는 Lambda로 전달되는 호출을 처리합니다.

 

* B,D가 정답.

https://www.examtopics.com/discussions/amazon/view/51366-exam-aws-certified-developer-associate-topic-1-question-50/

 

263.

 

- API 호출이 이미 Cloudwatch 로그에 기록되어 있는 로그에 메트릭 필터를 생성했을 것임 또한 가장 저렴

*C도 되긴 하는데 가격이 비싸서 최선의 정답이 아님.

 

264.

 

- A안되는 이유 : 기존 인스턴스를 계속 실행하면서 별도의 새 배포를 만들어야 하므로 A를 선택할 수 없습니다. 이는 용량 제약을 충족하지만 비용을 충족하지는 않습니다

- B 안되는 이유 : 새로운 교체 배치가 작동하지 않을 수 있기 때문에 롤링을 선택할 수 없습니다. 그러면 일관된 용량을 유지할 수 없습니다.

- C 안되는 이유 : 다운타임이 있기 때문에 "한 번에 모두"를 선택할 수 없습니다.

- D인 이유 : 불변" 방법보다 저렴합니다. 모든 인스턴스를 한 번에 배포하지 않기 때문입니다. (비용 효율적)

 

265.

- 256KB보다 큰 메시지를 보내려면 Amazon SQS Extended Client Library for Java를 사용할 수 있습니다. 이 라이브러리를 사용하면 Amazon S3의 메시지 페이로드에 대한 참조가 포함된 Amazon SQS 메시지를 보낼 수 있습니다. 최대 페이로드 크기는 2GB입니다.

 

266.

- 무엇이 비용을 절감시킬 수 있냐가 문제임 : API GW 가격은 단계 번호가 아닌 API 호출 수에 따라 달라집니다. 질문은 무엇이 비용을 절감할 수 있는지 묻는 것이므로 D가 정답.

 

267.

- X-Ray : AWS X-Ray는 애플리케이션이 처리하는 요청에 대한 데이터를 수집하는 서비스이며, 해당 데이터를 보고, 필터링하고, 통찰을 얻어 문제와 최적화 기회를 식별할 수 있는 도구

- 애플리케이션의 구성(최근엔 분산 마이크로서비스 등 복잡한 형태)을 시각화 한 맵으로 표현해주는 서비스

- 요청에 대한 추적 데이터를 Lambda 함수로 전송하고 워커에서 X-Ray 데몬을 실행하여 X-Ray SDK를 더 간단하게 사용할AWS Lambda 수 있습니다.

 

268.

- B : 클라이언트 측 암호화(애플리케이션 내에 저장한 마스터 키를 사용)는 클라이언트 측에서 암호화된 데이터를 전송한다. 실제로 전송 중과 유휴 상태를 모두 보호한다.

- D : SSL 연결은 추가 보안 계층을 제공

 

270.

- B가 아닌 이유 : 전송 가속은 다운로드가 아닌 주로 업로드의 경우에 사용, S3 Transfer Acceleration은 S3 버킷(주로 업로드)에 대한 더 빠른 전송 및 더 높은 처리량을 위한 것

- D인 이유 : Amazon CloudFront는 .html, .css, .js 및 이미지 파일과 같은 정적 및 동적 웹 콘텐츠를 사용자에게 빠르게 배포하는 웹 서비스

 

272.

- D는 S3 버킷에 대한 전체 액세스 권한을 제공하고 B는 더 제한적인 것처럼 보이며 읽기 액세스 권한만 제공할 수 있습니다. 문제는 읽기 전용 액세스를 요구하는 것이므로 D보다 B를 선택해야 합니다.

- B와 C 중에는 역할이 S3 버킷에 구성된 인라인 정책보다 선호되기 때문에 B를 선택

 

273.

- 순서 : 배포에서 후크 실행 순서(배포 그룹에 클래식 로드 밸런서 없음) 시작 -> 애플리케이션 중지 -> 번들 다운로드 -> 설치 전 -> 설치 -> 설치 후 -> 애플리케이션 시작 -> 서비스 유효성 검사 -> 종료

 

274.

- 여러 클라이언트가 동일한 레코드에 쓰기를 시도할 때 응용 프로그램의 안정성을 높이려면 개발자는 오류 재시도 및 지터가 포함된 지수 백오프를 구현해야 합니다. 이 접근 방식에서는 각 재시도 사이의 대기 시간을 늘려 쓰기 작업을 재시도하여 경합을 줄이고 성공적인 쓰기 가능성을 높이는 데 도움이 됩니다. 대기 시간에 지터를 추가하면 재시도 횟수가 무작위로 지정되어 모든 클라이언트가 동시에 재시도하여 발생하는 정체를 방지할 수 있습니다. 테이블의 쓰기 용량을 늘리면 경합을 줄이고 처리량을 늘리는 데 도움이 될 수 있지만 사용량이 가장 많은 시간에는 비용 효율적이거나 확장 가능한 솔루션이 아닐 수 있습니다.

 

* jitter : 시간 경과에 따른 지연 시간의 변화입니다. 모든 패킷이 A에서 B로 이동하는 데 정확히 같은 시간이 걸리면 지터가 없습니다.

* 지수 백오프(exponential backoff) : 지수 백오프의 기본 아이디어는 오류 응답이 연이어 나올 때마다 재시도 간 대기 시간을 점진적으로 늘린다는 것, 지터(임의 지연)를 사용하여 연쇄 충돌을 방지

 

275.

비교

- CodeCommit/CodeDeploy/CodePipeline -> AWS SNS로만 알림을 할 수 있습니다.

- Lamda/SNS/CodeBuild 일정 트리거에 대한 CodeCommit에서 수행할 수 있는 트리거입니다.

- CodePipeline-> Lamda의 상태 변경에서 트리거되며 이는 Cloudwatch events만 해당됩니다.

 

278.

- E : SSL 종료는 SSL 암호화 데이터 트래픽이 해독(또는 오프로드)되는 프로세스입니다. SSL(Secure Socket Layer) 연결이 있는 서버는 여러 연결 또는 세션을 동시에 처리할 수 있습니다. SSL 연결은 인증용 인증서를 사용하여 최종 사용자의 컴퓨터와 웹 서버 간에 암호화된 데이터를 보냅니다. SSL 종료는 암호 해독 프로세스 속도를 높이고 백엔드 서버의 처리 부담을 줄이는 데 도움이 됩니다.

 

참고

https://avinetworks.com/glossary/ssl-termination/

 

279.

- 작업 BatchGetItem은 하나 이상의 테이블에서 하나 이상의 항목 속성을 반환합니다. 기본 키로 요청된 항목을 식별합니다.

- 다만, 100개 이상의 항목을 요청하면 너무 많은 항목이 요청되었습니다."라는 메시지와 함께 를 ValidationException BatchGetItem반환합니다 .

 

281.

- 키워드는 서버리스입니다. 항상 SAM(서버리스 어플리케이션 모델)을 사용하여 서버리스 애플리케이션을 구축

 

283.

- 강력한 일관된 읽기는 최종적으로 일관된 읽기보다 더 많은 처리량을 사용합니다. 네트워크 지연 또는 중단이 있는 경우 강력한 일관된 읽기를 사용할 수 없으며 DynamoDB가 서버 오류(HTTP 500)를 반환할 수 있습니다. 

- 읽기 요청이 첫 번째 시도에서 리더 노드에 도달하지 않으면 강력한 일관된 읽기의 대기 시간이 길어질 수 있습니다.

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html

 

284.

 

- 동시성에 관해서는 Lambda가 king이라고 한다.

 

287.

- B (트러스트 관계) : 이 정책은 역할을 맡을 수 있는 주체와 조건을 정의합니다. 이를 IAM 역할에 대한 리소스 기반 정책이라고도 합니다. 이 정책을 간단히 '신뢰 정책'이라고 합니다. 

- C(권한 정책; 인라인 및 연결) :  이러한 정책은 역할을 맡은 보안 주체가 수행할 수 있는(또는 제한된) 권한과 리소스에 대해 정의

 

291.

- A가 아닌이유 : Auto Scaling에 대한 '동시 사용자 임계값' 메트릭이 없습니다. 이 값에 따라 확장하려면 사용자 지정 메트릭을 생성해야 합니다.

- D인 이유: CloudWatch로 전송된 Amazon Connect 지표에서 인스턴스에 대한 동시 호출 할당량을 초과한 총 음성 호출 수입니다. 할당량을 위반한 총 호출 수는 Sum 통계를 살펴보십시오.

https://docs.aws.amazon.com/connect/latest/adminguide/monitoring-cloudwatch.html

 

293.

- AssumeRole :  AWS 리소스에 액세스하는 데 사용할 수 있는 임시 보안 자격 증명 세트를 반환합니다. 이러한 임시 자격 증명은 액세스 키 ID, 보안 액세스 키 및 보안 토큰으로 구성됩니다. 일반적으로 계정 내에서 또는 교차 계정 액세스에 사용함.

- You cannot call the AWS STS GetFederationToken or GetSessionToken API operations

 

* AWS Security Token Service(AWS STS)를 사용하면 AWS 리소스에 대한 액세스를 제어할 수 있는 임시 보안 자격 증명을 생성하여 신뢰받는 사용자에게 제공

 

294.

- SDK는 자동으로 지수 백오프를 추가합니다. AWS SDK를 사용하지 않는 경우 자체 백오프 논리를 애플리케이션 코드에 추가합니다.

-> SDK를 사용하면 자동으로 지수 백오프를 추가했을 텐데, 문제에서는 SDK에 호환되지 않는다고 했으므로 수작업으로 지수 백오프를 애플리케이션에 추가해줘야함.

 

297.

 

- B인 이유 : ALB의 새로운 인증 작업은 Amazon Cognito를 통해 Google, Facebook 및 Amazon과 같은 소셜 자격 증명 공급자(IdP)를 통한 인증을 제공합니다. 또한 모든 OpenID Connect 프로토콜 호환 IdP와 기본적으로 통합되어 애플리케이션 전체에서 보안 인증 및 싱글 사인온 경험을 제공합니다.

- C가 안되는 이유 : Cloudfront는 CDN입니다. CloudFront 엔드포인트를 Amazon Cognito 리전 엔드포인트에 대한 프록시로 사용하도록 클라이언트 애플리케이션(모바일 또는 웹 클라이언트)을 구성합니다. 사용자가 애플리케이션에 액세스할 때 사용자를 안전하게 인증하도록 Application Load Balancer를 구성할 수 있습니다. 이렇게 하면 사용자 인증 작업을 로드 밸런서로 오프로드하여 애플리케이션이 비즈니스 로직에 집중할 수 있습니다.

 

* C라고 나왔는데 B가 맞는 정답

https://www.examtopics.com/discussions/amazon/view/78871-exam-aws-certified-developer-associate-topic-1-question-7/

 

299.

- B, E :  SQS를 사용하여 비동기식으로 데이터 처리

 

* 2계층 애플리케이션이란 프론트 엔드가 데이터 소스(예: 데이터베이스)에 직접 연결된 경우 2계층이라고 합니다.

* 프런트 엔드와 데이터 소스 사이에는 EC2 또는 SQS 대기열이 없습니다. 이 아키텍처는 데이터 원본을 실행하는 데만 비용을 지불하고 그 사이에 비용을 지불하지 않기 때문에 비용 효율적입니다. 그러나 단점은 질문 상태와 마찬가지로 백엔드가 동시에 들어오는 모든 요청에 ​​응답할 수 없다는 것입니다.

 

300.

- E : API 를 사용하여 세그먼트 문서를 X-Ray로 직접 보낼 수 있습니다. PutTraceSegments, PutTelemetryRecords permission을 주면 됨

https://docs.aws.amazon.com/xray/latest/devguide/xray-api-segmentdocuments.html

- B : X-Ray SDK로 애플리케이션을 구성하면 SDK가 세그먼트 문서를 생성합니다. SDK는 세그먼트 문서를 X-Ray로 직접 보내는 대신 로컬 UDP 포트를 통해 X-Ray 데몬 으로 전송