Design solutions that align with security best practices and priorities →hardMultiple ChoiceObjective-mapped
SC-100 Practice Question: Design solutions that align with security best practices and priorities
You are designing a secure DevOps pipeline in GitHub that deploys to Azure Kubernetes Service (AKS). The security team requires that no secrets are stored in the pipeline variables and that all container images are scanned for vulnerabilities before deployment. Which approach aligns with security best practices?
⚠ Common exam trap
Many candidates assume Azure DevOps is the only secure option or that storing secrets in Azure Key Vault is acceptable, but the question explicitly requires 'no secrets stored in the pipeline variables,' and OIDC eliminates secrets entirely, while Key Vault still requires a secret retrieval step that counts as a stored secret in the pipeline context.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use GitHub Actions with OpenID Connect to authenticate to Azure without storing any secrets. Integrate Microsoft Defender for Containers to scan images in Azure Container Registry.
It uses OpenID Connect (OIDC) to authenticate GitHub Actions to Azure without storing any long-lived secrets, which aligns with the requirement that no secrets be stored in pipeline variables. Additionally, integrating Microsoft Defender for Containers provides vulnerability scanning for container images in Azure Container Registry (ACR), meeting the image scanning requirement before deployment to AKS.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use Azure DevOps with a service principal that has a client secret stored in Azure Key Vault. Use Trivy to scan images.
Why it's wrong here
Although storing a client secret in Azure Key Vault protects it at rest and at use, a static secret still exists and must be rotated and managed, so it violates the requirement of having no secrets anywhere in the pipeline. Additionally, this option uses Azure DevOps rather than GitHub Actions, and Trivy is a third-party scanner that requires separate installation and configuration instead of the native, integrated scanning that Microsoft Defender for Containers provides for Azure Container Registry.
- ✓
Use GitHub Actions with OpenID Connect to authenticate to Azure without storing any secrets. Integrate Microsoft Defender for Containers to scan images in Azure Container Registry.
Why this is correct
OpenID Connect (OIDC) lets GitHub Actions authenticate to Azure AD using federated credentials, so the workflow receives a short-lived token without storing any client secret, password, or persistent key in the repository. Microsoft Defender for Containers integrates natively with Azure Container Registry to scan images for vulnerabilities on push, continuously assessing compliance and providing runtime protection without adding third-party components.
- ✗
Use GitHub Actions with a managed identity for the GitHub runner. Disable image scanning to speed up deployments.
Why it's wrong here
A managed identity for the GitHub runner is not supported because GitHub Actions runs on external infrastructure rather than on an Azure resource that can be assigned a managed identity; the correct zero-secret pattern is OIDC federation. Disabling image scanning to speed up deployments also violates the explicit security policy requiring vulnerability scanning, allowing known exploitable CVEs to be deployed to AKS without detection.
- ✗
Use GitHub Actions with environment secrets for Azure service principal credentials. Use Docker Hub's vulnerability scanning.
Why it's wrong here
Storing a service principal password in GitHub environment secrets still leaves a long-lived static credential in the pipeline, which can be exfiltrated and requires rotation overhead, thus failing the no-secrets requirement even though the secret is encrypted at rest. Docker Hub's vulnerability scanning only scans images that reside in Docker Hub, not images in Azure Container Registry, so it provides no integrated protection for images that are pushed to ACR and deployed to AKS.
Go deeper
Related to this question
About these practice questions
This SC-100 question is part of Courseiva's 208-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SC-100 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SC-100 exam.