Microsoft AZ-500

아니요는 오답입니다. 요구 사항은 on-premises Active Directory 자격 증명을 사용한 인증을 허용하는 것이며, 이는 Azure AD 전용 로그인이 아니라 domain 기반 인증 메커니즘(예: Kerberos/LDAP)을 의미합니다. Azure AD DS는 Azure에서 이러한 AD DS 프로토콜을 managed service로 제공하도록 특별히 설계되었으며 HDInsight ESP domain integration을 활성화하는 지원되는 접근 방식입니다. 대체 구현(예: Azure VM에 AD DS domain controller 배포)도 있을 수 있지만, 제안된 솔루션은 목표를 충족할 수 있으므로 아니요라고 답하는 것은 Azure AD DS가 요구 사항을 충족할 수 없다고 잘못 가정하는 것입니다.

Key Vault access policy는 user, service principal 또는 managed identity가 vault에서 secrets를 읽을 수 있는지 여부를 제어합니다. 이는 authorization에는 필요하지만, ARM deployment에 resource ID를 빌드하거나 전달하는 메커니즘을 제공하지는 않습니다. 올바른 access policy가 있더라도, deployment는 여전히 어떤 vault와 secret을 사용할지 지정할 방법이 필요합니다. 따라서 access policy는 permissions와 관련이 있을 뿐, Key Vault resource ID의 동적 구성이나 지정과는 관련이 없습니다.

Linked template는 배포를 재사용 가능한 modules 또는 별도의 template files로 분할하는 데 사용됩니다. linked template도 parameters를 받아 내부적으로 functions를 사용할 수는 있지만, secure parameter value에 대한 Key Vault secret reference를 제공하는 표준 메커니즘은 아닙니다. 문제는 이름이 parameters로 제공될 때 각 배포 중 적절한 Key Vault를 지정하기 위해 무엇을 사용해야 하는지를 묻고 있으며, 이는 일반적으로 다른 template를 도입하는 것이 아니라 deployment parameters를 통해 처리됩니다. linked template를 사용하면 불필요한 복잡성만 추가되며 요구 사항에 직접적으로 답하지 못합니다.

Automation Account는 scripts를 실행하거나 deployment workflows를 오케스트레이션할 수 있지만, Key Vault secret references를 전달하기 위한 ARM template 구성 요소는 아닙니다. 요구 사항은 ARM deployments 중 올바른 Key Vault를 지정하는 방법에 관한 것이며, 이는 template parameters와 parameter files를 통해 기본적으로 처리됩니다. Automation이 deployment를 호출할 수는 있지만, secret resolution을 위한 ARM 메커니즘을 대체하지는 않습니다. 따라서 직접적인 해결책의 범위를 벗어납니다.

오답입니다. Azure AD에서 role을 생성해도 애플리케이션에 Azure Key Vault의 secrets를 읽을 권한이 부여되지는 않습니다. Key Vault secret access는 vault 수준에서 Key Vault access policy를 통해 제어되거나, RBAC permission model을 사용하는 환경에서는 vault 범위의 Azure RBAC role assignment를 통해 제어됩니다. Azure AD role은 directory 수준의 관리를 위한 것이며, 애플리케이션이 Secret1을 사용하도록 권한을 부여하는 방법이 아닙니다.

오답입니다. Azure Key Vault에서 keys와 secrets는 서로 다른 object types이며 용도도 다릅니다. key를 생성하면 cryptographic operations는 가능해지지만, 기존의 Secret1이라는 secret에 애플리케이션이 액세스할 수 있게 되지는 않습니다. 요구 사항은 새로운 cryptographic asset 생성이 아니라 secret에 대한 액세스 권한 부여입니다.

오답입니다. Azure AD Application Proxy는 Azure AD를 통해 내부 웹 애플리케이션을 원격 액세스용으로 게시하는 데 사용됩니다. 이는 애플리케이션에 Azure Key Vault의 데이터를 읽을 권한을 부여하는 것과는 관련이 없습니다. Application Proxy를 사용하도록 설정하더라도, 애플리케이션이 Secret1에 액세스하려면 여전히 Vault1에 대한 명시적인 권한 부여가 필요합니다.

예는 잘못되었습니다. 새 SAS token은 이전에 배포된 SAS token을 무효화하지 않기 때문입니다. 이미 유효한 SAS URI를 가지고 있는 권한 없는 사용자는 해당 token이 만료되거나 서명 기반이 취소될 때까지 blob service와 file service에 계속 액세스할 수 있습니다. 기존의 모든 SAS 기반 액세스를 중지하려면 storage account key를 다시 생성하고/하거나 SAS에 사용된 stored access policy를 제거 또는 수정해야 합니다. 따라서 제안된 작업은 제시된 목표를 충족하지 않습니다.

Application permission은 background service나 automation job과 같이 로그인한 사용자가 없는 app-only access를 위한 것입니다. 이는 애플리케이션 사용자 대신 secret에 액세스해야 한다는 요구 사항과 일치하지 않습니다. 왜냐하면 결과 token은 애플리케이션 identity만 나타내기 때문입니다. 또한 application permission은 일반적으로 admin consent가 필요하므로 “admin consent 없음”이라는 부분도 잘못되었습니다. 이 옵션은 permission 유형과 consent 요구 사항 모두에서 틀렸습니다.

Delegated permission은 사용자를 대신하여 동작하는 데 적절한 일반 범주이지만, Azure Key Vault delegated permission은 일반적인 의미에서 사용자가 consent할 수 있는 것이 아닙니다. 이는 admin-restricted permission이며 앱이 이를 사용하려면 tenant에서 administrator 승인이 필요합니다. 따라서 admin consent가 없는 delegated permission이라고 하는 것은 Key Vault에 대해 불완전하며 기술적으로도 올바르지 않습니다. 이 때문에 delegated 모델 자체는 올바르게 식별했더라도 현재 답변은 틀렸습니다.

Admin consent가 필요한 application permission은 앱이 로그인한 사용자 컨텍스트 없이 자기 자신으로 리소스에 액세스할 때 사용됩니다. 이는 daemon app, scheduled task 또는 service principal에는 적절하지만 사용자 중심 시나리오에는 적절하지 않습니다. 문제에서 명시적으로 “애플리케이션 사용자 대신”이라고 했으므로 앱은 app-only permission을 사용하면 안 됩니다. Application permission에 admin consent가 일반적으로 필요하더라도 여기서는 permission 유형 자체가 잘못되었습니다.

Azure Security Center(현재 Microsoft Defender for Cloud)는 security posture management, recommendation, 그리고 threat protection에 중점을 둡니다. 잘못된 구성을 표시하고 least-privilege 개선을 제안할 수는 있지만, 여러 subscription 전반에 동일한 RBAC role assignment를 템플릿화하고 자동으로 적용하는 메커니즘은 제공하지 않습니다. 주된 목적은 monitoring과 security 개선이지, subscription provisioning 중 baseline access control 구성을 적용하는 것이 아닙니다.

Azure Policy는 resource 구성을 audit, deny 또는 remediation하여 compliance를 강제하고 평가하는 데 사용됩니다. resource가 표준(tag, SKU, encryption, 허용된 location)을 충족하도록 보장하는 데는 매우 뛰어나지만, baseline으로서 subscription 전반에 일관된 RBAC role assignment를 생성하고 유지하도록 설계된 것은 아닙니다. Policy는 Blueprints처럼 subscription RBAC assignment를 직접 정의할 수 없습니다.

Azure AD Privileged Identity Management (PIM)는 Azure AD role 및 Azure resource role에 대해 just-in-time activation, approval workflow, access review, 그리고 시간 제한이 있는 privileged role assignment를 제공합니다. 이는 privileged access 관리 방식을 개선하지만, 여러 subscription이 동일한 초기 role assignment 집합을 갖도록 구성해야 한다는 요구 사항을 해결하지는 못합니다. PIM은 elevation 및 lifecycle을 관리하는 것이지, subscription 간 RBAC 복제를 수행하는 것은 아닙니다.

아니요. 이는 올바르지 않습니다. Microsoft Antimalware VM extension을 추가하는 것은 Azure IaaS 가상 머신에 antimalware를 배포하는 지원되고 의도된 방법이기 때문입니다. VM extension은 antimalware와 같은 보안 도구를 포함하여 배포 후 VM 내부에 소프트웨어를 설치하고 구성하도록 특별히 설계되었습니다. automation 없이 VM별로 수동 수행하는 것은 운영상 번거로울 수 있지만, 여전히 Microsoft Antimalware를 배포해야 한다는 명시된 요구 사항은 충족합니다.

Access policies는 누가 Key Vault object에 접근할 수 있는지를 제어하지만, ADE가 VM encryption material을 저장하기 위해 근본적으로 사용하는 특정 Key Vault 설정은 아닙니다. 문제는 backup 지원과 함께 ADE를 사용하도록 설정하기 위해 어떤 vault 설정을 구성해야 하는지 묻고 있으며, encryption의 핵심 의존성은 permission model 자체가 아니라 secrets에 있습니다. 운영 측면에서 권한은 필요하지만, 제시된 선택지 중 최선의 답은 아닙니다. 이런 시험 문제에서 Microsoft는 종종 ADE가 사용하는 object type과 그 object에 도달하기 위한 authorization 메커니즘을 구분합니다.

Keys는 Azure Disk Encryption에서 선택 사항이며, BitLocker Encryption Key를 래핑하기 위해 Key Encryption Key를 구현하기로 선택한 경우에만 사용됩니다. KEK를 전혀 구성하지 않아도 ADE는 성공적으로 사용 설정될 수 있습니다. 문제에서 customer-managed key 래핑이 필요하다고 명시하지 않았으므로, Keys는 필수 설정이 아닙니다. 따라서 이 선택지는 너무 구체적이며 Azure Backup과 함께 사용하는 ADE에 보편적으로 요구되지는 않습니다.

Locks는 리소스의 실수로 인한 삭제 또는 수정을 방지하는 Azure resource management 제어입니다. 이는 encryption workflow에 참여하지 않으며 disk encryption material을 저장하거나 검색하는 역할도 없습니다. vault에 lock을 적용해도 VM에서 Azure Disk Encryption을 사용하도록 설정할 수는 없습니다. 또한 Locks는 ADE로 보호된 virtual machine에 대한 Azure Backup 호환성에도 영향을 주지 않습니다.

Azure Application Insights는 web app에 대한 application performance monitoring(APM), logging 및 telemetry를 제공합니다. 관찰 가능성을 위한 모범 사례이며 App Service와 통합할 수 있지만, Azure Repos에서 continuous deployment를 구성하는 데 필수는 아닙니다. 모니터링 리소스 없이도 CI/CD를 활성화할 수 있으므로, 가장 먼저 만들어야 하는 것은 아닙니다.

Azure Storage account는 build artifacts, diagnostics logs, deployment packages 또는 application data에 사용될 수 있지만, Azure Repos에서 App Service web app으로 continuous deployment를 설정하기 위한 선행 조건은 아닙니다. Azure DevOps는 자체 artifact storage에 artifacts를 저장할 수 있으며, App Service 배포는 기본적으로 고객 관리 Storage account를 요구하지 않습니다.

Azure DevTest Labs는 dev/test 환경(주로 VM 기반)을 생성하고 관리하며, 비용을 제어하고 auto-shutdown 같은 정책을 적용하도록 설계되었습니다. Azure Repos를 호스팅하거나 App Service continuous deployment를 구성하는 데 사용되지 않습니다. Azure Repos를 사용하여 Azure Web App에 CI/CD를 수행하는 경우, DevTest Labs는 관련이 없으며 필요하지 않습니다.