AZ-400-KR 문제 181

빌드 및 릴리스 파이프라인을 설계하고 있습니다.
파이프라인에 대해 시프트 레프트 테스트 전략을 구현해야 합니다.
어떤 유형의 테스트를 포함해야 할까요?

AZ-400-KR 문제 182

드래그 앤 드롭 질문
App1이라는 앱의 코드가 포함된 GitHub 저장소가 있습니다.
App1은 https://github.com/contoso/afeed 저장소의 함수 라이브러리에 의존합니다.
afeed 저장소의 복제본을 App1 저장소의 하위 디렉터리로 유지해야 합니다.
Git 명령어를 어떻게 완성해야 할까요? 정답을 보려면 적절한 값을 해당 대상으로 드래그하세요. 각 값은 한 번, 여러 번 또는 전혀 사용되지 않을 수 있습니다. 내용을 보려면 창 사이의 분할 막대를 드래그하거나 스크롤해야 할 수도 있습니다.
참고: 정답 하나당 1점입니다.

AZ-400-KR 문제 183

Azure Pipelines에서 빌드 파이프라인을 설계하고 있습니다.
이 파이프라인에는 자체 호스팅 에이전트가 필요합니다. 빌드 파이프라인은 하루에 한 번 실행되며 완료하는 데 30분이 소요됩니다.
에이전트에 적합한 컴퓨팅 유형을 추천해야 합니다. 솔루션은 비용을 최소화해야 합니다.
무엇을 추천하시겠습니까?

AZ-400-KR 문제 184

현재 한 팀에서 애플리케이션의 CI/CD 프로세스를 위해 Azure Pipeline 서비스를 사용하고 있습니다. 이 파이프라인은 파이프라인 전체에서 공유해야 하는 비밀 키를 사용해야 합니다. 이 비밀 키를 어떻게 정의하시겠습니까?

AZ-400-KR 문제 185

사례 연구 1 - Litware
개요
기존 환경
Litware, Inc.는 독립 소프트웨어 공급업체(ISV)입니다. Litware는 본사 1곳과 지사 5곳을 보유하고 있습니다.
애플리케이션 아키텍처
이 회사의 주요 애플리케이션은 ASP.NET 웹 폼 기반의 단일 모놀리식 퇴직 연금 관리 시스템으로, 로직은 VB.NET으로 작성되었습니다. 애플리케이션의 일부 새로운 부분은 C#으로 작성되었습니다.
이 애플리케이션은 개별 고객에 맞춰 다양한 버전으로 제작됩니다. 현재 100개 이상의 버전이 있습니다.
애플리케이션 코드베이스에 80개의 활성 코드 브랜치가 있습니다.
이 애플리케이션은 Microsoft Visual Studio를 사용하여 개발되었습니다. 소스 코드는 본사의 Team Foundation Server(TFS)에 저장되어 있으며, 지사에서는 TFS 프록시 서버를 통해 소스 코드에 접근합니다.
건축 관련 문제
Litware는 고객을 위한 새로운 코드 작성에 집중합니다. 기존 코드의 리팩토링이나 삭제를 위한 리소스는 제공하지 않습니다. 개별 개발자들이 코드 간의 의존성을 명확하게 파악하기 어렵기 때문에 코드베이스 변경에 오랜 시간이 걸립니다.
코드 병합 작업은 종종 몇 달이 걸리고 많은 개발자가 참여합니다. 코드 병합 과정에서 찾아내고 해결하기 어려운 버그가 발생하는 경우가 많습니다.
고객들은 퇴직연금 관리 시스템의 소유 비용이 지속적으로 증가하고 있다고 보고합니다. 관련 없는 코드를 통합해야 하는 필요성 때문에 사소한 코드 변경조차도 비용이 많이 듭니다.
고객들은 버그 보고 절차가 지나치게 복잡하다고 지적합니다.
계획된 변경 사항
Litware는 투자 계획을 위한 새로운 애플리케이션 제품군을 개발할 계획입니다. 이 투자 계획 애플리케이션은 기존 퇴직연금 관리 시스템과 최소한의 통합만 필요합니다.
투자 계획 애플리케이션 제품군은 다단계 웹 애플리케이션 1개와 iOS 모바일 애플리케이션 2개로 구성됩니다. 모바일 애플리케이션 중 하나는 직원용이고, 다른 하나는 고객용입니다.
Litware는 보다 애자일 개발 방법론으로 전환할 계획입니다. 공유 코드는 여러 패키지로 분리될 것입니다.
Litware는 내부 클라우드 전환 프로세스를 시작했으며, 적절한 경우 클라우드 기반 서비스를 사용할 계획입니다.
Litware는 고객의 버그 보고를 기다리는 대신, 오류를 사전에 감지하는 데 적극적으로 나서고자 합니다.
기술 요구사항
회사의 투자 계획 애플리케이션 제품군은 다음 요구 사항을 충족해야 합니다.
방화벽을 통한 새로운 유입 연결을 최소화해야 합니다.
* '개발자' 그룹의 구성원은 패키지를 설치할 수 있어야 합니다.
* 모든 권한 부여에는 최소 권한 원칙이 적용되어야 합니다.
* 새로운 기능을 독립적으로 개발할 수 있도록 지원하는 분기 전략을 사용해야 합니다.
* '팀 리더'라는 그룹의 구성원은 새 패키지를 생성하고 패키지 피드의 권한을 편집할 수 있어야 합니다.
* 모바일 애플리케이션 충돌 및 사용 중인 장치 유형에 대한 보고를 중앙 ​​집중화하려면 Visual Studio App Center를 사용해야 합니다.
* 기본적으로 모든 릴리스는 30일 동안 유지되어야 하며, 프로덕션 릴리스는 60일 동안 유지되어야 합니다.
* 코드 품질과 릴리스 품질은 매우 중요합니다. 릴리스 과정에서 해당 릴리스에 대해 버그가 발견된 경우, 단계별 배포를 진행해서는 안 됩니다.
* 모바일 애플리케이션은 기존 퇴직연금 관리 시스템의 주가 조회 서비스를 호출할 수 있어야 합니다. 시스템 업그레이드가 완료될 때까지 해당 서비스는 HTTPS를 통한 기본 인증만 지원합니다.
* 테스트 서버에 필요한 운영 체제 구성은 매주 변경됩니다. Azure Automation 상태 구성을 사용하여 서버를 생성하고 주기적으로 점검할 때 각 테스트 서버의 운영 체제가 동일하게 구성되도록 해야 합니다.
현재 기술적 문제
테스트 서버는 처음 배포될 때는 올바르게 구성되지만 시간이 지남에 따라 구성이 변경됩니다. Azure Automation 상태 구성은 이러한 구성을 수정하지 못합니다.
Azure Automation 상태 구성 노드는 다음 명령을 사용하여 등록됩니다.

현재 발생한 기술적 문제를 해결하려면 Register-AzureRmAutomationDscNode 명령에 대해 어떤 작업을 수행해야 합니까?