Lab: review a MicroBank cloud adapter

This is a design lab with inspected inputs

The output is a compatibility matrix and an implementation decision, not a running EKS/GKE cluster. That still requires concrete work: inspect the code's messaging and credential assumptions, then trace each dependency to a target mechanism. A generic list of cloud product names does not answer those questions.

Take one example all the way through: Ledger uses an AWS queue client. Identify the endpoint configuration and credential construction in your selected source. For a new target, name the intended compatible API, how credentials reach the process, what permissions they grant and how the private network reaches the destination. If any part requires a code change, record that change rather than treating it as an overlay setting.

Use the local contract as your evidence source. A row marked unknown is a useful finding; replacing it with a plausible service name would hide the work still needed.

Outcome and limits

Choose EKS or GKE and produce an adapter decision record, dependency matrix, infrastructure ownership plan, and acceptance and teardown checklist. This lab's required stage is a design and read-only review. It does not provide a complete cluster provisioning module or claim either cloud deployment is implemented. Live execution is a later, separately costed extension using the selected provider's current guides.

1. Inspect the application's cloud coupling

From the MicroBank checkout, identify client construction and endpoint configuration:

rg -n 'StaticCredentialsProvider|AwsBasicCredentials|endpointOverride|AWS_ENDPOINT_URL|SNS_TOPIC|SQS_QUEUE' \
  services infra/study

Read the matching source, excluding private runtime files. The inspected Ledger client explicitly constructs static credentials. Before using EKS Pod Identity, adapt and test its credential provider strategy and conditional local endpoint handling. Preserve the local emulator mode deliberately. A ServiceAccount annotation does not change the Java code's chosen credentials.

For GKE, decide how SNS/SQS is supplied. Workload Identity Federation for GKE authorizes Google API access; it is not an automatic SNS/SQS credential. Replacing messaging with Pub/Sub needs application semantics and failure tests, including envelope handling, retries, duplicate delivery, and settlement behavior.

2. Complete the adapter matrix

Save platform/targets/decision.md:

Record unknowns explicitly. Identify dependencies that prevent a real deployment. With MicroBank's current backend authorization gaps, the target remains private and uses only synthetic data.

3. Design the provisioning boundary

Use one explicit Terraform root/backend for the selected target and reuse a reviewed module interface. Keep the existing LocalStack state separate. State, saved plans, cloud credentials, and secret material must not enter the public repository or portal catalog.

Define stable non-secret outputs for the configuration layer: target name, namespace contract, dependency endpoints, and resource identities. Do not make Terraform and Argo CD both own the same application Deployment. Keep the workload overlay separate from cluster lifecycle and retained data.

If you have already implemented the selected root configuration, validate and plan it under the intended credentials, then review the exact saved plan. If the root configuration is not implemented yet, record that work as pending; planning requires actual configuration.

4. Review readiness for an optional live session

Require the application identity changes and tests, image publication, private access, dependency implementation, reviewed infrastructure plan, cost decision, and teardown ownership before applying anything. Then use the provider's official target setup and identity guides, recording every selected version.

During a live session, verify intended and denied permissions, resolve and connect to dependencies, deploy one target profile, inspect actual runtime image identity, and perform the agreed bounded acceptance check. Do not install the Advanced DevOps periodic synthetic CronJob or failure runner. Keep cloud simulation/load generation outside this course's local-only test policy.

5. Define teardown before starting

Remove workload ingress/load-balancer resources while the controllers needed to clean them up are still running. Handle persistent data according to the retention decision. Review the Terraform destroy plan for the resources it owns, then inspect provider inventory for retained disks, addresses, snapshots, logs, registries, and network services.

Checkpoint

Explain exactly which adapter steps are designed, implemented, planned, or executed. Completing the design review finishes the required stage of this lab. Live deployment remains a separate, unverified step. Only mark a target verified after retaining real deployment, access, recovery, and cleanup evidence.

Review the decision with a learner's questions

Could someone explain why this target was chosen, which dependencies remain unresolved, and what must be tested before a live run? Could they identify all resources that might remain after cleanup? If not, refine those rows before provisioning.

A cloud plan requires real target configuration and credentials; the course does not supply a validated EKS/GKE provisioning module here. Keep the portal capstone on the working local target while that optional implementation remains separate.

Sources

EKS getting started↗, EKS Pod Identity↗, GKE workload identity↗, AWS SDK credential chain↗, Terraform module composition↗.