문제 201
문제: 회사에 10개의 다른 부서가 있고, Azure 서비스에 여러 대의 가상 컴퓨터가 있습니다. 각 부서의 사람들은 자기 부서의 가상 컴퓨터만 사용합니다. 각 부서별로 가상 컴퓨터에 리소스 태그라는 것을 붙여서 관리하려고 합니다.
다음 중 어떤 두 가지 방법을 사용해야 할까요?
보기:
A. 파워셸 (PowerShell)
B. Azure 리소스 관리자 (ARM 템플릿)
C. 앱 등록 (App Registration)
D. Azure Advisor
답: A. 파워셸, B. Azure 리소스 관리자 (ARM 템플릿)
해설:
- 리소스 태그는 컴퓨터나 다른 Azure 서비스에 붙이는 이름표 같은 거예요. 어떤 부서에서 사용하는지 쉽게 알 수 있도록 붙이는 거죠.
- 파워셸은 윈도우에서 사용하는 명령어 입력 도구인데, Azure 서비스도 명령어로 관리할 수 있어요. 마치 컴퓨터에 명령을 내려서 파일을 정리하는 것처럼, Azure에도 명령을 내려서 태그를 붙일 수 있습니다.
- **Azure 리소스 관리자 (ARM 템플릿)**는 Azure 서비스를 설계도처럼 미리 만들어 놓는 거예요. 이 설계도 안에 어떤 태그를 붙일 건지도 함께 정할 수 있습니다. 그래서 ARM 템플릿을 사용하면 여러 개의 컴퓨터에 똑같은 태그를 한 번에 붙일 수 있어서 편리해요.
- 앱 등록과 Azure Advisor는 리소스에 태그를 붙이는 직접적인 방법은 아닙니다.
Azure 관련 용어 해설:
- Azure (애저): 마이크로소프트에서 만든 클라우드 서비스입니다. 쉽게 말해, 인터넷을 통해 다른 회사의 컴퓨터를 빌려 쓰는 거예요. 여기에 가상 컴퓨터나 웹사이트 같은 여러 가지 IT 서비스를 만들 수 있습니다.
- 가상 컴퓨터: 실제 컴퓨터가 아니라, Azure의 컴퓨터를 여러 개로 나눠서 마치 개인 컴퓨터처럼 사용할 수 있게 만든 것입니다.
- 리소스 태그: Azure에서 사용하는 여러 가지 서비스들(가상 컴퓨터, 웹사이트 등)에 붙이는 꼬리표입니다. 이 꼬리표를 이용해서 어떤 서비스인지, 누가 사용하는지 등을 쉽게 알 수 있습니다. 예를 들어 "부서: 인사팀", "용도: 테스트" 와 같은 태그를 붙일 수 있어요.
- 파워셸 (PowerShell): 윈도우 운영체제에서 사용하는 명령어 기반 도구입니다. Azure 서비스를 관리하는 명령어를 입력해서 여러 작업을 자동화할 수 있습니다.
- Azure 리소스 관리자 (ARM 템플릿): Azure에 어떤 서비스를 만들고 어떻게 설정할 건지 미리 정의해 놓은 파일입니다. 이 템플릿을 사용하면 똑같은 설정을 가진 여러 개의 서비스를 쉽게 만들 수 있습니다.
문제 202
문제: 회사에서 contoso.com이라는 Microsoft Entra ID를 사용하고 있고, aks1이라는 Azure Kubernetes Service 클러스터를 가지고 있습니다. 관리자가 contoso.com 사용자들이 aks1에 접근할 수 있도록 권한을 주는 데 어려움을 겪고 있습니다. contoso.com 사용자들이 aks1에 접근할 수 있도록 하려면 어떻게 해야 할까요?
보기:
A. contoso.com에서 조직 관계 설정을 변경합니다.
B. contoso.com에서 OAuth 2.0 authorization endpoint를 만듭니다.
C. AKS1을 다시 만듭니다.
D. AKS1에서 네임스페이스를 만듭니다.
답: B. contoso.com에서 OAuth 2.0 authorization endpoint를 만듭니다.
해설:
- 여러 회사 사람들이 하나의 Azure 서비스를 같이 사용하려면, 누가 누구인지 확인하는 절차가 필요해요. 이걸 인증이라고 합니다.
- **OpenID Connect (OIDC)**는 인터넷에서 신분을 확인하는 표준적인 방법 중 하나입니다. 마치 여러 웹사이트에서 하나의 아이디와 비밀번호로 로그인할 수 있게 해주는 것과 비슷해요.
- contoso.com에서 OIDC 인증 방식을 설정해서 aks1에게 알려주면, contoso.com의 사용자들이 자신의 아이디로 aks1에 로그인하고 사용할 수 있게 됩니다.
- 다른 보기들은 사용자 인증과 직접적인 관련이 없거나 불필요한 작업입니다.
Azure 관련 용어 해설:
- Microsoft Entra ID (마이크로소프트 엔트라 아이디): 회사나 학교 같은 조직에서 사용하는 클라우드 기반의 신분 관리 서비스입니다. 누가 회사 직원인지, 어떤 권한을 가지고 있는지 등을 관리해줍니다. 이전에는 Azure Active Directory라고 불렸습니다.
- 테넌트 (Tenant): Microsoft Entra ID에서 하나의 독립된 조직을 의미합니다. 마치 하나의 학교나 회사의 계정들을 묶어 놓은 그룹과 같아요.
- Azure Kubernetes Service (AKS): 컨테이너라는 작은 꾸러미 안에 담긴 여러 개의 앱들을 효율적으로 관리하고 실행할 수 있도록 도와주는 Azure 서비스입니다. 마치 레고 블록처럼 여러 개의 앱을 묶어서 관리하는 것과 같아요.
- 클러스터 (Cluster): 여러 대의 컴퓨터를 하나의 시스템처럼 묶어서 사용하는 것을 말합니다. AKS 클러스터는 여러 대의 가상 컴퓨터로 이루어져 있어서 앱들이 안정적으로 작동할 수 있도록 해줍니다.
- 인증 (Authentication): 사용자가 누구인지 확인하는 과정입니다. 예를 들어 아이디와 비밀번호를 입력해서 로그인하는 것이 인증입니다.
- OIDC (OpenID Connect): 인터넷에서 사용자의 신분을 확인하고 정보를 주고받는 표준적인 방법입니다.
OIDC (OpenID Connect) 개요
**OpenID Connect (OIDC)**는 OAuth 2.0 프로토콜을 확장하여 인증(Authentication)까지 제공하는 업계 표준 프로토콜입니다. OIDC를 사용하면 사용자는 하나의 아이덴티티 공급자(IDP, 예: Microsoft Entra ID, Google, Apple 등)를 통해 여러 애플리케이션에서 싱글 사인온(SSO)을 구현할 수 있습니다168.
주요 특징
- OAuth 2.0 기반
OIDC는 OAuth 2.0의 권한 부여(Authorization) 기능 위에 인증(Authentication) 기능을 추가합니다. 즉, 기존 OAuth 2.0의 액세스 토큰(access token) 외에, 사용자의 신원을 증명하는 *ID 토큰(ID token)*을 추가로 제공합니다18. - ID 토큰
인증이 성공하면 OIDC 공급자는 클라이언트에 ID 토큰을 발급합니다. 이 토큰은 JWT(JSON Web Token) 형식으로, 사용자의 식별 정보(클레임)를 안전하게 담고 있습니다. 애플리케이션은 이 토큰을 검증하여 사용자의 신원을 확인할 수 있습니다18. - 싱글 사인온(SSO)
OIDC는 여러 애플리케이션 간에 SSO를 쉽게 구현할 수 있게 해줍니다. 사용자는 한 번 로그인하면, 동일한 IDP를 사용하는 모든 애플리케이션에서 추가 인증 없이 접근할 수 있습니다16. - 표준화된 메타데이터
OIDC 공급자는 /.well-known/openid-configuration 엔드포인트를 통해 인증, 토큰, 키 등 필요한 메타데이터를 제공합니다6.
기본 동작 흐름
- 클라이언트(애플리케이션)가 인증 요청
사용자가 애플리케이션에 접근하면, 애플리케이션은 OIDC 공급자(예: Microsoft Entra ID)에 인증을 요청합니다. - 사용자 인증
OIDC 공급자는 사용자에게 로그인 화면을 제공하고, 인증을 수행합니다. - ID 토큰 및 액세스 토큰 발급
인증이 완료되면, OIDC 공급자는 클라이언트에 ID 토큰과(필요 시) 액세스 토큰을 반환합니다. - 애플리케이션에서 토큰 검증 및 사용자 정보 확인
애플리케이션은 ID 토큰을 검증하여 사용자의 신원을 확인하고, 필요하면 추가 정보를 조회합니다138.
활용 예시
- 웹/모바일 앱의 로그인 및 SSO
- Azure App Service, Functions 등에서 외부 인증 제공자 연결6
- GitHub Actions, Terraform 등에서 Azure 리소스 접근 시 안전한 인증51011
- 기업 내 다양한 SaaS 서비스의 통합 인증
Azure에서의 OIDC 활용
- Microsoft Entra ID(구 Azure AD)는 OIDC를 지원하는 대표적인 ID 공급자입니다.
Azure 애플리케이션 등록 후 OIDC를 활성화하면, 다양한 클라우드·온프레미스 앱에서 SSO 및 인증을 구현할 수 있습니다. - Azure Storage, App Service, GitHub Actions 등 다양한 Azure 서비스에서 OIDC를 통한 안전한 인증 및 권한 부여가 가능합니다.
요약 표
구분 | OAuth 2.0 | OpenID Connect (OIDC) |
목적 | 권한 부여(Authorization) | 인증(Authentication) + 권한 부여 |
토큰 종류 | Access Token | Access Token + ID Token |
사용자 정보 | 별도 제공 안 됨 | ID Token에 클레임(사용자 정보) 포함 |
SSO 지원 | 제한적 | 표준 지원 |
대표 활용 | API 접근 권한 위임 | 로그인, SSO, 신원 확인 |
정리:
OIDC는 OAuth 2.0을 기반으로 사용자의 신원 확인까지 제공하는 인증 표준 프로토콜로, ID 토큰을 통해 안전하고 편리한 SSO와 통합 인증을 실현할 수 있습니다. Azure 등 다양한 클라우드 환경에서 폭넓게 활용되고 있습니다.
문제 203
문제: rg1이라는 리소스 그룹에 사용하지 않는 여러 개의 리소스가 있습니다.
Azure CLI를 사용해서 확인 없이 RG1과 그 안의 모든 리소스를 삭제하려고 합니다. 어떤 명령어를 사용해야 할까요?
보기:
A. az group delete --name rg1 --no-wait --yes
B. az group deployment delete --name rg1 --no-wait
C. az group update --name rg1 --remove
D. az group wait -deleted -resource-group-name rg1
답: A. az group delete --name rg1 --no-wait --yes
해설:
- **Azure CLI (Command-Line Interface)**는 텍스트로 명령어를 입력해서 Azure 서비스를 관리하는 도구입니다. 마치 도스(DOS) 창이나 터미널처럼 사용할 수 있어요.
- az group delete 명령어는 리소스 그룹을 삭제하는 명령어입니다.
- --name rg1은 삭제할 리소스 그룹의 이름을 rg1으로 지정하는 옵션입니다.
- --no-wait yes는 삭제 작업을 기다리지 않고 바로 다음 명령어를 실행하도록 하는 옵션이며, 삭제 전에 확인하는 메시지를 보여주지 않도록 합니다.
- 따라서 az group delete --name rg1 --no-wait yes 명령어를 사용하면 확인 없이 rg1 리소스 그룹과 그 안의 모든 리소스를 바로 삭제할 수 있습니다.
- 다른 명령어들은 리소스 그룹을 삭제하는 용도가 아니거나, 확인 메시지를 건너뛰는 옵션이 없습니다.
Azure 관련 용어 해설:
- Azure CLI (애저 씨엘아이): 텍스트 기반으로 Azure 서비스를 관리하는 명령어 입력 도구입니다. 웹 브라우저 없이도 Azure를 조작할 수 있습니다.
- 리소스 그룹: Azure에서 관련된 여러 개의 리소스를 묶어서 관리하는 논리적인 컨테이너입니다. 마치 폴더처럼 여러 개의 파일을 묶어서 관리하는 것과 같아요. 가상 컴퓨터, 웹사이트, 데이터베이스 등을 하나의 리소스 그룹으로 묶을 수 있습니다.
- 명령어 (Command): 컴퓨터에게 특정한 작업을 지시하는 텍스트입니다. Azure CLI를 통해 Azure 서비스에 다양한 명령어를 내릴 수 있습니다.
- 옵션 (Option): 명령어의 세부 동작을 설정하는 것입니다. 명령어 뒤에 --와 함께 특정 단어를 써서 옵션을 지정할 수 있습니다.
문제 204
문제: contoso.onmicrosoft.com 도메인 이름을 가진 Microsoft Entra ID 테넌트가 있습니다.
contoso.com 도메인 이름은 다른 회사에 등록되어 있습니다.
@contoso.com으로 끝나는 Entra ID 사용자를 만들 수 있도록 하려면 어떤 세 가지 작업을 순서대로 수행해야 할까요?
보기:
A. 공용 contoso.com DNS 영역에 레코드 추가
B. Azure AD tenant 추가
C. Configure company branding
D. Azure DNS zone 생성
E. 사용자 지정 이름(도메인 이름) 추가
F. 도메인 확인
답: E → A → F
해설:
- 사용자 지정 이름(도메인 이름)을 추가합니다 (E): 먼저 Azure에게 @contoso.com이라는 도메인 이름을 우리 회사가 사용하고 싶다고 알려줘야 합니다.
- 공용 contoso.com DNS 영역에 TXT 레코드를 추가합니다 (A): 우리가 실제로 contoso.com 도메인의 주인인지 증명해야 합니다. 도메인을 등록한 회사(다른 회사)의 웹사이트 설정에 들어가서 Azure가 알려주는 특별한 **텍스트 조각(TXT 레코드)**을 추가합니다. 마치 집 주인이 맞는지 확인하기 위해 우편물을 받는 것과 비슷해요.
- 도메인을 확인합니다 (F): Azure에게 TXT 레코드를 추가했다고 알리면, Azure가 실제로 그 레코드가 있는지 확인합니다. 확인이 되면 이제 @contoso.com으로 끝나는 사용자를 만들 수 있게 됩니다.
Azure 관련 용어 해설:
- 도메인 이름: 인터넷 주소(예: google.com, microsoft.com)와 같이 웹사이트나 이메일 주소에 사용되는 고유한 이름입니다.
- DNS (Domain Name System): 인터넷 주소(도메인 이름)를 실제 컴퓨터의 주소(IP 주소)로 변환해주는 시스템입니다. 마치 전화번호부와 같아요.
- DNS 영역: 특정 도메인 이름에 대한 DNS 정보를 관리하는 공간입니다.
- TXT 레코드: DNS 영역에 텍스트 형태의 정보를 저장하는 데 사용되는 DNS 레코드의 한 종류입니다. 도메인 소유권 확인 등에 사용됩니다.
- 사용자 지정 이름 (Custom Name): Azure Entra ID에서 기본으로 제공하는 도메인 이름(*.onmicrosoft.com) 대신 자신이 소유한 도메인 이름을 사용하는 것을 말합니다.
- 도메인 확인: 자신이 추가하려는 도메인 이름을 실제로 소유하고 있는지 Azure에게 증명하는 과정입니다.
문제 205
문제: SubScription1이라는 Azure 구독에 다음 표와 같은 리소스 그룹이 있습니다. RG1 리소스 그룹에는 서유럽(West Europe)에 있는 WebApp1이라는 웹앱이 있습니다. 이 WebApp1을 RG2 리소스 그룹으로 이동하려고 합니다. 이 이동의 결과는 무엇일까요?
이름위치정책
이름 | 위치 | 정책 |
RG1 | 서유럽 (West Europe) | policy1 |
RG2 | 북유럽 (North Europe) | policy2 |
RG3 | 프랑스(France Central) | policy33 |
보기:
A. webapp1의 앱 서비스 계획은 서유럽에 그대로 있고, policy2가 webapp1에 적용됩니다.
B. webapp1의 앱 서비스 계획은 북유럽으로 이동하고, policy2가 webapp1에 적용됩니다.
C. webapp1의 앱 서비스 계획은 서유럽에 그대로 있고, policy1이 webapp1에 적용됩니다.
D. webapp1의 앱 서비스 계획은 북유럽으로 이동하고, policy1이 webapp1에 적용됩니다.
답: A. webapp1의 앱 서비스 계획은 서유럽에 그대로 있고, policy2가 webapp1에 적용됩니다.
해설:
- 웹앱은 인터넷에서 보여지는 웹사이트나 웹 서비스입니다.
- 앱 서비스 계획은 웹앱이 어떤 성능과 기능을 가진 컴퓨터에서 작동할지 결정하는 설정입니다. 마치 웹사이트를 운영하기 위한 서버의 사양과 같아요.
- 웹앱을 다른 리소스 그룹으로 이동해도, **앱 서비스 계획의 위치(서유럽)**는 바뀌지 않습니다. 앱 서비스 계획은 웹앱이 실행되는 지역을 결정하기 때문입니다.
- 리소스 그룹은 단순한 관리 폴더와 같아서, 웹앱이 어느 폴더에 있느냐에 따라 적용되는 정책이 달라질 수 있습니다. webapp1이 rg2로 이동했으므로, rg2에 설정된 policy2가 적용됩니다.
Azure 관련 용어 해설:
- 구독 (Subscription): Azure 서비스를 사용하기 위한 결제 계정입니다. 하나의 구독 아래 여러 개의 리소스 그룹과 서비스를 만들 수 있습니다.
- 리소스 그룹: Azure에서 관련된 여러 개의 리소스를 묶어서 관리하는 논리적인 컨테이너입니다.
- 웹앱 (Web App): Azure에서 제공하는 웹 애플리케이션 호스팅 서비스입니다. 웹사이트나 웹 서비스를 쉽게 배포하고 관리할 수 있습니다.
- 앱 서비스 계획 (App Service Plan): 웹앱이 실행될 기본 환경 설정을 정의합니다. 운영체제, 성능(CPU, 메모리), 가격 등을 결정합니다.
- 정책 (Policy): Azure 리소스에 특정한 규칙이나 설정을 적용하는 방법입니다. 예를 들어 특정 지역에만 서비스를 만들 수 있도록 하거나, 특정 종류의 설정을 금지할 수 있습니다.
- 위치 (Location): Azure 서비스가 실제로 데이터 센터가 있는 물리적인 지역을 의미합니다 (예: 서유럽, 북유럽, 미국 동부 등). 서비스를 만들 때 어떤 지역을 선택하느냐에 따라 데이터가 저장되는 위치가 결정됩니다.
'인공지능,프로그래밍 > MS Azure' 카테고리의 다른 글
Azure 104 연습 문제 36 (1) | 2025.04.17 |
---|---|
Azure 104 연습 문제 35 (1) | 2025.04.17 |
Azure 104 연습 문제 33 (2) | 2025.04.17 |
Azure 104 연습 문제 32 (0) | 2025.04.17 |
Azure 104 연습 문제 31 (0) | 2025.04.17 |