1. 
   We’re deploying Ansible Automation Platform 2.6 on a ROSA HCP (STS) using the AAP Operator and OpenShift GitOps (Argo CD). Our topology is external Postgres (RDS), external Redis (ElastiCache), and Automation Hub using S3 as external object storage. We are aiming to use AWS Pod Identity / IRSA (service account annotation) for S3 authentication, as the AAP enterprise topology documentation states this approach is tested (“HTTPS only accessible through AWS Role assigned to Automation Hub ServiceAccount at runtime by using AWS Pod Identity”): https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/tested_deployment_models/ocp-topologies#tested_system_configurations_4

2. We’ve run into an issue that makes us question whether this is a supported configuration, or if there is an operator-supported mechanism we’re missing:
   • We created/managed the Hub runtime ServiceAccount via GitOps with the expected IRSA annotation:
   • ServiceAccount: ansible-automation-platform/automation-platform-hub
   • Annotation: eks.amazonaws.com/role-arn: arn:aws:iam::751663800021:role/rosa-tools-staging-irsa-s3-ansible
   • ArgoCD sync-wave: -20
   • Shortly after Argo applies this ServiceAccount, it is modified and the IRSA annotation is removed. The ServiceAccount ends up containing operator labels (e.g. app.kubernetes.io/managed-by: automationhub-operator) and no longer has the eks.amazonaws.com/role-arn annotation. This appears to be the operator reconciling the ServiceAccount (it has an ownerReference to the AutomationHub CR: automationhub.ansible.com/v1beta1, name automation-platform-hub).
   • The net effect is that our GitOps-applied ServiceAccount annotation does not persist, and the Hub pods cannot reliably use AWS Pod Identity at runtime.
   • We also noticed that the Hub operator initially stalled at “Checking s3 storage configurations” until we added s3-access-key-id and s3-secret-access-key keys (set to placeholder values like "unused") into the referenced S3 secret, after which Hub pods began deploying. This makes us unsure whether “IRSA-only” (no static keys) is truly supported by the operator, or whether the operator currently requires those keys to exist for validation.

In addition, on our cluster the AutomationHub CRD does not appear to expose a field like service_account_annotations (we only see ingress_annotations and service_annotations), so we don’t see an obvious operator-supported way to persist the required ServiceAccount role annotation declaratively.