AWS Scopes
Configure AWS discovery scope and verify supported read-only provider access.
AWS ScopesConfigure AWS discovery scope and verify supported read-only provider access.
Azure ScopesConfigure Azure subscription scope and supported connection validation.
Google Cloud ScopesConfigure Google Cloud scope with the authorized runtime or impersonation identity.
Read-Only VerificationTrack successful connector verification separately from configured scope.
ConfigureVerify
Use shared discovery identities and CMDB relationships across cloud planning, connection validation and FinOps governance.
What Connects Here
Explore in detailAzure Scopes
Configure Azure subscription scope and supported connection validation.
Google Cloud Scopes
Configure Google Cloud scope with the authorized runtime or impersonation identity.
Read-Only Verification
Track successful connector verification separately from configured scope.
Configure → Verify → Validate
Explore the details below, then bring your workflow, source data and questions to a guided conversation.
Built into the platform
The capabilities behind
the experience.
AWS scopes
Configure AWS discovery scope and verify supported read-only provider access.
Azure scopes
Configure Azure subscription scope and supported connection validation.
Google Cloud scopes
Configure Google Cloud scope with the authorized runtime or impersonation identity.
Read-only verification
Track successful connector verification separately from configured scope.
Plan validation
Distinguish local policy checks from provider validation and resource execution.
Billing evidence
Use recorded provider costs with explicit coverage and currency requirements.
Actual product view
Inside Cloud Foundation.
See the running demo environment. Features and records are subject to your role, configuration and integrations.
Connected by design
Context travels
with the work.
Service records, configuration items, people, locations and evidence share the same operational foundation. Move from investigation to the related asset, service or customer workflow with clear ownership.
Explore the platform architectureImplementation context
Features depend on enabled modules, configured roles, source data and supported integrations. Agree your implementation scope and acceptance criteria during discovery.
Who this is for
Cloud architects, integration administrators, identity engineers and FinOps data owners
A cloud foundation must align provider identity, discovery scope and billing coverage before teams rely on shared operational context. Configuration, successful read-only verification, local plan checks and resource execution must remain clearly distinguishable. An evaluation of Cloud Foundation should make those boundaries inspectable before the team relies on the operating view.
Illustrative walkthrough
Establish provider identity and evidence boundaries
A fictional enterprise establishes AWS, Azure and Google Cloud evaluation scopes. Its architects review the supported identities, discovery configuration and billing evidence, then test a structured plan while documenting that live creation is disabled in the demonstration deployment.
01Review provider identity and scope
Inspect AWS, Azure or Google Cloud scope configuration and the authorized provider identity, including runtime or impersonation identity where applicable to the supported connection. Configure AWS discovery scope and verify supported read-only provider access.
02Verify read-only connectivity
Review the connector verification outcome separately from configured scope, then inspect the confirmed discovery context reused by the shared CMDB and cloud workspace. Configure Google Cloud scope with the authorized runtime or impersonation identity.
03Qualify plans and billing
Separate local policy validation from provider validation and execution, and confirm currency and coverage requirements before recorded provider costs inform a FinOps review. Distinguish local policy checks from provider validation and resource execution.
An architecture reviewer should see the configured provider identity, successful read-only verification evidence, confirmed inventory and a qualified billing period without treating one state as proof of the others. Use demonstration records and preserve the applicable reporting scope.
Explore the platform
See Qintorava in action.
Open a workspace for a closer look.
Prepare the evaluation
Bring the right inputs.
What to prepare
- Provider scope and authorized identity
- Discovery configuration and verification evidence
- Billing coverage and currency records
Candidate measures to agree
- Provider scopes independently verified
- Inventory linked to confirmed source identity
- Billing periods meeting coverage rules
These are evaluation criteria, not promised outcomes. Agree the baseline, scope, source coverage and acceptance method with the responsible owners before drawing conclusions.
Questions for this topic
Get the details.
Are the three providers configured identically?
No. AWS, Azure and Google Cloud require their supported scopes and identities, and the evaluator should inspect the actual connector permissions and verification result for each provider.
Does passing local validation create infrastructure?
No. Local policy checks, provider validation and resource execution are separate states; live resource creation is disabled by policy in the current demonstration deployment.
Can cloud costs be interpreted without coverage?
No. Recorded billing requires explicit completeness and currency qualification, so missing or incomplete data should not be interpreted as zero cost or used as a verified savings baseline.
Your next operating chapter
See what connects
when everything connects.
Bring one workflow, one service challenge or one part of your estate. We’ll show you where Qintorava fits.