Landing Zone Customer Guidance

Landing Zone Customer Guidance

Overview

Use this skill before recommending repo paths, blueprints, or config files for customer-use landing zone requests.

AGENTS.md is the canonical policy source for the customer safety gate, discovery sequence, unsupported-resource handling, artifact placement, and deployment defaults. This skill is the activation checklist for applying those rules in customer conversations.

Core principle: guide the customer through the required design decisions one at a time in plain language, then map answers back to repo terminology only after the customer understands the choice being made.

When to Use

• A customer asks for landing zone design, deployment, or recommendation help
• The request is outcome-first, such as "I want landing zone to run OKE"
• The customer may not know repository or Blueprint Factory terms
• You need to determine whether the standard published path or the Blueprint Factory fits

Do not use this skill for repo-development work. Once the request is clearly on the Blueprint Factory path and the customer decisions are already known, switch to landing-zone-config.

Workflow

1. For customer-use and ambiguous-or-mixed requests, show the exact warning from AGENTS.md and wait for explicit acceptance.
2. After acceptance, give one short orientation sentence and ask only the first missing question.
3. Follow the discovery order from AGENTS.md. The items are a decision sequence, not a single questionnaire.
4. Before asking the customer to choose between repo labels, explain those options in customer language and recommend a default when the repo has one.
5. After each answer, summarize what is now known in one sentence, then ask the next missing question.
6. After the hub family is known and before discussing public exposure, load balancers, or OKE ingress, inspect the matching hub guide or runtime artifacts first so you know what load balancer pattern already exists.
7. Before recommending deployment artifacts or config-mode generation, ask the customer to choose CIS Level 1 or CIS Level 2. Explain that CIS1 is the less complex baseline; recommend CIS2 for its stricter security posture, while making clear that generated CIS2 configurations require customer-managed encryption keys for applicable resources and therefore add Vault, key, IAM, deployment-ordering, rotation, recovery, and workload-lifecycle complexity. For OKE, mention Kubernetes-secret and worker boot-volume CMEKs specifically. Do not silently accept the generator's CIS2 default.
8. Only after all required decisions are known, including target region, any non-oc1 realm requirement, and the explicit CIS-level choice, may you recommend a published runtime path, a workload extension path, or config-mode generation.
9. When deployment execution comes up, use the secure delivery defaults from AGENTS.md: prefer ORM with customer-controlled private Object Storage and the Orchestrator rms-facade; keep Terraform CLI, customer-controlled CI/CD, or approved private GitHub as alternatives. Read references/orm-bucket-deployment.md before giving exact deployment or staged-update steps.
10. If the conversation turns into Orchestrator or Resource Manager runtime troubleshooting, use oci-lz-orchestrator-contract-advisor as a supporting verifier after this customer flow has established the deployment context.

Unsupported Requirements

If the selected published path, Blueprint Factory, or workload extension does not support a requested resource, service, topology, or behavior:

• Say plainly that it is not supported by the Landing Zone framework today.
• Do not invent config keys, edit generated JSON, or imply the framework can create it.
• Split the answer into "Generated by the landing zone" and "Manual post-deployment configuration required."
• Prepare supported prerequisites where possible, and keep manual lifecycle, drift, and compliance ownership explicit.
• For external connectivity such as Site-to-Site VPN or FastConnect, verify the selected repo path first and consult official OCI docs for service-specific manual steps.

Discovery Reminders

• Always default to One-OE; do not ask who operates the landing zone or ask the customer to choose a landing zone family.
• After establishing the One-OE baseline, ask: Do you want to deploy a Disaster Recovery (DR) region? If yes, ask for the home region first and the DR region next, one question at a time. Set dr_region on the complete home config for the DR Object Storage grant; the regional config has its own region metadata. The published Frankfurt/Amsterdam pair is an example. Explain that CIS2 deploys Vaults and keys in both regions, while matching compartment, governance, and extension IAM prerequisites stay home-owned.
• Ask in root AGENTS.md order: One-OE baseline, DR decision, region and optional realm, environments, workloads, firewall, hub model, network-producing extension scope and sizing before CIDR allocation, CIDRs, then the explicit CIS-level choice.
• Ask for the target OCI region early. Explain that realm defaults to oc1 public cloud when omitted, and ask for realm only when a non-public or sovereign deployment may apply, such as oc19 EU Sovereign Cloud.
• Explain each decision in customer language before using repo terms such as One-OE, Hub A, platform, project, or project_network.
• During network-scope sizing, ask whether project workloads can use shared subnets or require project-dedicated subnet allocations. Recommend shared subnets unless separate CIDR allocation or lifecycle management is required: shared subnets use address space more efficiently, while dedicated subnets commonly leave capacity stranded in lightly used per-project ranges.
• Before asking for that choice, explain that dedicated allocation is not an IAM boundary: principals with subnet permissions in the environment network compartment may use any of its subnets. Also explain that same-subnet traffic never traverses the hub firewall and must be controlled with NSGs and security lists.
• Use a professional, outcome-based question such as: “Shared subnets are the recommended default because they use the allocated address space efficiently. Do any projects need separately allocated subnet CIDRs for operational reasons, or can their workloads use shared subnets with NSGs and security lists for segmentation? Dedicated allocation does not provide IAM isolation.” Ask it as the next single discovery question, not as part of a bulk questionnaire.
• Do not propose concrete CIDRs until the root AGENTS.md network-scope gate is complete; use extension guides such as OKE or ExaCS only for extension-specific sizing inputs.

OKE-Specific Guardrails

• If the customer only says they want OKE, do not jump to oke_simple, single-stack vs multi-stack, or config snippets.
• Do not assume OKE means projects are required.
• Do not assume an environment needs project_network unless the intended topology requires a spoke VCN.
• Explain OCI CIDRs separately from Kubernetes pod and service CIDRs; use gen/workload-extensions/oke/AGENTS.md for repo-specific OKE networking semantics.
• Do not treat non-production as an automatic reason to recommend a no-firewall hub. Firewall-based designs are still the recommended default unless the customer explicitly accepts the tradeoff for a simpler non-production layout.
• When the customer asks for public access, do not assume the chosen hub needs a brand-new public load balancer design. Check the selected hub guide or runtime artifacts first; in the One-OE one-stack runtime, each hub family already includes a public load balancer example with placeholder backends.

RPC Requests

• For explicit RPC, Remote Peering Connection, inter-region OCI VCN peering, same-tenancy remote peering, or cross-tenancy remote peering requests, complete the standard landing zone discovery sequence and then use landing-zone-config.
• Model RPC through Blueprint Factory configuration with top-level remote_peering_connections.
• Read gen/addons/oci-x-rpc/AGENTS.md before collecting RPC-specific values or recommending a deployment sequence.
• For more than two Landing Zones, map the tenancy/region connection graph first. Identify every requested RPC edge and the acceptor/requestor role on each edge, then complete One-OE discovery for each Landing Zone.
• Ask whether each connection is only for access to the peer Landing Zone or whether traffic must transit through that peer to another connected Landing Zone. Do not infer transitive routing from "connect these tenancies."
• After the normal One-OE environment, workload, hub, and CIDR decisions are known, establish whether the peering is same-tenancy or cross-tenancy and which side is acceptor versus requestor.
• Treat environment names and counts as customer-defined. Derive local routed VCNs from the selected environments and platforms; do not assume a fixed prod/preprod/UAT topology.
• Collect the peer region and all reviewed remote routable CIDRs for each side. A side cannot infer the other side's CIDRs from its own config.
• For the requestor, collect the acceptor RPC OCID or approved orchestrator dependency key. For cross tenancy, also collect both tenancy OCIDs and the requestor network-administrator group OCID.
• Explain that One-OE continues to provide governance and baseline IAM. Same-tenancy RPC adds only network changes; cross-tenancy RPC adds the minimum peering policy surface.

Deployment Reference

• For the preferred ORM + private Object Storage workflow, staged file replacement, Plan/Apply controls, monitoring, and handoff requirements, read references/orm-bucket-deployment.md.
• Verify exact Resource Manager fields against the pinned Orchestrator ref; do not copy values from an unrelated stack, bucket, namespace, or tenancy.
• This skill is advisory only. Explain the deployment procedure and prepare customer-executable commands or UI steps, but do not upload objects, create or update ORM stacks, run Plan/Apply/Destroy jobs, or start deployment monitoring. A deployment action requires a separate explicit user request and must be handled outside this skill workflow with its own authorization checks.

ExaDB-D / ExaCS-Specific Guardrails

• If the customer says ExaDB-D, Exadata Database Service on Dedicated Infrastructure, Autonomous Database Dedicated, ExaCS, VMC, or AVMC, complete the base landing-zone discovery first.
• Ask whether Exadata infrastructure is shared across environments or dedicated per environment.
• Ask whether the customer will use Autonomous Database Dedicated on AVMCs, regular Exadata Database Service on VMCs, or both.
• Ask whether AVMCs/VMCs are shared or environment-specific. Explain that AVMC/VMC placement requires an ExaCS network with database and backup subnets.
• For Autonomous Database Dedicated, ask which environments and projects need project DB tiers; do not add them for regular Exadata Database Service-only designs.
• Use gen/workload-extensions/exacs/AGENTS.md for extension-specific placement mapping before authoring config.

ExaDB-C@C / ExaCC-Specific Guardrails

• Complete the base landing-zone discovery first before discussing ExaDB-C@C artifacts.
• Use the ExaDB-C@C generator guide under gen/workload-extensions/exacc/ for extension-specific semantics before authoring config or reviewing published snapshots.
• Treat Orchestrator dependency/output questions as contract checks, not as permission to skip customer discovery.