Issue title: Can't access secrets - "ResourceInitializationError: unable to pull secrets or registry auth..."
 Issue body: hi there! I'm enjoying Copilo, but am running into some issues. Have a pretty basic setup (pipeline, dockerfile, manifest, etc.) and started adding in SSM params to use as secrets, but can't get my cluster to update to a new version of a task now because I consistently get this message:

```ResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve secrets from ssm: service call has been retried 1 time...```

Haven't done any customization or anything to it, little perplexed. Was able to access secrets with a "dummy" version of the service up (just a lightweight HTTP echo server). Double checked that the param has the right tags and everything
 Comments: 
 Comment 0: Hi @markthethomas, 
I am seeing the same error, then I found this issue closed. Could you please let me know how you solved this ? Thank you in advance
Lamine 
 Comment 1: Hi @craquiest ! The issue was that a different AWS_PROFILE was used to create the secrets (https://github.com/aws/copilot-cli/issues/2095#issuecomment-805964170)

Do you know if the secrets are tagged? https://aws.github.io/copilot-cli/docs/developing/secrets/ Copilot can only access the secrets if the `copilot-application` and `copilot-environment` tags are present 
 Comment 2: Hi @efekarakus , thank you for the swift reply!  

Yes the secrets are tagged, I wrote a python script with boto3 to populate the secrets into ssm, using ssm_client.put_parameter() in a loop in order to avoid having to repeat the same awscli command for every secret. I made sure to add the tags in that function like this:

ssm.put_parameter(
            # Name=f"/{app_name}/{stage}/{k.upper()}",
            Name=f"{k.upper()}",
            Value=str(getattr(settings, k.lower())),
            Type='SecureString',
            Tags=[
                {
                    'Key': 'copilot-environment',
                    'Value': f"{stage}"
                },
                {
                    'Key': 'copilot-application',
                    'Value': f"{app_name}"
                },
            ],
        )

Maybe this has broken something? Do I need to revert to doing it by hand?
or does having slashes (/) in the name create issues? 

I also checked I used the same profile in the script to populate secrets than in the copilot env init command with --profile option. 

 Comment 3: That should be fine! I don't think having slashes should result into errors 🤔 

Would you mind sharing the `secrets` field in your manifest? and just to make sure was the service deploying fine before and it started breaking after integrating with secrets?
 Comment 4: Please find below. the secrets section of the manifest ( quite long) . Earlier I was setting them in the 'environment' secrets override section, under 'test' so I commented out the secrets section. Now I have reverted to just the secrets section.

I was testing this deployment back in november with these settings and it was working fine (besides a little issue on service discovery). Today, I started to test the deployment again as I am nearly done with the app development. Since November, the dockerfiles haven't changed, the secret list is basically the same, just a bit longer. Copilot went from version 0.7 to 1.4. Anything to do with Fargate moving to 1.4.0 maybe? 

secrets:                      # Pass secrets from AWS Systems Manager (SSM) Parameter Store.
#  GITHUB_TOKEN: GITHUB_TOKEN  # The key is the... of the SSM parameter.
  WELCOME: WELCOME
  SECRET_KEY: SECRET_KEY
  ALGORITHM: ALGORITHM
  TOKEN_EXP_MN: TOKEN_EXP_MN
  MONGO_HOST: MONGO_HOST
  MONGO_REPL_SET: MONGO_REPL_SET
  MONGO_DB_NAME: MONGO_DB_NAME
  MAX_POOL_SIZE: MAX_POOL_SIZE
  MIN_POOL_SIZE: MIN_POOL_SIZE
  USER_COLL: USER_COLL
  TONTINE_COLL: TONTINE_COLL
  ENROL_COLL: ENROL_COLL
  INVITE_COLL: INVITE_COLL
  VOTE_COLL: VOTE_COLL
  TRANSAC_COLL: TRANSAC_COLL
  LEG_COLL: LEG_COLL
  EVENT_COLL: EVENT_COLL
  EXTERNAL_COLL: EXTERNAL_COLL
  COMPOSE_PROJECT_NAME: COMPOSE_PROJECT_NAME
  REDIS_HOST: REDIS_HOST
  REDIS_PORT: REDIS_PORT
  QUEUE_NAME: QUEUE_NAME
  SMTP_USERNAME: SMTP_USERNAME
  SMTP_PASSWORD: SMTP_PASSWORD
  SMTP_SERVER: SMTP_SERVER
  SMTP_PORT: SMTP_PORT
  RESET_EMAIL_ADDRESS: RESET_EMAIL_ADDRESS
  ACTIVATE_EMAIL_ADDRESS: ACTIVATE_EMAIL_ADDRESS
  TONTINE_EMAIL_ADDRESS: TONTINE_EMAIL_ADDRESS
  SNS_SMS_URL: SNS_SMS_URL
  SNS_SMS_KEY: SNS_SMS_KEY
  INTECH_API_KEY: INTECH_API_KEY
  INTECH_BASE_URL: INTECH_BASE_URL
  INTECH_ACCOUNT_INFO: INTECH_ACCOUNT_INFO
  INTECH_TRANSAC_LIST: INTECH_TRANSAC_LIST
  INTECH_DO_TRANSAC: INTECH_DO_TRANSAC
  INTECH_TRANSAC_STATUS: INTECH_TRANSAC_STATUS
  TEGGI_FEE: TEGGI_FEE
  TRANSFER_FEE: TRANSFER_FEE
  WITHDRAWAL_FEE: WITHDRAWAL_FEE
  WITHDRAWAL_COST: WITHDRAWAL_COST

 Comment 5: ok! thanks for the info, the few things that I can see:
1. I don't know if this is a copy/paste issue but the fields under `secrets` are not indented.
2. Are all of these values defined in SSM parameter store like `GITHUB_TOKEN`? otherwise the deployment will fail 

 Comment 6: 1. the indent is a copy paste issue. It is indented (2 spaces) in the file. 
2. `GITHUB_TOKEN` is actually commented out, but it was creating a H1 header in the markdown after pasting so i took off the comment. Yes I just counted them (39) and compared side to side in SSM and the manifest. 

3. Let me paste again the first few lines: 
```
secrets:
  WELCOME: WELCOME
  SECRET_KEY: SECRET_KEY
  ALGORITHM: ALGORITHM
  TOKEN_EXP_MN: TOKEN_EXP_MN
  MONGO_HOST: MONGO_HOST
  MONGO_DB_NAME: MONGO_DB_NAME
  MAX_POOL_SIZE: MAX_POOL_SIZE
  MIN_POOL_SIZE: MIN_POOL_SIZE
```
 Comment 7: There was one set to 'None' so I deleted on both sides and started over the deployment, and it is working now for the 1st container. I'll keep going. Maybe setting them manually is not a bad idea after all, just to check one-by-one. Thanks a lot!
 Comment 8: awesome yay!
 Comment 9: @efekarakus Any chance copilot can somehow find out that we are pointing at a secret that doesn't exist/doesn't have the correct tags? I've just spend 3 hours trying to find out, until I found out I had a typo in one secret name :)
 Comment 10: Oh noooooo, that's a great suggestion! 🤔 

When implementing `secret init`, we can provide an output that can be safe to copy/paste directly to the manifest to avoid these typos.  
I also shared this info with our IDE team so that we can brainstorm ways of detecting invalid references in the manifest.
 Comment 11: > I also shared this info with our IDE team so that we can brainstorm ways of detecting invalid references in the manifest.

@efekarakus is there an issue tracking that idea of detecting invalid references in the manifest? I just ran into a similar issue where we had a secret that was defined in one environment but not the other, so when I copied the lines suggested by `copilot secret init` into our manifest, deploying to that one env failed. It took quite a while to determine it was because the secret doesn't exist there so AWS was throwing an error.
 Comment 12: Hi @codekitchen !

This feature is not on our short-term roadmap yet. If you are interested, here is our [roadmap](https://github.com/aws/copilot-cli/projects/2) and [this](https://github.com/aws/copilot-cli/projects/1) is our current sprint board. However, we are looking to provide a better experience for validating the secret reference! Once the feature goes into design phase, we could have the proposal available on GitHub for folks to see.

Thanks a ton for following up!!
{'source': 'GithubIssues', 'repo_name_with_owner': 'aws/copilot-cli', 'issue_id': 839140245, 'repo_stars': 2215.0}