A: No. This is an open-source infrastructure template and reference architecture. It is maintained by Microsoft but is not a Microsoft service with SLAs, support agreements, or operational guarantees.
A: MIT License. Free to use, modify, and distribute with attribution.
A: The deploying customer. You own and operate all deployed Azure resources in your subscription. Microsoft provides the template only.
A: No for standard usage. The primary supported scenario is customer-owned Azure subscriptions. Microsoft internal tenant deployment is intended only for authorized maintainers and internal engineering validation, and must follow all applicable internal governance and production policies.
A: The kit provisions:
- Azure Storage (data foundation)
- Azure Data Explorer / Kusto (analytics)
- Azure Synapse Analytics (data warehouse)
- RBAC scaffolding (access control)
All resources are created in your Azure subscription under your control.
A: No. This is explicitly designed for customer-owned subscriptions only. It does not:
- Provision resources in Microsoft internal Azure environments
- Connect to Microsoft-managed services
- Create Microsoft-hosted service components
- Deploy first-party production infrastructure
A: This is a reference architecture and starter kit. It provides a foundation that you can deploy and then:
- Customize for your specific requirements
- Harden with additional security controls
- Scale based on workload demands
- Integrate with existing infrastructure
You are responsible for assessing suitability, testing, and operational readiness for your production environment.
A: This kit is designed to work in all Azure commercial regions. Regional availability depends on:
- Resource availability in your chosen region
- Subscription quotas and capacity availability for the selected services/SKUs
- Data residency requirements
- Compliance and regulatory constraints
Specify your target region during deployment, and verify quotas and SKU availability before rollout.
A: No. This repository contains:
- ❌ Zero hardcoded secrets
- ❌ Zero API keys or connection strings
- ❌ Zero tenant IDs or subscription IDs
- ❌ Zero certificate files or private keys
All sensitive values are parameterized and supplied at deployment time by you.
A: You supply credentials during the deployment:
- Azure Portal UI: Guided forms capture values
- Bicep CLI: Parameters file contains your values
- Never: Commit credentials to the repository
Azure Key Vault is recommended for managing sensitive values post-deployment.
A: Yes. GitHub Secret Scanning is enabled on this repository to automatically detect and prevent accidental credential commits.
A: GitHub Secret Scanning will flag it. Immediately:
- Rotate the secret
- Create an issue documenting the rotation
- Work with maintainers to remove the secret from commit history
A: Data is stored in Azure resources in the region you specify during deployment. You have full control over data location, encryption, and retention.
A: No. Microsoft does not access customer data or deployed resources. You own and control all data. Microsoft provides only the deployment template.
A: The starter kit provides infrastructure components compatible with regulated workloads. However:
- You are responsible for compliance assessment
- You must implement required controls for your regulatory framework
- Consult with your compliance and security teams
- Additional hardening and monitoring are required
A: This kit provides a foundation compatible with common compliance frameworks. You are responsible for:
- Assessing applicability to your regulatory requirements
- Implementing additional controls as needed
- Auditing and monitoring deployed resources
- Maintaining compliance documentation
A: No. This is an open-source project. We provide no SLAs, response time guarantees, or operational support.
A: Use the Bug Report issue template. Include:
- Environment details (Azure region, resource types)
- Steps to reproduce
- Expected vs. actual behavior
- Relevant error messages
A: See SECURITY.md. Report privately via email, not in public issues.
A: Yes! See CONTRIBUTING.md for guidelines. Contributions are welcome via pull requests.
A: We commit to maintaining the core repository and addressing critical issues. However, as an open-source project, maintenance is best-effort.
A: Yes. The Bicep templates are designed to be modular and compatible with existing infrastructure. You can:
- Customize parameter files for your environment
- Reference existing resource groups and VNets
- Adjust RBAC for existing service principals
- Extend templates for additional components
A: This kit uses Azure Bicep. You can:
- Convert Bicep to ARM templates if needed (tools available)
- Use Terraform to orchestrate Bicep deployments
- Reference this architecture in non-Bicep IaC
A: Yes. RBAC scaffolding is parameterized. Specify your users, groups, and roles at deployment time or modify post-deployment via Azure Portal.
A: Yes. Bicep templates are modular. You can:
- Remove unnecessary components
- Substitute alternative Azure services
- Extend with additional modules
Maintain template structure and document your changes.
A: Yes. MIT License permits commercial use, modification, and distribution.
A: Per MIT License, you must include the license and copyright notice. No public credit required.
A: Yes. MIT License allows redistribution. Include the original license file.
A: No. All code is MIT licensed. Dependencies are listed in documentation.
A: Ensure your Azure account has:
- Owner or Contributor role on the target subscription
- Permissions to create resources in the target resource group
- No organization policies blocking resource creation
A: Bicep parameters control naming. Provide custom prefixes and conventions during deployment.
A: Use Azure Portal or Azure CLI:
az group delete --name myResourceGroup --yesThis removes all resources in the group.
A: See Azure Bicep documentation
- Check issues for existing Q&A
- Review architecture.md for technical details
- Open a new discussion or issue
- For security questions, see SECURITY.md