[DOP-C01] AWS DevOps Engineer Professional : Part 19

 

1. 사용자가 실행 중인 인스턴스에서 EBS 볼륨을 분리하고 새 인스턴스에 연결할 때 파일 시스템 손상을 방지하기 위해 아래 언급된 옵션 중 따라야 하는 옵션은 무엇입니까?
   • 먼저 볼륨 마운트 해제 
   • 처리하기 전에 볼륨의 모든 I/O 중지
   • 분리하기 전에 볼륨의 스냅샷을 찍습니다.
   • 모든 데이터가 그대로 유지되도록 볼륨을 강제로 분리합니다.
   설명:

   사용자가 EBS 볼륨을 분리하려고 할 때 사용자는 인스턴스를 종료하거나 명시적으로 볼륨을 제거할 수 있습니다. 파일 시스템 손상을 방지하려면 먼저 볼륨을 마운트 해제하는 것이 좋습니다.
   
   
   

2. 사용자가 기존 스냅샷에서 새 EBS 볼륨을 생성하고 있습니다. 스냅샷 크기는 10GB로 표시됩니다. 사용자가 해당 스냅샷에서 30GB의 볼륨을 생성할 수 있습니까?
   • 원래 볼륨이 크기 변경 속성을 true로 설정한 경우
   • 예
   • 스냅샷에 true로 설정된 크기 수정 속성이 있는 경우
   • 아니요
   설명:

   사용자는 항상 원래 스냅샷 크기보다 더 큰 새 EBS 볼륨을 생성할 수 있습니다. 사용자는 더 낮은 크기의 볼륨을 생성할 수 없습니다. 새 볼륨이 생성되면 인스턴스의 크기가 원래 크기로 표시됩니다. 사용자는 resize2fs 또는 기타 OS 특정 명령을 사용하여 장치의 크기를 변경해야 합니다.
   
   

3. 메시지는 기본적으로 SQS 대기열에 얼마 동안 보관됩니까?
   • 메시지를 읽지 않으면 절대 삭제되지 않습니다.
   • 이주
   • 1 일
   • 4 일
   설명:

   SQS 메시지 보존 기간은 구성 가능하며 1분에서 2주까지 설정할 수 있습니다. 기본값은 4일이며 메시지 보존 한도에 도달하면 메시지가 자동으로 삭제됩니다. 더 긴 메시지 보존 옵션은 더 큰 유연성을 제공하여 메시지 생성과 소비 사이의 더 긴 간격을 허용합니다.
   
   

4. 사용자가 실행 중인 Linux 인스턴스에 "/dev/sdf" 장치로 EBS 볼륨을 연결했습니다. 사용자는 "df -h" 명령을 실행할 때 연결된 장치를 볼 수 없습니다.
   
   이에 대한 가능한 이유는 무엇입니까?
   
   • 볼륨이 인스턴스의 동일한 AZ에 있지 않습니다.
   • 볼륨이 포맷되지 않았습니다
   • 볼륨이 루트 장치로 연결되지 않았습니다.
   • 볼륨이 마운트되지 않았습니다.
5. Amazon SQS를 사용할 때 메시지에 얼마나 많은 데이터를 저장할 수 있습니까?
   • 8KB
   • 2KB
   • 16KB
   • 4KB
   설명:

   Amazon SQS 버전 2008-01-01에서 SOAP 및 쿼리 요청의 최대 메시지 크기는 8KB입니다. 8KB보다 큰 메시지를 대기열로 보내야 하는 경우 AWS는 정보를 별도의 메시지로 분할할 것을 권장합니다. 또는 Amazon S3 또는 Amazon SimpleDB를 사용하여 정보를 보관하고 Amazon SQS 메시지에 해당 정보에 대한 포인터를 포함할 수 있습니다. 8KB보다 큰 메시지를 대기열로 보내면 HTTP 코드 400과 함께 MessageTooLong 오류가 발생합니다.

6. 메시지를 SQS에 저장할 수 있는 최대 시간은 얼마입니까?
   • 14 일
   • 한달
   • 4 일
   • 7 일
   설명:

   메시지는 1분에서 최대 14일까지 SQS(Simple Queue Service)에 저장할 수 있습니다.
   
   

7. DynamoDB에서 보조 인덱스는 ______ 작업을 지원하기 위한 대체 키와 함께 테이블의 속성 하위 집합을 포함하는 데이터 구조입니다.
   • 해당 사항 없음
   • 둘 다
   • 둘 다
   • 주사
   설명:

   DynamoDB에서 보조 인덱스는 쿼리 작업을 지원하기 위한 대체 키와 함께 테이블의 속성 하위 집합을 포함하는 데이터 구조입니다.
   
   

8. 사용자가 기존 스냅샷에서 새 EBS 볼륨을 생성했습니다. 사용자는 볼륨이 연결된 인스턴스에 볼륨을 마운트합니다.
   
   아래 언급된 옵션 중 사용자가 볼륨을 마운트하기 전에 필요한 단계는 무엇입니까?
   
   • 데이터 일관성을 위해 장치에서 주기적 검사 실행
   • 볼륨의 파일 시스템 생성
   • 원래 스냅샷 크기에 따라 볼륨 크기 조정
   • 단계가 필요하지 않습니다. 사용자가 직접 장치를 장착할 수 있습니다.
   설명:

   사용자가 빈 EBS 볼륨을 마운트하려고 할 때 사용자는 먼저 볼륨 내에 파일 시스템을 생성해야 합니다. 볼륨이 기존 스냅샷에서 생성되면 기존 데이터가 지워지므로 사용자는 볼륨에 파일 시스템을 생성할 필요가 없습니다.

9. 새로운 코드를 푸시할 때마다 이미지에 사전 설치된 코드로 AMI를 구축하려면 CI가 필요합니다. 최대한 저렴하게 하셔야 합니다.
   
   이것을 어떻게 합니까?
   
   • 새 커밋이 들어오는 즉시 요청 가격 바로 위의 스팟 인스턴스에 입찰하고 모든 인스턴스 구성 및 설정을 수행한 다음 스팟 인스턴스를 기반으로 AMI를 생성합니다.
   • 새 커밋이 들어올 때 CI가 새 온디맨드 EC2 인스턴스를 시작하고 모든 인스턴스 구성 및 설정을 수행한 다음 온디맨드 인스턴스를 기반으로 AMI를 생성하도록 합니다.
   • Light Utilization Reserved Instance를 구입하여 지속적 통합 머신에서 비용을 절약하십시오. 인스턴스에서 AMI를 생성할 때마다 이 크레딧을 사용하십시오.
   • CI 인스턴스가 커밋을 수신하면 새 EBS 볼륨을 CI 머신에 연결합니다. AMI를 생성하기 위해 새 EC2 인스턴스가 필요하지 않도록 이 EBS 볼륨에서 모든 설정을 수행합니다.
   설명:
   스팟 인스턴스는 가장 저렴한 옵션이며 AMI를 생성하는 데 몇 분 이상 걸리는 경우 최소 실행 기간을 사용할 수 있습니다. 또한 스팟 인스턴스는 온디맨드 요금에 비해 대폭 할인된 가격(30-45%)과 사용량이 적은 시간에 추가 5%1를 추가하여 최대 6시간까지 시간당 증분으로 미리 정의된 기간 동안 실행할 수 있습니다. 총 최대 50% 절감.
   
   
10. DynamoDB를 생각할 때 Global Secondary Key 속성에 해당하는 것은 무엇입니까?
    • DynamoDB를 생각할 때 Global Secondary Key 속성에 해당하는 것은 무엇입니까?
    • 파티션 키만 테이블과 다를 수 있습니다.
    • 파티션 키 또는 정렬 키는 테이블과 다를 수 있지만 둘 다 다를 수는 없습니다.
    • 정렬 키만 테이블과 다를 수 있습니다.
    설명:

    Global secondary index – 파티션 키와 정렬 키가 테이블에 있는 것과 다를 수 있는 인덱스입니다. 글로벌 보조 인덱스는 인덱스에 대한 쿼리가 모든 파티션에 걸쳐 테이블의 모든 데이터에 걸쳐 있을 수 있기 때문에 "글로벌"로 간주됩니다.
    
    

11. 장기 실행 작업은 한 번만 처리하면 됩니다. 어떻게 할 수 있습니까?
    • SNS 대기열을 사용하고 가시성 제한 시간을 작업을 처리할 수 있을 만큼 충분히 길게 설정합니다.
    • SQS 대기열을 사용하고 재처리 제한 시간을 작업을 처리하기에 충분한 시간으로 설정합니다.
    • SQS 대기열을 사용하고 가시성 제한 시간을 작업을 처리할 수 있을 만큼 충분히 길게 설정합니다.
    • SNS 대기열을 사용하고 재처리 제한 시간을 작업을 처리하기에 충분한 시간으로 설정합니다.
    설명:

    메시지 시간 제한은 성공적인 수신 요청 후 SQS가 다른 구성 요소에서 작업을 볼 수 있도록 대기하는 시간을 정의하며 적절한 구성은 중복 처리를 방지합니다.
    
    

12. Amazon SQS를 사용할 때 비어 있는 수신 요청을 많이 받고 있습니다. 이로 인해 인스턴스에 불필요한 네트워크 부하가 많이 발생합니다. 이 부하를 줄이기 위해 무엇을 할 수 있습니까?
    • 대신 SNS 주제에 대한 대기열을 구독하십시오.
    • 짧은 투표 대신 가능한 한 긴 투표를 사용하십시오.
    • 가시성 제한 시간을 더 짧게 변경하십시오.
    • EC2 인스턴스에서 <code>sqsd</code>를 사용하십시오.
    설명:
    Amazon SQS를 사용한 긴 폴링의 한 가지 이점은 반환할 수 있는 메시지가 없을 때 Amazon SQS 대기열로 전송된 ReceiveMessage 요청에 대한 응답으로 빈 응답의 수가 줄어든다는 것입니다. 긴 폴링을 사용하면 응답을 보내기 전에 대기열에서 메시지를 사용할 수 있을 때까지 Amazon SQS 서비스가 대기할 수 있습니다.
    
    
13. AWS에서 $1000 이상을 지출하는 시기를 알아야 합니다. 알림을 쉽게 볼 수 있는 방법은 무엇입니까?
    • API 호출과 연결된 AWS CloudWatch Events는 특정 임계값을 초과하면 SNS에 게시합니다.
    • 청구 페이지를 주기적으로 스크랩하고 Kinesis로 펌핑합니다.
    • AWS CloudWatch 지표 + 청구 경보 + Lambda 이벤트 구독. 임계값을 초과하면 관리자에게 이메일을 보내십시오.
    • 청구 페이지를 주기적으로 스크랩하여 SNS에 게시합니다.
    설명: 프리 티어를 유지하기 위해 주의를 기울이더라도 프리 티어 한도를 초과하면 알려주는 결제 알람을 만드는 것이 좋습니다. 청구 경보는 실수로 프리 티어 외부의 서비스를 사용하거나 트래픽이 예상을 초과하는 경우 자신도 모르게 요금이 발생하는 것을 방지하는 데 도움이 될 수 있습니다.
    
    
14. 공급업체에 AWS 계정에 대한 액세스 권한을 부여해야 합니다. 여가 시간에 프라이빗 S3 버킷에서 보호된 메시지를 읽을 수 있어야 합니다. 그들은 또한 AWS를 사용합니다.
    
    이를 수행하는 가장 좋은 방법은 무엇입니까?
    
    • API 액세스 키로 IAM 사용자를 생성합니다. 버킷에 액세스할 수 있는 사용자 권한을 부여합니다. 공급업체에 사용자의 AWS 액세스 키 ID와 AWS 비밀 액세스 키를 제공합니다.
    • 계정에서 EC2 인스턴스 프로필을 생성합니다. 연결된 IAM 역할에 버킷에 대한 전체 액세스 권한을 부여합니다. 이 프로필로 EC2 인스턴스를 시작하고 공급업체에 인스턴스에 대한 SSH 액세스 권한을 부여합니다.
    • 버킷에 액세스할 수 있는 권한이 있는 교차 계정 IAM 역할을 생성하고 공급업체 AWS 계정에 역할을 사용할 수 있는 권한을 부여합니다.
    • 서명된 S3 PUT URL과 서명된 S3 PUT URL을 와일드카드 값과 2년 기간으로 생성합니다. URL을 공급업체에 전달합니다.
    설명:

    타사가 조직의 AWS 리소스에 액세스해야 하는 경우 역할을 사용하여 액세스를 위임할 수 있습니다. 예를 들어 타사에서 AWS 리소스를 관리하기 위한 서비스를 제공할 수 있습니다. IAM 역할을 사용하면 AWS 보안 자격 증명을 공유하지 않고도 이러한 제3자에게 AWS 리소스에 대한 액세스 권한을 부여할 수 있습니다. 대신 타사는 AWS 계정에서 생성한 역할을 가정하여 AWS 리소스에 액세스할 수 있습니다.
    
    

15. AWS API Gateway, AWS Lambda 및 AWS DynamoDB를 사용하는 서버리스 아키텍처는 초당 400개의 지속적인 요청으로 트래픽이 크게 증가했으며 실패율이 크게 증가했습니다. 귀하의 요청은 정상 작동 중에 평균 500밀리초 동안 지속됩니다. DynamoDB 테이블이 프로비저닝된 처리량의 50%를 초과하지 않았으며 테이블 기본 키가 올바르게 설계되었습니다.
    
    가장 가능성이 높은 문제는 무엇입니까?
    
    • API 게이트웨이 배포가 요청을 제한하고 있습니다.
    • AWS API Gateway 배포에서 요청(비)직렬화 시 병목 현상이 발생합니다.
    • 동시 Lambda 함수 실행에 대한 제한 증가를 요청하지 않았습니다.
    • DynamoDB에서 Consistent Read 요청을 사용했으며 세마포어 잠금이 발생했습니다.
    설명:

    기본적으로 AWS API Gateway는 안정적인 상태에서는 초당 500개 요청, 급증 시에는 초당 1000개 요청으로 조절합니다. Lambda는 기본적으로 안전을 위해 100개의 동시 요청에서 조절합니다. 요청당 500밀리초(0.5초)에서 100개의 동시성에서 초당 200개의 요청을 지원할 수 있습니다. 이것은 현재 시스템에서 요구하는 초당 400개 요청보다 적습니다. AWS Support 콘솔을 통해 한도 증가 요청을 합니다. AWS Lambda: 계정당 동시 요청 안전 스로틀 -> 100.

16. 자주 스냅샷 또는 EBS 볼륨이 더 빠른 이유는 무엇입니까?
    • EBS 볼륨의 블록은 다른 EBS 볼륨과 논리적으로 분리되어 있지만 볼륨이 동일한 물리적 하드웨어를 공유하는 경우가 많기 때문에 느리게 할당됩니다. 첫 번째 스냅샷은 전체 블록 범위 할당을 강제하므로 두 번째 스냅샷은 할당 단계를 수행할 필요가 없으며 더 빠릅니다.
    • 스냅샷은 증분식이므로 마지막 스냅샷 이후에 변경된 장치의 블록만 새 스냅샷에 저장됩니다.
    • AWS는 모든 블록을 스냅샷하고 읽어서 드라이브가 미리 예열된 경우 스냅샷 동안 버스트 용량에 대해 더 많은 디스크 처리량을 프로비저닝합니다.
    • 드라이브는 미리 예열되어 있으므로 장치의 모든 블록을 이미 한 번 이상 읽은 경우 볼륨에 대한 블록 액세스가 더 빠릅니다.
    설명:

    EBS 볼륨에 데이터를 쓴 후 주기적으로 볼륨의 스냅샷을 생성하여 새 볼륨 또는 데이터 백업의 기준으로 사용할 수 있습니다. 볼륨의 주기적 스냅샷을 만드는 경우 스냅샷은 증분이므로 마지막 스냅샷 이후에 변경된 장치의 블록만 새 스냅샷에 저장됩니다. 스냅샷은 점진적으로 저장되지만 볼륨을 복원하려면 가장 최근의 스냅샷만 유지해야 하도록 스냅샷 삭제 프로세스가 설계되었습니다.
    
    

17. AWS CloudFormation의 경우 UpdateStack 호출을 거부하는 스택 상태는 무엇입니까?
    • <code>UPDATE_ROLLBACK_FAILED</code>
    • <code>UPDATE_ROLLBACK_COMPLETE</code>
    • <code>UPDATE_COMPLETE</code>
    • <code>CREATE_COMPLETE</code>
    설명:

    스택이 UPDATE_ROLLBACK_FAILED 상태이면 스택을 계속 롤백하여 작동 상태(UPDATE_ROLLBACK_COMPLETE)로 되돌릴 수 있습니다. UPDATE_ROLLBACK_FAILED 상태인 스택은 업데이트할 수 없습니다. 그러나 롤백을 계속할 수 있는 경우 스택을 원래 설정으로 되돌리고 다시 업데이트를 시도할 수 있습니다.
    
    

18. 한 시간 안에 천만 개의 레코드를 DynamoDB로 마이그레이션해야 합니다. 모든 레코드의 크기는 1.5KB입니다. 데이터는 파티션 키 전체에 고르게 분산됩니다.
    
    이 배치 로드 중에 프로비저닝해야 하는 쓰기 용량 단위는 몇 개입니까?
    
    • 6667
    • 4166
    • 5556
    • 2778
    설명:

    반올림하기 때문에 1.5KB를 쓰려면 2단위가 필요합니다. 이 로드를 수행하려면 총 2천만 단위가 필요합니다. 3600초 안에 그렇게 해야 합니다. 5556으로 나누고 반올림합니다.

19. 귀하의 CTO는 귀하의 AWS 계정이 해킹되었다고 생각합니다. 해커가 매우 정교한 AWS 엔지니어이고 그들의 흔적을 숨기기 위해 할 수 있는 모든 일을 한다고 가정할 때 무단 액세스가 있었는지 그리고 그들이 무엇을 했는지 확실히 알 수 있는 유일한 방법은 무엇입니까?
    • CloudTrail 로그 파일 무결성 검증을 사용합니다.
    • AWS Config SNS 구독을 사용하고 실시간으로 이벤트를 처리합니다.
    • AWS S3 및 Glacier에 백업된 CloudTrail을 사용합니다.
    • AWS Config 타임라인 포렌식을 사용합니다.
    설명:

    CloudTrail 로그 파일 유효성 검사(기본 또는 사용자 지정 구현)를 사용해야 합니다. 다른 모든 추적 방법은 충분히 정교한 해커에 의해 전체 계정이 손상되는 경우 위조될 수 있기 때문입니다. 검증된 로그 파일은 보안 및 포렌식 조사에서 매우 중요합니다. 예를 들어 검증된 로그 파일을 사용하면 로그 파일 자체가 변경되지 않았거나 특정 사용자 자격 증명이 특정 API 활동을 수행했음을 긍정적으로 주장할 수 있습니다. CloudTrail 로그 파일 무결성 검증 프로세스는 또한 로그 파일이 삭제 또는 변경되었는지 여부를 알려주거나 지정된 기간 동안 계정에 로그 파일이 전달되지 않았음을 긍정적으로 주장합니다.
    
    

20. 다음 중 AWS CloudFormation의 의사 매개변수가 아닌 것은 무엇입니까?
    
    
    • AWS::StackName
    • AWS::AccountId
    • AWS::StackArn
    • AWS::NotificationARNs
    
    
    설명: Pseudo parameters reference 문서

    다음은 의사 파라미터의 전체 목록입니다. AWS::AccountId, AWS::NotificationARNs, AWS::NoValue, AWS::Region, AWS::StackId, AWS::StackName.